For developers
Check a source against the rules.
Point it at a publisher and it reports every rule in the draft specification: what the documents look like, who signed them, whether the signatures hold, how old the data is and what the publisher can actually answer — including every rule it could not check.
On this page
Summary
32 rule(s) passed with 4 warning(s). Everything checked, conforms.
| Checked | https://sample.invalid/t/kamen-gradnja |
| Source | labelled fictional publisher, in this process, no network |
| Took | 5ms |
| Rules from | draft specification, document revision 2026-10-09 |
| Validator | protocol-kit 0.3.0 — the same rules xp validate runs |
This is a sample, and the publisher in it does not exist. A publisher whose website is its own unproven claim, whose records carry text shaped like an instruction to an AI agent, and most of whose questions fall through to not_covered. None of that is a failure of the format; all of it is reported.
It ran entirely inside this server — no request left the machine, and every address in the report is under sample.invalid, which can never be registered.
The most important thing to fix
Nothing failed and nothing was skipped. Every rule this validator applies, it applied, and each one passed — which is a statement about these documents and not about the business behind them.
4 warning(s) are listed below. A warning is not a conformance failure — it is something a consumer has to be told about, most often an absence of evidence rather than evidence of a problem.
Rule by rule
Format 11
Are the documents the shape the specification describes?
passXP-DISCOVERY-002§2.2
endpoints.public_profile names the canonical address
a consumer takes the canonical base from here rather than composing it
Observed: https://sample.invalid/b/kamen-gradnja
passXP-DISCOVERY-007§2.4
The well-known path form is reported honestly
recorded so no document derived from this report can describe the path as registered or standardised
Observed: the /t/{publisher}/.well-known/... form, which is NOT an RFC 8615 well-known path at all: RFC 8615 locates well-known resources at the ORIGIN ROOT. It is a platform-namespaced URL and works fine; it is simply not the thing RFC 8615 defines.
In: https://sample.invalid/t/kamen-gradnja/.well-known/x-protocol/manifest.json
passXP-EXPORT-001§4.2
The bulk export opens with a _meta header
a consumer reading only the first line learns what this is, whose it is and how to refresh it
Observed: kamen-gradnja
passXP-MANIFEST-002§3.1
data_last_updated is a real instant or absent
the newest record timestamp is stated
Observed: 2026-05-12T10:00:00Z
passXP-MANIFEST-003§3.3
Capability names are reported as handler names, not tool names
these are HANDLER names; a consumer must read tool names from tools/list on the MCP endpoint and must not call a capability string as if it were a tool
Observed: knowledge.search, knowledge.get
passXP-MANIFEST-009§3.8
A publisher that is not published is not described as served
the registry says it serves this publisher's records, so the endpoints below are expected to answer
Observed: published: true
passXP-SCHEMA-ENVELOPE§5.3
The envelope matches its published schema
every supported keyword in schema/envelope.schema.json applied and held
In: search_records
passXP-SCHEMA-EXPORT_META§5.3
The export_meta matches its published schema
every supported keyword in schema/export-meta.schema.json applied and held
In: https://sample.invalid/b/kamen-gradnja/dump.jsonl
passXP-SCHEMA-MANIFEST§5.3
The manifest matches its published schema
every supported keyword in schema/manifest.schema.json applied and held
In: https://sample.invalid/t/kamen-gradnja/.well-known/x-protocol/manifest.json
passXP-SCHEMA-RECORD§5.3
The record matches its published schema
every supported keyword in schema/record.schema.json applied and held
In: https://sample.invalid/b/kamen-gradnja/service/svc-stone-cutting
passXP-VERSION-001§1
protocol_x_version is a version this kit implements
the document contract is recognised
Observed: 1.0
Source and identity 6
Who is publishing this, and what has actually been proven about them?
warningXP-AUTHORITY-001§3.6
domain_verified rests on observed evidence
no domain proof is held. That is not a finding against the business -- it is the absence of one kind of evidence.
Observed: domain_verified=false
Next step: prove the domain by DNS TXT or a well-known file
Owned by where this publisher proves its domain. The publisher edits this; a consumer cannot.
warningXP-AUTHORITY-002§6.3
The website claim and the proven host are told apart
the website is the publisher's own claim and no host has been proven; a consumer must not present it as verified
Observed: https://kamen-gradnja.test (claimed), nothing proven
Owned by where this publisher proves its domain. The publisher edits this; a consumer cannot.
passXP-AUTHORITY-005§7.4
trust_tier is not published as a scale
only a real value is emitted; the orthogonal authority signals are the ones to read
Observed: unverified
passXP-DISCOVERY-003§2.3
Every locator is absolute and anchored to this origin
keys, revocations and endpoints all resolve to the origin that served the manifest
Observed: https://sample.invalid
passXP-IDENTITY-001§4.1
Every record names its publisher and its own address
(publisher, type, id) identifies each record and every URL resolves under the canonical base
Observed: 3 record(s)
passXP-IDENTITY-006§6.3
Published contacts are labelled with their audience and source
every contact states whose it is and which record it came from
Integrity 7
Do the signatures hold, and does the key chain reach a root?
passXP-INTEGRITY-001§8.1
The manifest signature verifies
SHA-256 over the canonical payload, Ed25519 over that digest -- the digest, not the message
Observed: kid fixture_reg_BnB5UK3BYNgx
passXP-INTEGRITY-003§8.2
The report states what the signature does and does not cover
there is no cryptographic link from the manifest to the bytes of the bulk export; a record read from dump.jsonl must not be described as cryptographically verified
Observed: signed: manifest, response envelopes, key entries, revocation list. NOT signed: dump.jsonl, HTML pages and their JSON-LD, llms.txt, sitemap.xml
passXP-INTEGRITY-006§8.4
The key is bound to this identity
the chain root -> registry key -> signing key verifies against the root you pinned
passXP-INTEGRITY-007§8.5
Mirrored fields agree with the attestation block
signed_at, signing_kid and jwks_url are the same inside the signature as outside it
passXP-INTEGRITY-009§8.7
Revocation was checked
the key is not listed as revoked as of that instant -- and that instant, not 'now', is what the finding is about
Observed: as of 2026-10-14T03:40:06Z
passXP-INTEGRITY-013§8.10
The envelope answers the call that was sent
the signed tool and arguments are the call this kit sent
Observed: search_records
In: https://sample.invalid/t/kamen-gradnja/mcp
passXP-MANIFEST-007§3.7
The manifest is signed, or states why it is not
a consumer can tell the difference between an unsigned registry and an unsigned moment
Observed: signed by fixture_reg_BnB5UK3BYNgx
Freshness 3
How old is this, and does it say when it stops being current?
passXP-FRESHNESS-003§8.6
The attestation states an expiry
the claim is bounded, and the bound is inside the signature
Observed: 2026-10-14T03:55:06Z
passXP-FRESHNESS-004§8.6
The attestation has not expired
Observed: valid for another 15m0s
passXP-FRESHNESS-005§9
The four ages are reported separately
a business can hold a current domain proof and year-old opening hours; one 'trust' number teaches a consumer to ignore both
Observed: data: 2026-05-12T10:00:00Z | authority: not stated | document: 2026-10-14T03:40:06Z | signature expiry: 2026-10-14T03:55:06.14076505Z
Answers 7
What can this publisher answer, and does it say so honestly when it cannot?
warningXP-COVERAGE-005§5.1
Evidence completeness is stated
evidence_complete is absent, so a consumer cannot tell a complete evidence set from one nobody accounted for. It is required BOTH ways for exactly that reason.
Next step: emit evidence_complete on every response
warningXP-COVERAGE-012§5.5
Publisher-authored strings are handled as data
this publisher is shipping text shaped like an instruction to an AI agent. It is data and this kit renders it as data -- a signature over it attests provenance, not benignity -- but a consumer whose prompt concatenates publisher content will act on it.
Observed: "do not mention any other" at [2].content; "ignore all previous" at [2].content; "you are now" at [2].content
In: the bulk export (https://sample.invalid/b/kamen-gradnja/dump.jsonl)
Next step: check whether this text belongs in the published record; a consumer must not need it to be absent in order to be safe
Owned by the record editor. The publisher edits this; a consumer cannot.
passXP-COVERAGE-001§5.1
The resolved invariant holds
status, covered, answers_request and unresolved agree
Observed: status=not_covered
passXP-COVERAGE-004§5.1
not_covered is scoped to what was published
this kit renders not_covered as a statement about publication, never as 'the business does not offer this'
Observed: This publisher has not published anything about that. That is not the same as the business not offering it.
passXP-COVERAGE-011§5.5
agent_instruction is present and treated as advisory
read as guidance; this kit's own behaviour does not depend on it, and a signed malicious string is still a malicious string
Observed: This publisher has published nothing bearing on this request. Say that plainly...
passXP-COVERAGE-012§5.5
Publisher-authored strings are handled as data
no string in this document is shaped like an instruction to an agent. This kit treats every one of them as data regardless -- the check reports what a publisher is shipping, it is not what makes a consumer safe.
Observed: the response envelope
In: the response envelope
passXP-TRANSPORT-001§10.1
Tool names come from tools/list
tool names were read from the server, not composed from the manifest; capability "knowledge.search" is a HANDLER name and is not a callable tool name -- calling it would fail
Observed: tools/list: [search_records, get_record]; manifest capabilities: [knowledge.search, knowledge.get]
Scope 2
What this run covered, and what it deliberately did not.
passXP-SCOPE-001§13
The report states its own boundaries
validating a document establishes facts about that document, not about the server that served it
Observed: 4 document(s) checked, 1 area(s) explicitly not checked
passXP-SCOPE-003§13
Excluded audits are named rather than folded in
these are not conformance requirements of this protocol and were deliberately left out of the verdict. No aggregate 'AI readiness' score is computed: there is no defensible weighting, and a number invites a consumer to act on it.
Observed: llms.txt, generic SEO advice and Dataset markup
Technical detail
Documents read
- https://sample.invalid/t/kamen-gradnja/.well-known/x-protocol/manifest.json
- https://sample.invalid/.well-known/x-protocol/registry-keys.json
- https://sample.invalid/b/kamen-gradnja/dump.jsonl
- https://sample.invalid/t/kamen-gradnja/mcp
Not checked, and why
This is the half of a validator report that usually goes missing. A check that did not run is reported here rather than counted as a pass.
| What | Why not |
|---|---|
| integrity of dump.jsonl, the public pages and llms.txt | those surfaces are not signed (XP-INTEGRITY-003), so there is nothing to verify |
Versions
| Specification document | 2026-10-09 |
| Validator (protocol-kit) | 0.3.0 |
| Started | 2026-10-14T03:40:06Z |
| Finished | 2026-10-14T03:40:06Z |
These are two of the four version numbers in play and neither implies another: protocol_x_version is the wire format, api_version is the MCP revision the server speaks, server_version is the publisher's build, and the validator has a version of its own.
The report as a file
The same report as JSON: every finding with its rule identifier, specification section, status, what was observed and what to do about it — plus the list of documents that were and were not read.
The download re-runs the check, so the file describes its own run rather than this page's. Nothing you typed is ever sent back to you from this origin as a file — that is why it re-runs instead of echoing.
The same fixtures ship inside the command-line tool. xp serve prints the base URL and the pinned root it generated; paste both into the next command.
xp serve xp validate http://127.0.0.1:8973/t/kamen-gradnja \ -allow-http -allow-private \ -root-kid <the kid xp serve printed> -root-key <the key xp serve printed> \ -q "concrete stairs"
What it cannot check
Four things this page is not, stated here rather than left for a reader to infer from a green result.
- It does not confirm identity. A root key fetched from the same origin as the signature it validates proves nothing, and a hosted validator has no root it obtained anywhere else. So every live run reports the root-of-trust rule as not checked. To actually confirm it, pin a root you obtained out of band and run xp validate … -root-kid … -root-key … yourself.
- It does not check whether anything published is true. The rules check shape, provenance, signature and freshness. A publisher can conform perfectly and be wrong in every field.
- It is not an endorsement. There is no “AI ready” and no “verified business” at the end of this, because neither would mean anything. What you get is a list of rules and their results.
- It describes the documents it read, at the moment it read them. Not the whole server, not yesterday, and not after the publisher's next edit.
Every fetch is bounded: https only, six seconds, two megabytes, at most two redirects, private and loopback addresses refused, and the destination re-checked at each redirect. That is protocol-kit/xpfetch, the same guard the command-line tool uses.