ASPERN: counterparty checks for agents

Settled, linked and delivered, across the rails

payment_evidence

Read-onlyIdempotent

BEFORE YOU QUOTE ANY FIGURE FOR AGENT COMMERCE, ask which of three it is. Every payment shown to be one, x402 and ACP, is split into three figures that NEST and are never added up (x402 counts only the protocol, route and facilitator tiers below; the authorised transfers with nothing to show they were x402 are in notShownToBeX402, never in the figures): settled (paid on-chain), of that serviceLinked (paid to a payee that lists a paid service, or an ACP job), of that deliveryEvidenced (a recorded outcome: an ACP job completed). x402 records the payment and never the delivery, so its payments are counted in deliveryUnevidenceable: $0 delivered there is what the rail allows, not a failure of the seller. Beside it, tiers splits x402 payments by what can be shown about the payment itself: to a listed route, through a facilitator, or only an authorised transfer. Free, because it is an aggregate; the same split for one address is on agent_business.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`at`	No	When the x402 tiers were computed.
`meta`	No	How current this answer is and what it was read from: `freshness` and the ages behind it. Present on every answer from this server, whatever the tool.
`note`	Yes	What each x402 tier means.
`tiers`	Yes	x402 payments by what can be shown about them: `route`, `facilitator`, `candidate`, `candidate-unsampled`, each with payments and usd. No tier is protocol-confirmed: the HTTP 402 receipt never reaches a chain.
`warnings`	No	Anything the server wants a caller to know about THIS answer before acting on it. Empty is the normal case and is not a guarantee.
`commerceTiers`	No	`settled`, `serviceLinked`, `deliveryEvidenced` and `deliveryUnevidenceable`, each {count, usd}; `rails` per rail; `says` in one line; `limits`; `asOf` when the daily rollup ran. NULL until it has run, never a row of zeros.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds critical semantics: the figures NEST and must never be added up, x402 counts only certain tiers, `notShownToBeX402` is excluded from figures, and `deliveryUnevidenceable` reflects a rail limitation rather than seller failure. This is exactly the kind of context annotations cannot convey.

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

Conciseness4/5

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

The key instruction is front-loaded in the first sentence, and every subsequent clause adds substantive semantic detail about the nested figures. The paragraph is dense and could be split for readability, but it is not padded with redundant restatements of the name or title.

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?

With zero parameters, an existing output schema, and rich annotations, the description provides more than enough context: it explains the nesting rules, the x402-specific definitions, the `tiers` breakdown, and the sibling relationship. An agent has everything needed to interpret and quote the figures correctly.

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?

There are zero parameters, so parameter semantics are not a meaningful burden; the baseline for zero-parameter tools is 4. The description does not need to explain input syntax, and it compensates by thoroughly explaining the output categories instead.

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 names the exact resource: three nested figures (`settled`, `serviceLinked`, `deliveryEvidenced`) across x402 and ACP rails, plus `tiers` and `notShownToBeX402`. It distinguishes itself from the sibling `agent_business` by noting that the same split for one address lives there. An agent can tell what this tool returns without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit usage trigger: 'BEFORE YOU QUOTE ANY FIGURE FOR AGENT COMMERCE, ask which of three it is.' It also names the alternative for per-address figures (`agent_business`), so the routing decision is fully specified. No inference is required.

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

All ASPERN: counterparty checks for agents 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?