Skip to main content
Glama

ASPERN: counterparty checks for agents

Does this agent have a business (paid)

agent_business
Idempotent

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. 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, explained in limits: an ADDRESS is not a customer; a PAYMENT is not a delivery; a SHARED FUNDER is not an identity; and a COST we cannot see is not a cost that is not there. It also carries economicChain: the four links 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 evidenced, unevidenced (about the agent), unread (about US) or unevidenceable (about the rail), never folded together. NO SCORE there either: the worst link governs. For an x402-only agent the delivery link is unevidenceable, which is the rail and not the agent. PAID.

Input Schema

NameRequiredDescriptionDefault
addressYesThe agent’s address.

Output Schema

NameRequiredDescriptionDefault
metaNoHow current this answer is and what it was read from: `freshness` and the ages behind it. Present on every answer from this server, whatever the tool.
saysYesHow much of the question we could answer, and which parts we could not.
limitsYesThe four conclusions 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. A COST we cannot see is not a cost that is not there.
addressYesThe agent this is about, read back.
answersYesOne per question: `asks` in a person’s words, `answered` as measured/partial/unmeasured, `says`, and the `figures` behind the sentence so you can do your own arithmetic. 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.
commerceNoSettled, of that service-linked, of that delivery-evidenced, nested and never added; plus the payments whose rail cannot evidence delivery (x402). Read `says` before quoting any of them as revenue. SINCE 2026-10-28 `settledShownToBeX402` and `rails.x402.usdShownToBeX402` sit beside `settled` and `rails.x402.usd`, which count every authorised transfer: the ShownToBeX402 figures count only payments shown to be x402. Quote those as x402.
coverageYesHow many of the six are measured, partial and unmeasured. A count, never averaged into a grade.
evidenceNoThe common payment record (TODO-07): `state: built` with `facilitator` (who submitted, never credited), `onChainRecipient`, `listedPayee`, `facilitatorIsRecipient`, `recipientIsListedPayee`, `settlement`, `delivery`, `deliveryEvidence`, `says`; or `state: not-applicable` with `says` naming why no single payment is described.
warningsNoAnything the server wants a caller to know about THIS answer before acting on it. Empty is the normal case and is not a guarantee.
recordAsOfNoWhen the nightly record behind most figures was computed. The revenue months are read live.
economicChainNoSINCE 2026-10-11. 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**.
answeredStatesNoWhat measured, partial and unmeasured each mean.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / evidence
      Added value: +{
      +  "description": "The common payment record (TODO-07): `state: built` with `facilitator` (who submitted, never credited), `onChainRecipient`, `listedPayee`, `facilitatorIsRecipient`, `recipientIsListedPayee`, `settlement`, `delivery`, `deliveryEvidence`, `says`; or `state: not-applicable` with `says` naming why no single payment is described.",
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • changedOutput schema / properties / commerce / description
      Previous value: -"Settled, of that service-linked, of that delivery-evidenced, nested and never added; plus the payments whose rail cannot evidence delivery (x402). Read `says` before quoting any of them as revenue."New value: +"Settled, of that service-linked, of that delivery-evidenced, nested and never added; plus the payments whose rail cannot evidence delivery (x402). Read `says` before quoting any of them as revenue. SINCE 2026-10-28 `settledShownToBeX402` and `rails.x402.usdShownToBeX402` sit beside `settled` and `rails.x402.usd`, which count every authorised transfer: the ShownToBeX402 figures count only payments shown to be x402. Quote those as x402."
  3. Changed3 schema fields changed
    • changedOutput schema / properties / answers / description
      Previous value: -"One per question: `asks` in a person’s words, `answered` as measured/partial/unmeasured, `says`, and the `figures` behind the sentence so you can do your own arithmetic."New value: +"One per question: `asks` in a person’s words, `answered` as measured/partial/unmeasured, `says`, and the `figures` behind the sentence so you can do your own arithmetic. 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."
    • addedOutput schema / properties / economicChain
      Added value: +{
      +  "description": "SINCE 2026-10-11. 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**.",
      +  "type": "object"
      +}
    • changedOutput schema / properties / limits / description
      Previous value: -"The four conclusions the data invites and this refuses."New value: +"The four conclusions 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. A COST we cannot see is not a cost that is not there."
  4. Changed1 schema field changed
    • addedOutput schema / properties / commerce
      Added value: +{
      +  "description": "Settled, of that service-linked, of that delivery-evidenced, nested and never added; plus the payments whose rail cannot evidence delivery (x402). Read `says` before quoting any of them as revenue.",
      +  "type": "object"
      +}
  5. Changed2 schema fields changed
    • addedOutput schema / properties / meta
      Added value: +{
      +  "description": "How current this answer is and what it was read from: `freshness` and the ages behind it. Present on every answer from this server, whatever the tool.",
      +  "type": "object"
      +}
    • addedOutput schema / properties / warnings
      Added value: +{
      +  "description": "Anything the server wants a caller to know about THIS answer before acting on it. Empty is the normal case and is not a guarantee.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  6. Added

TDQS

B3.4/5.0
Behavior4/5

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

Beyond the annotations, the description discloses a lot of non-obvious behavior: results are six separate answers with deliberately no aggregate score, the `limits` field carries four explicit refusal caveats, and `economicChain` reports four links tagged `evidenced`/`unevidenced`/`unread`/`unevidenceable` with worst-link governance. The x402 case (delivery link is unevidenceable) is a concrete, useful edge-case disclosure. The 'PAID' marker is consistent with readOnlyHint=false rather than contradicting it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is padded with rhetorical asides and heavy all-caps emphasis ('THERE IS NO SCORE', 'DEMONSTRATED'). The substance about `limits` and `economicChain` earns its place; the anti-scoring manifesto is repeated twice and could be compressed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still usefully explains the shape of the answer (six independent questions, no score, `limits`, `economicChain` status vocabulary), which is what an agent needs to interpret results. The one real omission is routing guidance relative to the many sibling evidence tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single required parameter at 100% schema coverage, so the schema already documents `address`. The description adds nothing about the address — no format, chain scoping, or whether an address can be a contract versus an EOA — so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific assessment target: whether an agent has a demonstrable business, broken into six named sub-questions (independence of payers, revenue trend, repeat custom, delivery evidence, cost, multi-address linkage). That is far more specific than the title alone. It never names a sibling, though, so the boundary against the very similar `agent_economic_profile` is left to the agent to infer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It describes who cares about the answer ('an investor, a marketplace or an operator') but never says when to call this tool versus `agent_economic_profile`, `counterparty_history`, or `payment_evidence`. There are no preconditions, exclusions, or alternative-routing statements — the agent must guess which of the many evidence tools to reach for.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources