ASPERN: counterparty checks for agents

One agent’s record day by day (paid)

counterparty_history

Idempotent

How one agent’s record has moved: dealings, independent payers, concentration and delivery, day by day. PAID, one cent a call over x402 — the median price of this rail. Without payment the tool answers with the price and how to pay it, and the free check remains available. The history begins the day we started keeping it; it is a record we keep, not one the chain gives away. WHY readOnlyHint IS false: this tool reads and writes nothing in our store, but calling it WITH an x402 payment authorisation transfers USDC from the caller to us and records a receipt, so the call is not free of consequence and an agent must not make it speculatively. Called without an authorisation it changes nothing and answers with the price.

Input Schema

Name	Required	Description	Default
`days`	No	1 to 365, default 90. The history begins the day we started keeping it, so a longer window does not reach further back than that.
`address`	Yes	The agent whose record you want day by day. An EVM, Cardano or Solana address.

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.
`items`	No	One entry per day: dealings, independent payers, concentration, delivery.
`change`	No	What moved across the window, and over which dates.
`address`	Yes	The address this history is for, normalised and read back.
`payment`	No	What was paid and how it settled. Present because this call took money.
`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.
`keptSince`	No	The day we began keeping this. Nothing before it exists, at any window.

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

Changed1 schema field changedSep 29, 2026
- addedOutput schema / properties / address / description
```
Added value: +"The address this history is for, normalised and read back."
```

Changed3 schema fields changedSep 26, 2026

addedOutput schema / properties / change

Added value: +{
+  "description": "What moved across the window, and over which dates.",
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedOutput schema / properties / items

Added value: +{
+  "description": "One entry per day: dealings, independent payers, concentration, delivery.",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

removedOutput schema / properties / series

Removed value: -{
-  "description": "One entry per day: dealings, independent payers, concentration, delivery.",
-  "items": {
-    "type": "object"
-  },
-  "type": "array"
-}

Changed3 schema fields changedSep 26, 2026

addedInput schema / properties / address / description

Added value: +"The agent whose record you want day by day. An EVM, Cardano or Solana address."

changedInput schema / properties / days / description

Previous value: -"1 to 365, default 90."New value: +"1 to 365, default 90. The history begins the day we started keeping it, so a longer window does not reach further back than that."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "address": {
+      "type": "string"
+    },
+    "keptSince": {
+      "description": "The day we began keeping this. Nothing before it exists, at any window.",
+      "format": "date",
+      "type": "string"
+    },
+    "payment": {
+      "description": "What was paid and how it settled. Present because this call took money.",
+      "type": "object"
+    },
+    "series": {
+      "description": "One entry per day: dealings, independent payers, concentration, delivery.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "address"
+  ],
+  "type": "object"
+}

First observedSep 24, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations by explicitly justifying readOnlyHint=false: the call transfers USDC via x402 and writes a receipt, so it is not consequence-free, while an unauthorised call changes nothing and returns only the price. This is exactly the kind of side-effect disclosure 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?

Front-loads the resource and its dimensions before the payment terms. The payment rationale is somewhat verbose and repeats the 'record we keep, not one the chain gives away' idea already implied in the days parameter note, but the length is defensible for a paid tool.

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?

With an output schema present, return format need not be described. The description covers pricing, payment mechanics, failure behaviour without payment, the temporal limit of the data, and the safety profile — everything an agent needs to decide and invoke 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?

Schema description coverage is 100%, so both parameters are already documented in the schema, including the default and the 1-365 range. The description reinforces the 'history starts when we began keeping it' caveat, which is useful but largely restates the schema note.

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 resource ('one agent's record') and enumerates exactly what it returns: dealings, independent payers, concentration, delivery, day by day. The scoping word 'one agent' cleanly separates it from the bulk siblings (counterparty_bulk, find_agents).

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?

Explains the payment prerequisite, that an unpaid call returns the price instead of data, and points to the durable 'free check' alternative. It also warns the agent not to call speculatively. It stops short of naming the specific sibling tool (counterparty_check) the free check corresponds to.

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.