org.aspern/aspern

Tools

• agent_changes

  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, out of about 2,900 tracked. 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.

  shallow
• check_service_endpoint

  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.

  shallow
• 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.

  shallow
• counterparty_check

  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.

  shallow
• 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.

  shallow
• evaluate_action

  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.

  shallow
• evidence_for

  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.

  shallow
• find_agents

  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.

  shallow
• find_vaults

  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.

  shallow
• identify

  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.

  shallow
• 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.

  shallow
• list_policies

  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.

  shallow
• list_vaults

  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.

  shallow
• monitor_subject

  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.

  shallow
• operator_check

  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`.

  shallow
• preflight_payment

  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.

  shallow
• 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.

  shallow
• vault_check

  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, 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` 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.

  shallow
• vault_exits

  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.

  shallow
• vaults_earned

  What depositors actually KEPT, against what their vault advertised. 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. 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.

  shallow

Embed this server’s score

Tool count and median score across every tool in this server’s corpus — honest in a way a single cherry-picked tool’s badge wouldn’t be.

[![Vouch score](https://vouch.tools/api/servers/0f7c6acc-f5fc-4323-b496-7ebb8d91b88a/badge.svg)](https://vouch.tools/servers/0f7c6acc-f5fc-4323-b496-7ebb8d91b88a)