Skip to main content
Glama
Sign In
Pinutss

jev-mcp

by Pinutss
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

jev-mcp-router

Selects the MCP tools that fit the query, inside a context budget.

Author: Pinuts. MIT license.

Part of JEV Labs.

Stack: Python 3.10+, HTTP, MCP stdio, Docker, HTML demo.

After jev-mcp serve: demo

Local, no keys

git clone https://github.com/Pinutss/jev-mcp-router
cd jev-mcp-router
uv sync
uv run jev-mcp demo
uv run jev-mcp serve

No agent and no LLM are required. JEV_PROVIDER=auto (the default) stays on the local heuristic. If JEV and a gateway are configured, they are used as the judge. Docker:

docker compose up

Related MCP server: mcp-catalogue

What the prototype does

The selector chooses tools from a catalog, under a token budget. It explains the choice, abstains if no candidate is safe, and allows only one fallback hop.

It does not run tools and does not ship them.

Selection is not authorization. Permissions come only from the catalog and the caller constraints. The task, a tool, or a model cannot add them.

Cursor and Hermes plugin

This repository is an Agent Plugin. Cursor and Hermes can install it directly.

Hermes

hermes plugins install Pinutss/jev-mcp-router --enable

Cursor

Install from the JEV plugins marketplace, or copy this folder to ~/.cursor/plugins/local/jev-mcp-router.

One tool: mcp_select. Pass query + tools. Keys stay in the process environment, not in the call.

Requires uv. JEV_PROVIDER defaults to local.

Hermes and OpenClaw

Yes, locally. The MCP process does not need JEV or a gateway:

uv run jev-mcp mcp

One tool: mcp_select. Pass query + tools. Keys stay in the process environment, not in the call.

Hermes (~/.hermes/config.yaml):

mcp_servers:
  jev-mcp:
    command: uv
    args: ["run", "--directory", "/path/to/jev-mcp-router", "jev-mcp", "mcp"]
    env:
      JEV_PROVIDER: local

OpenClaw (~/.openclaw/openclaw.json, or Settings > MCP > Stdio):

{
  "mcp": {
    "servers": {
      "jev-mcp": {
        "command": "uv",
        "args": ["run", "--directory", "/path/to/jev-mcp-router", "jev-mcp", "mcp"],
        "env": { "JEV_PROVIDER": "local" }
      }
    }
  }
}

Python

from jev_mcp_router import McpSelector, DEFAULT_TOOLS

result = McpSelector(provider="local").select(
    query="Read a local file, then search GitHub issues",
    tools=DEFAULT_TOOLS,
    max_tools=2,
    budget_tokens=250,
    scope="demo",
)
print(result.decision, [item.id for item in result.selected])

JEV + gateway (optional)

If you wire the cloud later, two keys are enough: JEV_API_KEY / JEV_BASE_URL, and your gateway. If GATEWAY_* is incomplete, the multi-LLM catalog resolves the judge. Vendor keys stay in the environment and each is sent only to its own vendor (OPENROUTER_API_KEY, OPENAI_API_KEY, GROQ_API_KEY, and the other catalog presets). A custom judge endpoint is discovered by scanning env for JEV_LLM_<NAME>_BASE_URL (plus JEV_LLM_<NAME>_API_KEY / JEV_LLM_<NAME>_MODELS); that key is used only against that base URL.

No key in the HTTP or MCP body.

cp .env.example .env

JEV_PROVIDER=jev will not start if JEV or the resolved gateway is missing. With auto, missing keys just keep the local heuristic.

Public catalog: GET /v1/llms. You can also point JEV_MODELS_FILE at a JSON catalog.

HTTP

uv run jev-mcp serve

GET /, /demo, /healthz, /v1/llms. POST /v1/select. Binds 127.0.0.1. The body must not contain keys. It may contain gateway_provider, gateway_model, llm_prefer.

Local validation

uv run jev-mcp benchmark

