org.aspern/aspern
REMOTE · ASPERN.ORG · SCANNED SEP 28
What the chain records about an address before you pay it, and whether a payment fits it.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security74
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one. See how to fix → View diagnostics → Partial
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability64
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 3527 tokens (~235/item across 15 items; 15 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management13
- Stability observed for 4 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 15 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 16 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities60
- Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28. See how to fix → Fail
How do I install the org.aspern/aspern MCP server?
org.aspern/aspern is a hosted endpoint at https://aspern.org/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · aspern.org
claude mcp add --transport http org-aspern-aspern 'https://aspern.org/mcp'
{
"mcpServers": {
"org-aspern-aspern": {
"url": "https://aspern.org/mcp"
}
}
} {
"servers": {
"org-aspern-aspern": {
"type": "http",
"url": "https://aspern.org/mcp"
}
}
} [mcp_servers.org-aspern-aspern] url = "https://aspern.org/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"org-aspern-aspern": {
"type": "remote",
"url": "https://aspern.org/mcp",
"enabled": true
}
}
} openclaw mcp add org-aspern-aspern --url 'https://aspern.org/mcp' --transport streamable-http
mcp_servers:
org-aspern-aspern:
url: "https://aspern.org/mcp" {
"McpServers": {
"org-aspern-aspern": {
"Transport": "http",
"Url": "https://aspern.org/mcp"
}
}
} assistant mcp add org-aspern-aspern -t streamable-http -u 'https://aspern.org/mcp'
{
"mcpServers": {
"org-aspern-aspern": {
"type": "http",
"url": "https://aspern.org/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 28 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 27 Sept 26 +8
- Authorization: unverified → partial ▲ security
- Schema quality: 1409 → 2419 ▼ functional
- Tool coverage: 65% → 100% ▲ functional
- Tool “check_service_endpoint” now declares an output schema ▲ functional
- Tool “counterparty_bulk” now declares an output schema ▲ functional
- Tool “counterparty_check” now declares an output schema ▲ functional
- Tool “counterparty_history” now declares an output schema ▲ functional
- Tool “find_agents” now declares an output schema ▲ functional
- Tool “identify” now declares an output schema ▲ functional
- Tool “preflight_payment” now declares an output schema ▲ functional
- First check of Tool coverage: 100 functional
- Schema quality: good → excellent functional
- New tool “find_vaults” functional
- New tool “list_vaults” functional
- New tool “operator_check” functional
- New tool “vault_check” functional
- “counterparty_history” reworded the description of “address” cosmetic
- “counterparty_history” reworded the description of “days” cosmetic
- “find_agents” reworded the description of “minDealings” cosmetic
- “find_agents” reworded the description of “minIndependent” cosmetic
- “find_agents” reworded the description of “noTwoWay” cosmetic
- “find_agents” reworded the description of “registered” cosmetic
- “find_agents” reworded the description of “serving” cosmetic
- “find_agents” reworded the description of “sort” cosmetic
- Tool “check_service_endpoint” changed its title: Check a service endpoint before connecting cosmetic
- Tool “counterparty_bulk” changed its title: Check up to fifty addresses in one call (paid) cosmetic
- Tool “counterparty_check” changed its title: What the chain records about one address cosmetic
- Tool “counterparty_history” changed its title: One agent’s record day by day (paid) cosmetic
- Tool “find_agents” changed its title: Find agents by what the record shows cosmetic
- Tool “identify” changed its title: Identify the party behind an identifier cosmetic
- Tool “preflight_payment” changed its title: Weigh one payment before sending it cosmetic
- 26 Sept 26 +1
- Schema quality: 960 → 1409 ▼ functional
- New tool “check_service_endpoint” functional
- New tool “identify” functional
- 25 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 24 Sept 26 60
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 28 Sept 2026 · Probed https://aspern.org/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=aspern.org | CN=YE2,O=Let's Encrypt,C=US | 22 Sept 2026 | 21 Dec 2026 | ECDSA 256 | ECDSA-SHA384 | 59013455066e68eefb7d547ba98d15b8366 |
| SANs: aspern.org | ||||||
| CN=YE2,O=Let's Encrypt,C=US (CA) | CN=Root YE,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | ECDSA 384 | ECDSA-SHA384 | 4df3b15dd6c0784c507cd37b58e6f115 |
| CN=Root YE,O=ISRG,C=US (CA) | CN=ISRG Root X2,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | ECDSA-SHA384 | 872165fc34b6e5fba8add5b3705fb53a |
| CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | SHA256-RSA | 6c8f1dc727c7117f7baf853ac980f9cd |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of aspern.org. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| org. | present | 26974 | 8 | Verified |
| aspern.org. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://aspern.org/mcp | Verified | 200 | |
| http (plaintext) | http://aspern.org/mcp | HTTPS enforced | 308 | https://aspern.org/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
check_service_endpoint Check a service endpoint before connecting ~370
Call this before connecting to a service, the way preflight_payment is called before sending money. Give it the http(s) URL of an MCP or A2A endpoint and it says who declares it, whether our daily probe reached it, what it answered with, and how many of the last readings answered. It keeps three things apart and never merges them: what an identity DECLARES the endpoint offers, what a probe OBSERVED, and the readings behind that. Read `drift` where present — tools declared but not answering is the signal that an endpoint has changed under the people relying on it. It also answers the three things a buyer wants BEFORE calling a paid endpoint, as separate fields and never folded into one number: `price` is the seller’s own published amount, asset, network and payee; `handshake` says whether it answered without credentials, which is the nearest observable thing to “can I try it”; and `measured` is how many of how many days answered and how slow it was, which is what we read rather than a guarantee anybody made. `manifest` and `changes` answer the question a registry cannot: a registration says what an agent offers, and only a series of readings says what it offered LAST WEEK. Store `manifest.hash` and compare it next time to detect an endpoint that changed under you. Two things this is NOT: an unreachable endpoint is an availability fact and never evidence of bad faith (weigh `latest` against `history`, since one bad day and a dead service look identical in a single reading), and an endpoint we have never probed is outside our reading rather than absent from the world. Free.
| Name | Type | Req | Description |
|---|---|---|---|
| url | string | yes | The absolute http(s) URL of the service endpoint you are about to connect to. |
| Name | Type | Req | Description |
|---|---|---|---|
| changes | array | – | Every move we saw in what it offers, oldest first, each with `added`, `removed`, a protocol-version move where there was one, and the two hashes. `at` is the day we SAW the change, not the day it hap… |
| declaredBy | array | – | Identities that declare this endpoint, and the tools each one claims. Their claim, not our verification. |
| drift | object|null | – | Declared but not observed, and the reverse. Null where either side is unknown — subtracting silence would manufacture a finding. |
| endpoint | string | – | – |
| handshake | string|null | – | Whether the protocol HANDSHAKE completed without credentials on the latest reading. `open` is the closest thing here to “you can try it” and is NOT a statement that calling its tools is free — a serv… |
| history | array | – | Up to fourteen readings. One bad day and a dead service look identical in a single reading. |
| latest | object|null | – | The most recent probe: outcome, latency, and what it answered with. |
| manifest | object|null | – | What the endpoint offers NOW, as something you can bind to: `hash` over the sorted tool names and the declared protocol version and nothing else, with `tools`, `firstSeen`, `lastSeen` and how many re… |
| measured | object | – | What we measured, which is NOT a guarantee: nothing on these rails publishes one. `serving` of `days`, every outcome by how often, and median and worst latency of the readings that answered. Left as… |
| outcomes | object | – | What each outcome word means, so a caller never has to guess. |
| price | object|null | – | The seller’s OWN published terms for this URL: `amount` in the asset’s own units with `asset` named beside it (a bare number would be read as dollars), `network` as CAIP-2, `payTo`, which catalogues… |
| says | string | yes | – |
No examples provided.
counterparty_bulk Check up to fifty addresses in one call (paid) ~71
Check up to fifty addresses in one call, each with its observations: for an agent or a desk holding a list of counterparties before paying any of them. PAID, one cent a call over x402, priced per call rather than per address.
| Name | Type | Req | Description |
|---|---|---|---|
| addresses | array | yes | Up to 50. |
| Name | Type | Req | Description |
|---|---|---|---|
| checked | integer | – | How many addresses were read. |
| items | array | yes | One entry per address given, in the order given, each with its own observations and its own limits. |
| limits | string | – | What this answer cannot tell you. |
| payment | object | – | What was paid and how it settled. Priced per call, not per address. |
No examples provided.
counterparty_check What the chain records about one address ~182
Before paying or hiring an agent: what the chain records about that address. Independent payers (counterparties that paid it and were never paid back), the ones it does pay back, how concentrated its custom is, how its ACP jobs ended, whether its advertised service answers, and when it was last paid. Free. Two limits to repeat whenever quoting it: independent means no payment BACK on the rails we read, NOT proof the payers are different parties, since one owner can fund many addresses that never pay each other; and an all-time record says nothing about whether the agent still works — 44% of agents ever paid have not been paid in 90 days. Takes an EVM address, a Cardano payment address (addr1…) or a Solana address.
| Name | Type | Req | Description |
|---|---|---|---|
| address | string | yes | The address you are about to pay or hire. |
| Name | Type | Req | Description |
|---|---|---|---|
| acp | object | – | How its jobs ended, where it has any. |
| address | string | yes | – |
| alsoHere | object|null | – | The same address on the capital side — a vault or an operator — with the check to call. A match on the address, never an identification of the party. |
| dealings | object | – | rails, chains, counterparties, independent, largestShare, firstPaid, lastPaid. `independent` means no payment BACK on the rails we read — NOT proof the payers are different parties, since one owner c… |
| format | object | yes | What kind of address this is and what we read for it. |
| identity | object | – | Registrations it holds. Claims, never verification. |
| limits | string | yes | What this answer cannot tell you. Quote it with the numbers. |
| masumi | object|null | – | – |
| mech | object | – | – |
| observations | array | yes | The findings, each with its evidence class and its own words. Read these first. |
| paidFor | object|null | – | What it was paid for, in the subject’s own words. |
| services | object | – | Callable services it declares, and how many answered our probe. |
| x402 | object | – | – |
No examples provided.
counterparty_history One agent’s record day by day (paid) ~159
How one agent’s record has moved: dealings, independent payers, concentration and delivery, day by day. PAID, one cent a call over x402 — the median price of this rail. Without payment the tool answers with the price and how to pay it, and the free check remains available. The history begins the day we started keeping it; it is a record we keep, not one the chain gives away.
| Name | Type | Req | Description |
|---|---|---|---|
| address | string | yes | The agent whose record you want day by day. An EVM, Cardano or Solana address. |
| days | number | – | 1 to 365, default 90. The history begins the day we started keeping it, so a longer window does not reach further back than that. |
| Name | Type | Req | Description |
|---|---|---|---|
| address | string | yes | – |
| change | object|null | – | What moved across the window, and over which dates. |
| items | array | – | One entry per day: dealings, independent payers, concentration, delivery. |
| keptSince | string | – | The day we began keeping this. Nothing before it exists, at any window. |
| payment | object | – | What was paid and how it settled. Present because this call took money. |
No examples provided.
evaluate_action Weigh one action against a named policy ~411
Call this when you are about to DO something and need one answer you can act on: pay an address, connect to an MCP server, call a tool, or put capital into a vault. Unlike a reputation score, the answer depends on the AMOUNT, the ACTION, the POLICY you name and how much we actually read — so the same address can be `allow` for $5 and `abstain` for $5,000. Four decisions. `allow` means nothing we could check objects, up to `maxAmountUsd`, and is NOT a statement that the action is safe: nothing here sees what it is for or what you agreed. `review` means something we READ does not match, and `reasons` names which rule. `abstain` means we did not read enough to have an opinion — our gap, never approval. `unsupported` means the policy has no rule for this action, and inventing one would be worse than declining. Every rule id in `reasons` is published in full at the policies tool, including to the party being evaluated. Free.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | What you are about to do. |
| amountUsd | number | – | What you are about to commit, in US dollars. Leave it out and the amount rules report that they did not run, rather than passing. |
| chain | string | – | The chain the action settles on, e.g. base, polygon, solana. |
| policy | string | – | A policy version or slug. Defaults to conservative-v1. An unknown name is REFUSED rather than silently replaced with the default. |
| resource | string | – | The http(s) endpoint being bought or connected to, where that differs from `subject`. This is what reaches the seller’s own catalogue entry, carrying their price and their payee. |
| subject | string | yes | What you are about to do it to: an address to pay, an endpoint URL to connect to, or a vault slug. |
| Name | Type | Req | Description |
|---|---|---|---|
| coverage | string | yes | How much of what the policy wanted was actually there. Below the policy floor the decision is `abstain` rather than `allow`. |
| decision | string | yes | `allow` is not “safe” and `abstain` is not “nothing found”. Read `decisions` in the answer for what each one means. |
| decisions | object | – | What each decision word means, so a caller never has to guess. Read it before treating `allow` as approval or `abstain` as a clean result. |
| limits | string | – | – |
| maxAmountUsd | number|null | – | The most this policy permits for this proposal. Null where the action moves no money, and null on anything but an `allow`, because a limit printed beside a `review` reads as permission. |
| missingEvidence | array | – | Rule ids whose evidence we do not hold. These lower `coverage` and are NEVER counted as objections. |
| policy | object | – | The policy applied: its intent, its ceiling and the coverage floor below which it abstains. |
| policyVersion | string | yes | Carried so an answer given today can be reproduced after the rules change. |
| proposal | object | – | What you asked about, read back, so a typo is visible before you act on the answer. |
| reasons | array | yes | Rule ids that decided. Look them up in the policy to see the sentence each one checks. |
| rules | array | – | Every rule considered, each pass, fail or unknown. The audit trail for the decision. |
| says | string | yes | – |
No examples provided.
evidence_for Every edge we hold about one subject ~249
Everything we hold about one subject, as edges, each carrying where it came from. Use it when you need to explain a decision rather than just make one, or to see what is MISSING before you act. Every edge has `source`, `observedAt` (when the world was in that state), `asOf` (when we read it — a fresh read of a stale fact is not a fresh fact), a `confidence` that names what it is confident IN, its own `coverage`, and the `method` that established it. Edges come in three kinds and are NEVER summed: `declared` is the subject speaking about itself, `observed` is our reading, `derived` is arithmetic over the others. Adding them together rebuilds the reputation score this replaces. It infers NO identity: a shared host or funder is reported as exactly that, because being the same party is a conclusion no join supports. `lookedForAndMissing` lists what we searched for and did not find, so a thin subject never reads as a complete picture. Free.
| Name | Type | Req | Description |
|---|---|---|---|
| subject | string | yes | An address, or the http(s) URL of an endpoint. |
| Name | Type | Req | Description |
|---|---|---|---|
| counts | object | yes | Edges by kind. NOT a score: the three are reported apart and never added. |
| edges | array | yes | Each with claim, object, kind, source, observedAt, asOf, confidence {value, in}, coverage and method. |
| kinds | object | – | What declared, observed and derived each mean. |
| limits | string | – | – |
| lookedForAndMissing | array | – | What we searched for and did not find, with why. Listed rather than omitted. |
| says | string | yes | – |
| subject | string | yes | – |
| subjectKind | string | – | – |
No examples provided.
find_agents Find agents by what the record shows ~348
Find agents to hire by what the chain records rather than what they claim: filter every address ever paid on x402, Virtuals ACP, the Olas mech marketplace or Masumi by independent payers, dealings, ACP completion, whether its declared service answers, whether it pays its own payers back, and how recently it was paid. Free. An address absent from the result was never paid on a rail we read, which is not the same as never having worked.
| Name | Type | Req | Description |
|---|---|---|---|
| activeDays | number | – | Paid within this many days. |
| limit | number | – | Default 25, maximum 200. |
| minCompletion | number | – | ACP jobs completed over those that ended, 0 to 1. |
| minDealings | number | – | Fewest dealings on the rails we read, all time. |
| minIndependent | number | – | Fewest counterparties that paid it and were never paid back. The closest thing here to "has real custom". |
| noTwoWay | boolean | – | Exclude agents that also pay their own payers, which can be one owner moving money between their own addresses. |
| rail | string | – | x402, acp, mech or masumi. |
| registered | boolean | – | Only agents holding a registration in a registry we read. A registration is a claim, never a verification. |
| serving | boolean | – | Only agents whose declared service answered our last probe. An agent that declares none is excluded, not failed. |
| sort | string | – | One named dimension: independent, dealings, usd, completion, recent, paidBack, largestShare or counterparties. There is no "best" — nothing here has earned the right to rank. |
| Name | Type | Req | Description |
|---|---|---|---|
| asOf | string|null | – | – |
| filters | object | – | What was applied, read back, including what a floor excluded. |
| items | array | yes | Matching agents, ordered by the ONE dimension asked for, never a composite score. |
No examples provided.
find_vaults Find a vault by what it has done ~392
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 — there are 18 — and `beating` the ones where they earned more. It matches only vaults whose realised return is COMPARABLE with an advertised one, 349 of 3,394 open vaults; 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.
| Name | Type | Req | Description |
|---|---|---|---|
| agentManaged | boolean | – | Only vaults a machine runs. |
| chain | string | – | e.g. base, solana, hyperliquid. |
| earned | string | – | in-line, beating or short — realised against advertised, comparable cases only. |
| limit | number | – | Default 25, capped at 100. |
| maxRisk | number | – | 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. |
| minOwnShare | number | – | 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. E… |
| minTvl | number | – | Floor on stated size, in US dollars. |
| platform | string | – | A platform id or its display name, e.g. morpho or Hyperliquid. |
| q | string | – | Part of a name or an address. |
| Name | Type | Req | Description |
|---|---|---|---|
| data | array | yes | Each with its slug, which vault_check takes. |
| fields | string | – | Which fields this tool kept from the endpoint’s own rows. |
| warnings | array | – | READ THESE: an `earned` or `minOwnShare` floor carries what it excluded, and the denominator is not visible from the rows. |
No examples provided.
identify Identify the party behind an identifier ~231
Call this FIRST whenever you hold something other than a wallet address. Give it a transaction hash, an http(s) URL, a hostname or an ERC-8004 registration number and it says which party that is, with the evidence for the link, so the other tools here can then be called with the address. It never picks between candidates: where a hostname or id matches several parties, `address` comes back null and every candidate is listed, because choosing one would be an identification the evidence does not support. A link through a hostname or a declared endpoint is the subject’s own claim, never proof that they control it. An identifier it cannot resolve is not evidence of anything wrong — read `says`, which distinguishes "no such thing" from "we do not read that chain". Free.
| Name | Type | Req | Description |
|---|---|---|---|
| q | string | yes | What you have: an address (returned as given), a transaction hash (the payee is read from the transfer inside it), a URL or hostname (matched against the x402 catalogue and declared agent endpoints),… |
| Name | Type | Req | Description |
|---|---|---|---|
| address | string|null | – | The party, or null where the evidence names more than one. Never a guess between candidates. |
| candidates | array | – | Every party the identifier could be, where it is not one. |
| check | string|null | – | The free check to call next with the address. |
| evidence | array | – | Why each link is claimed, and whether it is the subject’s own claim or something we read. |
| format | object | – | What kind of address it is and what we read for it. |
| given | string | – | What you sent, as sent. |
| kinds | object | – | What each reading would have meant, so an unrecognised identifier is not a dead end. |
| looksLike | string | – | What the identifier was read as: address, transaction, endpoint, host, agent-id or unrecognised. |
| says | string | yes | The answer in words, including the difference between "no such thing" and "we do not read that chain". |
No examples provided.
list_policies The policies a decision can be made under ~56
The policies evaluate_action can be run under, in full: every rule, its id and the sentence it checks. Published deliberately, including to the agents being evaluated — a rule nobody can read is a rule nobody can correct. Free.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| data | array | yes | Each policy with its slug, version, intent, ceiling, coverage floor and rules. |
| default | string | – | – |
| says | string | – | – |
No examples provided.
list_vaults Find the vault you mean ~87
The vaults we read, so a caller holding a name rather than a slug can find the one it means. Free. Absence from this list means we do not read that vault, never that it does not exist.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | number | – | Default 25, maximum 200. |
| q | string | – | Part of a vault or platform name, matched as typed. |
| Name | Type | Req | Description |
|---|---|---|---|
| data | array | yes | Each with its slug, which is what vault_check takes. |
| fields | string | – | Which fields this tool kept from the endpoint’s own rows, and where the rest are. |
No examples provided.
operator_check Who runs the money, and how much is theirs ~167
The question that follows vault_check: who runs the money, and how much of it is their own. Free. Read `ownShare` with its limits, which travel inside it: the leader’s holding is readable on Hyperliquid and Drift only — 584 of 3,394 open vaults — so elsewhere it is ABSENT and not zero, the median describes the strategies we can read rather than the manager, and a large own-share is evidence of alignment and never proof, because the address running a vault can be a treasury or a custodian holding for other people. `cannotSee` names whatever of that applies here. Take the slug from vault_check’s `operator`.
| Name | Type | Req | Description |
|---|---|---|---|
| slug | string | yes | The operator’s slug, as vault_check returns it in `operator.slug`. |
| Name | Type | Req | Description |
|---|---|---|---|
| agentManaged | integer | – | – |
| cannotSee | array | yes | – |
| capitalUsd | number|null | – | – |
| name | string | yes | – |
| ownShare | object|null | – | Median share of the vault its leader holds, the count it is taken over, and what it does and does not mean. |
| says | string | yes | – |
| strategies | object | – | How many open and closed, and on which platforms. |
No examples provided.
preflight_payment Weigh one payment before sending it ~348
Call this immediately before sending a payment, every time — not once per counterparty. It weighs THIS payment (the amount, the chain, the endpoint) against what the address has actually done: the price the seller themselves published for that endpoint, the address that endpoint names as its payee, the largest payment this address has ever received, and whether it has ever been paid on the chain you are about to use. Answers one of three verdicts. `nothing-against-it` means every check ran and none objected — it is NOT a statement that the payment is safe, because nothing here can see what the payment is for or what you agreed. `look-first` means at least one thing we could READ does not match, and the findings say which; a check that could not run never produces it, it produces `cannot-say`. `cannot-say` means we did not read enough to have an opinion, and must never be read as the first. Free. Give as much of amountUsd, chain and resource as you have: each one left out is a check that did not run, and the answer says so rather than passing.
| Name | Type | Req | Description |
|---|---|---|---|
| amountUsd | number | – | What you are about to send, in US dollars. |
| chain | string | – | The chain you are about to send it on, e.g. base, polygon, solana. |
| resource | string | – | The http(s) URL of the endpoint you are buying, where there is one. This is the sharpest check available: its catalogue entry carries the seller’s own price and their own payee address. |
| to | string | yes | The address you are about to pay. |
| Name | Type | Req | Description |
|---|---|---|---|
| check | string|null | – | The free counterparty check for this address. |
| findings | array | – | Every check that ran, each with the record behind it and its own `tone` and `kind`. NOT only the ones that objected: a `tone` of `good` is a check that MATCHED, so reading this array’s length as a co… |
| limits | string | – | – |
| listing | object|null | – | The seller’s own catalogue entry for the resource, where there is one. The sharpest check available. |
| observations | array | yes | Every check that ran, including the ones that could not: a field you left out appears here as a check that did not run, rather than as silence. |
| proposal | object|null | – | – |
| received | object | – | What you told us, read back, so a typo is visible. |
| says | string | yes | – |
| verdict | string | yes | `nothing-against-it` means every check ran and none objected — NOT that the payment is safe. `cannot-say` means too little was read to have an opinion, and must never be read as the first. It is also… |
| verdicts | object | – | What each verdict word means, so a caller never has to guess. |
No examples provided.
vault_check What the record shows about one vault ~189
Before putting capital into a vault: what the record shows about it, rather than what the venue says about itself. The headline is what a holder ACTUALLY EARNED set against the advertised rate — the one figure a depositor cannot get from the venue — with the risk band, the components that apply, and who runs it. Free. Read `earned.comparability` before quoting the ratio: a realised rate drawn from too short or too sparse a window is not a comparison with the advertised one, and `cannotSee` lists everything we could not establish for this vault rather than leaving it as an absence you have to notice. Rates are decimal fractions: 0.0432 is 4.32% a year.
| Name | Type | Req | Description |
|---|---|---|---|
| slug | string | yes | The vault’s slug, or an address we can resolve to one. Call list_vaults first if you have only a name. |
| Name | Type | Req | Description |
|---|---|---|---|
| cannotSee | array | yes | What we could not establish. Empty means every check ran. |
| capitalUsd | number|null | – | – |
| earned | object|null | – | Advertised against realised, with the ratio, the verdict, the window and its comparability. Null where we have too few price points to say. |
| name | string|null | – | – |
| operator | object|null | – | Who runs it, as the venue names them. |
| risk | object | – | The band, the share of components we could measure, and each applying component in its own words. |
| says | string | yes | – |
| slug | string | yes | – |
No examples provided.
vault_exits What actually left a vault ~220
Before putting capital somewhere, ask what has actually LEFT it. Every liquidity figure elsewhere is a level at an instant — how much could be withdrawn right now. This is the other half: withdrawals that SETTLED, over 7, 30 and 90 days, with the largest single exit we have ever recorded and the day it happened. Measured on the largest vault we read: $52.8M declared withdrawable against $265.8M actually withdrawn over thirty days, so a holder reading only the declared figure would badly underestimate what the vault has been able to pay. A LEVEL and a FLOW are never divided by one another and this returns no ratio between them. We see withdrawals that settled and NOT an attempt that reverted, a queue somebody waited in, or a gate that refused them — so an empty register means “nobody withdrew” OR “nobody could”, and `cannotSee` says so. Free.
| Name | Type | Req | Description |
|---|---|---|---|
| slug | string | yes | The vault slug, as list_vaults and find_vaults return it. |
| Name | Type | Req | Description |
|---|---|---|---|
| cannotSee | array | yes | What this register structurally cannot contain, so an empty one is never read as an easy exit. |
| declaredWithdrawableUsd | number|null | – | A LEVEL at this instant. Null where we cannot read it, which is not zero. |
| largestEverAt | string|null | – | – |
| largestEverUsd | number|null | – | Somebody actually got this much out, on `largestEverAt`. Evidence about the past, never a promise about now. |
| says | string | yes | – |
| slug | string | yes | – |
| tvlUsd | number|null | – | – |
| windows | array | yes | FLOWS over 7, 30 and 90 days: count, total, largest single, most recent. Never a share of the level. |
No examples provided.
What is the org.aspern/aspern MCP server?
org.aspern/aspern is an MCP server listed in the public MCP registry as org.aspern/aspern. What the chain records about an address before you pay it, and whether a payment fits it. This page covers its hosted endpoint (https://aspern.org/mcp).
Is the org.aspern/aspern MCP server safe to use?
org.aspern/aspern scores 69 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the org.aspern/aspern MCP server expose?
org.aspern/aspern exposes 15 tools: identify, check_service_endpoint, preflight_payment, vault_exits, evidence_for, and 10 more. Their descriptions and schemas cost roughly 3,480 tokens of context every time the server is loaded.
Does the org.aspern/aspern MCP server require authentication?
No. We connected to org.aspern/aspern without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the org.aspern/aspern MCP server still maintained?
org.aspern/aspern is still listed as active in the MCP registry. We last reached this channel on 28 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.