v1_output_verifyValidates output against schemas, claimed data, custom checks, and staleness budgets, returning verification results so you can confirm accuracy before relying on it.
Output Verify
Remote route: POST /v1/output/verify (0.50 USD x402/base/usdc on eip155:8453).
| Name | Required | Description | Default |
|---|---|---|---|
| checks | No | ||
| output | No | ||
| schema | No | ||
| claimed | No | ||
| subject | No | ||
| accuracy | No | ||
| stalenessBudgetSeconds | No |
| Name | Required | Description | Default |
|---|---|---|---|
| status | No |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the mutation/external-access profile is already covered. The one piece of added value is the x402 price (0.50 USD on eip155:8453), which tells the agent the call is paid. Beyond that, nothing about auth flow, what gets recorded/mutated, or failure modes is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and front-loaded, so nothing is bloated, but the two lines present carry almost no semantic payload beyond the pricing line. Brevity here comes from under-specification rather than tight writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter, open-world, paid verification tool with zero parameter documentation, the description omits everything an agent needs: what a 'check' is, what 'claimed' vs 'accuracy' mean, and what the verification returns (an output schema exists but its semantics are unconnected to the description).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Seven parameters (checks, output, schema, claimed, subject, accuracy, stalenessBudgetSeconds) with 0% schema description coverage, and the description says nothing about any of them. The agent has no basis for choosing between 'schema', 'claimed', and 'accuracy' or knowing what stalenessBudgetSeconds expects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the title ("Output Verify") and gives only a route and price. It never says what is being verified (outputs against a schema? claimed vs actual accuracy?) or what a verification produces, so an agent cannot distinguish it from siblings like v1_data_validate or v1_synthesis_verdict on purpose alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when to use this tool, when not to, or which sibling (v1_data_validate, v1_mcp_verify_uptime, v1_verdict_*) is the alternative. The only guidance is an HTTP route and price, which does not inform selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.