ASPERN: counterparty checks for agents

What moved in the agent record

agent_changes

Read-onlyIdempotent

What moved in the agent record, across every agent, since a date. The counterparty check answers what is true about one address NOW; this answers what changed, for all of them, which is the question anybody holding a list asks next. One row per FIELD that moved, not per address: an agent whose dealings and concentration both moved is two facts, and folding them would make you diff the answer to work out what was meant. Roughly one agent in five moves on an ordinary day; how many are tracked is a denominator on the answer rather than a number frozen here. A day with no row for an address is a day it did not move, never a day nobody looked. The record began on a date and from says which: asking for anything earlier answers from there rather than pretending nothing happened. Needs a key and the agents.changes capability.

Input Schema

Name	Required	Description
`limit`	No	Default 1,000, maximum 5,000. Read `capped` before concluding you have it all.
`since`	No	An ISO date, such as 2026-10-01. The last seven days if you leave it out.
`offset`	No	Rows to skip, for the next page when `capped` is true: the previous offset plus the rows it returned. Default 0.
`address`	No	One address, where you want its movement rather than everybody’s.

Output Schema

Name	Required	Description
`from`	No	The first day held at all. There is nothing before it because the feed began when it began.
`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.
`count`	Yes	Rows IN THIS ANSWER, which is one per field that moved and not one per agent. Where `capped` is true it is the page size and not the total, so it is a floor on how much moved and never the whole of it.
`items`	Yes	address, day, field, was, now, and the path of that agent’s full check.
`since`	Yes	The day this answer starts from, read back so a clamp is visible.
`capped`	No	TRUE where the page came back full, so ask again with an `offset`; FALSE means nothing moved after these rows in the window asked for, so the feed is complete rather than merely begun. A cap is not a count.
`limits`	Yes	What this answer cannot tell you. Quote it with the numbers.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

addedInput schema / properties / offset

Added value: +{
+  "description": "Rows to skip, for the next page when `capped` is true: the previous offset plus the rows it returned. Default 0.",
+  "type": "number"
+}

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

changedOutput schema / properties / capped / description

Previous value: -"The page was full, so there may be more. A cap is not a count."New value: +"TRUE where the page came back full, so ask again with an `offset`; FALSE means nothing moved after these rows in the window asked for, so the feed is complete rather than merely begun. A cap is not a count."

Changed1 schema field changedOct 6, 2026

addedOutput schema / properties / count / description

Added value: +"Rows IN THIS ANSWER, which is one per field that moved and not one per agent. Where `capped` is true it is the page size and not the total, so it is a floor on how much moved and never the whole of it."

AddedOct 4, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the description earns no credit for safety there. It does add genuinely non-obvious behavior: one row per field per agent, absent row means no movement rather than no coverage, data begins at a record start date, and a key plus the agents.changes capability is required. That auth/capability note is the strongest contribution, but nothing is said about output shape beyond what the output schema carries.

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 carries aphoristic padding such as 'the question anybody holding a list asks next' and 'rather than pretending nothing happened.' Those sentences cost length without adding callable guidance, though the row-granularity and truncation facts do earn their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return values, and it correctly spends its words on semantics the schema can't carry: field-level row granularity, absent-row interpretation, historical start boundary and auth requirements. A brief note on typical volume or ordering would close the remaining gap.

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%, so every parameter is already documented, including the capped/pagination pattern and the default date window. The description adds no format or default detail beyond the schema and instead explains `from`, which is an output field rather than a parameter.

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 opening sentence states a specific verb and resource: what moved in the agent record, across all agents, since a date. It also explicitly distinguishes itself from counterparty_check (current state of one address vs. change history for all). The phrase 'agent record' is slightly oblique about what an agent is, but the row-granularity sentence clarifies the answer shape.

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 names the alternative (counterparty_check) and the condition that selects it: point-in-time truth for one address versus change history across the list. It also states that the `address` case exists for narrowing to one holder. What is missing is guidance on narrowing by other dimensions or on when this tool is the wrong choice entirely.

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?