Read a business's own data in about five minutes.

Before you start

You need an HTTP client. curl is used below because it is already on your machine; anything that can make a request works, and nothing in this guide is specific to a language.

• No account. Every document in this guide answers an unauthenticated request.
• No API key. A key identifies you for rate limiting and is required only by a publisher who has closed anonymous reads — see Authentication.
• Nothing to install. jq is used to keep the output short and is optional everywhere it appears.

Everything is over HTTPS. Plain http:// is refused rather than redirected, because a redirect from a plaintext request has already happened in plaintext.

1Find a publisher

The platform publishes a plain-text index of every business on it, written for machines. Start there rather than guessing an address:

curl -s https://x-protocols.com/llms.txt

# X-Protocols

## How to read this

- Every business has a page at `/{country}/{city}/business/{publisher}`,
  and a machine index beneath it at `.../llms.txt`.
...

## Businesses (2)

- [Some Business](https://x-protocols.com/ba/sarajevo/business/some-business) — … (14 records)

The last path segment is the publisher slug. Every command below uses it, written as {publisher}. A business that has not said where it is yet lives at /b/{publisher} until it does, and that address keeps working afterwards — it answers 301 to the settled one, so follow redirects.

The list is paged. If the document ends with a More businesses: line, that URL is the next page; its absence is how you know you reached the end.

2Read its manifest

The manifest is the one document you have to read before any other, because every other address comes out of it. Never compose those URLs yourself:

curl -s https://x-protocols.com/t/{publisher}/.well-known/x-protocol/manifest.json | jq .

{
  "protocol_x_version": "1.0",
  "api_version": "2025-11-25",
  "registry": "x-protocol/v1",
  "publisher": { "slug": "{publisher}", "display_name": "…" },
  "capabilities": ["knowledge.search", "knowledge.get"],
  "endpoints": {
    "mcp":            "https://x-protocols.com/t/{publisher}/mcp",
    "public_profile": "https://x-protocols.com/…/business/{publisher}",
    "bulk_export":    "https://x-protocols.com/…/business/{publisher}/dump.jsonl",
    "jwks":           "https://x-protocols.com/t/{publisher}/.well-known/x-protocol/jwks.json",
    "revocations":   "https://x-protocols.com/t/{publisher}/.well-known/x-protocol/revocations.json"
  },
  "data_last_updated": "2026-09-11T09:12:00Z",
  "attestation": { "alg": "Ed25519", "kid": "…", "digest": "…", "signature": "…" }
}

3Read its records

Everything the business has published, one JSON object per line. This is the cheapest way to ingest a publisher whole — take the address from endpoints.bulk_export rather than building it:

curl -s https://x-protocols.com/ba/sarajevo/business/{publisher}/dump.jsonl | head -2

{"_meta": { "publisher": {…}, "authority": { "evidence": [ { "method": "dns_txt",
   "observed_at": "…", "proves": "control of published content at a specific website … NOT ownership of the business" } ] },
   "license": "…", "generated_at": "…" }}
{"id": "SKU-123", "type": "product", "title": "…", "url": "https://…", "attributes": {…},
 "updated_at": "…", "verified_at": "…"}

Read the _meta line before the records. It carries who published them, what evidence stands behind that claim, and what that evidence does not prove — a sentence written into the payload rather than left to a documentation page nobody opens.

The export is not signed. The manifest and every tool response are. That difference is deliberate and is stated in the specification; a validator reports the export's integrity as not checked rather than as passed.

4Ask it a question

Three JSON-RPC calls over one HTTP endpoint. Take the address from endpoints.mcp.

First, the handshake. Send the revision you speak; the server answers with the one it chose, which may be older than yours:

curl -s https://x-protocols.com/t/{publisher}/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize",
       "params":{"protocolVersion":"2025-11-25",
                 "clientInfo":{"name":"quickstart","version":"1"},"capabilities":{}}}'

Then ask what this publisher offers. Tool names are the publisher's own — a bakery may call its search find_products. Never hardcode one:

curl -s https://x-protocols.com/t/{publisher}/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' | jq '.result.tools[].name'

Then call one. The argument names come from that tool's own inputSchema, which tools/list returned beside the name:

curl -s https://x-protocols.com/t/{publisher}/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":3,"method":"tools/call",
       "params":{"name":"<the name you just read>","arguments":{"query":"opening hours"}}}'

A 401 here means this publisher has closed anonymous reads; everything else on this page still works without a key.

What the answer is allowed to mean

This is the part worth slowing down for. Every answer carries a coverage status, and the four are not shades of the same thing — they oblige you to do different things:

Responses also carry agent_instruction, which is the publisher asking a consumer to behave a certain way — typically “do not guess the value, do not substitute general knowledge”. It is advisory. Nothing enforces it, it is not a security mechanism, and a consumer that ignores it is not violating the format. It is there so a well-behaved consumer knows what the publisher intended.

When it does not work

Where to go next

• The specification — the normative rules: what a conforming publisher must emit, what a consumer must not conclude, and every rule identifier a validator reports.
• Check a source — run the conformance rules against a publisher and get a rule-by-rule report, including what could not be checked.
• Verify a response — four steps and about fifteen lines of code, using nothing of ours.
• The endpoint reference — every route, every error, and the same thing machine-readable.