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., "@Jev MCP Server Which module should handle this ticket: billing, auth, or UI?"
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.
Model Context Protocol (MCP) server for TypeSafe AI's Jev — The ultra-fast, machine-native "System 1" decision model.
Traditional LLMs are designed for slow, generative prose. When an AI Agent only needs to know "Is this a bug?" or "Which module should handle this ticket?", generating markdown tokens is expensive and slow.
Jev (by TypeSafe AI) is a non-generative System 1 decision model trained via RLCD (Reinforcement Learning for Calibrated Decisions). It returns typed, calibrated probabilities and decisions directly in 70ms–300ms, with $0 output cost.
This MCP server brings Jev's high-speed decision primitives into your favorite AI environments (Claude Desktop, Cursor, Antigravity IDE, Windsurf, Continue).
jev_noul: Calibrated boolean proposition evaluation (True/False).
jev_choice: Ultra-fast single-choice selection from candidate categories.
jev_score: Calibrated ranking along an ordered scale of criteria.
jev_batch_decisions: Concurrent evaluation of multiple questions in a single low-latency roundtrip.
Related MCP server: askjev
You can run this MCP directly from GitHub without cloning or manual installs!
Obtain an API key with access to Jev models via OpenRouter.
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"jev": {
"command": "npx",
"args": ["-y", "github:miaopj0325-collab/jev_mcp"],
"env": {
"OPENROUTER_API_KEY": "sk-or-v1-xxxxxxxxxxxxxxxx"
}
}
}
}Add to your .gemini/config/mcp_config.json:
{
"mcpServers": {
"jev": {
"command": "npx",
"args": ["-y", "github:miaopj0325-collab/jev_mcp"],
"env": {
"OPENROUTER_API_KEY": "sk-or-v1-xxxxxxxxxxxxxxxx"
}
}
}
}.cursor/mcp.json){
"mcpServers": {
"jev": {
"command": "npx",
"args": ["-y", "github:miaopj0325-collab/jev_mcp"],
"env": {
"OPENROUTER_API_KEY": "sk-or-v1-xxxxxxxxxxxxxxxx"
}
}
}
}git clone https://github.com/miaopj0325-collab/jev_mcp.git
cd jev_mcp
npm install
# Test with your OpenRouter key
export OPENROUTER_API_KEY="sk-or-v1-xxxxxxxx" # or $env:OPENROUTER_API_KEY in PowerShell
npm start传统的对话大模型（LLM）专注于文本生成。当 AI Agent 仅仅需要裁决 “这行代码是否有 Bug？” 或 “工单归属于哪个模块？” 时，耗费数秒逐字生成 Token 既昂贵又容易产生格式幻觉。
Jev（由前 OpenAI RLHF 联合发明人创立的 TypeSafe AI 研发）是业内首个专注于“系统一（快思考）”的非生成式决策模型：
毫秒级极速响应：典型时延在 70ms ~ 300ms 之间；
颠覆性成本：输入仅 $0.042 / 百万 Token，输出 Token 完全免费（$0）；
严格机器原生：不输出废话文本，直接返回高精度的校准概率与强类型判定。
本项目是 Jev 的标准 MCP（Model Context Protocol）服务，可让各大 AI 助手（Claude Desktop、Cursor、反重力 IDE、Windsurf 等）瞬间拥有毫秒级快速决断能力！
借助 npx，你完全不需要 git clone 任何代码，直接在各客户端配置文件中添加几行 JSON 即可瞬间启动！
访问 OpenRouter Keys 创建一个 API Key（Jev 当前按超低费率计费，输出免费）。
在配置文件 claude_desktop_config.json（Mac 路径：~/Library/Application Support/Claude/，Windows 路径：%APPDATA%\Claude\）的 mcpServers 下添加：
{
"mcpServers": {
"jev": {
"command": "npx",
"args": ["-y", "github:miaopj0325-collab/jev_mcp"],
"env": {
"OPENROUTER_API_KEY": "你的_OPENROUTER_API_KEY"
}
}
}
}在全局配置 .gemini/config/mcp_config.json 的 mcpServers 下添加：
{
"mcpServers": {
"jev": {
"command": "npx",
"args": ["-y", "github:miaopj0325-collab/jev_mcp"],
"env": {
"OPENROUTER_API_KEY": "你的_OPENROUTER_API_KEY"
}
}
}
}在项目的 .cursor/mcp.json 中配置：
{
"mcpServers": {
"jev": {
"command": "npx",
"args": ["-y", "github:miaopj0325-collab/jev_mcp"],
"env": {
"OPENROUTER_API_KEY": "你的_OPENROUTER_API_KEY"
}
}
}
}工具名称 | 原语类型 | 说明 | 推荐落地场景 |
| 是非判定 (True/False) | 快速评估命题真伪，输出校准概率及布尔结论 | 代码断言、Bug 拦截、CI/CD 提交门禁 |
| 类别单选 (Choice) | 从自定义选项集合中做出最合理的单项选择 | 意图识别、日志错误归因、故障分类分流 |
| 梯级打分 (Score) | 依据递进标准打出量化分级与置信度 | 风险评级、代码异味评分、紧急度分级 |
| 批量并行决策 | 单次网络请求并发执行多个决策问题 | 大批量数据/状态快速联合判定 |
环境变量名 | 是否必填 | 默认值 | 作用描述 |
| 是 | - | 你的 OpenRouter API 密钥 |
| 否 |
| 指定调用的 Jev 决策模型版本（可选） |
如果你想本地运行或修改源码：
git clone https://github.com/miaopj0325-collab/jev_mcp.git
cd jev_mcp
npm install
# 设置环境变量后启动
export OPENROUTER_API_KEY="你的_KEY" # Windows PowerShell: $env:OPENROUTER_API_KEY="你的_KEY"
npm start本项目遵循 MIT License 开源协议。
Submit multiple decision tasks in a single request (combining noul, choice, and score). Evaluates concurrently with ultra-low latency.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | The context or state to analyze. | |
| questions | Yes | Questions map matching OpenRouter Jev decision schema. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full behavioral disclosure burden. It usefully adds that evaluation is concurrent and ultra-low-latency, but it does not explain failure semantics, batch size limits, or whether partial failures are possible. These are meaningful gaps for a batch operation.
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?
A single, front-loaded sentence with no wasted words. The core action comes first, and the parenthetical carries important differentiation without bloating the description.
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?
Given no annotations and no output schema, the description is adequate but thin. An agent knows the two required inputs and the batch intent, but it does not clarify the question-object shape, error behavior, or any batch constraints. An agent would likely need to consult sibling tools or external schema documentation.
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 description coverage is 100%, so the baseline of 3 applies. The description adds some meaning by indicating questions can combine noul, choice, and score, but it does not explain the nested question object structure beyond what the schema already says.
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?
Begins with a precise verb and resource, 'Submit multiple decision tasks in a single request', and explicitly names the three combined decision types: noul, choice, and score. This clearly distinguishes it from the individual sibling tools.
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 'single request' framing and 'combining noul, choice, and score' clearly signal a batch use case, reinforced by the sibling tool names. It does not explicitly state when to call the individual siblings instead, but the intended context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ultra-fast single-choice classification using Jev's Choice primitive. Evaluates context against predefined options and returns the winning selection with confidence distribution.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | The context, text, or state to classify. | |
| options | Yes | Key-value dictionary of candidates where key is the option ID and value is the criteria description. Example: {"db": "Database failure", "network": "Connection timeout", "auth": "401 Unauthorized"} | |
| instruction | Yes | The routing or classification question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds meaningful behavior beyond the schema: the tool is 'ultra-fast,' evaluates context against options, and returns both the winning selection and a confidence distribution. It does not cover edge cases or side effects, but for a classification primitive this is reasonably transparent.
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 concise and front-loaded, opening with the core classification purpose before stating the evaluation and return behavior. Every clause adds useful information, though 'Ultra-fast' is a minor marketing flourish.
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?
For a tool with three required parameters, a nested options object, no output schema, and no annotations, the description is minimally viable. It explains the high-level return shape but does not fully describe output structure, tie-handling, or how instruction and options interact. The schema covers parameter semantics, but the description leaves some invocation context implicit.
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 description coverage is 100%, so the baseline is 3 even without parameter detail in the description. The description does not add parameter-level meaning, but the schema already documents context, options with an example, and instruction thoroughly.
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 description clearly identifies the tool as performing 'single-choice classification' with a specific verb ('Evaluates') and resource ('Jev's Choice primitive'). It states the outcome: 'returns the winning selection with confidence distribution,' and the 'single-choice' framing distinguishes it from siblings like jev_batch_decisions.
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?
Usage is implied by the phrase 'single-choice classification' and 'Evaluates context against predefined options,' so an agent can infer when it applies. However, the description provides no explicit when-to-use or when-not-to-use guidance and does not mention alternatives such as jev_score, jev_noul, or jev_batch_decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast boolean proposition evaluation (True/False) using Jev's Noul decision primitive. Returns calibrated truth probability and boolean verdict. Ideal for verification, assertions, bug detection, and criteria checks.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | The state, log, code snippet, or text context to analyze. | |
| instruction | Yes | The proposition or yes/no question to evaluate (e.g. 'Does this log indicate an unrecoverable database crash?'). | |
| true_criteria | No | Specific condition/criteria for evaluating to True (optional). | |
| false_criteria | No | Specific condition/criteria for evaluating to False (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the tool is 'Fast' and 'Returns calibrated truth probability and boolean verdict', which are useful behavioral traits. However, it omits details on error handling, determinism, or how contradictory criteria are resolved. The mention of 'Jev's Noul decision primitive' is opaque and not explained, leaving some ambiguity.
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 a compact two-sentence structure with the core function front-loaded ('Fast boolean proposition evaluation'). Every sentence serves a purpose: the first states the action and primitive, the second states the output and use cases. No fluff or repetition.
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?
For a tool with four parameters, no output schema, and no annotations, the description provides a clear overview, mentions the return type, and lists typical use cases. It does not offer examples or clarify the 'Jev's Noul decision primitive' but covers the essential information an agent needs to invoke the tool correctly. The schema fills in parameter details, so the description is nearly complete for this complexity.
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 description coverage is 100%, so all four parameters (context, instruction, true_criteria, false_criteria) are already documented in the schema. The description does not add any additional meaning beyond what the schema provides; it focuses on the tool's purpose and output rather than parameter details. Baseline 3 is appropriate since the schema handles the heavy lifting.
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 description clearly states a specific verb and resource: 'Fast boolean proposition evaluation (True/False)'. It also lists concrete use cases (verification, assertions, bug detection, criteria checks) and the return type (calibrated truth probability and boolean verdict). This distinguishes it from siblings like jev_choice (multi-choice) and jev_score (scoring) without needing to open the schema.
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 provides clear usage context via 'Ideal for verification, assertions, bug detection, and criteria checks', indicating when to apply it. However, it does not explicitly state when NOT to use it or mention alternatives like jev_choice or jev_batch_decisions. The guidance is implied rather than explicit, but strong enough for an agent to infer appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calibrated hierarchical scoring using Jev's Score primitive. Rates context against an ordered progression of criteria levels (returns weighted score & distribution).
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | The context or text content to score. | |
| criteria | Yes | Ordered list of benchmark levels from lowest to highest. Example: ["Informational", "Low priority", "Urgent block"] | |
| instruction | Yes | The scoring guidance or dimension (e.g. 'Assess the security severity level'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return behavior ('returns weighted score & distribution'), which is helpful, but it does not mention side effects, permissions, or determinism. For a scoring tool, this is acceptable but not exhaustive; it adds some behavioral context beyond the schema.
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 a single, well-structured sentence. It front-loads the core concept ('Calibrated hierarchical scoring') and then elaborates concisely. No unnecessary words; every clause adds information.
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?
The tool has three parameters and no output schema, so the description must cover the return behavior, which it does ('returns weighted score & distribution'). It could elaborate on how 'calibrated' works or provide an example of criteria ordering, but the schema example already covers that. For a scoring tool, this is sufficiently complete.
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?
The schema already describes all three parameters with full coverage (100%). The description adds value by explaining the ordering of criteria ('ordered progression of criteria levels') and the concept of 'calibrated hierarchical scoring', which enriches the meaning beyond the schema. It also hints at the output type. This exceeds the baseline of 3.
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 description clearly states the tool's purpose: calibrated hierarchical scoring using Jev's Score primitive, rating context against an ordered progression of criteria levels. It specifies the verb ('rates'), the resource ('context against criteria levels'), and the result ('weighted score & distribution'). This is specific and distinguishes it from sibling tools like jev_choice or jev_batch_decisions, which likely serve different functions.
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 implies the tool is for scoring content against a hierarchy of criteria, but it does not explicitly state when to use it versus alternatives. There is no mention of 'use this when you need to evaluate severity' or exclusionary language. The usage is implied through the phrasing but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0jev_batch_decisionsjev_choicejev_nouljev_scoreScored across 4 tools
Each tool targets a distinct decision primitive: boolean evaluation, single-choice classification, hierarchical scoring, and batch processing. The batch tool clearly aggregates the other three rather than competing with them, so there is no meaningful selection ambiguity.
All tool names share a consistent 'jev_' prefix followed by a lowercase noun or noun phrase, using snake_case throughout. The naming convention is uniform and predictable across the entire set.
Four tools is well-scoped for a decision-primitive server: three core evaluation types plus one batching convenience tool. Every tool earns its place without redundancy or bloat.
The tool surface covers the full stated domain of Jev decision primitives: boolean verification, option selection, hierarchical scoring, and concurrent batch evaluation. There are no obvious missing operations for this specialized purpose.
Deterministic contextual decision arbitration and action routing for autonomous software. Takes current state, context, or intent plus caller-supplied candidate actions, state transitions, routes, refusals, escalations, tools, or models and returns a deterministic ordered candidate field. Also provides persistent machine representations for memory, retrieval, indexing, and downstream coherence measurement.
Decision-only prompt routing and firewall checks for local/cloud routing, PII and jailbreak risk.
Deterministic decision layer for autonomous agents: reproducible PROCEED/REVIEW/SKIP verdicts.
JSON/YAML, regex, diff, JWT, SQL dialects — the keyless millisecond ops an agent needs mid-task.
