Skip to main content
Glama

ASPERN: counterparty checks for agents

Six risks across every vault we score

vault_risk_dimensions
Idempotent

SIX RISKS, NOT ONE WORD, across every vault we score. A risk band is a weighted whole and a reader takes it as a summary of everything, which it is not: ours weighs drawdown, crowding, exit, concentration and consistency, and it contains NO reading of who may move the money. Two vaults read low while a multisig needing a single signature controlled them. So this groups what is already measured into market, liquidity, concentration and operating risk, ADDS the controller as its own dimension, and ADDS evidence — how much of the vault we could read at all. There is deliberately NO overall figure: a composite would be the number everybody quotes and nobody can check. THE FINDING IS FREE: population says how many scored vaults carry a band that reads BETTER than one of their own dimensions, and how many of those read worse on a dimension the band never contained — which is the number to read before trusting any one word on this platform. THE LIST IS PAID (dimensions.read): which vaults, with each one’s six levels, what it holds, and a sentence naming the disagreement. locked says when it is withheld, so an empty items is never mistaken for no matches — denominators.matchedTheFilter counts them either way. For ONE vault the whole table is FREE at vault_check, which also computes what else it could not see. Filter with dimension and level to run the screen that matters, e.g. the vaults whose controller reads high.

Input Schema

NameRequiredDescriptionDefault
levelNoThe level to keep. With `dimension` it applies to that one; alone it keeps any vault reading this on ANY dimension, which is the fastest way to find everything that reads `severe` somewhere.
limitNoRows to return, 1 to 200, default 50. The population figures are over EVERYTHING scored and never over the page.
offsetNoRows to skip, for walking a long list. `denominators.matchedTheFilter` is the total to walk.
dimensionNoKeep only vaults with a READING on this dimension, and with `level` keep only those at that level. Without `level` it keeps every vault whose dimension read at all, which excludes the unread — an unread dimension is our coverage and never a level.
disagreeingNoSend `true` to keep only the vaults whose overall band reads BETTER than at least one of their own dimensions. This is the screen the dimensions exist for: it is where reading the single word would have misled you.

Output Schema

NameRequiredDescriptionDefault
asOfNoWhen this was assembled. Each row carries its own `asOf`: the scores were taken at different moments, so this is a register of readings and not a snapshot.
metaNoHow 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.
itemsYesPAID. One row per vault: `slug`, `name`, `tvlUsd`, `band`, `levels` keyed by dimension, `coverage` with the component COUNTS behind the evidence dimension, `worseThanBand`, `outsideTheBand`, `says` and `asOf`. EMPTY where withheld, which `locked` states — never read an empty list here as no matches.
limitsYesWhat this route does not do: nothing here is a new measurement, and its evidence dimension counts components only — `coverage.cannotSeeCount` is 0 for every vault and means NOT COMPUTED HERE, not "nothing was unreadable". The per-vault `vault_check` computes it properly and is free.
lockedNoNull for a caller entitled to the list. Otherwise it names the capability, the number of free rows, and says plainly that the rest is withheld rather than absent.
warningsNoAnything the server wants a caller to know about THIS answer before acting on it. Empty is the normal case and is not a guarantee.
withheldYesHow many matching vaults are NOT in `items`. Zero for an entitled caller. For everybody else it is the difference between what matched and the free rows, so a short list is never mistaken for a short population.
populationYesFREE. `scored` is the denominator, `disagreeing` how many carry a band better than one of their dimensions, `withARiskOutsideTheBand` how many read worse on a dimension the band does not contain, `byDimension` which dimension does it and how often, and `says` the finding in a sentence. Computed over everything scored, BEFORE any filter: a headline over a filtered set would be a headline about the filter.
denominatorsYesWhat every figure above is over: `openVaults`, `scored`, `neverScored` (named rather than left to subtraction, because a vault nobody scored must never read as one that scored well), `matchedTheFilter` and `returned`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

It discloses far more than the annotations: what is free (`population`) versus paid (`dimensions.read`), what `locked` means so an empty `items` is never mistaken for no matches, that `denominators.matchedTheFilter` counts withheld rows, and that there is deliberately no composite score. The paid list also explains the otherwise puzzling readOnlyHint=false for what is functionally a listing tool.

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 key differentiator (six dimensions, controller added, no composite) is front-loaded, but the rhetorical register — ALL CAPS emphasis, 'SIX RISKS, NOT ONE WORD', 'THE FINDING IS FREE / THE LIST IS PAID' — adds length and flourish beyond what an agent needs. The density of real information is high, but several clauses restate the same point, so it is not tight enough for a 4.

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, yet the description still supplies the semantics an agent needs to read it — free population figures, paid item list, `locked` and the denominator behavior — plus the filter model. For a 5-parameter, no-required-parameter screening tool, nothing needed to call it correctly is missing.

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 carries the parameter burden and the baseline is 3. The description adds a layer of meaning beyond it by framing `dimension`+`level` as a screening combination with the concrete example of 'controller reads high', and by explaining `disagreeing` as the screen the dimensions exist for rather than just a boolean.

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 names the resource precisely (vault risk broken into market, liquidity, concentration, operating, controller and evidence dimensions) and states what the tool adds over existing measurement — the controller dimension and an evidence/coverage dimension. It also routes single-vault lookups to a named sibling (vault_check), so an agent can distinguish this list-level screen from the single-vault tool. It never states the verb as cleanly as 'list' and doesn't contrast with find_vaults/list_vaults, so it falls short of a 5.

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 gives concrete usage conditions — filter by `dimension` and `level` to run the screen that matters, e.g. vaults whose controller reads `high`, and use `disagreeing` for the screen the dimensions exist for — plus the free/paid boundary and the alternative (vault_check) for a single vault. No explicit 'when not to use this' beyond the single-vault case, so it is clear context without full exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources