ASPERN: counterparty checks for agents

One check before you sign (paid)

check_action

Idempotent

CALL THIS BEFORE YOUR AGENT SIGNS ANYTHING THAT MOVES MONEY. One request instead of five: it reads the counterparty record, decodes the calldata you are about to sign, looks up the seller’s own catalogue listing, runs an unpaid 402 handshake with the endpoint, and applies a published policy — and then, which is the point, compares them WITH EACH OTHER. The losses an agent actually suffers live between those readings and no single one of them can see them: the bytes paying an address you never checked, so a spotless counterparty record is about a party this transaction does not pay; an UNLIMITED APPROVAL wearing the shape of a one-cent payment; the seller’s listing naming a payee the calldata does not; a policy allowing a payment for a path that is not served. Every cross-check names BOTH readings that disagree in between, and none of them is an accusation — the record can be wrong. Send calldata whenever you have it: it unlocks the strongest check there is. A cross-check can only make the verdict worse, never better. SEND calldata, chain AND from and it is also SIMULATED: one eth_call at the latest block, the node executes it and throws the result away, nothing is signed or spent. A revert is the strongest finding available, because every other reading argues about whether you should send it and this one is that it will not work. Not a state diff, run against the current block, and a node that refuses is reported as our gap rather than as a failure. ran says which parts did not run and why, because a check that did not happen must never look like one that passed. PAID; its five components are each free on their own tools and what is sold here is the comparison.

Input Schema

Name	Required	Description
`from`	No	The address the transaction would be sent FROM. Only used to SIMULATE it, and worth sending: without it the call runs as the zero address and reverts for a reason about our request rather than your transaction.
`asset`	No	The TOKEN you are paying in. Compared against the one the seller’s listing prices in: a payment in a token the seller does not credit leaves your side and arrives nowhere, and every other check passes on it.
`chain`	No	The chain it is about to be sent on, e.g. base.
`action`	No	What you are about to do, because the checks differ: `pay` weighs a recipient’s payment record, `allocate_capital` weighs a VAULT (pass its slug as `subject`) on exit, controller and evidence, `connect_mcp` and `call_tool` weigh a server or tool you are about to trust. Defaults to `pay`. Choosing the wrong one does not fail — it answers the wrong question, and `checked` in the reply names which checks actually ran.
`policy`	No	A policy slug or version from list_policies. Defaults to conservative.
`subject`	No	For allocate_capital: the vault slug.
`calldata`	No	The hex bytes you are about to sign. Left out, the transaction is reported as UNREAD rather than fine.
`resource`	No	The http(s) URL of the endpoint being bought, where there is one.
`valueWei`	No	Native value in wei, where the transaction carries any. Simulation only.
`amountUsd`	No	What is about to be sent, in dollars.
`recipient`	No	The address about to be paid.

Output Schema

Name	Required	Description
`ran`	Yes	Which parts ran and why each one did not.
`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`	Yes	The worst thing found, in one sentence.
`parts`	Yes	Each reading on its own: policy, transaction, listing, endpoint, settledOn.
`limits`	Yes	What this check structurally cannot contain: what the action is FOR, terms agreed privately, anything beyond a single `eth_call` at the latest block (no state diff, no fork), and calls the decoder refuses rather than guesses at. Read it before treating a clean answer as a safe one.
`verdict`	Yes	The policy’s decision, worsened by the cross-checks and never improved by them.
`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.
`crossChecks`	Yes	The comparisons between parts. Each names the TWO readings that disagree. The ones that AGREED are published too, because a comparison that ran and agreed is different from one that never ran. `tone` is `bad`, `warn`, `good` or `neutral`, and the fourth is the one to read carefully: a NEUTRAL check established nothing and can neither improve nor worsen the verdict. `the-price-has-moved-since-the-listing` compares the endpoint’s own quote with its catalogue entry in BASE UNITS after checking that both name the same token, so it is exact; where the tokens differ or either is unnamed it reports `the-two-prices-are-not-comparable` instead, because a 402 states an amount in the asset’s smallest unit and never its decimals. The same rule is applied by `preflight_payment` and `evaluate_action`.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

changedOutput schema / properties / limits / description

Previous value: -"What this check structurally cannot contain: what the action is FOR, terms agreed privately, any simulation, and calls the decoder refuses rather than guesses at. Read it before treating a clean answer as a safe one."New value: +"What this check structurally cannot contain: what the action is FOR, terms agreed privately, anything beyond a single `eth_call` at the latest block (no state diff, no fork), and calls the decoder refuses rather than guesses at. Read it before treating a clean answer as a safe one."

Changed3 schema fields changedOct 15, 2026

changedInput schema / properties / action / description

Previous value: -"Defaults to pay."New value: +"What you are about to do, because the checks differ: `pay` weighs a recipient’s payment record, `allocate_capital` weighs a VAULT (pass its slug as `subject`) on exit, controller and evidence, `connect_mcp` and `call_tool` weigh a server or tool you are about to trust. Defaults to `pay`. Choosing the wrong one does not fail — it answers the wrong question, and `checked` in the reply names which checks actually ran."

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 changedOct 11, 2026

changedOutput schema / properties / crossChecks / description

Previous value: -"The comparisons between parts. Each names the TWO readings that disagree. The ones that AGREED are published too, because a comparison that ran and agreed is different from one that never ran."New value: +"The comparisons between parts. Each names the TWO readings that disagree. The ones that AGREED are published too, because a comparison that ran and agreed is different from one that never ran. `tone` is `bad`, `warn`, `good` or `neutral`, and the fourth is the one to read carefully: a NEUTRAL check established nothing and can neither improve nor worsen the verdict. `the-price-has-moved-since-the-listing` compares the endpoint’s own quote with its catalogue entry in BASE UNITS after checking that both name the same token, so it is exact; where the tokens differ or either is unnamed it reports `the-two-prices-are-not-comparable` instead, because a 402 states an amount in the asset’s smallest unit and never its decimals. The same rule is applied by `preflight_payment` and `evaluate_action`."

AddedOct 11, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Adds substantial behavior beyond annotations: paid, cross-comparison logic, the `between` field naming disagreeing readings, asymmetrical verdict impact ('can only make the verdict worse'), simulation semantics, revert interpretation, node refusal handling, and `ran` reporting for skipped checks. These details materially change how an agent interprets results.

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?

Front-loads the call-to-action and key value proposition, and most sentences carry useful operational nuance. It is dense and somewhat rhetorical, with all-caps emphasis and long sentences, but not padded with irrelevant material.

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?

Given the complexity, high schema coverage, and presence of an output schema, the description provides enough context: what it aggregates, when to invoke it, what simulation does, how failures and gaps are represented, and why it is paid. Nothing critical for correct invocation appears missing.

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 100%, so baseline is 3, but the description adds combination-level meaning: calldata unlocks the strongest check, and calldata + chain + from enables simulation. It also reinforces that missing calldata means UNREAD rather than fine, which is more than the individual schema fields convey.

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 action and scope: a pre-signing composite check that reads five sources and compares them. It clearly distinguishes itself as an aggregate ('one request instead of five') whose sold value is the comparison, though it does not name sibling alternatives directly.

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?

Strong usage trigger: 'CALL THIS BEFORE YOUR AGENT SIGNS ANYTHING THAT MOVES MONEY.' It also tells the agent to send calldata whenever available and specifies that calldata, chain, and from together enable simulation. It lacks explicit when-not-to-use guidance or named alternatives among the many sibling tools.

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?