Skip to main content
Glama

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)

  1. 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"
  1. 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.

  1. Register it, from the root of the repo where you want to use it:

& "$HOME\JevMCP\.venv\Scripts\jev-mcp.exe" install
  1. Verify:

& "$HOME\JevMCP\.venv\Scripts\jev-mcp.exe" check

macOS / Linux

git clone https://github.com/NicolasRisso/JevMCP ~/JevMCP
python3 -m venv ~/JevMCP/.venv && ~/JevMCP/.venv/bin/pip install -e ~/JevMCP
echo 'export OPENROUTER_API_KEY=sk-or-...' >> ~/.bashrc && source ~/.bashrc

Use ~/.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 check

What the commands do

  • It's an editable install, so a git pull in the JevMCP folder takes effect in every repo the next time the server starts.

  • install runs claude 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 user registers it once for every repo.

    • --provider openrouter and --fallback pin the provider settings described below.

    • Keys are never written by the installer. The server reads them from your environment.

    • jev-mcp uninstall removes the registration.

  • check sends 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.git
echo 'export OPENROUTER_API_KEY=sk-or-...' >> ~/.bashrc && source ~/.bashrc
jev-mcp install --scope user && jev-mcp check

The 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_API_KEY

TypeSafe key. Set this or OPENROUTER_API_KEY

OPENROUTER_API_KEY

OpenRouter key. Set this or TYPESAFE_API_KEY

JEV_PROVIDER

auto

Which key to use: typesafe or openrouter. Auto picks TypeSafe if its key is set, otherwise OpenRouter

JEV_FALLBACK

off

true: if the chosen provider fails, retry on the other one (needs both keys)

JEV_MODEL

jev-latest / typesafe/jev-1.13

Model for the primary provider (TypeSafe / OpenRouter default)

JEV_API_URL

provider's endpoint

Endpoint URL for the primary provider

JEV_CONCURRENCY

16

Max requests to Jev in flight at once

JEV_CHUNK_CHARS

60000

Files larger than this are split into path#N chunks

JEV_MAX_ITEMS

500

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-mcp

Primary 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 .githooks
pytest

The 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 tool
jev_askA
Read-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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathsNofiles, globs or dirs
textsNo{id:text}
verboseNo
questionsYes{id:{type:noul|choice|score,instructions,criteria}}
thresholdNo

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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. 1 tool updatev0.1.0
    • First observedjev_ask

TDQS

A4.7/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness5/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    B
    maintenance
    Enables 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.
    7
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    Enables 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.
    1
    136 npm
    2
    MIT
  • A
    license
    A
    quality
    C
    maintenance
    Enables 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.
    5
    MIT
  • A
    license
    B
    quality
    C
    maintenance
    Enables 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.
    5
    1
    AGPL 3.0