jev-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JEV_MCP_MOCK | No | 1 enables deterministic local mock mode | |
| JEV_MCP_MODEL | No | Default model | jev-latest |
| JEV_MCP_BLOCK_AT | No | Screen block threshold | 0.75 |
| TYPESAFE_API_KEY | Yes | Live TypeSafe API credential | |
| JEV_MCP_REVIEW_AT | No | Default review threshold | 0.5 |
| TYPESAFE_BASE_URL | No | Optional API root | |
| JEV_MCP_AUTO_ACCEPT | No | Default automation threshold | 0.8 |
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": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| jev_evaluateA | Escape hatch: send shared state plus named noul/choice/score questions to TypeSafe Jev. Use when no other jev_* recipe fits. Jev does not write code or prose. Questions in one call run in parallel. Returns typed answers, probabilities, confidence, usage, and action auto|review|escalate. |
| jev_assess_change_riskA | Assess security, operational, compatibility, scope, reversibility, and blast-radius risk for a proposed change. The host supplies context; this server does not read Git or files. High-risk or incomplete evidence never returns auto. |
| jev_check_requirementA | Check each supplied requirement or acceptance criterion against a host-supplied diff and verification evidence. Returns criterion-level covered, partial, not_covered, or not_verifiable statuses. |
| jev_classify_issueA | Classify an issue by category, severity, urgency, and an allowlisted owner candidate. The tool may return unknown; it must not invent an owner. |
| jev_coding_loopA | Call before spending a frontier turn on retry/stop/model-tier. One Jev fan-out returns next (continue|retry|ask_user|stop), model_tier (cheap|standard|reasoning), risk, focus, and noul flags done_enough / needs_more_context / tests_likely_fail. Policy in code maps confidence to action auto|review|escalate. Does not edit files. |
| jev_reviewA | Score a proposed diff against the request: correctness, spec-match, test-gap, blast-radius, plus noul safe_to_apply. Composite weights live in code. Call before declaring a fix done. Does not apply the patch. |
| jev_verifyA | Check each claim against provided evidence (PR description, agent brief, docs, diffs). Returns per claim: verified|contradicted|unsupported, probabilities, confidence, and auto vs review. Prefer this over asking a chat model to 'double-check'. |
| jev_screenA | Judge fetched or pasted text before the agent reads it: prompt-injection probability, substance, and optional relevance to purpose. Recommendation: pass|review|block|skip. Use on untrusted web pages, issues, and pastes. Not for first-party repo files. |
| jev_rankA | Rank files, symbols, errors, or skills against a plain-language query. No embeddings. One Choice over candidate ids plus a Noul that the top hit actually answers the query (so a forced winner cannot masquerade as a match). Max 250 candidates per Jev call; larger lists are chunked then re-ranked. Pass candidates in; this server does not index the repo. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| pack-coding-loop | Exact question JSON used by the coding-loop recipe. Tune thresholds in code, not by rewriting Jev into a chat prompt. |
| pack-review | Exact question JSON used by the review recipe. Tune thresholds in code, not by rewriting Jev into a chat prompt. |
| pack-verify | Exact question JSON used by the verify recipe. Tune thresholds in code, not by rewriting Jev into a chat prompt. |
| pack-screen | Exact question JSON used by the screen recipe. Tune thresholds in code, not by rewriting Jev into a chat prompt. |
| pack-rank | Exact question JSON used by the rank recipe. Tune thresholds in code, not by rewriting Jev into a chat prompt. |
| pack-change-risk | Exact question JSON used by the change-risk recipe. Tune thresholds in code, not by rewriting Jev into a chat prompt. |
| pack-requirement | Exact question JSON used by the requirement recipe. Tune thresholds in code, not by rewriting Jev into a chat prompt. |
| pack-issue | Exact question JSON used by the issue recipe. Tune thresholds in code, not by rewriting Jev into a chat prompt. |
TDQS
Scored across 9 tools
Each tool has a clearly defined job—risk, classification, verification, review, screening, ranking—so they are mostly easy to distinguish. The main ambiguity is jev_evaluate, which is intentionally an escape hatch and can conceptually overlap with any of the other tools, though its description frames it as a fallback.
All tools share the jev_ prefix and use snake_case, making the set feel consistent. The only deviation is jev_coding_loop, which is a noun-style name rather than a verb_noun pattern like assess_change_risk or classify_issue.
Nine tools is well-scoped for a decision-support/evaluation server. Each tool addresses a distinct stage in the workflow—screening, risk assessment, review, verification, ranking, and a general escape hatch—so none feels redundant or excessive.
The tool surface covers the full evaluation lifecycle for the stated domain: risk assessment, issue classification, requirement checking, coding-loop guidance, diff review, claim verification, text screening, and ranking. The escape-hatch jev_evaluate also prevents dead ends for questions that don't fit an existing recipe.