Discovery and Registry — v0.2 draft

• Status: draft proposal, 2026-10-21. Extends v0.1; nothing in v0.1 changes.
• Editors: AutoIsto s. r. o.
• Licence: CC BY 4.0 (this text, the schemas and the examples)

The key words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in capitals.

1. Purpose#

A person tells an agent what they want: a used estate car in Žilina, a two-room flat in Brno. The agent needs to know which intent holders serve that country and category, and where their servers are. This chapter defines three things:

1. the holder descriptor, which every holder publishes on its own domain (§2);
2. the registry, a public list of holders built from their descriptors and checked automatically (§3–§6);
3. how agents use the registry (§7).

The registry lists who serves what. It does not hold intents, does not route them and does not rank holders.

2. Holder descriptor#

A holder describes itself in one file on its own host:

https://<host>/.well-known/isto-intents.json

Schema: holder-descriptor. Example: holder-descriptor-sk.

Each entry of servers:

Rules:

1. The descriptor MUST be served over HTTPS on port 443 with status 200, with a JSON content type, at most 64 KB, without a redirect. Server urls in one descriptor MUST be distinct.
2. Every server url MUST use HTTPS and MUST be on <host> or on a subdomain of <host> with a leading www. removed. A server on another domain is listed by that domain's own descriptor.
3. The descriptor MUST NOT contain personal data other than the operator's contact, which SHOULD be a role address (for example info@), not a person's.

3. Registry#

The reference registry is operated by the editors of this specification at:

https://istointents.org/registry.json

Schema: registry. Example: registry-sk-cz. It is served with Access-Control-Allow-Origin: *, so that any agent or web page can read it.

Each entry is one host. It carries two kinds of fields, kept apart:

• declared — copied from the holder's descriptor: operator and each server's description. The operator is responsible for them.
• observed — what the registry itself saw: status, checkedAt, lastOkAt, the tools the server listed and its MCP server name. Only these are the registry's statement.

Entries are ordered by id. The order is not a recommendation, and the registry gives no score, rank or preference to any holder, including those of its own operator.

4. Getting listed#

1. Publish the descriptor (§2) with "registry": { "listing": "requested", "terms": "<terms URL>" }. Publishing it on your host is the proof that you control the host, in the same way as an ACME HTTP challenge; no token, account or e-mail is needed.

2. Ask the registry to read it:

   POST https://istointents.org/registry/v0/submit
   Content-Type: application/json
   
   { "host": "www.example.com" }

3. The registry fetches the descriptor, validates it against its schema and checks every server (§5). The response says whether the entry is listed and, if not, what failed. A new entry is listed when at least one of its servers passes the check (a passing deprecated server counts).

The registry terms are at registry/terms.

After that, the registry re-reads the descriptor at every check: a change to the descriptor appears in the registry without a new submission. Listing is free.

5. Automated check#

For every server with binding: "mcp" the registry, about every 6 hours (each entry is due 6 hours after its last check; with many entries the interval can grow):

1. calls initialize over Streamable HTTP; it MUST succeed within 10 seconds;
2. calls tools/list; the list MUST contain the tools of every declared profile. For consent-link: intent_publish_intent, intent_get_intent, intent_list_matches and intent_withdraw_intent;
3. for consent-link, reads the input schema of intent_publish_intent; it MUST NOT have a top-level property for contact data (email, e-mail, phone, telephone, name, address, contact, compared case-insensitively) — profile rule 1 of the MCP binding.

The check never calls a tool, so it creates nothing at the holder. Requests carry the user agent IstoIntentsRegistry/0.2 (+https://istointents.org/registry/).

The check covers the interface only. It is not a certification: it does not show that a holder follows the other rules of this specification, keeps its promises to people, or obeys the law.

6. Status#

1. A failure never deletes an entry. An entry keeps lastOkAt, and returns to active at the first check that passes.
2. If the descriptor cannot be fetched or can no longer be used, the entry keeps its last valid content and its servers get unreachable or non-conformant as above, with the reason in observed.problem.
3. An entry is removed only when its operator withdraws it — "listing": "withdrawn" in the descriptor (honoured even if the rest of the descriptor does not validate), the descriptor answering 410 Gone, or a request to the contact address of the registry — or under the registry terms.

7. Agents#

1. An agent that has no holder configured for a person's country and category SHOULD read the registry and use servers whose status is active and whose countries, categories and languages fit.
2. When several fit, the agent SHOULD let the person choose, naming the operator and the host, or follow the person's stated preference. The registry order is not a choice.
3. An agent SHOULD cache registry.json no longer than 24 hours.
4. The registry is also available as an MCP server at https://istointents.org/mcp with one read-only tool, registry_find_holders (country, category, optional language), which returns the active servers that fit, each with its operator, host, URL, what it serves and when it was checked.
5. A listed holder's MCP server SHOULD, in its server instructions, point agents to https://istointents.org/registry.json for countries or categories it does not serve.

8. Relation to the MCP Registry#

The MCP Registry lists MCP servers of every kind and tells clients how to connect to them. This registry lists only Isto Intents holders: what they serve and whether their servers answered the last check. The two refer to each other and neither replaces the other:

1. A server in a descriptor MAY name its MCP Registry entry in mcpRegistryName. The registry looks the name up and reports observed.mcpRegistry as match (same remote URL), mismatch or absent. This does not affect status.

2. A holder that publishes its server to the MCP Registry SHOULD add to its server.json:

   "_meta": {
     "io.modelcontextprotocol.registry/publisher-provided": {
       "org.istointents": {
         "descriptor": "https://<host>/.well-known/isto-intents.json",
         "registry": "https://istointents.org/registry.json"
       }
     }
   }

9. Privacy and security#

1. The registry holds no data about buyers or intents, and a descriptor MUST NOT carry any.
2. The registry fetches only https:// URLs on port 443 whose host is a domain name (never an IP address), follows no redirects, stops after 10 seconds, and reads at most 64 KB of a descriptor and 256 KB of a server response.
3. A submission needs no identity and the registry stores none. It is limited to one per host every 10 minutes, and to 300 submissions of hosts not yet listed per day in total; a listed host may always resubmit.

10. Data licence#

registry.json is published under CC BY 4.0. Attribution: "Isto Intents Registry, istointents.org".