jev-mcp exposes twelve typed judgment tools to agents over MCP

Twelve tools and the problem they solve

The README frames the project in one line: fast, cheap, typed judgments from TypeSafe's Jev model, as MCP tools. The reasoning is about where a frontier model is the wrong tool. The README says each judgment comes back typed, with probabilities and for most tools a confidence score, in roughly 150 to 500 ms, for a fraction of a cent, and it names the category this replaces: the cheap mechanical checks agents otherwise skip, because a frontier model is too slow to run on every page, claim, or candidate list. The twelve tools are named and their jobs are specific. jev_verify checks claims against evidence, and jev_screen judges content before it enters context, which the use cases describe as screening a fetched page for injected instructions and skipping pages with nothing to say. jev_noul returns a calibrated probability for a stated proposition, jev_find picks the best candidate by meaning, and jev_rerank scores and sorts every candidate. jev_classify batch-assigns items to classes, jev_decide settles bounded alternatives, jev_compare judges how two passages relate, jev_extract pulls field values with regex plus judgment, and jev_audit audits extracted values against their source before they are trusted. The last two are the ones aimed at a coding agent: jev_review scores a proposed diff before the task is called done, and jev_gate reviews a patch and verifies completion claims in one call.

Running it locally over stdio

The server requires Node.js 22 or newer and an API key for a Jev provider, with TypeSafe direct at console.typesafe.ai/settings/keys as the default and alternatives listed under Configuration. From npm the whole server is one command.

npx -y @jkudish/jev-mcp

Each client then registers that command as an MCP server. For Claude Code the README gives a single add command.

claude mcp add jev -- npx -y @jkudish/jev-mcp

Amp uses the same shape with its own client name.

amp mcp add jev -- npx -y @jkudish/jev-mcp

For Codex the configuration goes into the config.toml file, and the server is described by a command and an argument list.

[mcp_servers.jev]
command = "npx"
args = ["-y", "@jkudish/jev-mcp"]

OpenCode expects an mcp entry with a local type and a command array, and passes the provider key through an environment object.

{
  "mcp": {
    "jev": {
      "type": "local",
      "command": ["npx", "-y", "@jkudish/jev-mcp"],
      "environment": { "TYPESAFE_API_KEY": "ts_..." }
    }
  }
}

Any other MCP client uses the conventional mcpServers shape with a command, an args array and an env object.

{
  "mcpServers": {
    "jev": {
      "command": "npx",
      "args": ["-y", "@jkudish/jev-mcp"],
      "env": { "TYPESAFE_API_KEY": "ts_..." }
    }
  }
}

The README also offers a paste-in prompt so a coding agent can perform the whole registration itself, checking whether TYPESAFE_API_KEY is already set in the server environment and walking through setting it up without pasting the key into the chat.

The environment variable that silently disappears

One operational warning is worth reading twice. Some MCP clients filter the environment before spawning servers, which silently drops TYPESAFE_API_KEY, and if the server reports a missing key you pass it explicitly as shown in the configuration above. This is the kind of failure that looks like a broken install rather than a configuration quirk, because the client starts the process, the process starts, and only then does the key turn out to be absent. The second half of the same point is that the key is not the only secret in play in HTTP mode. If you host the server for a team or a remote agent, the auth token and the provider key are separate concerns: the provider key pays for the judgments, and the auth token protects the endpoint that spends it.

HTTP mode for a shared server

Stdio is the default, and to host one shared server for a team or a remote agent the README says to run it in stateless HTTP mode with an auth token and a provider key in the environment.

JEV_MCP_AUTH_TOKEN="$(openssl rand -hex 32)" TYPESAFE_API_KEY=ts_... npx -y @jkudish/jev-mcp --http

It listens on PORT, default 8080, serves MCP at /mcp and has a health check at /health. HOST defaults to 127.0.0.1, so setting HOST=0.0.0.0 explicitly is what serves beyond your own machine. The README states that --http and JEV_MCP_TRANSPORT=http are equivalent, which is the detail that matters for containers and service units, since a deployment can select the transport through the environment without argv. It speaks MCP 2026-07-28 and falls back to stateless serving for 2025-era clients, so it keeps no sessions and scales behind any load balancer. Clients authenticate with a bearer token.

claude mcp add --transport http jev https://jev.example.com/mcp --header "Authorization: Bearer $JEV_MCP_AUTH_TOKEN"

Every call spends your Jev key, so JEV_MCP_AUTH_TOKEN is required unless HOST is loopback.

URL tokens, TLS and the limits at the edge

