Expose typed Jev judgments to MCP agents

01 · Role in the system

What Jev does here

Jev provides the bounded Choice, Score, and Noul answers behind six MCP tools. The server validates requests, applies configurable budgets and retry policy, adds abstention to matching, and returns a stable structured envelope. Agent clients receive typed values rather than prose, while consequential authorization decisions remain outside this screening layer.

One server, six tools, one judgment engine underneath

The server's surface is deliberately boring: six MCP tools covering classification, scoring, checking, matching, screening, and free-form typed questions. Each tool validates its request locally, applies configurable budgets and a retry policy, and only then forwards a bounded question to Jev. Results return in a stable structured envelope, so an agent client parses values, such as an enum, a score, or a match verdict, instead of free text that has to be re-parsed and re-validated on every call.

The layering is the reusable idea. Agents built on any MCP-compatible runtime can add a decision layer without changing their prompts, because the server, not the client, owns request hygiene: schema validation, budgets, retries, and abstention behavior in matching. When evidence is thin, the matching tool returns an explicit no-match rather than forcing a guess, which keeps downstream logic deterministic even when the model is uncertain.

Screening is not a security boundary

The claim this record refuses to make is that Jev scores can gate authorization. Confidence values are request-level judgments, not correctness guarantees, and the record states the boundary plainly: screening is not a security or authorization boundary. Consequential authorization decisions stay in code above this layer, and any integration that copies this pattern should keep the same split, treating tool results as triage signals rather than access-control verdicts.

The published measurements also carry an asterisk the directory preserves: they were produced with one early-access key against a limited field-service data set, which is why this record lists no performance number. What the artifact does demonstrate is integration shape: where the typed layer sits, what stays in code, and how downstream agents consume typed values without prompt engineering on their side of the interface.

What the envelope buys agent builders

Because every tool returns the same structured envelope, client-side handling collapses to a few deterministic branches: use the value, retry within policy, or surface the abstention to the caller. There is no prompt drift to manage and no JSON repair path on the client, because the server is the only component that talks to the model. If TypeSafe updates the underlying model, the client contract holds for as long as the envelope does, which is the property that makes this worth wrapping in a protocol at all.

The budget layer deserves a note from anyone copying the design. Rate and cost control live at the server, so one misbehaving agent cannot turn into an unbounded bill, and retries are applied where the question is formed rather than where the answer is consumed. In a multi-agent deployment that is the difference between a bounded component and a shared liability, and it requires no trust in the scores themselves: confidence arrives with the value, and the limitations are part of the published interface rather than a footnote in an issue tracker.

A third benefit shows up in review and auditing. When judgment calls funnel through one server, there is exactly one place to understand what gets asked and how budgets are spent, instead of that logic being scattered across every agent that ever wrapped a prompt. The audit surface shrinks accordingly: the six tool definitions, the budget configuration, and the retry policy are all published in the repository, so a reviewer can read the whole judgment pathway in one place. That is precisely what this directory grades as E2, an inspectable public artifact, rather than a claim that has to be taken on faith.

02 · Control boundary

Where Jev sits

MCP tool calls become validated Jev requests; the server returns stable structured results and keeps policy in code.

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

• Screening is not a security or authorization boundary, and confidence is not correctness.
• Published measurements come from one early-access key and a limited field-service data set.

04 · Attribution

Public sources

This is a Community record: the project was published by a third-party community author.

• blakestone-x ↗Community · github · public · checked 2026-09-18