Skip to main content
Glama

jev-flash-router

npm version License: MIT Node.js MCP OpenRouter

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 costoutput_tokens: 0 on every call

  • TypeSafe Jev — Powered by the cutting-edge typesafe/jev-latest model

  • MCP-native — Works seamlessly with Cursor, Windsurf, Claude Desktop, and Claude Code

  • Zero-config — Run via npx or build locally from source

  • Three decision formatsnoul (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

{
  "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"
      }
    }
  }
}

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

Option C: GUI Client Setup (Manual Field Entry)

  • Server name: jev

  • Executable command: node (or npx)

  • 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 SettingsFeaturesMCP ServersAdd 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

state

string

Yes

Context, code diff, error log, or task description

question

string

Yes

Targeted question (e.g., "Will this change cause a breaking API error?")

type

string

Yes

Decision format: "noul", "choice", or "score"

criteria

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

typesafe/jev-latest


License

MIT

Available Tools

1 tool
evaluate_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
typeYesDecision format: 'noul' (binary yes/no probability), 'choice' (categorical distribution), or 'score' (ordered rubric).
stateYesThe context, code diff, error log, or task description to evaluate.
apiKeyNoOptional OpenRouter API key. If omitted, the OPENROUTER_API_KEY environment variable will be used.
criteriaYesCriteria map: for 'noul' provide { true: '...', false: '...' }, for 'choice' provide { option1: '...', option2: '...' }, for 'score' provide an array of strings in order.
questionYesThe targeted question to evaluate (e.g., 'Will this change cause a breaking API error?').

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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. 1 tool updatev1.0.3
    • First observedevaluate_decision

TDQS

A3.7/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count3/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.

Completeness3/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    B
    maintenance
    Provides 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.
    9
    MIT
  • 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
    A
    maintenance
    Enables 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.
    1
    MIT