ASPERN: counterparty checks for agents

Find a vault by what it has done

find_vaults

Read-onlyIdempotent

Find a vault by what it has DONE rather than what it is called. Free. The filter worth knowing is earned: short returns the vaults where a holder earned LESS than the venue advertises — how many there are is in the answer, never here — and beating the ones where they earned more. It matches only vaults whose realised return is COMPARABLE with an advertised one, which is a SMALL part of the open vaults and the exact share is in vaults_earned, not in this sentence; a venue that quotes nothing or a share price that never moves is excluded rather than counted as in-line, so a short list here means few comparable and not few that performed. Call vault_check on a slug for the full answer.

Input Schema

Name	Required	Description
`q`	No	Part of a name or an address.
`chain`	No	e.g. base, solana, hyperliquid.
`limit`	No	Default 25, capped at 100.
`earned`	No	in-line, beating or short — realised against advertised, comparable cases only.
`minTvl`	No	Floor on stated size, in US dollars.
`offset`	No	Where to start, for the next page: send the `nextOffset` of the previous answer. Default 0.
`maxRisk`	No	Ceiling on the published risk score. Scored for a part of the open vaults and not all of them; the unscored are EXCLUDED from a scored filter, which is not the same as scoring well, and the counts are on the answer rather than here.
`platform`	No	A platform id or its display name, e.g. morpho or Hyperliquid.
`minOwnShare`	No	Floor on the share of the vault its leader holds, 0 to 1. Readable on Hyperliquid and Drift only, so a floor on it excludes every other venue, where it is ABSENT and not zero. How many that is today is in the answer. Evidence of alignment, never proof: the holder can be a treasury or a custodian.
`agentManaged`	No	Only vaults a machine runs.

Output Schema

Name	Required	Description
`data`	Yes	Each with its slug, which vault_check takes.
`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.
`fields`	No	Which fields this tool kept from the endpoint’s own rows.
`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.

Changed1 schema field changedOct 29, 2026

addedInput schema / properties / offset

Added value: +{
+  "description": "Where to start, for the next page: send the `nextOffset` of the previous answer. Default 0.",
+  "type": "number"
+}

Changed5 schema fields changedOct 15, 2026

changedInput schema / properties / maxRisk / description

Previous value: -"Ceiling on the published risk score. Scored for 936 of 3,394 open vaults; the unscored are excluded, which is not the same as scoring well."New value: +"Ceiling on the published risk score. Scored for a part of the open vaults and not all of them; the unscored are EXCLUDED from a scored filter, which is not the same as scoring well, and the counts are on the answer rather than here."

changedInput schema / properties / minOwnShare / description

Previous value: -"Floor on the share of the vault its leader holds, 0 to 1. Readable on Hyperliquid and Drift only — 584 of 3,394 open vaults — so a floor excludes every other venue, where it is ABSENT and not zero. Evidence of alignment, never proof: the holder can be a treasury or a custodian."New value: +"Floor on the share of the vault its leader holds, 0 to 1. Readable on Hyperliquid and Drift only, so a floor on it excludes every other venue, where it is ABSENT and not zero. How many that is today is in the answer. Evidence of alignment, never proof: the holder can be a treasury or a custodian."

addedOutput schema / properties / meta

Added value: +{
+  "description": "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.",
+  "type": "object"
+}

changedOutput schema / properties / warnings / description

Previous value: -"READ THESE: an `earned` or `minOwnShare` floor carries what it excluded, and the denominator is not visible from the rows."New value: +"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."

changedOutput schema / properties / warnings / items / type
```
Previous value: -"object"New value: +"string"
```

Changed5 schema fields changedSep 26, 2026

addedOutput schema / properties / data

Added value: +{
+  "description": "Each with its slug, which vault_check takes.",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / fields

Added value: +{
+  "description": "Which fields this tool kept from the endpoint’s own rows.",
+  "type": "string"
+}

removedOutput schema / properties / items

Removed value: -{
-  "description": "Each with its slug, which vault_check takes.",
-  "items": {
-    "type": "object"
-  },
-  "type": "array"
-}

changedOutput schema / properties / warnings / description

Previous value: -"Read these: an `earned` filter carries what it excluded."New value: +"READ THESE: an `earned` or `minOwnShare` floor carries what it excluded, and the denominator is not visible from the rows."

addedOutput schema / required
```
Added value: +[
+  "data"
+]
```

Changed1 schema field changedSep 26, 2026

addedInput schema / properties / minOwnShare

Added value: +{
+  "description": "Floor on the share of the vault its leader holds, 0 to 1. Readable on Hyperliquid and Drift only — 584 of 3,394 open vaults — so a floor excludes every other venue, where it is ABSENT and not zero. Evidence of alignment, never proof: the holder can be a treasury or a custodian.",
+  "type": "number"
+}

AddedSep 26, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already establish this as a safe, read-only, idempotent, open-world read. The description adds meaningful behavioral context beyond annotations: the call is free, the `earned` filter only matches comparable advertised/realised returns, venues with no quote or static share price are excluded, and a short list means few comparable cases rather than few performers.

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 and the caveats are relevant, but the description is noticeably wordy and repeats the same idea several times, such as counts being in the answer rather than here. For a 10-parameter tool with full schema coverage, some of the emphasis could be tightened without losing meaning.

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?

Given the rich schema, annotations, and output schema, the description supplies the additional context an agent needs: the tool's performance-based discovery purpose, the meaning and limits of the `earned` filter, and the handoff to `vault_check` for detail. Return-value details and other parameters are appropriately left to the structured fields.

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 itself documents all ten parameters. The description nonetheless adds substantive meaning for the key `earned` parameter by explaining `short` and `beating` and the comparability/exclusion rules, though it does not add semantics for the other parameters.

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 states a specific verb and resource, and crucially distinguishes the tool from name-based discovery: it finds a vault by what it has DONE rather than what it is called. It also names the `earned` filter as the key mechanism, which lets an agent understand its distinct purpose relative to generic vault listing.

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 usage context for the `earned` filter, including what `short` and `beating` return, and directs the agent to `vault_check` on a slug for the full answer. It does not explicitly compare `find_vaults` to the sibling `list_vaults`, so the alternative-selection guidance is slightly incomplete.

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?