ASPERN: counterparty checks for agents

What the vaults you hold share

portfolio_screen

Read-onlyIdempotent

READ THE VAULTS YOU HOLD TOGETHER. This one is about a SET rather than a single subject; an allocator does not hold one subject. This answers the three questions that only exist across holdings and that no vault page can show you: a CONTROLLER behind more than one of them, a MARKET behind more than one of them, and an EXIT that is not the sum of the exits. It is a screen, not advice: there is no allocation percentage and no expected return in this answer and there never will be. THE EXIT IS FOUR FIGURES AND THEY ARE NEVER ADDED UP — declared (the venue publishes a withdrawable figure), behind-a-queue (we have READ that a request comes first, so nothing leaves today at any price whatever cash is sitting there), floor-only (the only reading is uninvested cash, a lower bound) and unread — because a portfolio that is 40% readable is not a portfolio that is 40% liquid. A queue OUTRANKS a declared figure: a vault can publish a number and still take a request first, and the number is then what a request settles from. The exit split, the coverage and the bands are FREE, and so is every per-vault reading behind them at vault_check; a plan buys what the holdings SHARE. It cannot verify that you hold any of this.

Input Schema

Name	Required	Description	Default
`holdings`	Yes	The vaults you hold, as `slug:usd,slug:usd`. The amount after each slug is OPTIONAL and the answer is useful without it: leave it off and every figure counts holdings rather than dollars, and `positionsNotStated` says how many. Where you price SOME of them, a shared exposure whose sharers are not all priced reports `positionUsd: null` rather than a partial sum, because a partial sum reads as a complete one. At most 50 holdings.

Output Schema

Name	Required	Description
`exit`	Yes	FOUR CLASSES, NEVER SUMMED: `declared`, `behind-a-queue`, `floor-only`, `unread`, each with `holdings` and `positionUsd`. Read `behind-a-queue` first: that is money nothing can be taken from today.
`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 findings in words, including what was not stated.
`asked`	No	How many holdings you named.
`notHeld`	No	The slugs we do not hold at all, LISTED rather than dropped: a portfolio quietly one short is the wrong answer to the question you asked.
`coverage`	Yes	The share of your holdings carrying each reading at all: `risk`, `exit`, `control`, `markets`. A control band of `unknown` counts as UNREAD, because it is.
`resolved`	No	How many of them we hold a vault for.
`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.
`cannotSee`	Yes	What this answer does not contain, starting with the fact that we cannot verify you hold any of it, and ending with the fact that it is not advice.
`byRiskBand`	No	Holdings per published risk band, with `unread` as its own key rather than folded into low.
`positionUsd`	No	The total you stated, over the holdings you priced. Null where you priced none.
`sharedVenues`	No	PAID. Venues and chains carrying more than one holding. NULL where withheld.
`byControlBand`	No	Holdings per control arrangement: `unguarded`, `thin`, `checked`, `unread`.
`sharedMarkets`	No	PAID. Markets or collateral more than one holding lends against. A vault page gives your share OF that market; this says how much of YOUR money is behind it. NULL where withheld.
`sharedControllers`	No	PAID. Controllers that can move the money in MORE THAN ONE of your holdings, with the slugs and your stated position behind each. Reading the vaults one at a time shows one controller each; held together they are one bet. NULL where withheld, which `detailRequires` states — never read a null here as "nothing is shared".
`positionsNotStated`	No	Holdings you named without an amount. Every dollar figure in this answer excludes them.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 18, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely non-duplicated behavior: a queue OUTRANKS a declared exit figure, the four exit readings are never summed, and the tool cannot verify that the caller actually holds the listed vaults. Minor shortfall: it never discusses rate limits, cost, or what 'a plan buys' concretely means.

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 definition is long and written in an idiosyncratic all-caps register that makes a single-sentence point ('four figures, never added up') across several clauses. Most sentences do carry information, but prose could be compressed without loss.

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-shape explanation is not required, and the description still goes beyond it by pre-empting the two obvious misreadings of the exit output (adding four figures, treating coverage as liquidity). Scope, limitations and routing are all present; only plan/cost semantics are left unspecified.

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% and the property description already carries the format, optionality, pricing rules, null-versus-partial-sum behavior and the 50-holding cap. The tool description contributes only the caveat that holdings cannot be verified, so baseline 3 is appropriate.

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?

The first sentence states the verb and resource precisely ('READ THE VAULTS YOU HOLD TOGETHER') and immediately scopes it as a set-level operation, naming the three cross-holding questions it answers (shared controller, shared market, non-additive exit). It explicitly distinguishes itself from the sibling vault_check ('every per-vault reading behind them at vault_check'), so an agent can route without opening either schema.

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 states when this tool is the right one (cross-holding shared exposure that 'no vault page can show you') and points at vault_check for the free per-vault readings it sits on top of. It also states a boundary ('It cannot verify that you hold any of this'). There is no crisp when-not/exclusion list beyond the vault_check handoff, 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?