JevMCP
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@JevMCPWhich files in src mention the deprecated API?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
JevMCP
Give your AI coding agent a fast, cheap second brain for yes/no, multiple-choice and scoring questions.
JevMCP is an open-source MCP server that lets agents such as Claude Code and Cursor hand those questions off to TypeSafe's Jev. Jev reads the files, and the agent gets back a compact answer with a confidence score for each one. It works with a TypeSafe or an OpenRouter API key.
Why it helps: to answer "which of these 300 files mention X?", an agent normally reads all 300 files into its context. With JevMCP it gets back a short table of answers instead. That uses fewer tokens, runs faster, and costs very little (Jev charges $0.042 per million input tokens, and each request takes 70–500 ms).
Status: early (0.1.0). The API shape may change.
How it works
agent ──jev_ask(questions, paths)──▶ JevMCP ──reads files, chunks, fans out──▶ Jev API
agent ◀── {file: {q: [answer, confidence]}, unsure: [...]} ◀── compacts answers ◀──┘All questions for one file go in one request (Jev answers them in parallel).
Requests to Jev for different files run concurrently.
Confident answers come back as a few characters each. Unsure answers also include the top two probabilities and are listed in
unsure, so the agent knows which files to open itself.
Related MCP server: jev-flash-router
Install
You need one API key: OPENROUTER_API_KEY (Jev is served through OpenRouter's alpha Decisions endpoint) or TYPESAFE_API_KEY (from https://console.typesafe.ai/keys). The commands below clone JevMCP into your home folder; change the path if you like.
Windows (PowerShell)
Get the package:
git clone https://github.com/NicolasRisso/JevMCP "$HOME\JevMCP"python -m venv "$HOME\JevMCP\.venv"; & "$HOME\JevMCP\.venv\Scripts\pip.exe" install -e "$HOME\JevMCP"Save your key as a user environment variable (persists across reboots; the second command also sets it for the current window):
[Environment]::SetEnvironmentVariable('OPENROUTER_API_KEY', 'sk-or-...', 'User')$env:OPENROUTER_API_KEY = 'sk-or-...'For a TypeSafe key, use TYPESAFE_API_KEY instead. From cmd.exe, setx OPENROUTER_API_KEY sk-or-... does the same as the first command. Restart Claude Code (and other open terminals) afterwards so they see the new variable.
Register it, from the root of the repo where you want to use it:
& "$HOME\JevMCP\.venv\Scripts\jev-mcp.exe" installVerify:
& "$HOME\JevMCP\.venv\Scripts\jev-mcp.exe" checkmacOS / Linux
git clone https://github.com/NicolasRisso/JevMCP ~/JevMCPpython3 -m venv ~/JevMCP/.venv && ~/JevMCP/.venv/bin/pip install -e ~/JevMCPecho 'export OPENROUTER_API_KEY=sk-or-...' >> ~/.bashrc && source ~/.bashrcUse ~/.zshrc on macOS. Then, from the root of the repo where you want to use it:
~/JevMCP/.venv/bin/jev-mcp install~/JevMCP/.venv/bin/jev-mcp checkWhat the commands do
It's an editable install, so a
git pullin the JevMCP folder takes effect in every repo the next time the server starts.installrunsclaude mcp add jev --scope local -- <that venv's python> -m jev_mcp. Local scope: only this repo, stored in your Claude Code user config, not in the repo, so nothing gets committed.--scope userregisters it once for every repo.--provider openrouterand--fallbackpin the provider settings described below.Keys are never written by the installer. The server reads them from your environment.
jev-mcp uninstallremoves the registration.
checksends one tiny request (a fraction of a cent) to each configured provider and prints the latency and the result. It never prints keys.
Linux servers (over SSH)
On a headless box, skip the clone and install straight from GitHub with pipx:
pipx install git+https://github.com/NicolasRisso/JevMCP.gitecho 'export OPENROUTER_API_KEY=sk-or-...' >> ~/.bashrc && source ~/.bashrcjev-mcp install --scope user && jev-mcp checkThe claude CLI must be installed on that server. Update later with pipx upgrade jev-mcp. For many servers, put these lines in a script and run ssh host 'bash -s' < setup.sh.
Other MCP clients
Run python -m jev_mcp (or jev-mcp) over stdio with a key in the environment.
Example
{
"paths": ["reviews/**/*.txt"],
"questions": {
"mentions_cleanliness": {"type": "noul", "instructions": "Does the review mention cleanliness?"},
"sentiment": {"type": "choice", "instructions": "Overall sentiment of the review",
"criteria": {"positive": "Mostly positive", "negative": "Mostly negative", "mixed": "Both"}}
}
}Returns (the shared folder moves into root, and unsure lists what to check by hand):
{"root":"reviews/","results":{"1.txt":{"mentions_cleanliness":0.96,"sentiment":["positive",0.94]},
"2.txt":{"mentions_cleanliness":[0.51,"?"],"sentiment":["mixed",0.42,{"mixed":0.5,"negative":0.41}]}},
"unsure":["2.txt"]}The whole tool definition adds about 1 KB to the agent's context.
See docs/tools.md for the full tool reference.
Configuration
Env var | Default | Meaning |
| TypeSafe key. Set this or | |
| OpenRouter key. Set this or | |
| auto | Which key to use: |
| off |
|
|
| Model for the primary provider (TypeSafe / OpenRouter default) |
| provider's endpoint | Endpoint URL for the primary provider |
|
| Max requests to Jev in flight at once |
|
| Files larger than this are split into |
|
| Refuses a call that would send more than this many items (safety cap) |
Using both keys
If both keys are set, JEV_PROVIDER chooses which one to use. Set JEV_FALLBACK=true to use the other key when the primary fails:
claude mcp add jev -e OPENROUTER_API_KEY=or_key -e TYPESAFE_API_KEY=ts_key -e JEV_PROVIDER=openrouter -e JEV_FALLBACK=true -- jev-mcpPrimary fails with | What happens |
Network error, 5xx, 429/529 after one retry | That item is retried on the fallback provider |
401/402/403 (bad key, no credits, forbidden) | Falls back, and the primary is skipped for the rest of the call |
400/413/422 (the request itself is invalid) | No fallback, since the other provider would reject it too. The error is reported |
Fallback is invisible to the agent. The answers look the same, so no extra tokens are spent. If both providers fail, the error names each one.
Limitations
Jev is a fast classifier, not a reasoning model. According to its documentation, it is weak at counting, arithmetic, date comparisons, and multi-step reasoning. It is also easily influenced by instructions hidden in the text it reads. See docs/limitations.md.
Development
pip install -e .[dev]git config core.hooksPath .githookspytestThe pre-push hook runs pytest and blocks the push if any test fails. Commit messages follow Conventional Commits; see AGENTS.md.
License
MIT. This is an independent project, not affiliated with TypeSafe AI.
Available Tools
1 tooljev_askARead-only
Answer typed questions about files via the Jev classifier without reading them into your context. noul=yes/no (criteria optional); choice: criteria {option:desc}; score: criteria [2-10 levels, low->high], answer is the 0-based level position (fractional allowed). Batch all questions per call. Out: {root?,results:{item:answer or {qid:answer}},unsure?}. noul -> P(yes) | [p,"?"]; choice/score -> [value,conf(,top2 probs)]. Open unsure items yourself. Weak at counting, math, dates, multi-step reasoning.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | No | files, globs or dirs | |
| texts | No | {id:text} | |
| verbose | No | ||
| questions | Yes | {id:{type:noul|choice|score,instructions,criteria}} | |
| threshold | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, but the description adds much more: output structure, per-type answer formats, confidence markers, unsure behavior, and known limitations. This is substantial behavioral context that annotations alone do not convey, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded, with the main purpose stated first and all critical format information compressed into a few lines. It contains little wasted text, though the compressed syntax is somewhat hard to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description covers input formats, output shape, per-type answer representation, batching, and known weaknesses, which is strong. But `threshold`, `verbose`, the meaning of `root?`, and the exact trigger for `unsure?` remain implicit, so it is not fully self-sufficient for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 60%, so the description carries meaningful weight. It thoroughly defines the `questions` object's three types, criteria syntax, and 0-based level position, which are essential and not in the schema. However, `threshold` and `verbose` are not explained in the schema or the description, so parameter coverage is not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb ('Answer'), a resource ('typed questions about files'), and a distinguishing characteristic ('without reading them into your context'). It clearly enumerates the supported question types and output behavior, so an agent knows exactly what the tool does and does not need to disambiguate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent when to use the tool ('without reading them into your context') and instructs it to batch all questions per call. It also gives explicit exclusions: 'Weak at counting, math, dates, multi-step reasoning' and directs the agent to 'Open unsure items yourself,' which is actionable guidance for deciding when and how to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
jev_ask
TDQS
Scored across 1 tool
With only a single tool, there is no possibility of confusing one tool with another. The tool's multiple question types (noul, choice, score) are clearly delineated within the one tool, so agents can disambiguate the intended use from the parameter descriptions.
The sole tool name 'jev_ask' follows a clean snake_case convention with a descriptive verb. As there is no other tool to compare against, no naming inconsistencies or mixed conventions exist.
At one tool, the server is on the low end of tool counts, but for the narrow purpose of classifier-based file questioning, a single comprehensive tool is reasonable. It slightly under-utilizes the typical 3-15 tool range, yet it does not feel excessively thin given its focused scope.
The single tool covers multiple question types, batching, and uncertainty handling, addressing the full lifecycle of querying files without needing additional operations. The documented limitations (weak at counting, math, dates, multi-step reasoning) are clearly stated, so there are no hidden gaps in the tool surface.
Maintenance
Related MCP Connectors
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
A paid remote MCP for OpenAI Codex context compressor, built to return verdicts, receipts, usage log
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
A paid remote MCP for Pydantic AI structured output, built to return verdicts, receipts, usage logs,
Related MCP Servers
- AlicenseAqualityBmaintenanceEnables frontier coding agents to delegate routine probabilistic judgments to TypeSafe Jev, providing calibrated triage signals for failures, attempts, completion, context ranking, findings, risk, and generic evidence-grounded questions.7MIT
- AlicenseAqualityBmaintenanceEnables AI coding agents to make fast, zero-output-token decisions by evaluating context, diffs, logs, or options through the OpenRouter Decisions API using TypeSafe Jev, returning calibrated probabilities for binary, categorical, or scoring questions.1136 npm2MIT
- AlicenseAqualityCmaintenanceEnables coding or reasoning agents to request structured judgments from TypeSafe's Jev model at decision points, including choices, scores, claim verification, and code reviews, with probabilities and confidence returned as data.5MIT
- AlicenseBqualityCmaintenanceEnables AI agents to obtain typed judgments from TypeSafe's Jev System One models, including yes/no probabilities, multiple-choice selections with distributions, and rubric-based scores, directly usable in code.51AGPL 3.0