ASPERN: counterparty checks for agents

Could you get your money back out (paid)

vault_exit_confidence

Idempotent

Before you put capital in, ask what evidence there is that you could get a PARTICULAR amount back out. Every other reading about a vault is about return or about risk of loss; this is about the practical question a holder has, and it is always about a size: "can I get out" has no answer, "can I get $2m out of a vault with $400k free and 25,941 settled withdrawals behind it" has several. Six readings, each with its own verdict and the question it answers in a holder’s own words: has anybody actually got money out, is there anything in it now, could YOUR amount leave, is somebody queued ahead of you, how much of the capital is lent out, and can somebody change the terms under you. The answer is the WORST of them and never an average — a queue in front of you is not offset by a long history, it happens before your turn — and an unknown outranks a supports, because a gap we could not read must never be counted as a pass. not-asked marks a component whose input you did not send, and not-applicable one this venue does not have at all — only two venues have an exit queue to be behind. Neither is a gap in our record and neither lowers the answer. A withdrawable figure is a FLOOR on venues whose vaults lend into markets holding their own liquidity, and the component says so rather than reading it as a ceiling. NOTHING HERE IS A GUARANTEE of withdrawal and no sentence it emits contains the word: a vault that has paid everybody for a year can stop tomorrow. PAID.

Input Schema

Name	Required	Description	Default
`slug`	Yes	The vault’s slug, or its contract address — either resolves.
`amountUsd`	No	What you are thinking of taking out, in dollars. Send it: without it the sizing component reports `not-asked` and you get the general picture rather than an answer about you.

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 worst component in one sentence, with what it does and does not mean.
`slug`	Yes	The vault this is about, read back, so an answer cannot be attached to the wrong one.
`limits`	Yes	Why the answer is the worst component rather than an average, and why no sentence here contains the word guarantee.
`summary`	Yes	The worst component. Never an average and never a score.
`verdicts`	No	What each verdict means, beside the answer rather than in documentation you have to find.
`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.
`amountUsd`	No	The amount asked about. Null means the sizing did not run.
`cannotSee`	Yes	What this structurally cannot contain, so a supporting answer is never read as an assured exit.
`components`	Yes	Each reading: `key`, the `asks` it answers, its `verdict` and what it read.

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

AddedOct 11, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, idempotent=true, openWorld=true) the description adds substantial behavioral semantics: the answer is the WORST component and never an average, 'unknown' outranks 'supports', 'not-asked' vs 'not-applicable' handling, the withdrawable figure is a FLOOR, and the 'PAID' marker discloses cost that annotations do not. It also disclaims that nothing is a guarantee of withdrawal. This is meaningfully richer than the structured fields alone.

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 in the first sentence, and most sentences carry real semantics (worst-of rule, unknown ranking, floor semantics). However it is long for a two-parameter tool and includes rhetorical padding such as the '$2m out of a vault with $400k free' illustration and the repeated 'PAID' emphasis, which dilute rather than inform.

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 is not obliged to explain return values, yet it covers verdict aggregation, unknown handling, and the floor caveat thoroughly. Inputs, semantics, and limitations are all addressed; what is missing is any explicit sibling routing or when-not-to-use guidance.

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 schema already documents slug and amountUsd; the description nonetheless reinforces why amountUsd matters ('it is always about a size', a bare 'can I get out' has no answer) and warns that omitting it downgrades the result to a general picture. That adds interpretive value over the raw schema description, though it does not introduce new parameter mechanics.

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 description states a specific capability: judging the evidence that a holder could withdraw a particular dollar amount from a vault, via six named readings with individual verdicts. It conceptually distinguishes itself from other vault readings by saying 'every other reading about a vault is about return or about risk of loss', though it never names the sibling tools (vault_exits, vault_risk_dimensions) it is contrasted against. An agent knows what this does, but not precisely which sibling it should pick instead.

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 through 'Before you put capital in, ask what evidence there is' and the schema note that omitting amountUsd gives only a general picture. There is no explicit statement of alternatives or when-not-to-use, and no named sibling to route to. Guidance is present but situational rather than directive.

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?