Binds delegated results to their arrival channel: provenance grades plus a grounded truth tier.
Scored across 4 tools
cbdr_info and verify_receipt are reasonably distinct, but channel_verdict and grounded_verification carry nearly identical boilerplate descriptions ('Paid work: refused over MCP'), so an agent cannot tell what each actually does or when to choose one over the other. Their boundaries are unclear despite different names.
All names use snake_case, which is superficially consistent, but the patterns are mixed: cbdr_info is an acronym-prefixed noun, channel_verdict and grounded_verification are noun phrases, and only verify_receipt follows a verb_noun action pattern. Readable, but not a predictable scheme an agent can rely on.
Four tools is a plausible count for a niche receipts/verification server, but two of them (channel_verdict, grounded_verification) are explicitly non-operational over MCP, leaving only two usable tools. The effective surface is borderline thin.
There is no tool to issue, create, or consume a delegation receipt, and the two core paid operations (verdict, grounded verification) are refused over MCP, forcing agents off-protocol. verify_receipt inspects only the envelope without settling or consuming the nonce, so primary workflows cannot complete within MCP.
Prices, grading ranks, and tier-boundary wording (free, informational).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two real behavioral traits: the call is free and informational (non-mutating). However, it says nothing about auth requirements, rate limits, caching, or what the response looks like, leaving meaningful gaps for a tool with zero annotation coverage.
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?
A single compact fragment with no wasted words and the key content front-loaded. It is terse to the point of under-specification, but nothing in it is filler.
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?
With no output schema, the description must describe return values, and it partially does by listing prices, grading ranks, and tier-boundary wording. It still leaves the 'cbdr' concept undefined and omits the response shape, so it is adequate rather than complete.
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?
The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema is trivially complete.
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 names the resource contents (prices, grading ranks, tier-boundary wording) but is a bare noun phrase with no verb, and the acronym 'cbdr' is never expanded. An agent can infer this is a read-only lookup of pricing/tier data, which does differentiate it loosely from verification siblings, but the purpose is not stated affirmatively.
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?
The parenthetical '(free, informational)' hints that this is the no-cost lookup option versus the verification siblings, but no explicit when-to-use or when-not-to-use guidance is given. The agent must guess whether to call this before or instead of channel_verdict or grounded_verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid work: refused over MCP — payments collect on the HTTP x402 surface (POST /verdict).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose one key behavioral trait: this channel refuses paid work and defers payment collection to the x402 HTTP surface. It omits what the caller actually receives on invocation (error payload, empty result, redirect) and whether any auth is needed to reach the HTTP path.
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?
A single terse sentence that front-loads the refusal and names the escape hatch. It is efficient, though the dash-and-parenthetical phrasing is slightly cryptic and leans on jargon ("x402 surface") that a reader may not parse immediately.
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 zero-param, no-output-schema stub the description covers the essential redirect, but it leaves unresolved what the tool does at all when called and what the caller should expect back. For a tool whose entire behavior is a refusal, that missing detail is the most important thing an agent needs.
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?
The tool takes zero parameters and the schema is trivially complete, so there is nothing for the description to add. Baseline 4 applies for a no-argument tool.
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 communicates the operation's outcome — it refuses paid work over MCP — but never says what a "channel_verdict" actually is or what the tool returns when called. It is differentiated from siblings only implicitly by naming the HTTP surface, not by contrast with cbdr_info, grounded_verification, or verify_receipt.
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?
It names the alternative surface (POST /verdict over HTTP x402) for paid work, which is genuine routing guidance. However it never states when this MCP tool itself is the right call — whether free/unpaid verification passes through, or whether any invocation always yields a refusal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid work: refused over MCP — payments collect on the HTTP x402 surface (POST /grounded).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose one genuinely useful behavioral fact: the tool refuses paid work over MCP and payments are collected on the HTTP x402 surface. That is real transparency about a refusal/auth-gating behavior, but it omits what the tool returns, what errors look like, and what a caller should do if it invokes anyway.
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?
One short sentence with no filler, and the key fact (refused over MCP) is front-loaded. It is slightly cryptic in its use of jargon like 'x402 surface', but it does not waste words.
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 zero-parameter, no-output-schema tool the structured fields are empty, so the description is the only information source. It adequately tells the agent the tool is unavailable for paid work via MCP, but it never explains what grounded_verification verifies or what a successful call would produce, leaving the tool's core semantics unexplained.
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?
The tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to document. Baseline of 4 applies; no parameter detail is missing.
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 never states what grounded_verification actually does. It says the tool 'refused over MCP' and points to a payment surface, which is a transport/availability notice rather than a statement of the tool's purpose (verifying something). An agent cannot tell what would be verified or how it relates to siblings like verify_receipt or channel_verdict.
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?
It signals one negative condition — paid work is refused over MCP — and names an out-of-band alternative (POST /grounded on the HTTP x402 surface). However, it gives no guidance on when this tool is usable at all, nor how it relates to the sibling tools (verify_receipt, cbdr_info, channel_verdict), so the agent is left to guess what to call instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Receipt envelope inspection (signature/expiry/channel; does not consume the nonce, settles nothing).
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the critical side-effect profile — nonce is not consumed and nothing is settled — which is genuinely valuable. However, it omits auth/permission requirements, error behavior, and what a failed verification means operationally.
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?
A single, tightly written sentence with the resource stated first and the behavioral caveat front-loaded rather than buried. It borders on terse for a security-sensitive tool, but no sentence is wasted.
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 tool with no annotations, no output schema, and a nested undocumented parameter, the description covers the safety profile but not the return semantics. An agent cannot learn from it what 'verification' yields (boolean, reason codes, decoded fields), which is a real gap for a verification tool.
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?
The single 'receipt' parameter is an undocumented nested object at 0% schema description coverage, and the description adds no field-level meaning (what a receipt envelope must contain, required fields, format). The word 'envelope' hints at structure but supplies nothing actionable.
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?
States a specific verb+resource ('verify_receipt' → 'Receipt envelope inspection') and enumerates the checks performed (signature/expiry/channel). It does not explicitly differentiate itself from siblings like channel_verdict or grounded_verification, but the scope is unambiguous.
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?
There is no explicit when-to-use or when-not guidance relative to the sibling tools. The parenthetical 'does not consume the nonce, settles nothing' implies the intended usage context (a non-mutating pre-check), but the agent must infer that this is the lightweight inspection step versus a full settlement flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cbdr_infochannel_verdictgrounded_verificationverify_receiptExternal anchoring layer: records AI agent accountability boundaries on both sides. Content-blind.
Compiles source-agent outputs into validated, receiver-ready handoff packages.
Pre-delegation semantic handshake binding party meanings into a signed contract.
Deterministic contextual decision arbitration and action routing for autonomous software. Takes current state, context, or intent plus caller-supplied candidate actions, state transitions, routes, refusals, escalations, tools, or models and returns a deterministic ordered candidate field. Also provides persistent machine representations for memory, retrieval, indexing, and downstream coherence measurement.
Add one secure layer between your agents and this server.
