pi.phos.nz/mcp
Last observed:— recorded as HTTP_5XX (http_502)
Observations
| Observed | Snapshot | Recorded as | Detail | Latency (ms) | Tools | Tool schema fingerprint |
|---|---|---|---|---|---|---|
| REL-SNAP-002 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-003 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-004 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-005 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-006 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-007 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-008 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-009 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-010 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-011 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-012 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-013 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-014 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-015 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-016 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-017 | HTTP_5XX | http_502 | — | — | — | |
| REL-SNAP-018 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-019 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-020 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-021 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-022 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-023 | PROTOCOL_ERROR | fetch_failed | — | — | — | |
| REL-SNAP-024 | HTTP_5XX | http_502 | — | — | — | |
| REL-SNAP-025 | HTTP_5XX | http_502 | — | — | — | |
| REL-SNAP-026 | HTTP_5XX | http_502 | — | — | — |
Identity
- Record key
pi.phos.nz/mcp— the normalised endpoint observed. See the methodology for the rule.- Declared addresses (not anchored)
- The registry declared 2 distinct addresses that normalise onto this one record key, as observed in REL-SNAP-026. Our identity rule keys a record on the lowercased host and the path with any trailing slash removed; the scheme, the query string and the fragment are not part of it. So this page holds all of them as one endpoint with one history. This count is not covered by the chain: no inclusion proof reaches it. The published root commits to the snapshot records this page is drawn from, never to how many addresses the registry declared. Each observation above is of whichever address was contacted on that sweep, and this record does not distinguish between them — so the tool count and the tool schema fingerprint describe one of the declared addresses rather than all of them. The addresses themselves are not published. See the methodology for the rule and how often it applies.
- Transport
- streamable-http
- Registry names (not anchored)
- io.github.albermm/piranha-vision, nz.phos/piranha What the registry said when we swept it, as observed by us — not evidence that the registry was correct, that the name belongs to whoever registered it, or that it still resolves. Not covered by the chain: no inclusion proof reaches this field. — more than one registry name refers to this single endpoint. We record both rather than choosing between them; the observation covers the endpoint and cannot be attributed to one of them.
- Name reported by the server
- Not reported. Self-reported and unverified — never used as identity.
Verifying this record
Each observation above carries a merkle leaf in the published snapshot it belongs to. Verify the chain explains how to walk a leaf to a published root without taking our word for any of it.