Build blueprint
MCP Capability Router
A proxy exposing only the small capability subset relevant to the current step.
- Problem
- Large MCP tool sets overload model context and increase incorrect tool selection.
- Why Jev
- Selecting capability groups is a bounded classification problem repeated at every turn.
- Architecture
- User intent + agent state → capability Choices → filtered MCP manifest → downstream model.
- Current alternative
- Expose all tools, manually configure servers, or ask an LLM to choose.
- Jev advantage
- Reduces schemas in context and can run before each agent turn.
- Unknowns
- Cost of false exclusion and whether confidence is sufficient for fallback.
Why this confidence: Concrete developer-tool problem with an observable, typed outcome.
This is an authored hypothesis derived from the research corpus. Nothing here demonstrates product demand, or that Jev performs well on this particular workload. Run the validation experiment before building past the MVP.
Sources
Limitations
- Cost of false exclusion and whether confidence is sufficient for fallback.
- This is a research hypothesis, not evidence of product demand or Jev performance in this workflow.
Supporting research
- Cascade router PlausibleA cheap decision chooses whether to use rules, a small model, a premium model, a specialist, or a human.
- typesafe-mcp ObservedAn MCP server exposing TypeSafe evaluation to coding agents.
- TypeSafe reports a low input-token price and no metered output-token charge for Jev. Vendor ClaimPublished pricing is echoed across launch discussion, but remains mutable vendor pricing.
- Parallel decision matrix PlausibleOne state is evaluated against many named questions, replacing repeated prompt/parse cycles.