An MCP server that exposes only tools leaves the judgment to the caller. The agent still has to decide which tool fits, whether the call is safe, and what to do with a result it does not understand. A decision server exposes that judgment directly: typed questions in, calibrated answers out, with no action attached.
The interface should be a judgment
The cleanest decision server has one tool and a narrow contract. Typesafe MCP exposes a single evaluate tool for noul, choice, and score questions. It ships as one static Go binary, registers itself with Claude Code, Claude Desktop, and Codex in one command, retries 429 and 529 with exponential backoff, applies a 60-second timeout and a 16 MiB response cap, and can score up to 500 records in one call. It is effectively a thin wrapper around Jev's REST API, and that is the point: the interface is the judgment, not a workflow.
Glama's Jev Decision MCP takes the same shape further into minimalism. One read-only tool, jev_decide; choice takes 1–255 named options, score rates 2–10 ordered levels with a 0-based score, and noul returns a 0–1 probability. It batches independent questions in one call and preserves question IDs. Questions in a batch cannot see each other's answers. It never executes an action.
Jev Decision Layer for Cursor ships four advisory tools, each building exactly one Choice question and returning a decision. The README states that nothing is ever executed. That constraint is worth copying: a decision server that also acts is two products with one permission model.
Batch independent questions and preserve IDs
Batching is not just a latency trick. It changes what the caller has to reason about. Glama's server keeps question IDs stable across a batch, so the caller can map answers back without guessing from order. Each question is independent, which means a batch is safe only when the questions do not depend on each other's answers. If B depends on A, send them in separate calls.
Jev MCP shows what a larger surface looks like. It ships nine tools (jev_step, jev_coding_loop, jev_tool_route, jev_review, jev_verify, jev_gate, jev_screen, jev_rank, and jev_evaluate) with a prepared-call router that accepts at most 32 candidates, rank handling up to 5,000 candidates at no more than 250 options per upstream call, and a state-plus-questions budget of an estimated 64,000 tokens. Calls default to a 30-second deadline. The limits are part of the contract: over-budget questions are rejected rather than silently truncated.
The catalog is honest about the gap. Jev MCP's README says live quality and cost savings have not been measured, and JEV_MCP_MOCK=1 is for tests and demos rather than production. The batching and routing are structural; the savings are not yet evidence.
Name the action, or leave it to the caller
There are two defensible designs. The first returns probabilities and lets the caller decide. Glama's server does this: thresholds, escalation, and action execution stay outside the model. The second returns an action label alongside the numbers. Jev MCP returns auto, review, or escalate with token usage, and incomplete context never permits auto.
| Server | Surface | Returns | Executes? | Notable limit |
|---|---|---|---|---|
| Typesafe MCP | One evaluate tool | Noul, choice, score answers | No | 500 records per call; 16 MiB response cap |
| Glama Jev Decision MCP | One jev_decide tool | Answers and usage | No | 1–255 options; 2–10 score levels |
| Jev MCP | Nine tools | Typed answers plus action | No | 64k token budget; 32-candidate router |
| OpenRouter Jev MCP | Five tools | Checks, classifications, scores | No | Alpha OpenRouter endpoint |
An action label is only useful if code treats it as advice and keeps its own policy floor. A probability is only useful if the caller has a threshold and a human path. The server's job is to make the judgment legible; the application's job is to decide.
Failure semantics matter more than tool count
OpenRouter Jev MCP is a good stress test because it depends on an alpha endpoint. Five tools cover yes/no checks, classification, scoring, multi-question evaluation, and health. It retries transient HTTP codes up to three attempts with exponential backoff from 0.25 seconds, enforces a 20-second network deadline, and allows at most eight requests in flight per instance. Malformed JSON, missing answers, and invalid values produce structured errors; failures are treated as no judgment, not as a negative verdict. Diagnostics log to a local state directory with a 20 MiB cap and 24-hour retention, and secret filtering is best effort.
That last detail matters. A decision server that logs state is a data processor, and "best effort" is not a retention policy. Read the log path before you point it at production traffic.
The smaller servers have simpler failure contracts. Typesafe MCP retries 429 and 529 and caps responses. Glama's server starts without a key so the client can discover the tool, but decision calls return MISSING_API_KEY; it does not invent an answer. OpenRouter's server does not accept native TypeSafe keys at all. These are not edge cases. They are the first things to test.
Discovery and dispatch
A dispatcher is a different product from a decision server, and it is easy to confuse the two. jev-mcp-dispatcher discovers a server's tools at runtime with list_tools() and routes plain-language commands using only Jev Choice and Noul, with no general-purpose LLM calls. Tool selection is a Choice over live tool names and descriptions. Non-enum arguments use a per-word Noul pass, and values are exact substrings copied from the command.
The limits are severe: only string, integer, number, boolean, and enum parameters; values must appear literally; optional parameters are still force-extracted; there is no confidence gating, retry, or multi-turn clarification; two same-typed numbers can claim the same word. It is a proof of concept, not a router you should put in front of an arbitrary MCP catalog.
MCP Router is the production-shaped version. It discovers, catalogs, classifies, and deduplicates servers and tools, exposes each agent only the small authorized subset it needs, and runs routing as System One Choice, Score, or Noul questions. The decision engine is pluggable: Laya, a 421M open-weight Jev-compatible model under Apache 2.0, at the edge; a hosted endpoint; or Azure OpenAI. Retrieval uses Postgres with pgvector plus full-text search, fused with reciprocal-rank fusion. A deterministic, deny-by-default policy engine and execution manager gate everything, and model scores are relevance data that can never widen access. Exposure budgets can be lowered per request but never raised. The README publishes no benchmarks, and the stack assumes Postgres with pgvector.
That is the right division: the model ranks, the policy engine authorizes, and the caller executes.
What to build
- Expose judgment, not side effects. If the server acts, it needs the same permission design as any other tool.
- Keep question IDs stable and batch only independent questions.
- Publish limits: option counts, score levels, token budgets, timeouts, and what happens over budget.
- Return typed errors, never a fabricated answer. Treat provider failure as no judgment.
- Leave thresholds and actions in the caller, or return an action label that is explicitly advisory.
- Log enough to audit the decision, and define retention before collecting state.
The MCP server is a transport, not a policy. Agent Skill can teach an agent how to structure the questions, but it is guidance, not a runtime library. For the routing side, MCP Tool Routing covers how tool choice becomes a decision; Jev in Coding Agents shows the client side; and One Request, Many Questions is the batching background. Build the server so a decision model is useful without being trusted.
