Output Verification

by org.dpdns.agendamcp.output-verification

agent_output_verification

Idempotent

Lint caller-provided claim evidence for relay-readiness review. Returns a review-only verdict with per-claim findings, orphaned evidence references, and owner actions. It does not fetch or validate the cited sources; verify_before_relay is the ceiling, never permission to relay, and human review is required for every verdict. Required tool arguments: claims, evidence. Extract claims from the answer and attach the actual source text, evidence_ids, and matching quotes. If evidence is unavailable, report that gap; do not invent sources or treat the result as permission to relay. Illustrative example arguments (synthetic; replace with your own data): {"claims":[{"claim_id":"c1","claim":"The example record says registration is active.","support_level":"direct","evidence_ids":["e1"],"supporting_quotes":[{"evidence_id":"e1","quote":"Registration active"}]}],"evidence":[{"evidence_id":"e1","name":"Synthetic registry excerpt","source_type":"official_document","content":"Registration active"}]}. This product offers 5 free trial attempts for agent_output_verification: call MCP free_trial_status, then MCP free_trial with that tool's own inputSchema arguments; no HTTP adapter or wallet is needed. HTTP alternative: /v1/agent-output/trial; GET that URL for input_schema and example_request, then POST raw tool arguments there (not an MCP/A2A envelope). Both transports share the allowance and daily capacity is limited. Other tools are not included in this trial. Evaluation on paid endpoints requires a signed Base USDC payment for the exact request, or Pro access. Discovery is free. Keep the original request and X-Payment-Signature for result recovery within 24 hours. Current prices: https://output-verification.agendamcp.dpdns.org/.well-known/x402. Do not pay automatically. Evidence triage only: no factual-truth verification, no legal, compliance, sanctions, or financial advice. Human review is required before any commercial action.

Input Schema

TableJSON Schema

Name	Required	Description
`topic`	No
`claims`	Yes
`evidence`	Yes
`unsupported_claims`	No	Important claims the analyst could not back with evidence.

Output Schema

TableJSON Schema

Name	Required	Description
`verdict`	Yes	Machine-actionable relay verdict. verify_before_relay: claims are declared-supported and structurally consistent; the pack is caller-declared and never externally verified here, so this is the best possible routing and human review is mandatory. block_unsafe_claims: at least one claim is marked unsupported or cites evidence that is not present. not_decision_ready / insufficient_information: not enough structured claim material to verdict, or no claim cites evidence present in the supplied pack. allow_relay is reserved and never issued from caller-declared packs: this gate performs no external verification, so nothing it returns may be read as relay-ready. A declared support_level is a caller assertion, not a verified fact: it counts only where the claim cites an evidence_id the caller actually supplied.
`watch_next`	Yes
`claim_count`	Yes
`limitations`	Yes
`score_scope`	No
`weak_claims`	Yes	Claims declared with weak support that should be strengthened before relay.
`trust_signal`	Yes
`evidence_gaps`	Yes
`owner_actions`	Yes	Concrete fixes the producing agent should make before the output is relayed.
`unsafe_claims`	Yes	Claims that must not be relayed as fact: marked unsupported, or citing evidence_ids absent from the supplied evidence.
`readiness_label`	Yes
`readiness_score`	Yes	Heuristic 0-100 score over declared evidence structure, capped below the review_ready band (max 84) because caller-declared packs are never externally verified here. Only claims that cite an evidence_id present in the supplied evidence contribute to it; a claim whose declared support_level nothing in the pack corroborates weighs nothing. Not approval, clearance, or factual verification.
`not_advice_notice`	Yes
`grounded_claim_count`	Yes	Number of claims with at least one supporting quote whose normalized text appears in the cited evidence item's content fields. A quote that is only declared, with no matching evidence content, does not count.
`human_review_required`	Yes	True for any verdict other than allow_relay: a human should review before the consuming agent acts.
`unsupported_statements`	Yes	Statements the producing agent itself flagged as unsupported (from evidence-audit unsupported_claims).
`factual_verification_performed`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false. The description adds substantial context beyond annotations: states it returns 'a review-only verdict with per-claim findings, orphaned evidence references, and owner actions', clarifies it does NOT fetch sources, and emphasizes it is never permission to relay. However, the description devotes significant space to pricing/trial/payment mechanics, which dilutes the core behavioral disclosure. The readOnlyHint=false is somewhat at odds with a seemingly analytical tool, though the description clarifies it's a lint/review operation.

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

Conciseness2/5

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

The description is bloated with pricing, trial, and payment mechanics (5 free trial attempts, HTTP alternative, payment signatures, wallet requirements) that are irrelevant to the core function of linting claim evidence. These details should be in separate tooling or documentation. The core functional description is buried under commercial boilerplate, making it hard for an agent to parse the essential behavior.

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

Completeness3/5

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

The tool has an output schema, so return values needn't be explained in detail, and the description summarizes what the verdict contains. However, with only 25% schema description coverage and 4 parameters, the description should do more to explain parameter semantics. The heavy focus on pricing/trial mechanics detracts from API usage completeness. It adequately covers the 'what' but under-serves the 'how to call correctly' given low schema coverage.

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

Parameters3/5

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

Schema description coverage is only 25%, meaning most parameters are undocumented in the schema. The description mentions required arguments (claims, evidence) and gives an illustrative example, which helps. However, it doesn't explain the semantics of support_level values, claim_type taxonomy, or the distinction between evidence_ids and supporting_quotes beyond what the example shows. With 4 params at 25% coverage, the description partially compensates but leaves gaps.

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?

States a specific verb and resource: 'Lint caller-provided claim evidence for relay-readiness review.' The description clearly distinguishes scope ('does not fetch or validate cited sources') and clarifies it's triage-only, not factual verification. Specific and clear, though the name 'agent_output_verification' suggests a broader purpose than claim-evidence linting – there is a slight mismatch between the tool's title and its actual function.

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?

Provides clear usage context: extract claims from the answer and attach actual source text, evidence_ids, and matching quotes. States what NOT to do ('do not invent sources or treat the result as permission to relay'). Explicitly says human review is required for every verdict. However, does not name or compare against sibling tools like decision_verify or decision_check, leaving the agent to infer when to use this vs. those alternatives.

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

All Output Verification tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?