ASPERN: counterparty checks for agents

Try a withdrawal before making it (free up to $1,000)

simulate_withdrawal

Idempotent

TRY ONE WITHDRAWAL FROM A VAULT BEFORE YOU MAKE IT. Runs the vault’s own withdraw(amount, holder, holder) by eth_call at the head block, as the holder you name or, if you name none, as its largest depositor: the contract executes and nothing is signed, sent or spent. Says whether it would have gone through, the revert reason where it would not (e.g. NotEnoughLiquidity, TransferReverted past a V2 vault’s idle balance), the block, and what the holder’s position was worth; a size over what the holder owns is tried at their position and said so. It does NOT show a later block, or what happens once somebody else takes the same free money. Morpho vaults for now; anything else answers simulated: false and is not charged. FREE up to $1,000; over it PAID, $2 a simulation over x402, or free with a decision pass from this vault’s due-diligence report.

Input Schema

Name	Required	Description
`pass`	No	A decision pass from this vault’s due-diligence report (its X-ASPERN-Decision-Pass header): simulations over $1,000 on that vault without paying again.
`vault`	Yes	The vault slug, or an address we can resolve to one. `list_vaults` or `find_vaults` find a slug.
`holder`	No	The address to withdraw as. Leave it out to try as the vault’s largest depositor.
`amountUsd`	Yes	How much to withdraw, in US dollars. Up to 1000 is free.

Output Schema

Name	Required	Description
`at`	No	When, UTC.
`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 answer in one paragraph.
`block`	No	The block it was simulated at.
`price`	Yes	`usd` for a paid simulation and `freeUpToUsd`.
`vault`	Yes	The vault slug the request resolved to.
`holder`	No	The address the withdrawal was tried as.
`paidBy`	No	free, report-pass or this-call.
`reason`	No	The revert reason where it would have reverted.
`askedUsd`	No	The amount asked.
`holderAs`	No	named or largest-depositor.
`triedUsd`	No	The amount tried: the amount asked, or the holder’s position less 0.1% where they own less.
`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.
`holderUsd`	No	What that holder’s shares were worth at the block.
`simulated`	Yes	Whether a withdrawal was run. False where the vault is not one we simulate, no endpoint answered, or there was no holder to try as; nothing is charged then.
`limitations`	No	What one simulation does not show.
`wouldGoThrough`	Yes	True if the withdrawal would have gone through at that block, false if it would have reverted, null where nothing was tried.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 2, 2026

changedOutput schema / properties / askedUsd / type

Previous value: -"number"New value: +[
+  "number",
+  "null"
+]

changedOutput schema / properties / at / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / block / type

Previous value: -"number"New value: +[
+  "number",
+  "null"
+]

changedOutput schema / properties / holder / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / holderAs / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / holderUsd / type

Previous value: -"number"New value: +[
+  "number",
+  "null"
+]

changedOutput schema / properties / paidBy / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / triedUsd / type

Previous value: -"number"New value: +[
+  "number",
+  "null"
+]

AddedNov 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only give generic safety hints, so the description carries the real load and delivers: no signing/sending/spending, head-block-only scope, per-holder defaulting, revert reasons surfaced (NotEnoughLiquidity, TransferReverted past V2 idle balance), oversize amounts clamped to position, unsupported chains not charged, and the x402 pricing model.

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 an all-caps imperative and ordered from what it does to limits to pricing. The middle is dense with stacked parentheticals and em-dashes, so some sentences require a second read, but no content is filler.

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?

Covers scope, mechanism, failure modes, unsupported-vault behavior, indirection via list_vaults/find_vaults, and cost model; an output schema exists, yet the description still sketches the return shape well enough to plan around it.

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 meaning beyond the schema by explaining what happens when amountUsd exceeds the holder's position (tried at their position and reported as such) and by tying `pass` to free over-limit simulations on that vault.

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?

A specific verb plus resource plus mechanism: it runs the vault's own withdraw(amount, holder, holder) via eth_call at the head block. It also draws a clear line against adjacent tools (it simulates a call, it does not screen exits or report positions), so an agent can distinguish it from siblings like exit_screen or vault_exits.

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?

The opening line states the timing ('BEFORE YOU MAKE IT') and the description adds the boundary condition that only Morpho vaults are supported (others return simulated: false unpaid), plus the free/paid threshold. It does not name a sibling as the alternative to use instead, which keeps it just short of a 5.

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?