jev-agent-mcp

Verify claims against evidence

verify_claim

Read-only

Check if your evidence actually supports each claim before you state, cite, or act on it. Returns verified, contradicted, unsupported, or fabricated verdicts with probabilities and confidence.

Instructions

Check whether supplied evidence actually supports claims you are about to state or act on. Returns a verdict and probabilities per claim, never prose.

WHEN TO USE: before reporting work as complete or a bug as fixed, before stating a root cause, before citing a source, or before building the next step on something you concluded earlier. Pass the claim and the raw evidence you believe backs it.

WHAT TO PASS: "evidence" is the actual material (test output, diff, log, document text), and "claims" are the specific statements to check against it. Several claims about the same evidence go in one call. Add "quote" when you attribute exact words to the evidence.

HOW TO READ THE RESULT, per claim:

verified: the evidence states or directly implies the claim.
contradicted: the evidence says the opposite. Retract or fix the claim.
unsupported: the evidence does not address the claim either way. The claim may still be true, but this evidence does not show it; find evidence that does.
fabricated: the "quote" is not in the evidence. Decided by string match with no model call, so "probabilities", "confidence", and "certainty" are null.
"probabilities" covers supports / contradicts / says_nothing. "confidence" (0-1) says how concentrated that distribution is, and "certainty" (high/medium/low) applies the thresholds to it.
"needs_escalation" lists claim ids whose verdict has low certainty. Do not treat those as settled, including a low-certainty "verified": get more direct evidence, check it yourself, or tell the user the claim is unconfirmed. A verdict only covers the evidence you passed; it cannot notice evidence you left out.

Input Schema

TableJSON Schema

Name	Required	Description
`claims`	Yes
`evidence`	Yes	The source material itself: test output, a diff, a log, a document section, fetched page text. Not your summary of it. The model judges the claim against this and nothing else.
`thresholds`	No	Override the uncertainty thresholds for this call. Tighten them (e.g. confidence_high 0.9, noul_band [0.1, 0.9]) when acting on a wrong answer would be costly or irreversible.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`model`	Yes
`usage`	Yes
`verdicts`	Yes
`needs_escalation`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description goes far beyond the readOnlyHint/openWorldHint annotations by disclosing exact verdict semantics ('verified', 'contradicted', 'unsupported', 'fabricated'), stating that fabricated verdicts use string matching with no model call, that probabilities are null in that case, and that needs_escalation means a verdict is not settled. It also warns that the tool cannot notice omitted evidence, reinforcing the openWorldHint.

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 long but tightly organized with clear section headers ('WHEN TO USE', 'WHAT TO PASS', 'HOW TO READ THE RESULT'). Every paragraph contributes new, decision-relevant detail, and the most important guidance is front-loaded. Nothing feels redundant or filler.

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 tool with nested claim objects, an evidence union type, tunable thresholds, and a rich result, the description covers all the tricky parts: claim splitting, quote handling, verdict interpretation, low-certainty escalation, and the fact that evidence scope bounds the conclusion. The presence of an output schema reduces the need to document return values, but the description adds even more clarity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though the schema already documents each parameter, the description adds operational meaning: evidence must be raw material, not a summary; claims should be split into separate entries; quote is checked by exact string match; thresholds can be tightened when the cost of a wrong answer is high. This makes the abstract schema actionable.

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 action ('Check whether supplied evidence actually supports claims') and a clear resource/scope ('claims you are about to state or act on'). It also immediately distinguishes the tool's output format ('verdict and probabilities per claim, never prose'), which separates it from vague review/judgment tools among siblings.

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 'WHEN TO USE' section is explicit and practical, listing concrete moments such as 'before reporting work as complete', 'before citing a source', and 'before building the next step'. 'WHAT TO PASS' clarifies what counts as evidence versus claims. It does not explicitly name alternative tools or say when not to use it, so it falls 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