jev-flash-router
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-flash-routerEvaluate this diff: is it safe to merge?"
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.
jev-flash-router
Zero-token-output decision router MCP server powered by TypeSafe Jev.
AI coding agents waste hundreds of reasoning tokens just deciding which file to edit, which route to pick, or whether a diff breaks tests. jev-flash-router evaluates context, code diffs, logs, or planning options and returns calibrated probabilities in ~150ms — with $0.00 output token cost.
Features
~150ms decisions — Lightning-fast evaluation via OpenRouter Decisions API
Zero output token cost —
output_tokens: 0on every callTypeSafe Jev — Powered by the cutting-edge
typesafe/jev-latestmodelMCP-native — Works seamlessly with Cursor, Windsurf, Claude Desktop, and Claude Code
Zero-config — Run via
npxor build locally from sourceThree decision formats —
noul(binary),choice(categorical),score(rubric)
Related MCP server: Jev MCP
Quick Start
1. Get an OpenRouter API Key
Obtain an API key from OpenRouter with access to the Jev model.
2. Client Setup
Option A: Run directly via npx (Recommended)
{
"mcpServers": {
"jev": {
"command": "npx",
"args": ["-y", "jev-flash-router"],
"env": {
"OPENROUTER_API_KEY": "sk-or-v1-YOUR-ACTUAL-API-KEY"
}
}
}
}
Option B: Run from Local Source (Cloned Repository)
{
"mcpServers": {
"jev": {
"command": "node",
"args": ["/path/to/jev-flash-router/dist/index.js"],
"env": {
"OPENROUTER_API_KEY": "sk-or-v1-YOUR-ACTUAL-API-KEY"
}
}
}
}
3. Install AI Agent Skill (Recommended)
To automatically configure your AI agent (Antigravity IDE, Cursor, Claude Code) with the Master Jev Skill so it proactively uses zero-token decisions:
npx -y jev-flash-router install-skillOption C: GUI Client Setup (Manual Field Entry)
Server name:
jevExecutable command:
node(ornpx)Arguments:
/path/to/jev-flash-router/dist/index.js(or-y\njev-flash-router)Environment:
OPENROUTER_API_KEY=sk-or-v1-YOUR-ACTUAL-API-KEY
MCP Client Configuration
Cursor
Go to Settings → Features → MCP Servers → Add New MCP Server:
{
"mcpServers": {
"jev": {
"command": "node",
"args": ["/path/to/jev-flash-router/dist/index.js"],
"env": {
"OPENROUTER_API_KEY": "sk-or-v1-YOUR-ACTUAL-API-KEY"
}
}
}
}
Claude Desktop
Edit ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"jev": {
"command": "node",
"args": ["/path/to/jev-flash-router/dist/index.js"],
"env": {
"OPENROUTER_API_KEY": "sk-or-v1-YOUR-ACTUAL-API-KEY"
}
}
}
}
Windsurf
Add to your Windsurf MCP configuration:
{
"mcpServers": {
"jev": {
"command": "node",
"args": ["/path/to/jev-flash-router/dist/index.js"],
"env": {
"OPENROUTER_API_KEY": "sk-or-v1-YOUR-ACTUAL-API-KEY"
}
}
}
}
Installation for Developers
Clone and Run Locally
git clone [https://github.com/Ravinder82/jev-flash-router.git](https://github.com/Ravinder82/jev-flash-router.git)
cd jev-flash-router
npm install
npx tsc --types node && chmod +x dist/index.js
API Reference
Tool: evaluate_decision
Evaluates context and returns calibrated probabilities.
Parameter | Type | Required | Description |
| string | Yes | Context, code diff, error log, or task description |
| string | Yes | Targeted question (e.g., "Will this change cause a breaking API error?") |
| string | Yes | Decision format: |
| object | Yes | Criteria map matching the chosen type |
Criteria Examples
noul (binary yes/no):
{
"true": "breaks existing callers",
"false": "backward compatible"
}
choice (categorical):
{
"option1": "use caching",
"option2": "recompute",
"option3": "defer"
}
score (ordered rubric):
[
"critical",
"warning",
"info"
]
Cost and Performance
Metric | Value |
Latency | ~150ms |
Output tokens | 0 |
Output cost | $0.00 |
Input cost | ~$0.042 / 1M tokens |
Model |
|
License
MIT
Available Tools
1 toolevaluate_decisionA
Zero-token-output decision engine powered by TypeSafe Jev. Evaluates context, code diffs, logs, or planning options and returns calibrated probabilities. Use this BEFORE generating long reasoning plans or multi-file edits to pick optimal paths.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Decision format: 'noul' (binary yes/no probability), 'choice' (categorical distribution), or 'score' (ordered rubric). | |
| state | Yes | The context, code diff, error log, or task description to evaluate. | |
| apiKey | No | Optional OpenRouter API key. If omitted, the OPENROUTER_API_KEY environment variable will be used. | |
| criteria | Yes | Criteria map: for 'noul' provide { true: '...', false: '...' }, for 'choice' provide { option1: '...', option2: '...' }, for 'score' provide an array of strings in order. | |
| question | Yes | The targeted question to evaluate (e.g., 'Will this change cause a breaking API error?'). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does disclose notable traits: 'Zero-token-output' (no token generation), 'returns calibrated probabilities' (output behavior), and the 'TypeSafe Jev' engine dependency. However, it does not mention the external OpenRouter API call, API key requirements (beyond the schema), or latency/cost implications — material operational information for an agent deciding whether to invoke the tool.
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?
Three sentences, each earning its place: identity (zero-token-output engine), capability (evaluates and returns probabilities), and usage timing (use BEFORE planning or edits). The most distinctive trait is front-loaded. There is slight redundancy between 'zero-token-output decision engine' and 'returns calibrated probabilities', but no real wasted words.
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?
There is no output schema and no annotations, so the description must cover return behavior and operational traits itself; it states probabilities as the general output but does not specify per-type return shapes for 'noul' vs 'choice' vs 'score'. The external OpenRouter dependency and cost/latency implications are left to schema inference. For a 5-param tool with fully documented inputs, the description is adequate but leaves output-format and operational details unstated.
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 100%, so the baseline is 3 and the schema already documents all five parameters, including type-specific criteria formats for 'noul', 'choice', and 'score'. The description marginally reinforces the 'state' parameter by listing the same input kinds (context, code diffs, logs, planning options) but adds no syntax, format, or edge-case detail beyond what the schema provides.
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 uses specific verbs and resources: it 'evaluates context, code diffs, logs, or planning options' and 'returns calibrated probabilities,' clearly identifying the tool as a decision evaluator with a defined input scope and output shape. Minor deduction for jargon like 'Zero-token-output' and 'TypeSafe Jev,' which add character but require interpretation. With no sibling tools to differentiate against, the verb+resource specification carries the clarity burden and succeeds.
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 final sentence gives explicit timing guidance: 'Use this BEFORE generating long reasoning plans or multi-file edits to pick optimal paths.' This is concrete contextual direction for when the tool adds value relative to the agent's workflow. No exclusions or when-not-to-use guidance is given, though no sibling tools exist, so the guidance is as complete as the context allows.
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
v1.0.3- First observed
evaluate_decision
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of an agent confusing it with another. Its purpose is stated clearly and does not overlap with anything else in the set.
The single tool name uses a clear snake_case verb_noun format: evaluate_decision. With only one tool there is no broader naming pattern to compare against, so it cannot earn a full 5.
One tool is acceptable for a narrowly scoped decision engine, but the surface feels thin for a server named as a 'router.' It is on the borderline: useful but unlikely to cover a real workflow by itself.
The core evaluation/probability function is present and well described, but there is no follow-up mechanism to apply the decision or inspect routing outcomes. The description implies integration with planning, yet the server stops at returning probabilities.
Maintenance
Related MCP Connectors
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.
Deterministic decision layer for autonomous agents: reproducible PROCEED/REVIEW/SKIP verdicts.
Decision-only prompt routing and firewall checks for local/cloud routing, PII and jailbreak risk.
Deterministic JSON repair, validate, example-gen, schema-coerce for agents. Zero LLM, sub-10ms.
Related MCP Servers
- AlicenseAqualityBmaintenanceProvides coding agents and CI with a typed decision layer that sends bounded state and questions to Jev, then returns deterministic actions for review, risk assessment, requirement checks, and verification.9MIT
- 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
- AlicenseAqualityAmaintenanceEnables agents to get fast, calibrated probabilistic answers from Jev (Typesafe AI) to yes/no, scale, or choice questions about provided material, without using a generative model.1MIT
- AlicenseNot gradedqualityBmaintenanceEnables typed decisions, confidence-gated tool calls, and computer-use action selection for any LLM via Model Context Protocol, bridging TypeSafe Jev with Codex, Claude, Grok, and OpenCode.30MIT