Some clients can only be configured with a URL and cannot send headers, such as claude.ai custom connectors, and the README describes a second authentication form for them. Setting JEV_MCP_PATH_TOKEN=1 and giving the client https://jev.example.com/mcp/<token> makes the server compare that segment raw and in constant time against JEV_MCP_AUTH_TOKEN, and the server refuses to start unless the token is URL-safe, allowing letters, digits and the characters . _ - ~. The guidance is a dedicated high entropy token, for example one from openssl rand -hex 32, served over HTTPS only, and treating the whole URL as the secret: redact full paths from proxy and access logs, keep the URL out of shared configs, and avoid redirects of it. Rotate the token if it escapes. It is off by default because a URL is easier to leak than a header, and the header form keeps working alongside it.

The server itself speaks plain HTTP, so TLS is terminated at a reverse proxy or load balancer before anything beyond loopback, and connection limits and request rate limits belong at that ingress. The process bounds admitted /mcp requests through JEV_MCP_MAX_CONCURRENCY, default 16, with excess shed with a 429, and caps request bodies at 4 MiB, but it does not limit sockets waiting to finish headers or repeatedly rejected requests. That division of responsibility is deliberate and worth understanding: the application level protections are in the server, the socket level protections are in the proxy.

The package layout and what it depends on

The npm package is @jkudish/jev-mcp, an ES module with the binary mapped to dist/index.js and exports for the package root and the server path both pointing at dist/server.js. The engines field requires Node 22 or newer, and the build is a plain tsc invocation with a prepare script that runs it, a typecheck script using tsc --noEmit, and a test script that runs the node test runner over eight test files covering units, mocks, the provider, a typesafe abort regression, HTTP, an exa example, the server and the hook gate. The dependencies are few and tell you the shape of the thing: the Model Context Protocol node and server packages, the TypeSafe AI SDK, zod for schemas, and @jkudish/jev-agent-tools. The repository adds src/, test/, examples/, a skills/ directory that is shipped in the package files list, plus an .agents/ directory and a SECURITY.md. The examples directory is worth a look before you write your own integration, since it holds classify and hook-gate examples in both markdown and mjs form with sample JSON payloads, and the hook-gate example is the shape you would copy to gate an agent task on a completion claim.

Where jev-mcp is the wrong tool

Four boundaries are clear. The first is scope. These are twelve narrow tools over one hosted model, not a general reasoning engine, so anything requiring synthesis, planning or open ended writing is still a frontier model job, and this server complements that rather than replacing it. The second is cost and dependency shape. Every call spends your Jev key, and the README says the point is a fraction of a cent per judgment, which is only a good deal at the volume the tool is designed for. If your pipeline judges a handful of items, the setup of a provider account, a key and an MCP registration is not worth it. The third is the maturity signal, which the README states outright: this is early software, expect rough edges, with issues and pull requests welcome. The repository is MIT licensed, is not archived, and the last push was on 2026-10-16, with v0.14.3 released on 2026-10-13 and v0.14.2 the same day, and the package.json version reads 0.14.4, so the published version and the released tags move separately and a 0.x version number is the honest signal that interfaces may change. The fourth is that the server is a proxy to somebody else's model. The judgments are only as good as the provider behind them, and a screening tool that is wrong in the safe direction blocks content while one that is wrong in the unsafe direction passes injected instructions, so for a security-relevant use you should treat jev_screen as one layer rather than a control. The sensible alternative for the cheapest useful version of this is to run the same small model yourself behind a thin script and call it from your agent, which costs engineering time but removes the provider dependency and the per call charge, and for the diff and gate cases specifically, running your own test suite and a linter against the patch catches a real class of problems that a judgment model cannot.

Editorial conclusion

Adopt jev-mcp if your agent performs mechanical checks that a frontier model is too slow and too expensive to run on every page, claim or candidate list, because the server turns those into single calls that return probabilities and confidence scores in about 150 to 500 ms. Do not adopt it if you need open ended reasoning, since it is a wrapper around one hosted model rather than a general reasoning tool, and do not adopt it if you cannot hold a provider key, since every call spends it. Verify two things before you wire it into a pipeline: that your MCP client actually passes TYPESAFE_API_KEY through to the server environment, because the README says some clients filter the environment and silently drop it, and that your transport choice matches your deployment, since stdio is the default and the HTTP mode exists for a shared team server. The practical first step is to run npx -y @jkudish/jev-mcp as a local stdio server and try one claim verification to see the verdicts and the reported cost.

Frequently asked questions

Official sources

1. Issues
2. jkudish/jev-mcp on GitHub
3. License: MIT
4. README
5. Releases