Skip to main content
Glama

ASPERN: counterparty checks for agents

How well we know whether declared endpoints answer

endpoint_coverage
Read-onlyIdempotent

BEFORE YOU TREAT ANY ENDPOINT AS RELIABLE, ask how well we know. There is no uptime number here and there will not be one, because the states mean different things and summing them produces a figure about nothing: a 402 is an x402 seller doing exactly what it advertises, a 401 or 403 is credentials WE do not hold, a 3xx is a move we chose not to follow, and a timeout describes OUR attempt rather than the host. Only the states marked fault: true are the endpoint failing. TWO POPULATIONS, each on its own denominator and NEVER added together: the HOSTS registered identities declare, probed daily under a deadline that sometimes expires before every host is reached — so a host we did not ask keeps whatever an earlier day found, and notAsked says how many — and the x402 RESOURCES sellers list, where a state is published only after three knocks because one failure is not a finding. The second number is the uncomfortable one and it is published anyway: most listed resources have never been knocked on at all, which is our reach and not a judgement of the sellers. Free, because a coverage claim nobody can audit is marketing rather than evidence.

Input Schema

NameRequiredDescriptionDefault

No arguments

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.
saysYesBoth populations in prose, each with its own denominator, and what the fault count does and does not include.
hostsYesThe daily HEAD probe of hosts registered identities declare. `declared`, `asked` and `notAsked` — the probe runs under a deadline, so these differ and the difference is hosts whose state is a memory. `lastRunAt`, `ageHours` and `stale` against a daily cadence. `staleHosts` counts hosts nobody confirmed inside the freshness window. `byState` is one entry per state with `hosts`, `agents` (identities standing behind them — one dead host can carry hundreds), `share`, `fault` (true, false, or NULL where the state is about our attempt or our credentials rather than the endpoint) and `says`. `agentsBehindFaults` counts identities behind a fault state only, built from the states that ARE faults rather than by negating `answering`.
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.
cannotSeeYesWhat no figure here can reach: endpoints nobody declares, whether the declaring identity controls the host, whether a 402 offer can actually be signed (that needs the response BODY and comes from the knock flow), and whether an endpoint that answered answered anything good.
resourcesYesThe x402 resources sellers list, on its OWN denominator. `declared`, `everKnocked` (knocked even once) and `confirmable` (knocked three times or more, the only ones whose state we will publish), with `everKnockedShare` and `confirmableShare` beside them, plus `knockedLastWeek` and `oldestKnockHours`. Read `confirmableShare` as the honest answer to "can ASPERN tell me whether an x402 endpoint works": today it is small.
measuredAtYesWhen these figures were counted. The host states come from the last probe RUN, whose own age is on `hosts.ageHours`; a fresh read of a stale probe is not a fresh fact.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already declare read-only, open-world, idempotent, non-destructive behavior, and the description adds substantial context beyond that: state meanings, why states are not summed, the two separate denominators, fault semantics, deadline and notAsked behavior, and three-knock publication for x402 resources. This is unusually rich behavioral disclosure with no contradiction.

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 description is front-loaded and structured around the right warning, but it is very long and rhetorical for a zero-parameter tool. Sentences such as 'The second number is the uncomfortable one...' and the closing 'Free, because...' add manifesto tone rather than invocation-critical detail.

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

Completeness5/5

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

Given the tool's complexity and the presence of an output schema, the description provides enough contextual caveats to interpret coverage correctly: denominators are separate, only fault states count as failure, and x402 reach is not a seller judgement. Nothing essential for correct use appears missing.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4. The description correctly does not waste space documenting parameters and instead explains the coverage semantics.

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 clearly establishes that this tool reports endpoint coverage rather than uptime, and it explains the two populations being covered. However, it does not explicitly contrast itself with sibling tools such as check_service_endpoint or knock_on_endpoint, so sibling differentiation is left implicit.

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

Usage Guidelines4/5

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

The opening line gives a clear usage condition: ask this before treating any endpoint as reliable. It does not name when not to use it or which sibling tool to use instead for direct endpoint probing, so it stops short of explicit routing.

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