ASPERN: counterparty checks for agents

Where one vault is exposed

vault_exposure_graph

Read-onlyIdempotent

Where one vault’s capital is exposed, as a graph: vault → market → collateral, loan asset and oracle. Every edge carries its size in dollars, its share of what the vault allocates, the vault’s share of the market, the LLTV where it secures, when it was read and where from. Cut from the vault’s due-diligence document, the same engine the report and vault_check use, so it says nothing the report does not. A node not fully read has state: unknown and says what was not read (an oracle’s feeds are never assessed here), and capital in no market read is its own node, never dropped. Free. It does not assess the collateral’s quality, the borrowers or the oracle, and it is not a block-level reconciliation.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>"
    },
    "name": "vault_exposure_graph"
  }
}

Input Schema

Name	Required	Description	Default
`slug`	Yes	Vault slug or contract address.

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	What the graph holds, in one sentence.
`edges`	Yes	from, to, kind (supplies, secured-by, lends, priced-by, not-placed), usd, shareOfAllocated, shareOfMarket, lltv, readAt, source.
`nodes`	Yes	id, kind (vault, market, collateral, loan-asset, oracle, unplaced), label, state (read or unknown), unread, address.
`vault`	Yes	The vault, by slug.
`limits`	Yes	What it does not assess.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly, idempotent, non-destructive, open-world); the description adds substantial behavior beyond them. It specifies what each edge carries (dollar size, share of vault allocation, vault's share of market, LLTV, read timestamp and source), how incomplete reads surface (`state: unknown` plus what was not read), that unallocated capital appears as its own node and is never dropped, that the call is free, and that it is not a block-level reconciliation.

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?

Content is front-loaded with the graph shape first, then edge payload, then caveats, which is the right order. The prose is dense and largely earns its space, though a few clauses (e.g. 'so it says nothing the report does not') are wordier than needed for the point they make.

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?

An output schema exists, so return values need not be re-explained, yet the description still previews the edge fields and the unknown-state convention. Combined with the explicit negative scope (no collateral/borrower/oracle quality, no block-level reconciliation), an agent has everything needed to call it and to interpret gaps 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?

There is a single required parameter and the schema documents it fully at 100% coverage ('Vault slug or contract address'). The description adds no further meaning about slug resolution or fallback behavior, so the baseline of 3 applies — the schema does the work here.

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 description names a specific output artifact and its shape: 'Where one vault's capital is exposed, as a graph: vault → market → collateral, loan asset and oracle.' That is far more precise than the title, and it positions the tool against siblings by noting it is 'cut from the vault's due-diligence document' using the same engine as the report and vault_check.

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 description gives clear routing context — it is the graph view of the same data the due-diligence report and vault_check already produce, so an agent knows not to expect anything beyond those. It also states explicit scope exclusions ('does not assess the collateral's quality, the borrowers or the oracle'). It stops short of naming a direct alternative for overlapping questions such as capital_coverage or vault_risk_dimensions.

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.