Community · E2 · artifact verified
Expose Jev decisions to MCP clients
JDE, the Jev Decision Engine, wraps Jev as an MCP server: any MCP client - Claude Code, Cursor, your own agent - gets typed decision tools, with a policy layer, a decision ledger, and recorded evals comparing the hosted jev-1.13.0 against local alternatives.
01 · Role in the system
What Jev does here
The engine's judge module speaks the systemone protocol (hosted TypeSafe Jev by default, a local Jeb behind jeb serve or AINode as alternates), and the MCP layer exposes that judgment as tools any MCP client can call: ask a choice, request a score, gate an action. A policy module decides what may be asked and what may execute, and a ledger records every decision so behavior is auditable after the fact. The eval directory carries a recorded comparison run from 2026-09-29 between hosted jev-1.13.0 and local backends, plus MCP server tests - infrastructure with receipts rather than a demo.
02 · Control boundary
Where Jev sits
Jev as a decision tool behind MCP: the judge module speaks systemone with pluggable backends, a policy layer bounds what may execute, a ledger audits every verdict, and MCP clients anywhere consume it as ordinary tools.
Code owns the loop, permissions, thresholds, validation, and side effects. Jev owns only the bounded judgments described above.
03 · Known limits
What this evidence does not prove
- MCP transport only; non-MCP clients use the underlying modules directly.
- The 2026-09-29 eval comparison is recorded by the author.
- 2 stars; policy coverage is the author's set.
04 · Attribution
Public sources
This is a Community record: the project was published by a third-party community author.
- Titanium-Devops ↗Community · github · public · checked 2026-10-03