How observations are made

Probe procedure

A record is probed only when it is listed and has set consent.probes: true. Each probe is performed for every endpoint the record declares:

MCP

A JSON-RPC initialize call over streamable HTTP, followed by notifications/initialized and tools/list. The declared server name, protocol version, and tool list are recorded.

A2A

An HTTP GET of the agent-card URL. The response is parsed as JSON and checked for the required name and url fields.

OpenAPI

An HTTP GET of the document, parsed as JSON or YAML without resolving external references. The version, path count, and operation count are recorded.

HTTP

A plain GET; the response status, latency, and server header are recorded.

Requests use ports 80 and 443 only, follow at most five redirects with each hop re-validated, time out at ten seconds, and cap the response body read. The prober identifies itself as NandaTown2-Pulse/0.1 with a link to this page. The scheduled cadence is every six hours; a listed record may also be probed on demand from its page or via POST /api/town/records/<slug>/probe. Each observation records whether it was scheduled or manual.

Observation states

answered

The endpoint returned a response with status 2xx or 3xx.

auth_required

The endpoint returned 401 or 403. It is reachable but declined the unauthenticated probe.

refused

The endpoint returned 429. The target is paused for 24 hours after this result.

no_answer

No response was received within the timeout, or the connection failed.

error

A response was received but could not be interpreted for the requested probe type, or the address was refused before connection.

Statistics

Summary statistics at /api/town/records/<slug>/stats report the number of liveness observations in the window (n), the count that answered, the answered rate, and the median latency of answered probes. A rate is reported only when n is greater than zero; when n is zero the rate is null rather than a fabricated 0%. A rate over a small n carries a correspondingly wide uncertainty, which is why n is always reported alongside it. The window is a query parameter (1 to 90 days, default 30).

Evidence model

One evidence record states one observation: an observer, a subject (identified by the exact record fingerprint probed), a time, and an outcome. Evidence is written by the prober; a record cannot write evidence about itself. Records are retained for 90 days. Because evidence names the fingerprint of the record version it observed, a result never silently transfers to a later, edited version of the same record.

Capability change detection

For MCP endpoints, each structural observation's tool list is compared with the previous one for the same target. When the set changes, the observation records the added and removed tool names and the time of the prior observation. A record file is frozen at merge, but the service it points to can change underneath it; this comparison surfaces that drift.

Limitations

• A probe observes one request at one time from one network location. It is not a measurement of general availability.
• An answered result confirms a response, not the correctness or safety of that response.
• The prober is a single observer. The evidence model names the observer so that independent observers can be added without changing the schema, but at present there is one.
• A hosted model or service can change behaviour without changing the record that points to it; only tool-list drift on MCP endpoints is currently detected.
• If the prober misses its schedule, liveness indicators are marked paused; a paused indicator means absence of recent observation, not a negative result.

Reproducibility

The registry data is a public git repository and the derived index is rebuilt from it. The full evidence stream is exported as newline-delimited JSON at nanda-town-2.up.railway.app/api/town/evidence, so every count, rate, and history shown on the site can be recomputed from primary records. The API is described in OpenAPI form.