Annotated set in benchmarks/annotated_tasks.json. This is a local baseline, not a live JEV trial.

Limits

Local ranking is lexical and deterministic. Scope isolates lists, it is not auth. One fallback hop. No tool execution. No store, no PyPI yet.

docs/vision.md is a long-term target, not the current contract.

Available Tools

1 tool
mcp_selectC

Selectionne des outils MCP pertinents sous un budget de contexte. N'execute aucun outil.

NameRequiredDescriptionDefault
queryYes
scopeNo
toolsYes
max_toolsNo
llm_preferNo
budget_tokensNo
gateway_modelNo
min_relevanceNo
allow_fallbackNo
failed_tool_idNo
gateway_providerNo
required_permissionsNo
forbidden_permissionsNo

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden and only establishes that the tool does not execute anything. It says nothing about how selection happens (LLM/gateway, determinism, latency, token cost), what fallback behavior means, or what the result looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero filler and the core function front-loaded, which is good. But for a 13-parameter tool the brevity crosses into under-specification rather than disciplined economy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A 13-parameter selection tool with no annotations and no output schema needs far more: at minimum what the output is (a ranked/filtered tool list?), how budget and relevance thresholds interact, and what happens on fallback. The description covers only the headline purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 13 parameters, and the description only vaguely gestures at two of them ('budget de contexte' hints at budget_tokens; 'pertinents' hints at relevance/query). max_tools, min_relevance, llm_prefer, gateway_model, gateway_provider, allow_fallback, scope, failed_tool_id and the permission filters are entirely unexplained anywhere.

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?

States a specific verb and resource ('Selectionne des outils MCP pertinents') plus a scope qualifier ('sous un budget de contexte') and a negative clarification ('N'execute aucun outil'). The purpose is unmistakable, though there are no siblings to differentiate from.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'N'execute aucun outil' rules out one misuse (expecting execution), which is the only usage guidance present. There is no statement of when to prefer this over direct tool invocation, nor any prerequisite about supplying a tools array or query.

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 observedmcp_select
Deploy Server
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

B3/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool is exposed, so there is no competing operation to confuse it with; its description clearly states it selects MCP tools and does not execute them. The purpose is unambiguous, though the set is too small to demonstrate real disambiguation.

Naming Consistency4/5

mcp_select uses a readable snake_case verb form with a server prefix, and with only one tool there is no convention mixing. The name is understandable, though it does not follow a broader verb_noun pattern because no other tools exist.

Tool Count2/5

A single tool is explicitly considered too few for the apparent scope; the server is a focused selector, but one operation leaves no room for related lifecycle actions. The score reflects the thin surface rather than poor quality.

Completeness3/5

The tool covers the core selection operation, but a selection service would typically also expose ways to inspect available tools, configure budget, or refresh the index. Those gaps are notable but not fatal for a minimal router.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Bifrost-MCP Gateway

    david-spies
    A
    license
    Not graded
    quality
    D
    maintenance
    Enterprise-grade dynamic MCP proxy that eliminates token bloat by lazy-loading tool schemas based on semantic intent, enabling efficient orchestration of multiple backend tools from a single endpoint.
    MIT

  • mcp-catalogue

    Aidan-Kay
    F
    license
    Not graded
    quality
    C
    maintenance
    A browse-first MCP middleware that provides an LLM-friendly catalogue for discovering and invoking tools across multiple upstream MCP servers, reducing context overhead.
    -

  • context-saver

    msuther898
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP proxy that reduces context usage through semantic tool routing, enabling on-demand discovery and routing of relevant tools.
    MIT

  • MCP Proxy Gateway

    steveweltman
    A
    license
    Not graded
    quality
    B
    maintenance
    A context-aware MCP proxy that reduces token usage by exposing only 3 tools (mcp_search, mcp_call, mcp_schema) to LLMs, with on-demand tool loading and BM25 search.
    103 npm
    2
    MIT