ASPERN: counterparty checks for agents

Endpoints that contradict their own listing

endpoint_disagreements

Read-onlyIdempotent

WHICH ENDPOINTS CONTRADICT THEIR OWN LISTING: they ask to be paid at an address the catalogue entry they published does not name. The contradiction appears only when the live handshake and the published listing are held together: either half on its own looks ordinary, since a reachable endpoint and a stated payee are each unremarkable alone. A disagreement is between two statements by the SAME party, so it is theirs to explain and never ours to resolve, and it is NOT evidence of fraud: a seller may have moved their payee and not relisted. Measured only over endpoints we have knocked on, which is our reach and not the catalogue; comparable is the denominator, because an endpoint that names no payee cannot disagree and is counted neither way. THE COUNTS ARE FREE AND THE LIST IS NOT: items comes back NULL without a plan rather than empty, since an empty list would say we found none. Any SINGLE endpoint is free — test_purchase and list_x402_endpoints both carry its own reading — because that one is reproducible in two requests and because withholding something that can cost a buyer money is not a thing we do.

Input Schema

Name	Required	Description	Default
`limit`	No	Rows once a plan is held. Default 50, capped at 200.

Output Schema

Name	Required	Description
`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 finding in a sentence, with its denominator.
`items`	No	One per disagreeing endpoint: `resource`, `listedPayee`, `quotedPayee`, `seenAt`. NULL without a plan — never an empty array, which would say we found none.
`limits`	Yes	What this is measured over and what a disagreement is not.
`knocked`	Yes	Endpoints we have knocked on at all. The population every other figure here is drawn from.
`sellers`	Yes	How many distinct listed payees those belong to. Worth more than the endpoint count: it says whether this is scattered or a few parties contradicting themselves repeatedly.
`serving`	No	Of those, how many answered with a price at the most recent knock.
`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.
`comparable`	Yes	How many could be compared at all: both the endpoint and its listing named a payee. The DENOMINATOR for `disagreeing`.
`notServing`	No	Gone, unreachable or erroring at the most recent knock. A fact about our last look, not a verdict on the seller.
`disagreeing`	Yes	How many name a payee their own listing does not.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 15, 2026

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"
+}

AddedOct 13, 2026

TDQS

A4.1/5.0

Behavior5/5

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

The description adds substantial behavior beyond annotations: `items` returns NULL without a plan rather than an empty list, counts are free but the list is paid, and the measurement scope is limited to endpoints that were actually contacted. It also clarifies that a disagreement is not fraud evidence and explains the `comparable` denominator, which is exactly the kind of context an agent needs before calling.

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

Conciseness3/5

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

The core definition is front-loaded, and most sentences carry useful scope or paywall information. However, the description is verbose and stylistically dramatic, with philosophical asides that could be compressed for faster agent parsing.

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 rich annotations and output schema, the description is complete enough: it covers the measurement scope, plan-gating behavior, NULL return semantics, and alternatives for single-endpoint checks. No critical invocation detail is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the only parameter, `limit`, is fully described in the schema with its default and cap. The description adds no further detail about `limit`, so the baseline score of 3 is appropriate when the schema carries parameter semantics.

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?

The description clearly defines the tool as identifying endpoints whose live handshake payee differs from their published catalogue listing. It distinguishes the concept from related tools by naming `test_purchase` and `list_x402_endpoints` as alternatives for single-endpoint readings, though it never states the operation as a crisp 'list' verb.

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?

It explains that counts are free while the list requires a plan, and that any single endpoint can be checked through `test_purchase` or `list_x402_endpoints` instead. This gives clear guidance on when to use the bulk list versus single-endpoint alternatives, though it does not explicitly frame all sibling-routing conditions.

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?