Search / org.aspern/aspern
protogridR0· no sign-inWhat the chain records about an address before you pay it, and whether a payment fits it.
v1.1.0 · active · website · descriptor JSON · versions
{
"mcpServers": {
"aspern": {
"type": "http",
"url": "https://aspern.org/mcp"
}
}
}claude mcp add --transport http aspern https://aspern.org/mcp[mcp_servers.aspern]
url = "https://aspern.org/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"aspern": {
"type": "remote",
"url": "https://aspern.org/mcp",
"enabled": true
}
}
}{
"mcpServers": {
"aspern": {
"type": "http",
"url": "https://aspern.org/mcp"
}
},
"deeplink": "cursor://anysphere.cursor-deeplink/mcp/install?name=aspern&config=eyJ0eXBlIjoiaHR0cCIsInVybCI6Imh0dHBzOi8vYXNwZXJuLm9yZy9tY3AifQ%3D%3D"
}{
"servers": {
"aspern": {
"type": "http",
"url": "https://aspern.org/mcp"
}
}
}{
"mcpServers": {
"aspern": {
"httpUrl": "https://aspern.org/mcp"
}
}
}extensions:
"aspern":
enabled: true
name: "aspern"
type: streamable_http
uri: "https://aspern.org/mcp"
timeout: 300
protocol.modernnewest supported version is 2025-06-18; 2026-07-28 not supported, older versions are deprecated until 2027-07-28protocol.statelessonly applies to 2026-07-28 serversprotocol.transportstreamable HTTPprotocol.list_ttlonly applies to 2026-07-28 serversauth.prm, auth.as_metadata, auth.cimdno remote uses OAuthauth.secret_in_urlno templated URLtools.descriptionsevery tool has a descriptiontools.description_length19 tools have descriptions over 1,024 characters, which crowds the contexttools.schemasevery tool has an object input schematools.annotations32 of 32 tools declare readOnlyHint or destructiveHinttools.directory_hintsevery tool declares readOnlyHint, destructiveHint, idempotentHint and openWorldHinttools.token_costabout 17,215 tokens to load every tooltools.api_dumptools are not a one-to-one API dumpstability.changes177 tool changes in 30 daysstability.rug_pull2 tools kept their name but changed most of their description in 30 days; review before trusting themdeps.known_vulns, deps.mcp_sdk_version, deps.resolvableno npm or PyPI packageinspect_paymentchangedannotationsagent_economic_profilechangeddescriptionOne agent, four readings, in the order a buyer actually asks them: what it EARNS and from whom, whether its contracted work FINISHED and who signed it off, who it RESTS ON as a supplier, and whether it is still TRADING and its endpoints answer. Every other tool here answers one of those; this is the one that answers them together, over the same nightly record, so the four cannot disagree with each other or with the endpoints they summarise. THERE IS NO SCORE ON TOP and there will not be one: a single figure would be the thing every reader quotes and the only one none of them can check, and it would average a measured quantity with an unmeasured one until neither is visible. Each block keeps its own counts and its own denominator. A block we have not read comes back NULL rather than as a row of zeros, because "it has no completed jobs" and "we have not read its job side" are different facts and a buyer choosing between agents deserves to know which one they are looking at; `blocksAnswered` says how many of the four this answer could fill. `cannotSee` names what no block here can reach at all — revenue that never touched a rail we read, dependencies that are not payments, and whether completed work was any GOOD, which we cannot see from who signed it off. PAID.
One agent, four readings, in the order a buyer actually asks them: what it EARNS and from whom, whether its contracted work FINISHED and who signed it off, who it RESTS ON as a supplier, and whether it is still TRADING and its endpoints answer. Those questions are answered singly elsewhere on this server; this is the one that answers them together, over the same nightly record, so the four cannot disagree with each other or with the endpoints they summarise. THERE IS NO SCORE ON TOP and there will not be one: a single figure would be the thing every reader quotes and the only one none of them can check, and it would average a measured quantity with an unmeasured one until neither is visible. Each block keeps its own counts and its own denominator. A block we have not read comes back NULL rather than as a row of zeros, because "it has no completed jobs" and "we have not read its job side" are different facts and a buyer choosing between agents deserves to know which one they are looking at; `blocksAnswered` says how many of the four this answer could fill. `cannotSee` names what no block here can reach at all — revenue that never touched a rail we read, dependencies that are not payments, and whether completed work was any GOOD, which we cannot see from who signed it off. PAID.
endpoint_disagreementschangeddescriptionWHICH ENDPOINTS CONTRADICT THEIR OWN LISTING: they ask to be paid at an address the catalogue entry they published does not name. This is the one reading here that cannot be reproduced from anywhere else — an uptime checker sees a live endpoint and a catalogue reader sees a published payee, and only holding BOTH shows the contradiction. A disagreement is between two statements by the SAME party, so it is theirs to explain and never ours to resolve, and it is NOT evidence of fraud: a seller may have moved their payee and not relisted. Measured only over endpoints we have knocked on, which is our reach and not the catalogue; `comparable` is the denominator, because an endpoint that names no payee cannot disagree and is counted neither way. THE COUNTS ARE FREE AND THE LIST IS NOT: `items` comes back NULL without a plan rather than empty, since an empty list would say we found none. Any SINGLE endpoint is free — `test_purchase` and `list_x402_endpoints` both carry its own reading — because that one is reproducible in two requests and because withholding something that can cost a buyer money is not a thing we do.
WHICH ENDPOINTS CONTRADICT THEIR OWN LISTING: they ask to be paid at an address the catalogue entry they published does not name. The contradiction appears only when the live handshake and the published listing are held together: either half on its own looks ordinary, since a reachable endpoint and a stated payee are each unremarkable alone. A disagreement is between two statements by the SAME party, so it is theirs to explain and never ours to resolve, and it is NOT evidence of fraud: a seller may have moved their payee and not relisted. Measured only over endpoints we have knocked on, which is our reach and not the catalogue; `comparable` is the denominator, because an endpoint that names no payee cannot disagree and is counted neither way. THE COUNTS ARE FREE AND THE LIST IS NOT: `items` comes back NULL without a plan rather than empty, since an empty list would say we found none. Any SINGLE endpoint is free — `test_purchase` and `list_x402_endpoints` both carry its own reading — because that one is reproducible in two requests and because withholding something that can cost a buyer money is not a thing we do.
test_purchasechangeddescription, annotationsWALK THE WHOLE PURCHASE OF AN x402 ENDPOINT WITHOUT PAYING, in the order a buyer actually asks the questions, stopping at the first one that objects. Every other tool here answers ONE question about one subject; the losses live between them. Five steps: is the endpoint there, what does it charge RIGHT NOW, does the seller’s own catalogue entry agree with what it just said, does the record say anything against paying that payee under a published policy, and — the step that only exists because this is a rehearsal — is the price still the one the decision was made on, re-read a moment later. A quote that moved between the decision and the signature would authorise something nobody decided on. THE VERDICT HAS THREE STATES AND cannot-tell IS NOT would-proceed: an unanswered question is never rounded up to a passed one. `quotedRaw` is what the endpoint said, in the asset’s smallest unit, and `quotedUsd` is NULL unless the catalogue carries both halves of the same token’s pair to scale it — nothing in a payment-requirements document names the decimals, and a figure scaled by a guessed exponent is a hundred-fold error waiting to be quoted. We knock only on endpoints already in the x402 catalogue we read, at most one live handshake a minute per resource, because fetching a URL because a request named it would make us a prober-for-hire pointed at somebody else’s host. Nothing is signed and nothing is spent. FREE.
WALK THE WHOLE PURCHASE OF AN x402 ENDPOINT WITHOUT PAYING, in the order a buyer actually asks the questions, stopping at the first one that objects. All five are asked in one pass and in that order, so the walk stops where a buyer would stop. Five steps: is the endpoint there, what does it charge RIGHT NOW, does the seller’s own catalogue entry agree with what it just said, does the record say anything against paying that payee under a published policy, and — the step that only exists because this is a rehearsal — is the price still the one the decision was made on, re-read a moment later. A quote that moved between the decision and the signature would authorise something nobody decided on. THE VERDICT HAS THREE STATES AND cannot-tell IS NOT would-proceed: an unanswered question is never rounded up to a passed one. `quotedRaw` is what the endpoint said, in the asset’s smallest unit, and `quotedUsd` is NULL unless the catalogue carries both halves of the same token’s pair to scale it — nothing in a payment-requirements document names the decimals, and a figure scaled by a guessed exponent is a hundred-fold error waiting to be quoted. We knock only on endpoints already in the x402 catalogue we read, at most one live handshake a minute per resource, because we knock only on what the catalogue already lists: a URL named in a request is not by itself a reason to send traffic to somebody else’s host. Nothing is signed and nothing is spent. FREE.
portfolio_screenchangeddescriptionREAD THE VAULTS YOU HOLD TOGETHER. Every other tool here answers about ONE subject; an allocator does not hold one subject. This answers the three questions that only exist across holdings and that no vault page can show you: a CONTROLLER behind more than one of them, a MARKET behind more than one of them, and an EXIT that is not the sum of the exits. It is a screen, not advice: there is no allocation percentage and no expected return in this answer and there never will be. THE EXIT IS FOUR FIGURES AND THEY ARE NEVER ADDED UP — `declared` (the venue publishes a withdrawable figure), `behind-a-queue` (we have READ that a request comes first, so nothing leaves today at any price whatever cash is sitting there), `floor-only` (the only reading is uninvested cash, a lower bound) and `unread` — because a portfolio that is 40% readable is not a portfolio that is 40% liquid. A queue OUTRANKS a declared figure: a vault can publish a number and still take a request first, and the number is then what a request settles from. The exit split, the coverage and the bands are FREE, and so is every per-vault reading behind them at `vault_check`; a plan buys what the holdings SHARE. It cannot verify that you hold any of this.
READ THE VAULTS YOU HOLD TOGETHER. This one is about a SET rather than a single subject; an allocator does not hold one subject. This answers the three questions that only exist across holdings and that no vault page can show you: a CONTROLLER behind more than one of them, a MARKET behind more than one of them, and an EXIT that is not the sum of the exits. It is a screen, not advice: there is no allocation percentage and no expected return in this answer and there never will be. THE EXIT IS FOUR FIGURES AND THEY ARE NEVER ADDED UP — `declared` (the venue publishes a withdrawable figure), `behind-a-queue` (we have READ that a request comes first, so nothing leaves today at any price whatever cash is sitting there), `floor-only` (the only reading is uninvested cash, a lower bound) and `unread` — because a portfolio that is 40% readable is not a portfolio that is 40% liquid. A queue OUTRANKS a declared figure: a vault can publish a number and still take a request first, and the number is then what a request settles from. The exit split, the coverage and the bands are FREE, and so is every per-vault reading behind them at `vault_check`; a plan buys what the holdings SHARE. It cannot verify that you hold any of this.
exit_screenaddedYOU HAVE A SIZE AND YOU WANT TO KNOW WHERE IT HAS ACTUALLY CLEARED. Every other exit reading here is about one vault; this asks the same question across every vault whose withdrawal history we have read, which is the question an allocator with capital actually has. Send `amountUsd` and each vault comes back with one of THREE verdicts, and the middle one is the finding: `paid-in-one` means a single settled withdrawal at least that large has been recorded there; `paid-across-a-day` means that much has left in one day and never in one withdrawal, which is a different fact and not a weaker version of the first; `never-asked-this-size` means nothing that large has been withdrawn, which is NOT a refusal and NOT a failure, because most vaults have never been asked. It exists because an auditor screened a $6M exit from a vault declaring $15.10M withdrawable, got a supporting answer, and found the largest withdrawal ever observed there was $500K. Declared liquidity is a LEVEL at an instant; what has left is a FLOW; only the second is evidence about a size. The two are never divided by one another and no ratio between them is returned. `population` names how many vaults have no history at all, because those are UNREAD rather than untested and must not be counted as either answer. Nothing here is a forecast: a vault that paid this much last March can refuse today. PAID.
vault_exitschangedinput schemaportfolio_screenaddedREAD THE VAULTS YOU HOLD TOGETHER. Every other tool here answers about ONE subject; an allocator does not hold one subject. This answers the three questions that only exist across holdings and that no vault page can show you: a CONTROLLER behind more than one of them, a MARKET behind more than one of them, and an EXIT that is not the sum of the exits. It is a screen, not advice: there is no allocation percentage and no expected return in this answer and there never will be. THE EXIT IS FOUR FIGURES AND THEY ARE NEVER ADDED UP — `declared` (the venue publishes a withdrawable figure), `behind-a-queue` (we have READ that a request comes first, so nothing leaves today at any price whatever cash is sitting there), `floor-only` (the only reading is uninvested cash, a lower bound) and `unread` — because a portfolio that is 40% readable is not a portfolio that is 40% liquid. A queue OUTRANKS a declared figure: a vault can publish a number and still take a request first, and the number is then what a request settles from. The exit split, the coverage and the bands are FREE, and so is every per-vault reading behind them at `vault_check`; a plan buys what the holdings SHARE. It cannot verify that you hold any of this.
vault_exitschangedoutput schemavault_checkchangedoutput schemaShowing the latest 10. Full history: list_changes · trend: quality JSON.
Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.
+dns-namespace +website +reachable +uptime-99% +updated-0d-ago -no-repository
Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed. How it is computed.
| remote | auth | reachable | uptime 30d | p50 | protocol | last ok |
|---|---|---|---|---|---|---|
https://aspern.org/mcp streamable-http | none | yes | 99% | 358 ms | 2025-06-18 | 2026-10-20 |
agent_business | Does this agent have a BUSINESS, and can any of it be demonstrated? Six questions an investor, a marketplace or an operator actually asks, each answered separately: are the addresses paying it really independent customers; is revenue growing or shrinking; how much is repeat custom; how many of those payments can be shown to have bought anything; what does it cost to run and to whom; and if it has several addresses, can the link be DEMONSTRATED or is it an unconfirmed assumption. Measured once and not refreshed since, on two live agents: one takes $2,388 a month from 4,772 payers of whom 97% are repeat, the other $932,414 from 7,220 payers of whom 12% are — two completely different businesses that a counterparty count reports identically. THERE IS NO SCORE over the six, deliberately: a number would average "thousands of addresses paid this" against "we hold no delivery record at all", and the second is a statement about US. Four things the data invites and this refuses: an ADDRESS is not a customer (one customer can hold twenty); a PAYMENT is not a delivery (the busiest agents settle on rails that carry money without carrying a job, so "no delivery record" there is our reach and not a finding); a SHARED FUNDER is not an identity (an exchange funds thousands of strangers), so a link is published as demonstrated or as merely co-occurring and the second is never promoted; and a COST we cannot see is not a cost that is not there. PAID. SINCE 2026-10-11 IT ALSO CARRIES `economicChain`: the four links of the chain an agent has to complete to be a working economic subject — a customer paid it, it ordered or did work, the result was demonstrably delivered, a customer came back. Each link is `evidenced`, `unevidenced` (we read the rail and found nothing — a statement about the agent), `unread` (THE RAIL RECORDS IT AND WE DO NOT READ IT — a statement about us, and the only one of the four that closes by our building something) or `unevidenceable` (the rail does not record it at all, so no reading by anybody will change it — a statement about the rail). Those three silences are never folded together, because they call for three different acts. Masumi settles work through an escrow whose release or refund is on chain, and SINCE 2026-10-11 WE READ IT: a release to the seller is the buyer letting the escrow go, which is the closest thing to an accepted delivery this chain can show, and it counts alongside an ACP completion. A CLOSURE does not count — over all 29,088 settled escrows at the time this was measured once, 5,819 refunded to the BUYER against 4,659 released, so counting closures would publish a refund as delivered work more often than not. An agent whose escrows the step reader has not walked yet is `unread` rather than `unevidenced`, per agent, because the chain carries the answer and we have not asked for that one. THE FOURTH STATE is the one to read carefully: x402 is 91% of the volume and records payment, never delivery, so for an x402-only agent link three is unevidenceable and reporting it as missing would blame the agent for the rail. NO SCORE: the worst link governs, because averaging lets a strong payment record carry an absent delivery record. Measured once and not refreshed since, over all 3,135 addresses we held then: paid 3,048, hires 432, delivered 684, returned 2,412, and **185 with all four**. |
agent_changesread-only | What moved in the agent record, across every agent, since a date. The counterparty check answers what is true about one address NOW; this answers what changed, for all of them, which is the question anybody holding a list asks next. One row per FIELD that moved, not per address: an agent whose dealings and concentration both moved is two facts, and folding them would make you diff the answer to work out what was meant. Roughly one agent in five moves on an ordinary day; how many are tracked is a denominator on the answer rather than a number frozen here. A day with no row for an address is a day it did not move, never a day nobody looked. The record began on a date and `from` says which: asking for anything earlier answers from there rather than pretending nothing happened. Needs a key and the agents.changes capability. |
agent_dependencies | If your firm relies on several external agents, what do they rest on AT ONCE? Give it two to twenty-five addresses and it finds the parties more than one of them pays. THE PRODUCT IS THE DISTINCTION, NOT THE JOIN: finding that three agents paid the same address tells you almost nothing — on our rails one address is paid by 71 agents across 4,100 payments and another by three agents once each, and calling both "shared" makes the second sound like the first. Four tests must ALL hold before the word dependency is used: repeated (more than one payment, because a single payment is an event), one-way (it has never paid them back, because money moving both directions is trade between peers and survives either of them leaving), sustained (spanning more than a day, so a burst of twenty in an afternoon is not a standing arrangement), and shared (more than one of the agents you named). All four are published on every party under `tests`, so you can draw the line somewhere else than we did. Anything short is a `shared-counterparty` with its failed test named and is reported as a LEAD. The concentration line counts dependencies only. A party just ONE of them pays is left out entirely — that is `counterparty_check`, free. Most shared infrastructure, a cloud region or a model provider on a card or one operator holding the keys, leaves no payment at all, so what this finds is a FLOOR on the concentration that exists and never a measure of it. PAID. |
agent_economic_profile | One agent, four readings, in the order a buyer actually asks them: what it EARNS and from whom, whether its contracted work FINISHED and who signed it off, who it RESTS ON as a supplier, and whether it is still TRADING and its endpoints answer. Those questions are answered singly elsewhere on this server; this is the one that answers them together, over the same nightly record, so the four cannot disagree with each other or with the endpoints they summarise. THERE IS NO SCORE ON TOP and there will not be one: a single figure would be the thing every reader quotes and the only one none of them can check, and it would average a measured quantity with an unmeasured one until neither is visible. Each block keeps its own counts and its own denominator. A block we have not read comes back NULL rather than as a row of zeros, because "it has no completed jobs" and "we have not read its job side" are different facts and a buyer choosing between agents deserves to know which one they are looking at; `blocksAnswered` says how many of the four this answer could fill. `cannotSee` names what no block here can reach at all — revenue that never touched a rail we read, dependencies that are not payments, and whether completed work was any GOOD, which we cannot see from who signed it off. PAID. |
capital_coverageread-only | 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. |
check_action | CALL THIS BEFORE YOUR AGENT SIGNS ANYTHING THAT MOVES MONEY. One request instead of five: it reads the counterparty record, decodes the calldata you are about to sign, looks up the seller’s own catalogue listing, runs an unpaid 402 handshake with the endpoint, and applies a published policy — and then, which is the point, compares them WITH EACH OTHER. The losses an agent actually suffers live between those readings and no single one of them can see them: the bytes paying an address you never checked, so a spotless counterparty record is about a party this transaction does not pay; an UNLIMITED APPROVAL wearing the shape of a one-cent payment; the seller’s listing naming a payee the calldata does not; a policy allowing a payment for a path that is not served. Every cross-check names BOTH readings that disagree in `between`, and none of them is an accusation — the record can be wrong. Send `calldata` whenever you have it: it unlocks the strongest check there is. A cross-check can only make the verdict worse, never better. SEND `calldata`, `chain` AND `from` and it is also SIMULATED: one `eth_call` at the latest block, the node executes it and throws the result away, nothing is signed or spent. A revert is the strongest finding available, because every other reading argues about whether you should send it and this one is that it will not work. Not a state diff, run against the current block, and a node that refuses is reported as our gap rather than as a failure. `ran` says which parts did not run and why, because a check that did not happen must never look like one that passed. PAID; its five components are each free on their own tools and what is sold here is the comparison. |
check_service_endpointread-only | Call this before connecting to a service. 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` carry the series: a registration says what an agent offers now, and the readings say 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. For a CATALOGUED x402 resource that no agent registered, read `unpaidProbe`: our own unpaid 402 handshake, which is free for both sides and says whether the endpoint is still there and what it charges now against a catalogue entry that may be months old. Free. |
counterparty_bulk | Check up to fifty addresses in one call, each with its observations, AND what the set shares underneath: the parties that two or more of them pay. That second part is the one answer no per-address row can contain, because the input is your own shortlist — four agents stopping together because they all pay one party is invisible in four separate clean records. PAID two ways and they buy different things: one cent a call over x402, priced per call rather than per address, buys the rows; the `shared` block needs the `dependency.shared` capability, on Analyst and above, and when it is missing the block says so rather than vanishing. A shared recipient is not proof of a shared dependency — several agents paying one address may be paying a relayer, a bridge or the same customer back — and an empty list is a finding about these addresses AND about our reach. WHY readOnlyHint IS false: this tool reads and writes nothing in our store, but calling it WITH an x402 payment authorisation transfers USDC from the caller to us and records a receipt, so the call is not free of consequence and an agent must not make it speculatively. Called without an authorisation it changes nothing and answers with the price. |
counterparty_checkread-only | 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, WHETHER THOSE INDEPENDENT PAYERS ARE INDEPENDENT OF EACH OTHER under `independence`, WHAT IT ITSELF RESTS ON under `restsOn` (how many parties it pays and how much of its spending goes to the largest of them), how its ACP jobs ended, whether its advertised service answers, and when it was last paid. Free. Three 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; an all-time record says nothing about whether the agent still works — 44% of agents ever paid have not been paid in 90 days; and `restsOn` counts every party this address has PAID rather than purchases from identified sellers, so a recipient there has not been shown to supply anything, and `restsOn.suppliers` of zero means it has paid nobody on a rail we read, never that it depends on nobody. Takes an EVM address, a Cardano payment address (addr1…) or a Solana address. |
counterparty_history | 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. WHY readOnlyHint IS false: this tool reads and writes nothing in our store, but calling it WITH an x402 payment authorisation transfers USDC from the caller to us and records a receipt, so the call is not free of consequence and an agent must not make it speculatively. Called without an authorisation it changes nothing and answers with the price. |
endpoint_disagreementsread-only | WHICH ENDPOINTS CONTRADICT THEIR OWN LISTING: they ask to be paid at an address the catalogue entry they published does not name. The contradiction appears only when the live handshake and the published listing are held together: either half on its own looks ordinary, since a reachable endpoint and a stated payee are each unremarkable alone. A disagreement is between two statements by the SAME party, so it is theirs to explain and never ours to resolve, and it is NOT evidence of fraud: a seller may have moved their payee and not relisted. Measured only over endpoints we have knocked on, which is our reach and not the catalogue; `comparable` is the denominator, because an endpoint that names no payee cannot disagree and is counted neither way. THE COUNTS ARE FREE AND THE LIST IS NOT: `items` comes back NULL without a plan rather than empty, since an empty list would say we found none. Any SINGLE endpoint is free — `test_purchase` and `list_x402_endpoints` both carry its own reading — because that one is reproducible in two requests and because withholding something that can cost a buyer money is not a thing we do. |
evaluate_actionread-only | 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. 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. A FAILED RULE NOW CARRIES `detail` WHERE IT CAN: `observed` is what we read in the rule’s own vocabulary, `accepted` is what the policy would have taken, and `failedCondition` is the sentence replacing the generic one. On `controller-risk-within-policy` that matters more than anywhere: a vault can read `controller.level: low` in vault_check and still fail here, because the LEVEL says how dangerous the arrangement is and the BAND says what it is — a timelock with no guardian is `thin`, conservative accepts `checked` only, and both readings are right. The detail says so rather than leaving a reader to find a computational error that is not there. Every rule id in `reasons` is published in full at the policies tool, including to the party being evaluated. SINCE 2026-10-11 A POLICY JUDGES THE RISK LEVEL, NOT ONLY ITS TRUSTWORTHINESS. `risk-band-is-supported` asks whether the band survives what we could not read; `risk-band-within-policy` and `controller-risk-within-policy` ask whether the band and the control we DID read are ones this policy will commit capital against. Conservative will not allocate into a band worse than moderate, nor where control is `thin` — one party able to move the money — and returns `review` rather than `abstain`, because a band we read as high is a finding about the vault and not a gap in our reading. Permissive declares neither threshold and is unchanged. This closed a real defect: a vault our own vault_check called high risk with 0.5% withdrawable used to come back `allow`, because every rule about the AVAILABILITY of risk data passed. Free. |
evidence_forread-only | 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. |
exit_screen | YOU HAVE A SIZE AND YOU WANT TO KNOW WHERE IT HAS ACTUALLY CLEARED. Every other exit reading here is about one vault; this asks the same question across every vault whose withdrawal history we have read, which is the question an allocator with capital actually has. Send `amountUsd` and each vault comes back with one of THREE verdicts, and the middle one is the finding: `paid-in-one` means a single settled withdrawal at least that large has been recorded there; `paid-across-a-day` means that much has left in one day and never in one withdrawal, which is a different fact and not a weaker version of the first; `never-asked-this-size` means nothing that large has been withdrawn, which is NOT a refusal and NOT a failure, because most vaults have never been asked. It exists because an auditor screened a $6M exit from a vault declaring $15.10M withdrawable, got a supporting answer, and found the largest withdrawal ever observed there was $500K. Declared liquidity is a LEVEL at an instant; what has left is a FLOW; only the second is evidence about a size. The two are never divided by one another and no ratio between them is returned. `population` names how many vaults have no history at all, because those are UNREAD rather than untested and must not be counted as either answer. Nothing here is a forecast: a vault that paid this much last March can refuse today. PAID. |
find_agentsread-only | 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, how spread its own SPENDING is (`spreadSuppliers`, the one filter here about what the agent rests on rather than who rests on it), 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. EVERY ROW CARRIES `subject`, WHICH IS WHAT WE CAN POSITIVELY SAY IT IS, with the evidence under it. Measured once and not refreshed since, over all 3,077 paid addresses: **1,377 agent, 38 marketplace, 1,662 unknown**. Those are a PAST reading kept because they are the point — this contract once claimed `unknown` would be commonest before anything had been measured, and the measurement found it at zero, which is how a defect in the classifier was caught. Read the answer’s own denominators for today’s mix; these say what KIND of mix to expect. `agent` means we saw agent-protocol work (ACP, Olas mech, Masumi) or saw it HIRE as well as be hired. `marketplace` means many paid it and it paid many, both above a stated floor. `unknown` is the largest bucket and is a real answer, not a failure: it means the evidence does not separate an agent from something that merely sells. READ THIS BEFORE FILTERING: a catalogue listing does NOT make a subject an API service. Agents sell priced endpoints too — this platform sells four — so a listing says it sells over HTTP and nothing about which kind of seller. `api-service` is therefore in the vocabulary and is currently UNREACHABLE: separating it would need evidence that a subject does NOT do agent work, and that is an absence, since 86% of these addresses pay nobody on a rail we read and paying from a second wallet looks identical to buying nothing. Nothing is inferred from a zero and no self-description is read, so a listing calling itself an autonomous agent moves nothing. |
find_vaultsread-only | 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. |
identifyread-only | 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. |
inspect_payment | Call this with the CALLDATA you are about to sign, before you sign it. Every other check here asks whether an address is worth dealing with; this asks whether the transaction is the one you think it is, and the two catch different losses. No amount of reputation makes the recipient in the bytes match the recipient on your screen, and a spotless counterparty record says nothing about an UNLIMITED APPROVAL granted to it, which is not a payment at all but a standing permission that outlives the transaction. It reads three calls — transferWithAuthorization, approve, transfer — and REFUSES to guess at any other: decoding unknown calldata without the ABI means guessing where each argument begins, and a confident wrong answer about where money goes is worse than none. Amounts are atomic units, never dollars, because the token owns its decimals. Free, needs no key, stores nothing. |
list_policiesread-only | 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. |
list_vaultsread-only | 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. |
list_x402_endpointsread-only | WHICH ENDPOINTS A PAYEE SELLS, or which ones match some text. The sharpest check a payment can get is the endpoint being bought, and until this a caller had to know its URL by heart. Nearly every catalogued resource names a payee, and the catalogue holds tens of thousands of them. Every field is the SELLER’s own catalogue entry and never our reading of it, and a listing is not evidence that the endpoint answers — `test_purchase` knocks on it. `priceUsd` is their published price and `priceRaw` is the figure in the asset’s own base units; the two are different claims. FREE. |
monitor_subjectdestructive | Ask to be told when the answer about an address CHANGES. The dimensions are the ones the counterparty check already answers, so this is that same reading on a schedule rather than a second opinion; what it adds is the comparison. The first run records a reading and reports nothing — there is nothing yet to compare against, and a first reading dressed up as news is the thing this avoids. Idempotent per subject: calling it again edits the watch rather than creating a second. An unknown dimension or policy is REFUSED rather than dropped, because a watch that quietly ignores half of what you asked for is worse than no watch. Needs a key. WHY readOnlyHint IS false: this call writes a row in our store on behalf of the caller, so a second identical call is not free of consequence. |
operator_checkread-only | 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, 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`. |
portfolio_screenread-only | READ THE VAULTS YOU HOLD TOGETHER. This one is about a SET rather than a single subject; an allocator does not hold one subject. This answers the three questions that only exist across holdings and that no vault page can show you: a CONTROLLER behind more than one of them, a MARKET behind more than one of them, and an EXIT that is not the sum of the exits. It is a screen, not advice: there is no allocation percentage and no expected return in this answer and there never will be. THE EXIT IS FOUR FIGURES AND THEY ARE NEVER ADDED UP — `declared` (the venue publishes a withdrawable figure), `behind-a-queue` (we have READ that a request comes first, so nothing leaves today at any price whatever cash is sitting there), `floor-only` (the only reading is uninvested cash, a lower bound) and `unread` — because a portfolio that is 40% readable is not a portfolio that is 40% liquid. A queue OUTRANKS a declared figure: a vault can publish a number and still take a request first, and the number is then what a request settles from. The exit split, the coverage and the bands are FREE, and so is every per-vault reading behind them at `vault_check`; a plan buys what the holdings SHARE. It cannot verify that you hold any of this. |
preflight_paymentread-only | 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. THE ENDPOINT’S OWN WORD OUTRANKS THE CATALOGUE. Where we have probed the endpoint, `againstEndpoint.price` carries what it actually demanded and when, ranked above the seller’s listing and above what the address has been paid, with every disagreement between the three kept rather than resolved — `live-price-differs-from-listing` means the price has MOVED and the live figure is the one to pay, and `quoted-payee-is-not-the-one-being-paid` means the endpoint asks to be paid somewhere other than where you are sending. `live-price-not-comparable` means the two prices are in different tokens or one is unnamed, so they were NOT compared rather than compared and found to agree. `againstQuote` IS THE FIELD TO BRANCH ON: `exact-match`, `below-quote`, `above-quote` or `unknown`. **`below-quote` is not a pass** — the endpoint has said what it wants for THIS call and the payment is under it, so it will not buy the thing unless the terms allow a partial payment, which we cannot see; it is a REVIEW and never a refusal. Paying less than the CATALOGUE’s price is a different question and stays `neutral`, because a directory entry may price a different unit and was written once. FINDINGS WORTH KNOWING BY NAME. `below-listed-price` means the payment is under half the seller’s published price: ordinary, not an objection, and NOT a confirmation of the amount either, because the listing may price a different unit or tier — it is `neutral` and cannot improve the verdict. `network-not-comparable` means the listing names a network we could not resolve, so the chains were not compared rather than compared and found to agree. A CAIP-2 id and a chain name are resolved through one shared map, so `eip155:8453` and `base` are the same network here and in check_action; they used to disagree. |
record_receipt | Call this AFTER you have paid an address or called a tool, to put what you did on the record. Until now this platform answered "should I" and never heard what happened, which is the difference between a lookup and a control layer: a receipt lets the next question about this subject be asked against a record instead of a guess, and lets a verdict we gave be read back against what followed. `reference` is YOUR evidence, a transaction hash or the digest of a signed payload, and we store it WITHOUT verifying it. `outcome` comes back null and stays null until something actually reads what happened, so a receipt nobody has checked never looks like one that settled. Needs a key; a receipt is readable only by the key that wrote it. WHY readOnlyHint IS false: this call writes a row in our store on behalf of the caller, so a second identical call is not free of consequence. |
test_purchase | WALK THE WHOLE PURCHASE OF AN x402 ENDPOINT WITHOUT PAYING, in the order a buyer actually asks the questions, stopping at the first one that objects. All five are asked in one pass and in that order, so the walk stops where a buyer would stop. Five steps: is the endpoint there, what does it charge RIGHT NOW, does the seller’s own catalogue entry agree with what it just said, does the record say anything against paying that payee under a published policy, and — the step that only exists because this is a rehearsal — is the price still the one the decision was made on, re-read a moment later. A quote that moved between the decision and the signature would authorise something nobody decided on. THE VERDICT HAS THREE STATES AND cannot-tell IS NOT would-proceed: an unanswered question is never rounded up to a passed one. `quotedRaw` is what the endpoint said, in the asset’s smallest unit, and `quotedUsd` is NULL unless the catalogue carries both halves of the same token’s pair to scale it — nothing in a payment-requirements document names the decimals, and a figure scaled by a guessed exponent is a hundred-fold error waiting to be quoted. We knock only on endpoints already in the x402 catalogue we read, at most one live handshake a minute per resource, because we knock only on what the catalogue already lists: a URL named in a request is not by itself a reason to send traffic to somebody else’s host. Nothing is signed and nothing is spent. FREE. |
vault_checkread-only | Before putting capital into a vault: what the record shows about it. The headline is what a holder ACTUALLY EARNED set against the advertised rate, with the risk band, the components that apply, who runs it, and `keys`: who can move the money. Read `keys.actsAlone` before any return figure, because a strategy can be excellent and one private key away from being emptied; across what we read, a single key controls $1.26bn and 47 of 249 multisigs require one signature. Free. Read `earned.comparability` AND `earned.representativeness` before quoting the ratio: the first says whether a realised rate can be compared with the advertised one at all, the second whether the result is worth planning around rather than one day that moved, and `cannotSee` lists everything we could not establish for this vault rather than leaving it as an absence you have to notice. `changedHands` carries whether those keys have been MOVING, which is the due-diligence question `keys` cannot answer — read its `watchedSince`, because a count of zero means nothing moved since we started watching and not that the vault has never changed hands. Rates are decimal fractions: 0.0432 is 4.32% a year. |
vault_exit_confidence | Before you put capital in, ask what evidence there is that you could get a PARTICULAR amount back out. Every other reading about a vault is about return or about risk of loss; this is about the practical question a holder has, and it is always about a size: "can I get out" has no answer, "can I get $2m out of a vault with $400k free and 25,941 settled withdrawals behind it" has several. Six readings, each with its own verdict and the question it answers in a holder’s own words: has anybody actually got money out, is there anything in it now, could YOUR amount leave, is somebody queued ahead of you, how much of the capital is lent out, and can somebody change the terms under you. The answer is the WORST of them and never an average — a queue in front of you is not offset by a long history, it happens before your turn — and an `unknown` outranks a `supports`, because a gap we could not read must never be counted as a pass. `not-asked` marks a component whose input you did not send, and `not-applicable` one this venue does not have at all — only two venues have an exit queue to be behind. Neither is a gap in our record and neither lowers the answer. A withdrawable figure is a FLOOR on venues whose vaults lend into markets holding their own liquidity, and the component says so rather than reading it as a ceiling. NOTHING HERE IS A GUARANTEE of withdrawal and no sentence it emits contains the word: a vault that has paid everybody for a year can stop tomorrow. PAID. |
vault_exitsread-only | SEND `exitAmountUsd` WITH THE POSITION YOU ARE WEIGHING and this answers whether that size has ever cleared here: the schema has carried it since 2026-10-08, and an auditor still had to find it by guessing because this sentence did not say so. Without it the answer still describes the capacity; with it, `exitCapacity` says `covered-now`, `above-declared` or `unknown` for your amount, and whether a single withdrawal that large has ever been recorded. 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. An empty register therefore has FOUR readings, not two: “nobody withdrew”, “nobody could”, “a reader asked and found nothing at all”, and “no reader has ever asked”. `haveFlowHistory` separates the first two from the last two and `lastReadAt` separates those — null there means nobody has ever looked, so the register is not a weak reading of the vault but the absence of one. `haveFlowHistory` separates the third from the first two, and where it is false every figure is NULL rather than zero. Every answer dates itself: `capitalAsOf` and `declaredAsOf` say when each level was read, `flowsNewestAt` how far our movement history reaches, and `windowsEndAt` the instant the windows count back from. For a capital decision the age of the record is part of the record. Free. |
vault_risk_dimensions | 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`. |
vaults_earnedread-only | What depositors actually KEPT, against what their vault advertised. READ `population` BEFORE QUOTING ANY SHARE FROM THIS. The comparison covers only the vaults where we hold BOTH an advertised rate and a realised one, which is a narrow and lopsided set, usually dominated by one venue: `population.largestVenue` names it and `population.concentration` says how much of the set it is. A share from here is a statement about those vaults, never about DeFi and never about this whole site. Not the vault’s return, which is what a unit held throughout would have earned: this is read from the depositor register, per vault, and set against the venue’s own quote scaled to how long those depositors have held. Measured today: of the vaults with a comparison, four in five gave their depositors less, at a median of thirty points short. ADVERTISED RATES ARE DECIMAL FRACTIONS and some are in the hundreds of per cent: 0.042 is 4.2% and 4.2 is 420%. Those survive a stated band of -1 to 5 (-100% to 500%); `advertisedBand.refused` says how many readings the band threw out, and `advertisedIsHigh` marks each row above 100% so a remarkable figure cannot be mistaken for a misplaced decimal. TWO THINGS TO REPEAT WHENEVER QUOTING IT. A depositor who withdrew everything is not in the register and the ones who left after losing are exactly the ones a return figure most needs, so this reads BETTER than the truth rather than worse; and `gapPoints` is percentage POINTS, not per cent, because a depositor cannot lose more than they put in. The aggregate and the widest gaps are free; the rest of the list needs the earned.detail capability and `withheld` says how many are missing. |
Schemas: list_tools.
{
"name": "org.aspern/aspern",
"$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
"remotes": [
{
"url": "https://aspern.org/mcp",
"type": "streamable-http"
}
],
"version": "1.1.0",
"websiteUrl": "https://aspern.org",
"description": "What the chain records about an address before you pay it, and whether a payment fits it."
}