ASPERN: counterparty checks for agents

How much capital we can actually read

capital_coverage

Read-onlyIdempotent

BEFORE YOU TRUST ANY COVERAGE FIGURE FROM US, ask this. It says how much of the market each vault reading actually covers, counted TWO WAYS: by number of open vaults and by the capital in them. They differ by a lot, and the difference is the finding — more than half our vault COUNT is one venue’s small automated vaults, so a count-weighted coverage figure is mostly a statement about that venue and tells you almost nothing about whether the capital you care about is covered. NEITHER is called "the coverage". Free, because it is a statement about OUR OWN limits and a coverage claim nobody can audit is marketing rather than evidence. It says what we CAN read and never whether a vault is any good; WHICH vaults are missing a reading is the paid screen, not this. Readings: would take a deposit, risk score, withdrawable now, crowding, how exit works, time to exit, worst fall, who can move the money, what a holder earned — the same 9 columns the vault screen shows, read from the same expressions.

Input Schema

Name	Required	Description	Default
No arguments

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.
`rows`	Yes	One per reading: `key`, `label`, `vaults`, `tvlUsd`, `byCount` and `byCapital` (0..1, null where no capital was read at all — not a cover of nothing), plus `says` for what the reading lets you decide and `screenColumn` for the vault-screen column asking the same question. SOME READINGS CANNOT BE PUT TO SOME VAULTS AT ALL, and where that is so the row also carries `notApplicable` {vaults, tvlUsd, because} with `byCountApplicable` and `byCapitalApplicable` beside the plain shares. Read those two for the question "how much of what we COULD read have we read", and the plain ones for "how much of everything". A vault that mints one share per unit of asset has not failed to earn anything through its price, and a redeem that settles in the asking transaction has no notice period to state — counting either as a gap would make our coverage look worse than it is in a way that is just as dishonest as making it look better. The two shares are never equal where `notApplicable` is present, and `because` names what put those vaults outside.
`says`	Yes	The widest and thinnest readings by capital, and whether counting vaults and weighing capital disagree.
`limits`	Yes	What these figures are not.
`byVenue`	No	THE SAME QUESTION PER PROTOCOL, which is the one to ask if you hold something specific: the shares elsewhere on this answer say how much of OUR capital carries each reading, and this says whether we cover the venue you are in. Twenty venues, biggest by capital first, each with `tvlUsd`, a `readings` map of share-of-capital per reading, and `fullyEvidenced` asking the hardest question of that venue alone. Every share is BY CAPITAL and NULL where the venue has no capital we could weigh — a venue we cannot weigh is not a venue with no coverage, and a zero there would say the opposite.
`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.
`measuredAt`	No	When the coverage was counted. Null means the job has never run, which `says` states rather than reporting zeros.
`tvlTotalUsd`	No	Capital across them, in US dollars. The denominator of every `byCapital`.
`vaultsTotal`	No	Open vaults. The denominator of every `byCount`.
`fullyEvidenced`	No	THE NUMBER TO READ FIRST if you are deciding how far to trust this platform on a given market: the share of capital carrying EVERY reading at once — a realised return, free liquidity, a risk band, who may move the money, how redemption works, and capital re-read within 48 hours. It cannot be worked out from the shares below, because a vault missing a different one from its neighbour drops out of both, and it is deliberately the least flattering figure on this answer.
`vaultsWithNoSizeRead`	No	Open vaults whose SIZE we never read. They are in the count denominator and cannot be in the capital one, which is why this is named rather than left to subtraction.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 17, 2026

changedOutput schema / properties / fullyEvidenced / description

Previous value: -"THE NUMBER TO READ FIRST if you are deciding how far to trust this platform on a given market: the share of capital carrying EVERY reading at once — a realised return, free liquidity, a risk band, who may move the money, how redemption works, and capital re-read within 48 hours. It cannot be worked out from the six shares below, because a vault missing a different one from its neighbour drops out of both, and it is deliberately the least flattering figure on this answer."New value: +"THE NUMBER TO READ FIRST if you are deciding how far to trust this platform on a given market: the share of capital carrying EVERY reading at once — a realised return, free liquidity, a risk band, who may move the money, how redemption works, and capital re-read within 48 hours. It cannot be worked out from the shares below, because a vault missing a different one from its neighbour drops out of both, and it is deliberately the least flattering figure on this answer."

changedOutput schema / properties / rows / description

Previous value: -"One per reading: `key`, `label`, `vaults`, `tvlUsd`, `byCount` and `byCapital` (0..1, null where no capital was read at all — not a cover of nothing), plus `says` for what the reading lets you decide and `screenColumn` for the vault-screen column asking the same question."New value: +"One per reading: `key`, `label`, `vaults`, `tvlUsd`, `byCount` and `byCapital` (0..1, null where no capital was read at all — not a cover of nothing), plus `says` for what the reading lets you decide and `screenColumn` for the vault-screen column asking the same question. SOME READINGS CANNOT BE PUT TO SOME VAULTS AT ALL, and where that is so the row also carries `notApplicable` {vaults, tvlUsd, because} with `byCountApplicable` and `byCapitalApplicable` beside the plain shares. Read those two for the question \"how much of what we COULD read have we read\", and the plain ones for \"how much of everything\". A vault that mints one share per unit of asset has not failed to earn anything through its price, and a redeem that settles in the asking transaction has no notice period to state — counting either as a gap would make our coverage look worse than it is in a way that is just as dishonest as making it look better. The two shares are never equal where `notApplicable` is present, and `because` names what put those vaults outside."

Changed1 schema field changedOct 15, 2026

addedOutput schema / properties / byVenue

Added value: +{
+  "description": "THE SAME QUESTION PER PROTOCOL, which is the one to ask if you hold something specific: the shares elsewhere on this answer say how much of OUR capital carries each reading, and this says whether we cover the venue you are in. Twenty venues, biggest by capital first, each with `tvlUsd`, a `readings` map of share-of-capital per reading, and `fullyEvidenced` asking the hardest question of that venue alone. Every share is BY CAPITAL and NULL where the venue has no capital we could weigh — a venue we cannot weigh is not a venue with no coverage, and a zero there would say the opposite.",
+  "type": [
+    "array",
+    "null"
+  ]
+}

AddedOct 15, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real context beyond them: it is free, it is a statement about the service's own limits, and it makes no quality judgement. It does not describe response shape, but the output schema covers that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the key instruction, but the body is rambling and repetitive ('It says what we CAN read and never whether a vault is any good' restates earlier points), and the closing enumeration of nine columns is largely tangential for a no-argument metric 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?

For a no-param read tool with a full output schema and safety annotations, the description supplies the missing framing (what the numbers mean, that they are two distinct counts, that this is not a quality verdict). Return values need not be described given the output schema.

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?

Zero parameters, so the baseline of 4 applies; there is nothing for the description to clarify or compensate for.

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?

It states a specific resource — the coverage of each vault reading, counted two ways (open-vault count and capital) — and explicitly separates itself from the paid screen that lists which vaults are missing. That is enough to tell it apart from list_vaults/find_vaults, though no sibling is named directly.

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 imperative ('BEFORE YOU TRUST ANY COVERAGE FIGURE FROM US, ask this') gives a clear when-to-use trigger, and it states a when-not ('never whether a vault is any good'; the missing-vaults screen is a different, paid tool). No alternative tool is named, so it falls 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?