ASPERN: counterparty checks for agents

Record what you did, so it can be checked later

record_receipt

Call this AFTER you have paid an address or called a tool, to put what you did on the record. Until now this platform answered "should I" and never heard what happened, which is the difference between a lookup and a control layer: a receipt lets the next question about this subject be asked against a record instead of a guess, and lets a verdict we gave be read back against what followed. reference is YOUR evidence, a transaction hash or the digest of a signed payload, and we store it WITHOUT verifying it. It comes back claimed and within the hour is judged against the payments we read from the chain: verified, contradicted, not found after two days, or unverifiable. Read the outcome at GET /v1/receipts/{id}. A claim never raises an evidence status, so a receipt nobody has checked never looks like one that settled. Needs a key; a receipt is readable only by the key that wrote it. WHY readOnlyHint IS false: this call writes a row in our store on behalf of the caller, so a second identical call is not free of consequence.

Input Schema

Name	Required	Description
`chain`	No	The chain it settled on, where it settled on one.
`action`	Yes	Which kind of thing you are recording: `payment` for money that left, `tool_call` for a call you made. It decides nothing about verification — both are stored as YOUR claim, with your `reference` as the evidence — but it decides what the receipt can later be reconciled against, and a payment filed as a tool call will never meet the chain reading that would confirm it.
`policy`	No	The policy you evaluated under, so a later disagreement can be read against what we said at the time.
`subject`	Yes	The address you acted on.
`verdict`	No	The decision we gave you before you acted, for the same reason.
`deadline`	No	ISO 8601 time you expected it by. A time already past is refused, because it is usually seconds where milliseconds were meant.
`expected`	No	What you expected to follow, in your words. Ours to store and yours to claim.
`amountUsd`	No	What you committed, in US dollars.
`reference`	Yes	Your evidence that it happened: a transaction hash, or the digest of a signed payload. Stored, not verified.

Output Schema

Name	Required	Description
`id`	Yes	The receipt, for asking about it later.
`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.
`says`	No	What was and was not verified.
`outcome`	No	Always null here: the receipt is a claim when it is written. Within the hour it is judged against the payments we read from the chain; read the outcome with `receipt_status`.
`subject`	No	The address the receipt is about, read back, so a receipt cannot be filed against the wrong party.
`evidence`	No	The common payment record (TODO-07): `state: built` with `facilitator` (who submitted, never credited), `onChainRecipient`, `listedPayee`, `facilitatorIsRecipient`, `recipientIsListedPayee`, `settlement`, `delivery`, `deliveryEvidence`, `says`; or `state: not-applicable` with `says` naming why no single payment is described.
`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.
`recordedAt`	Yes	When we wrote it down. Not when your action happened.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

addedOutput schema / properties / evidence

Added value: +{
+  "description": "The common payment record (TODO-07): `state: built` with `facilitator` (who submitted, never credited), `onChainRecipient`, `listedPayee`, `facilitatorIsRecipient`, `recipientIsListedPayee`, `settlement`, `delivery`, `deliveryEvidence`, `says`; or `state: not-applicable` with `says` naming why no single payment is described.",
+  "type": "object"
+}

Changed1 schema field changedOct 25, 2026

changedOutput schema / properties / outcome / description

Previous value: -"Always null here. It stays null until something reads what actually happened; null is \"nobody has checked\", never \"it failed\"."New value: +"Always null here: the receipt is a claim when it is written. Within the hour it is judged against the payments we read from the chain; read the outcome with `receipt_status`."

Changed3 schema fields changedOct 15, 2026

changedInput schema / properties / action / description

Previous value: -"What you did."New value: +"Which kind of thing you are recording: `payment` for money that left, `tool_call` for a call you made. It decides nothing about verification — both are stored as YOUR claim, with your `reference` as the evidence — but it decides what the receipt can later be reconciled against, and a payment filed as a tool call will never meet the chain reading that would confirm it."

addedOutput schema / properties / meta

Added value: +{
+  "description": "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.",
+  "type": "object"
+}

addedOutput schema / properties / warnings

Added value: +{
+  "description": "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.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Changed1 schema field changedSep 29, 2026

addedOutput schema / properties / subject / description

Added value: +"The address the receipt is about, read back, so a receipt cannot be filed against the wrong party."

AddedSep 28, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses that reference is stored unverified, that a background judgement runs within the hour and can land as verified/contradicted/not-found/unverifiable, that an unchecked claim never inflates evidence status, that a key is required, that receipts are readable only by the writing key, and explicitly why readOnlyHint is false and a duplicate call is not free. This is exactly the extra context annotations cannot carry.

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 call-to-action is front-loaded in the first clause, and the operational facts (evidence handling, verification outcomes, auth, idempotency) are all earned. Some framing prose ('the difference between a lookup and a control layer') is rhetorical padding that could be cut without losing instruction.

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 non-idempotent write tool with an output schema, the description covers everything an agent needs: when to call, what is stored versus verified, how and when the verdict is produced, where to read it, and the access-control model. No material gap remains.

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?

Schema coverage is already 100%, so baseline is 3; the description still adds meaning for `reference` (it is the caller's evidence, explicitly not verified) and explains the verification lifecycle that determines what a receipt can later be checked against. It does not add much for the optional fields (chain, policy, verdict, expected, deadline, amountUsd), which rely entirely on the schema text.

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?

States a specific verb and resource (record a receipt of what you did) and explicitly frames it as the counterpart to the platform's 'should I' tools like check_action/evaluate_action. An agent can distinguish this write-and-later-reconcile tool from the read-only evaluation siblings without opening any 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?

'Call this AFTER you have paid an address or called a tool' gives an explicit temporal trigger and implicitly excludes pre-action use. It also routes the read path to GET /v1/receipts/{id} (receipt_status), so the agent knows where the follow-up verdict lives.

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?