Skip to main content
Glama

jev-in-mcp

Jev lives inside an MCP relay. To the agent it is one MCP server; to the user's MCP servers it is a client. Every tool passes through unchanged, every server gets one extra tool, <server>__use_jev, and there is one global use_jev over all servers; each hands a goal to TypeSafe Jev: Jev picks the tool calls, the calling model supplies any text that has to be written, and the relay executes. Built on jev-dev-kit.

client (LLM) ──MCP──► jev-in-mcp ──MCP──► github, filesystem, browser, ...
                          ├── <server>__use_jev(goal): Jev runs that server's tools in a loop
                          └── use_jev(goal): the same over every server (server chosen first, then the tool)

Install

Node 20+. Three commands, then restart your MCP client.

npx jev-in-mcp setup     # a local page to store the Jev API key (OpenRouter or TypeSafe); nothing goes through a chat
npx jev-in-mcp import    # copies the mcpServers entries of Claude Code, Cursor, Windsurf and Claude Desktop into jev-in-mcp's config
npx jev-in-mcp status    # what is configured, which servers connect, how many tools each has

Then replace the servers in your client's config with one entry:

{ "mcpServers": { "jev": { "command": "npx", "args": ["-y", "jev-in-mcp"] } } }

Config lives in ~/.config/jev-in-mcp/config.json (or $JEV_IN_MCP_HOME); the key in credentials.json next to it (mode 600), or in JEV_API_KEY. Not on npm yet: install from GitHub with npm install -g github:chy4pro/jev-in-mcp and use jev-in-mcp in place of npx jev-in-mcp.

{
  "servers": {
    "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_TOKEN": "..." },
                "purpose": "Issues, pull requests and files on GitHub",
                "jev": { "deny": ["delete_repository"], "describe": { "create_issue": "Opens a new issue with the given title and body; returns its number." } } },
    "notes":  { "url": "http://localhost:8080/mcp" }
  },
  "jev": { "provider": "openrouter", "model": "typesafe/jev-1.13" },
  "use_jev": { "global": true, "max_steps": 20, "result_chars": 800 }
}

Related MCP server: MCP Coordinator

What the client sees

  • <server>__<tool>: every downstream tool, passed through unchanged.

  • <server>__use_jev(goal, max_steps?, pause_after?, session?, input?): Jev runs that server's tools toward the goal, one decision per step (~300 ms), and returns the status, the trace and every call made. When a value must be written rather than chosen (a search query, a note's text), the call returns status: "needs_input" with the field and a session; the model calls the same tool again with session and input and the run continues. Where the client supports MCP sampling, the relay asks the model inside the call instead and nothing is interrupted.

  • use_jev(goal, servers?, ...): the same over every server. Jev picks the server first, then the tool, in one request.

  • jev_status(): servers, key status, and which tools each use_jev may use.

Tools with a required parameter Jev cannot express (objects, arrays) are not offered to Jev; deny keeps destructive tools away from it; describe replaces a tool's sentence with what actually happens when it is called, which is where the quality of a server's use_jev is decided.

Status

0.1.0. Needs real-world runs against common servers before it is recommended; the loop and the relay are covered by tests, the sampling path is not exercised by any client yet.

Relation to other projects

  • jev-dev-kit: the framework this is built on. use_jev is its runLoop; the relay supplies candidates (tools), text (the calling model) and actions (tool calls).

  • jev-for-chrome: the Chrome extension; a browser becomes one more downstream server once it exposes an MCP endpoint.

  • jiawei686/jev-ultrafast-mcp: Jev driving a browser behind one MCP tool. jev-in-mcp is not browser-specific: any MCP server gets a use_jev.

  • abhishekashokvkumar/jev-mcp-dispatcher: Jev picking one tool call from one sentence. jev-in-mcp runs multi-step loops and lets the calling model write the values Jev cannot choose.

Roadmap

  1. Relay with pass-through tools, per-server use_jev with the needs_input path, setup page for the key.

  2. Sampling path where the client supports it; config import from clients.

  3. Per-tool description overrides and a small eval set per common server.

  4. Options supplied by the model: the calling model writes a few fixed programs (scripts, recipes) and registers them as candidates, so Jev chooses among them and the relay runs them. Not designed yet; the open questions are where such programs live, how they are described to Jev, and how they are kept safe.

License

MIT

Available Tools

1 tool
jev_statusA

Which servers are connected, whether a Jev key is configured, and which tools each use_jev may use.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries the behavioral disclosure burden. It transparently describes what the tool reports, and the content strongly implies a read-only status operation. It does not explicitly state that it has no side effects or whether any special authentication is required, leaving minor gaps.

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

Conciseness5/5

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

The description is a single well-formed sentence that front-loads the main subject and packs three distinct pieces of information without repetition or filler. Every phrase earns its place.

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?

For a zero-parameter status tool with no output schema and no siblings, the description covers the essential information an agent needs to decide to call it: what the result will tell them. It could mention the output format or whether the result is a summary vs. detailed list, but that is not necessary for correct invocation.

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?

The tool takes zero parameters, so the baseline is 4. The description adds useful context about the state aspects that will be reported, even though there are no parameter semantics to clarify.

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 clearly identifies the tool as a status reporter: it lists three specific facts it provides (connected servers, Jev key configuration, and per-use_jev tool permissions). It lacks an explicit verb like 'list' or 'show,' and there are no siblings to differentiate from, so it does not fully earn a 5.

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?

The description implies the tool should be used when an agent needs to check server connectivity, Jev key configuration, or available tools for use_jev. However, it never explicitly states when to use it, and with no sibling tools, there is no alternative routing guidance.

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_status

TDQS

A3.9/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap. The single tool has a clear, distinct purpose.

Naming Consistency5/5

The tool name 'jev_status' is clear and descriptive, and with only one tool there are no conflicting naming conventions to cause inconsistency.

Tool Count3/5

The server exposes a single tool, which feels thin for a typical MCP server. However, it is appropriate for a status-only tool, so the count is borderline.

Completeness5/5

The status tool covers the key aspects of its domain: connection state, key configuration, and tool permissions. No obvious gaps for a status endpoint.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Acts as a proxy for multiple MCP servers, reducing context window usage from 15,000+ tokens to ~500 tokens by dynamically loading servers on-demand and exposing only 3 tools instead of all tool definitions.
    5
    GPL 3.0
  • A
    license
    Not graded
    quality
    C
    maintenance
    Acts as a proxy/router for multiple downstream MCP servers, exposing only meta-tools to the host to reduce token usage, enabling efficient search and invocation of tools from a fleet of servers.
    8 npm
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    Aggregates multiple MCP servers into a single interface, reducing token overhead and simplifying tool management for LLMs.
    6
    197 npm
    18
    Apache 2.0