jev-router
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JEV_FAKE | No | 1 = offline keyword stand-ins | 0 |
| LLM_FAKE | No | 1 = offline keyword stand-ins | 0 |
| JEV_MODEL | No | Jev model name | jev-latest |
| LLM_MODEL | No | Any OpenRouter model id | anthropic/claude-sonnet-5 |
| JEV_BASE_URL | No | Base URL for Jev API | https://openrouter.ai/api |
| JEV_MCP_SERVERS | No | Server config for the CLI and the gateway | mcp_servers.json |
| TYPESAFE_API_KEY | No | Alternative to OpenRouter for Jev (set JEV_BASE_URL=https://api.typesafe.ai) | |
| OPENROUTER_API_KEY | No | Used for Jev and for the LLM in run / eval |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| jev_routeB | Decide which tools (across all connected MCP servers) and playbooks a request needs. Returns only the YES tools with their input schemas, and the instructions of each YES playbook. |
| jev_callB | Call a tool chosen by jev_route. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
jev_route handles selection/decision while jev_call handles execution. The two tools have clearly distinct roles with no overlap, so agents cannot misselect.
Both tools use the jev_ prefix and a concise verb (route, call) in snake_case. The pattern is consistent and predictable.
Two tools are exactly what a router needs: one to decide and one to invoke. No bloat or missing operation, so the count is well scoped.
The router covers the full flow of selecting relevant tools/playbooks and then calling a chosen tool. No obvious lifecycle gaps for its orchestration purpose.