ASPERN: counterparty checks for agents

Evidence on a counterparty before trading (paid)

counterparty_evidence

Idempotent

Before trading with an agent or service: what the records actually say about it, in one answer. Identity links with their strength (declared by the agent, observed by us, or corroborated by a second party), settled payment history with first and last payment, active months and long silences, counterparties with top-1 and top-3 share, Herfindahl and repeat ratio, each catalogued service with its price, how often it was paid at that price and whether delivery can be observed at all, what we cannot see, and whether there is enough history to conclude. Paid ($0.01). Settled payments, distinct counterparties and delivery evidence are SEPARATE figures and never a score: much measured agent-payment volume is self-dealing, wash or tests, and a payment does not show a service was delivered. Read sufficiency and warnings before any figure, and quote guard with them.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "counterparty_evidence"
  }
}

Input Schema

Name	Required	Description	Default
`address`	Yes	The agent or service address you are about to trade with.

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.
`guard`	Yes	Quote it with the figures.
`address`	Yes	The address as we read it, normalised. Compare it with what you sent.
`history`	No	byRail, firstSettled, lastSettled, monthsActive, longestGapDays, gaps; status.
`delivery`	No	Per service: price, paid at that price, answered, deliveryObservable, says; status.
`identity`	No	links[] with kind, strength (declared \| observed \| corroborated), source, asOf; status.
`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`	No	What the records behind this answer cannot show for this address. Quote it with the figures.
`sufficiency`	Yes	verdict (sufficient \| insufficient-history) and missed[] naming each threshold.
`counterparties`	No	unique, dealings, top1Share, top3Share, hhi (null below 10 dealings), repeatRatio, flags; status.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations say readOnlyHint=false and destructiveHint=false, and the description explains why: the call is paid ($0.01) even though it mutates nothing. It goes well beyond that, warning that settled payments, distinct counterparties and delivery evidence are separate figures and never a score, that much agent-payment volume is self-dealing, wash or tests, and that payment does not prove delivery. It also flags that the answer discloses 'what we cannot see' and includes a sufficiency verdict — behavioral context an agent could not get from the annotations or schema.

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-loaded: the purpose and timing land in the first clause, followed by the enumeration of outputs, then the interpretive caveats. Every item earns its place, though the output list is a long comma-chain that could be broken into shorter sentences for faster 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?

An output schema exists, so return values do not need spelling out, yet the description still supplies the interpretive frame those fields lack — figures vs. score, self-dealing caveat, sufficiency/warnings/guard protocol. Combined with the stated price, this is sufficient for an agent to call it and to read the result correctly.

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?

One parameter with 100% schema description coverage ('The agent or service address you are about to trade with'), mirrored in the description's framing. The schema already carries the meaning, so the baseline 3 applies; the description adds no format, resolution or validation detail for the address.

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?

Names a specific subject and deliverable: 'Before trading with an agent or service: what the records actually say about it, in one answer,' then enumerates the concrete contents (identity links, payment history, counterparty concentration, service catalogue, caveats). An agent knows exactly what comes back. It stops short of 5 because it never names the nearby siblings — counterparty_check, counterparty_history, counterparty_bulk, evidence_for — so the agent gets no explicit routing cue.

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?

States the triggering context clearly ('Before trading with an agent or service') and adds a consumption rule: read `sufficiency` and `warnings` before any figure and quote `guard` with them. That is real when-to-use guidance. No explicit exclusions or named alternatives, which keeps it at 4 rather than 5.

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.