jev-mcp

jev_pick

Read-only

Choose one candidate from a list you already have, returning one pick or null with relative probabilities and per-candidate fit scores to avoid guessing.

Instructions

Choose one candidate from a list you already have — grep hits, symbols, failing test names, file paths — instead of guessing. One Choice over the candidate ids plus a none escape hatch, and one absolute yes/no per candidate. Use it after a search has produced the candidates. It cannot invent a value: pick is always one of your ids or null. probabilities are relative (they sum to 1 across candidates and none); fits is absolute per candidate. Read both: a confident pick whose fits is under 0.3 is the nearest miss, not a match. Up to 240 candidates in one call. Keep each text to what identifies it (the matching line plus a little context); for ranking many long passages use jev_rank.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "question": "<question>",
      "candidates": "<candidates>"
    },
    "name": "jev_pick"
  }
}

Input Schema

Name	Required	Description
`question`	Yes	What you are choosing, e.g. 'Which grep hit is the definition of parseConfig?'
`candidates`	Yes	The candidates to choose among, 2 to 240. Ids must be unique and none may be 'none'.
`none_label`	No	What it means for no candidate to be the one. Defaults to a generic description.
`thresholds`	No	Override the server's configured gating thresholds for this call only.

Output Schema

Name	Required	Description
`fits`	Yes	Absolute per candidate: P(this is exactly what the question asks for), on its own.
`gate`	Yes	auto/review/escalate on the Choice `confidence`.
`pick`	Yes	The id of the chosen candidate, or null when `none` won.
`model`	Yes	The versioned model id that actually answered.
`usage`	Yes	Token usage. Jev charges for input tokens only.
`confidence`	Yes	How peaked the Choice distribution is, 0..1. Gates on this, not on `fits`.
`latency_ms`	Yes	Wall-clock time for the underlying API call(s), including retries.
`probabilities`	Yes	Relative: P(each candidate is the one) plus `none`, summing to 1 across all of them.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.7.0Nov 6, 2026

TDQS

A4.2/5.0

Behavior5/5

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

The annotations (readOnlyHint, openWorldHint) are minimal, and the description adds substantial behavioral detail the annotations do not contain. It explains that the tool cannot invent a value ('pick is always one of your ids or null'), that probabilities are relative across candidates, that fits is absolute per candidate, and that a high-confidence pick with fits under 0.3 is a near miss. It also states the 240-candidate limit. This is exactly the extra context an agent needs to interpret results correctly.

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

Conciseness4/5

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

The description leads with the core purpose and keeps the operational warnings (probability vs fits, candidate cap, sibling routing) tight. It is dense but every sentence carries information. The backtick-heavy phrasing is slightly busy, but it is not padded.

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?

An output schema exists, so the description does not need to document return values. It still explains how to read the pick, probabilities, and fits, which covers the gap that the output schema alone would leave. It is complete enough to call correctly, with only minor gaps around the none-escape-hatch semantics.

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?

Schema coverage is 100%, so the schema already documents every parameter. The description goes further by explaining the relationship between probabilities and fits and how to interpret the thresholds, which is meaning beyond the schema's field-level text. The none_label escape hatch is implied but not explained in detail.

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 opens with a specific verb and resource: 'Choose one candidate from a list you already have — grep hits, symbols, failing test names, file paths.' It even names the sibling to use for a different case ('for ranking many long passages use jev_rank'). It does not fully distinguish jev_pick from jev_evaluate, jev_verify, or jev_next_step, so it falls just short of 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 Guidelines4/5

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

It says exactly when to call it ('after a search has produced the candidates') and which alternative handles long-passage ranking (jev_rank). It does not explain when not to use it or how it relates to jev_evaluate, jev_verify, or jev_gate_action, but the selection context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server