jev-mcp

jev_rank

Read-only

Rank up to 500 candidate texts by how well each answers your query, with calibrated relevance scores to triage search hits, passages, files, or tool results before reading.

Instructions

Rank up to 500 candidate texts by how well each helps answer a query, using Jev's calibrated yes/no judgment (one question per candidate, batched). Use it to triage search hits, retrieved passages, files, tool results or skills before you spend reading budget on them — and to find out whether anything in the set is relevant at all (any_relevant). Candidates are judged independently and in parallel, so ranking 200 is barely slower than ranking 5. Oversized sets are auto-chunked to fit the context budget. Pass short, self-contained candidate texts (a snippet, a docstring, a summary); a whole file per candidate wastes budget and dilutes the judgment. Candidate text is NOT echoed back — keep your own id -> text map. relevance is P(helps answer the query): near 1 relevant, near 0 not, near 0.5 the model is unsure. Use min_relevance to drop the tail rather than trusting the ordering of near-ties.

Input Schema

TableJSON Schema

Name	Required	Description
`query`	Yes	What you are trying to find out.
`top_k`	No	How many ranked results to return. Default 10.
`candidates`	Yes	The candidates to rank, 1 to 500.
`instructions`	No	Optional extra definition of what counts as relevant here, folded into every question.
`min_relevance`	No	Drop candidates whose relevance is below this. Default 0 (keep everything).

Output Schema

TableJSON Schema

Name	Required	Description
`model`	Yes	The versioned model id that actually answered.
`usage`	Yes	Token usage. Jev charges for input tokens only.
`chunks`	Yes	How many API requests the candidate set was split into.
`ranked`	Yes	Sorted by relevance descending; ties keep input order. Candidate text is not echoed back.
`latency_ms`	Yes	Wall-clock time for the underlying API call(s), including retries.
`any_relevant`	Yes	P(at least one candidate helps answer the query), the maximum across chunks. Low means: look elsewhere.
`total_candidates`	Yes	How many candidates were judged, before top_k/min_relevance.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.4Sep 17, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=true, openWorldHint=true), the description discloses substantial behavioral details: candidates are judged independently and in parallel ('ranking 200 is barely slower than ranking 5'), oversized sets are auto-chunked, candidate text is not echoed back, and the relevance score is defined as a probability ('near 1 relevant, near 0 not, near 0.5 unsure'). It also mentions the calibrated yes/no judgment and batching. This goes well beyond what annotations provide.

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 well-organized and front-loaded with the core purpose. Every sentence carries weight: it covers the evaluation method, use cases, performance characteristics, input best practices, output interpretation, and filtering guidance. There is no fluff or repetition. Given the tool's complexity, the length is appropriate and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for an agent to call the tool correctly. It covers the full scope (what it does, when to use it, how to structure inputs, what the relevance score means, and how to filter results). The presence of an output schema relieves the description from explaining return formats, and the description fills in all other necessary context, including behavioral nuances like parallel processing and auto-chunking.

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 schema has 100% description coverage, so the baseline is 3. The description adds meaningful semantics beyond the schema: it explains the relevance probability scale, how min_relevance should be used to drop the tail, and that the 'id' is returned as-is and never shown to the model. It also clarifies that candidate text is not echoed, which impacts how the id->text mapping must be maintained. These insights help the agent use the parameters more effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('rank'), a precise resource ('up to 500 candidate texts'), and the evaluation criterion ('by how well each helps answer a query'). It also enumerates concrete use cases (triage search hits, retrieved passages, files, tool results, skills) which makes the purpose unambiguous and distinct from generic tools. While it doesn't explicitly contrast with sibling tools, the function is self-evident enough that an agent can infer when to pick it.

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?

The description gives explicit when-to-use guidance: 'Use it to triage... before you spend reading budget on them' and also explains the parallel speed characteristic. It provides strong context on what inputs are appropriate ('short, self-contained candidate texts') and warns against passing whole files. However, it does not explicitly mention when NOT to use it or point to alternative tools (e.g., jev_verify or jev_evaluate), so it stops short of a full exclusion statement.

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

Deploy Server