jev-mcp

jev_verify

Read-only

Check up to 100 claims against a single evidence block, returning supported, contradicted, or not_addressed with calibrated confidence for each claim. Use it to validate factual assertions before communicating or writing them.

Instructions

Check each of up to 100 claims against one block of evidence, and get supported / contradicted / not_addressed per claim with a calibrated confidence. Use it before you assert something to the user or write it into a file: verify your draft's factual claims against the source you actually read, or check a summary against the document it summarises. The rubric is strictly literal and closed-world: a claim counts as supported only if the evidence states or directly entails it. A claim that is true in the world but absent from the evidence comes back not_addressed, which is the answer you want when you are checking for unsupported assertions. Claims should be single, self-contained statements — split compound sentences, and resolve pronouns before sending. Evidence should be the passage you want to hold the claims to, nothing more. all_supported is true only when every claim is supported AND the model was confident about each one; treat review/escalate gates as claims a human should look at.

Input Schema

TableJSON Schema

Name	Required	Description
`claims`	Yes	Self-contained statements to check, one per entry. Split compound claims.
`evidence`	Yes	The only material the claims are judged against.
`thresholds`	No	Override the server's configured gating thresholds for this call only.

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.
`claims`	Yes	One result per input claim, in input order.
`summary`	Yes	Counts across all claims.
`latency_ms`	Yes	Wall-clock time for the underlying API call(s), including retries.
`thresholds`	Yes
`all_supported`	Yes	True only if every claim is `supported` and every gate is `auto`.

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, it explains the literal/closed-world rubric, the not_addressed semantics for absent-but-true claims, the all_supported confidence condition, and the review/escalate gate interpretation. This is substantial behavioral context not available from annotations or schema.

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?

Dense and well organized: purpose, usage, rubric, input formatting, and output semantics each get one focused segment. No filler, with the most important scope ('up to 100 claims... evidence') front-loaded.

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?

For a verification tool with an output schema and full parameter coverage, the description covers when, how, and with what constraints to call it, plus how to interpret results. Nothing an agent needs to invoke or trust the tool is missing.

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 already documents all 3 parameters at 100%, so the baseline is 3; the description adds operational meaning for claims (self-contained, split compounds, resolve pronouns) and evidence (passage only, nothing more). Thresholds are less enriched, but the gate discussion covers their intent.

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?

States a precise verb–object–result: check up to 100 claims against one evidence block and return per-claim supported/contradicted/not_addressed. The phrase 'verify your draft's factual claims' makes the tool's role unmistakable next to siblings like jev_rank or jev_gate_action.

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?

Gives explicit when-to-use instructions: before asserting something to the user or writing it into a file, and for checking a summary against the source document. It does not name specific alternative tools or explicit when-not-to-use cases, so it stops just short of a 5.

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

Deploy Server