ASPERN: counterparty checks for agents

vault_assessment

Read-onlyIdempotent

THE HASH-COMMITTED ASSESSMENT OF A VAULT, in the shape ERC-8004’s Reputation Registry points at, and the only thing here a third party can publish on chain under their own name. Until 2026-10-21 this document was reachable from the API and the web and from NO tool, so an agent could read every figure behind it and not the document itself. Each dimension is its own score and they are never blended: a vault can have an excellent record and a poor provenance grade, and one number would destroy the distinction this platform exists to draw. data.document is what the hash covers, byte for byte, and data.feedbackHash is that hash. READ data.document.refusals BEFORE ANY MISSING DIMENSION: from aspern-0.4 an absent dimension is UNREAD unless a refusal names it, and a refusal means we hold a reading we will not stand behind — a liquidity share over 100% of the vault, for instance, which is a disagreement between two of our own readings rather than a fact about the vault. data.alsoPublished sits deliberately OUTSIDE the hash: the risk band, the lending figures and the books reconciliation are ASPERN’s own reading, and a consumer attesting the hash is attesting the document alone. data.erc8004 carries the call arguments for whoever wants to publish it; ASPERN does not make those calls and never holds a mainnet key. Ask for an older methodology to rebuild a document at the version a hash was issued under; the list is on /v1/meta. Free.

Input Schema

Name	Required	Description	Default
`slug`	Yes	The vault’s slug, or its contract address — either resolves.
`methodology`	No	Build the document at an older methodology version, so a hash issued under it stays checkable. Omit for the current one. THIS IS THE DOCUMENT’S OWN VERSION and not `meta.methodologyVersion`, which stamps every answer this API serves and moves for different reasons; the two were one number until 2026-10-21 and will drift apart.

Output Schema

Name	Required	Description
`data`	No	The document and everything published beside it: `document` (what the hash covers, with `assessments`, `observations`, `refusals` and `limitations`), `feedbackHash`, `alsoPublished` (our own risk band, lending figures and books reconciliation, deliberately OUTSIDE the hash) and `erc8004` (the call arguments, one giveFeedback per dimension). Null where no document could be built.
`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.
`slug`	No	The vault this document is for, read back so an answer cannot be attached to the wrong vault.
`metric`	No	Always `assessment` here. The route answers in the availability envelope every per-vault reading uses.
`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.
`availability`	No	Whether a document could be built at all, and when it was read. An assessment rests on a record: where there is not enough of one, `status` says so and `data` is absent, which is a fact about OUR evidence for this vault and not a judgement of the vault.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 21, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive and open-world behavior, so the safety profile is covered; the description goes further by disclosing that the call is free, that ASPERN never holds a mainnet key and does not make the ERC-8004 calls, and what the hash does and does not cover. That is genuine context beyond the structured fields, though rate limits and pagination are unaddressed.

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 purpose is front-loaded, but the body is a dense all-caps run of em-dash clauses mixing behavioral disclosure, consumer guidance and release history. The 2026-10-21 narrative and the 'one number would destroy the distinction' aside are background that an agent does not need to call the tool.

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?

An output schema exists, so return values need not be spelled out, yet the description usefully explains the hash/alsoPublished boundary and the refusal semantics that govern how to interpret missing dimensions. For a two-parameter read tool with full schema coverage, the agent has enough to call it and interpret 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?

Schema description coverage is 100%, so the schema already carries both parameters, including the slug/address resolution and the methodology-version caveat. The description reinforces the hash-rebuild use case for methodology and points to /v1/meta for the version list, but adds little that the schema does not already say.

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 clause states the resource precisely — a hash-committed assessment document for a vault — and adds a distinguishing property (the only artifact a third party can publish on chain under their own name) that separates it from sibling vault readings. It is clear what the tool returns, though it never plainly contrasts itself with named siblings such as vault_check or vault_risk_dimensions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the agent learns to read data.document.refusals before treating a missing dimension as unknown, and to pass an older methodology to re-check an old hash, with the version list on /v1/meta. There is no explicit when-to-use/when-not versus the many sibling vault tools, so the agent must infer the boundary.

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?