ASPERN: counterparty checks for agents

Two to five vaults side by side, from each one’s report

compare_vaults

Read-onlyIdempotent

Compare 2 to 5 named vaults side by side on one taxonomy: identity (chain, address, platform, curator, operator), capital (reported assets, the venue’s withdrawable figure, the withdrawable share, and what the capital figure means, e.g. a book value whose recovery is not established), the assessment (status, published band, highest finding, findings above the band, critical flags) and the earned verdict. Free. Every conclusion is copied from each vault’s own due-diligence report, the same document the PDF is printed from; a vault with no report in the last two days says so and gets no band, finding or flag. Each cell is read with its own readAt and source, or unknown with why: an unknown is never 0 and never a pass. The vaults were read at different moments and readAtSpreadMinutes says how far apart. There is no winner and no overall ranking; sort orders by the one figure you name and echoes it. Quote each vault’s dueDiligence headline, not a comparison of bands across reports.

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": {
      "slugs": "<slugs>"
    },
    "name": "compare_vaults"
  }
}

Input Schema

Name	Required	Description
`sort`	No	Optional. Orders the rows by that one figure, unknowns last. Without it the rows keep the order you gave.
`order`	No	desc (default) or asc; only with `sort`.
`slugs`	Yes	2 to 5 vault slugs or contract addresses, comma-separated. Call list_vaults first if you have only names.

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 comparison in one sentence, generated from the fields above.
`sort`	Yes	Null without a sort key. Otherwise `key`, `order`, `means`, `unknownLast` (slugs without that figure, placed last) and `says`.
`fields`	Yes	The taxonomy in display order: group, key, label.
`limits`	Yes	What this comparison does not do: no vault is placed above another and no overall verdict is drawn.
`vaults`	Yes	One row per vault: `slug`, `name`, `dueDiligence` (the report headline, null where none is stored in the last two days), `dueDiligenceSays`, `identity`, `capital`, `assessment`, `earned`, `readAt` {earliest, latest} and `says`. Every cell is {state: "read", value, readAt, source, note?} or {state: "unknown", why}.
`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.
`readAtSays`	Yes	The spread in words.
`readAtSpreadMinutes`	Yes	Minutes from the earliest read time in the table to the latest. The rows are not one block read at one instant.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description goes well beyond them: it declares the tool is free, states that every conclusion is copied from each vault's own due-diligence report, that a vault without a report in the last two days yields no band/finding/flag, that each cell is either a `read` with `readAt` and `source` or an `unknown` with `why`, and that `readAtSpreadMinutes` exposes staleness skew. The "an unknown is never 0 and never a pass" rule is exactly the kind of interpretive constraint annotations cannot express.

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 with purpose and scope, then the taxonomy, then caveats about unknowns and staleness, then the ranking disclaimer and the quoting instruction. It is dense and the taxonomy enumeration runs long, but nearly every clause carries decision-relevant information; only the parenthetical about book value is slightly verbose.

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 multi-vault comparison with an output schema present, the description supplies everything an agent needs to call it correctly and to interpret the result honestly: scope, the no-report case, unknown-vs-zero semantics, timestamp spread, and the no-ranking caveat. Return shape details are appropriately delegated to the output schema rather than repeated.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description still adds value by explaining that `sort` orders by the one figure named and echoes it, that omitted `sort` preserves the caller's order, and by grounding what the sortable capital figures mean ("a book value whose recovery is not established"). It does not document `order` or the slug format beyond what the schema already says.

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?

"Compare 2 to 5 named vaults side by side on one taxonomy" states a specific verb, an explicit arity limit, and the resource, then enumerates the four comparison dimensions (identity, capital, assessment, earned verdict). It is clearly distinguishable from single-vault siblings like vault_due_diligence or vault_assessment by the cardinality and the side-by-side framing, and it pre-empts two obvious misreadings by stating there is no winner or overall ranking.

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?

Usage context is clear: 2-5 vaults, one named sort figure, no ranking, and an explicit instruction to "Quote each vault's dueDiligence headline, not a comparison of bands across reports." What is missing is an explicit routing sentence naming the alternative for a single vault (e.g. vault_due_diligence); the only pointer, "call list_vaults first," lives in the schema rather than the description.

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.