Conformance

A BEST-compliant endpoint must:

1. Expose GET /.well-known/best returning a valid manifest — 200, public, application/json

2. Include at least one service in the manifest

3. List all supported capabilities with valid schema URLs

4. Implement the HTTP API for every listed capability

5. Return valid JSON conforming to the referenced schemas

6. Use standard HTTP status codes and the BEST error format — except deviceAuthorizationUrl and tokenUrl, which answer errors per RFC 6749 §5.2 (Agent Registration)

7. Declare authentication in the manifest (or omit for public) — never an undocumented 401

8. Reference every declared service from at least one capability — in the same manifest or, for a multi-tenant root, in its tenant manifests

9. Keep every manifest description within the length limit and free of mechanics (Manifest Discipline)

10. Publish no second machine-readable or agent-directed description of the service (Origin Discovery)

11. Where deviceAuthorizationUrl is declared, carry the sign-in guidance verbatim — the manifest text as that authentication block's note, the device text as the device answer's note, the token text at the start of the token answer's note — in the words of the version the manifest declares, or of a later one; and, from 0.9.17, accept connection in the device request and give it back as the token answer's name, keying the mcp entry by it (Agent Registration)

12. Bind a correlation id to the sender that first used it, refusing another sender's command naming it with a 400 that names the field (Command Results and Correlation)

13. Meet these obligations: the tenants of a credential answered with no tenant_id listed at the root, and the end of a credential (Agent Registration); the correlation id on every later fact about what a command created (Command Results and Correlation); a workflows capability active only with a recipe (Workflows); a query's parameters schema enforced and an /events range in RFC 3339 (Queries, Events); no constant pseudo-tenant hosting a surface (Multi-Tenancy rule 5); application/cloudevents+json accepted on POST /commands (HTTP Transport); and, in specs/security.md, cleartext refused and never carrying a credential, request records without credentials or query strings, and the 413 and 429 answers

Per-capability required endpoints (for active capabilities; partial is exempt but must document available routes in endpoints):

Capability	Required endpoints
io.best.agents.commands	GET /commands, POST /commands
io.best.agents.events	GET /events
io.best.agents.queries	GET /queries, GET /queries/{schema}/{version}, GET /queries/{schema}
io.best.agents.workflows	GET /workflows, GET /workflows/{id}

Multi-tenant root manifests additionally follow the Multi-Tenancy rules.

Compliance does not require: any specific language, framework, or architecture; any specific event transport; MCP support; or AI/LLM capabilities — a BEST service can be deterministic or human-operated.

Why the root manifest's rules matter for agents

An AI agent hitting a root manifest that has an empty capabilities array but no tenants.manifest cannot proceed — it has no signal for what to do next. A root manifest that follows the Multi-Tenancy rules gives any agent unambiguous guidance: check capabilities → if absent, check tenants.manifest → ask user for tenant ID → fetch tenant manifest.