ASPERN: counterparty checks for agents

What several agents rest on at once (paid)

agent_dependencies

Idempotent

If your firm relies on several external agents, what do they rest on AT ONCE? Give it two to twenty-five addresses and it finds the parties more than one of them pays. THE PRODUCT IS THE DISTINCTION, NOT THE JOIN: finding that three agents paid the same address tells you almost nothing — on our rails one address is paid by 71 agents across 4,100 payments and another by three agents once each, and calling both "shared" makes the second sound like the first. Four tests must ALL hold before the word dependency is used: repeated (more than one payment, because a single payment is an event), one-way (it has never paid them back, because money moving both directions is trade between peers and survives either of them leaving), sustained (spanning more than a day, so a burst of twenty in an afternoon is not a standing arrangement), and shared (more than one of the agents you named). All four are published on every party under tests, so you can draw the line somewhere else than we did. Anything short is a shared-counterparty with its failed test named and is reported as a LEAD. The concentration line counts dependencies only. A party just ONE of them pays is left out entirely — that is counterparty_check, free. Most shared infrastructure, a cloud region or a model provider on a card or one operator holding the keys, leaves no payment at all, so what this finds is a FLOOR on the concentration that exists and never a measure of it. PAID.

Input Schema

Name	Required	Description	Default
`addresses`	Yes	The agents your firm relies on. At least two, because the question is what they rest on together; at most 25, because the join covers every payment each has made.

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.
`read`	Yes	HOW CURRENT THE RAIL BEHIND THIS IS. Recomputed from the payments table on every call, never a stored snapshot — but only as current as the chain that has fallen FURTHEST BEHIND, which is the date given, not the chain most recently read. `furthestBehind` names it and `stalled` lists any chain reporting an error, which may be further behind still. A dependency formed after `railReadAt` is not here yet. Do not confuse it with `firstAt`/`lastAt` on each party: those are when payments HAPPENED.
`says`	Yes	What was found, with the floor stated.
`kinds`	No	What dependency and shared-counterparty each mean.
`agents`	Yes	The agents asked about, read back and de-duplicated.
`limits`	Yes	That the four tests are a JUDGEMENT about where a relationship becomes a reliance, published as one so you can draw the line elsewhere, and that a party only one of these agents pays is left out rather than listed.
`shared`	Yes	Parties paid by more than one of them, dependencies first. Each carries `kind`, `tests` with all four, `paidBy` with payments and span, and what it means.
`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.
`cannotSee`	Yes	Why this is a floor: most shared infrastructure leaves no payment at all.
`concentration`	No	The dependency reaching the most of your agents, or null. DEPENDENCIES ONLY: counting leads here would let three agents who each bought something once produce "three of your five depend on this".

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

Changed2 schema fields changedOct 11, 2026

addedOutput schema / properties / read

Added value: +{
+  "description": "HOW CURRENT THE RAIL BEHIND THIS IS. Recomputed from the payments table on every call, never a stored snapshot — but only as current as the chain that has fallen FURTHEST BEHIND, which is the date given, not the chain most recently read. `furthestBehind` names it and `stalled` lists any chain reporting an error, which may be further behind still. A dependency formed after `railReadAt` is not here yet. Do not confuse it with `firstAt`/`lastAt` on each party: those are when payments HAPPENED.",
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "agents",
-  "shared",
-  "says",
-  "cannotSee",
-  "limits"
-]New value: +[
+  "agents",
+  "shared",
+  "says",
+  "cannotSee",
+  "limits",
+  "read"
+]

AddedOct 11, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well past the annotations: it discloses the four gating tests, that failures are downgraded to 'shared-counterparty' with the failed test named and reported as a LEAD, that the concentration line counts dependencies only, and that the result is a FLOOR on real concentration, never a measure. It also explains the otherwise puzzling readOnlyHint=false by stating 'PAID.'

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 purpose is front-loaded, but the body is a dense wall of prose with capitalized emphasis and a rhetorical 71-agents-vs-3-agents illustration that could be compressed. Every sentence is informative, yet the payload is oversized for a one-parameter tool and hurts quick scanning.

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 paid analytics call with an output schema, the description supplies everything an agent needs to decide and to interpret: eligibility rule, the four tests published per party under `tests`, LEAD vs dependency reporting, and the important scope caveat that most shared infrastructure produces no payment at all.

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 description coverage is 100% and the single parameter already carries its own rationale (min 2, max 25 and why). The description only restates 'two to twenty-five addresses', adding no new format or syntax guidance, so the baseline of 3 is right.

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: given 2-25 addresses it finds the parties more than one of them pays. The opening line plus 'THE PRODUCT IS THE DISTINCTION, NOT THE JOIN' makes the output semantics sharper than a generic join, and it is clearly separable from counterparty_check and counterparty_bulk.

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?

Explicit when-to-use ('If your firm relies on several external agents') and explicit exclusions: single-payer parties are routed to 'counterparty_check, free', and infrastructure with no payment is called out as invisible to this tool. The four tests (repeated, one-way, sustained, shared) define inclusion precisely.

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?