jev-mcp (burnigtm)

How we reviewed this: we ran its 141 tests in Docker offline and drove all nine tools over stdio MCP against a local stand-in, capturing each request. We made no Jev calls.

What it does

Nine tools and eight prompt packs, and the server states its own boundary in the tool description: “This server never executes the selected call.” It returns a handoff and a call object; the host decides.

Three things here are better than the field:

Redaction that actually redacts. Tool arguments are reduced to their shape before anything leaves:

{"id":"c1","name":"Read","description":"Read a file from disk","effect":"read_only",
 "argument_shape":{"type":"object","keys":["file_path","api_token"],"extra_keys":0}}

We passed {"file_path": "/etc/shadow", "api_token": "sk-live-SECRET-VALUE-12345"}. Neither value appears in the captured request. Nothing else in this batch does this.

Failing closed, with a floor. Any upstream error produces an error result with no call attached. And the dispatch threshold cannot be lowered: set auto_accept to 0.1 and Math.max(0.8, autoAccept) still requires 0.8. Destructive and external-write effects always require review.

Budgets that are honest. When the context is truncated to fit, the response says so — and truncation permanently disqualifies automatic approval, rather than quietly proceeding on a partial view.

The redaction is also the problem

Because values never leave, the model answering “should this call run now?” is looking at a name, a sanitised description and a list of key names. We built a candidate whose description read “Remove stale build artifacts from the project directory”, whose effect was read_only, whose three trust booleans were true, and whose one argument was rm -rf / --no-preserve-root. The stand-in approved it and the server returned:

{"action":"auto","handoff":"execute_tool",
 "call":{"candidate_id":"cleanup","name":"Bash",
         "arguments":{"command":"rm -rf / --no-preserve-root"}}}

The model approved a command it was never shown.

The deeper issue is the trust boundary. The schema labels authorized, schema_valid and effect as “trusted host facts”, and the eligibility check does:

if (candidate.authorized !== true) reasons.push("not_authorized");

But MCP tool inputs are written by the model, not by host code. The server has no way to tell a genuine host assertion from one the model made up. The README’s promise of “validated host facts” means, in the code, “the caller set these to true”.

This is arguably the intended design — the host is the trust boundary, and the server says it never executes — but the wording claims a guarantee the code cannot provide.

Verdict

The most carefully built MCP server we have reviewed: real limits, real fail-closed behaviour, a __proto__ scan, honest coverage reporting, and a README that says “live quality and cost savings have not been measured”.

Two practical notes. The privacy design means whoever calls it must do the validating, because the judge cannot. And it is not published: jev-mcp on npm is a different author’s project, so clone it rather than installing by name.

Compare Jev MCP for a toolbox and jev-eval-mcp for the eval-first take.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 20, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.