Conformance & Versioning

2.1 Requirement keywords

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

2.2 Conformance levels

A server declares the level it implements. Levels are additive.

• Level 1: Core Read. The server exposes the required read resources for the domains it supports, with conformant schemas and naming. Sufficient for agents that observe and report.
• Level 2: Tools. The server additionally exposes the required action tools (for example, creating a lead or booking a service appointment) with conformant inputs, outputs, and errors.
• Level 3: Eventing. The server additionally supports subscriptions/eventing for the resources it exposes, so agents can react to change rather than poll.

A server MUST NOT claim a level it does not fully meet for the domains it advertises. A server MAY support a subset of domains; it MUST declare which.

2.3 Versioning

The specification uses semantic versioning (MAJOR.MINOR.PATCH).

• MAJOR: breaking changes to resource shapes, tool contracts, or naming.
• MINOR: backwards-compatible additions (new optional fields, new tools, new domains).
• PATCH: clarifications and editorial fixes with no contract impact.

A conformant server MUST advertise the specification version(s) it implements (see Reference). Agents MUST negotiate against the advertised version and MUST NOT assume fields outside it.

2.4 Lifecycle

Each release moves through a defined lifecycle:

Stage	Meaning
Draft (RFC)	Open for public comment. Contracts may change. Current state of v0.1.
Candidate	Feature-frozen; under partner review and reference-implementation testing.
Ratified	Adopted by the council. Changes follow the versioning rules above.
Superseded	Replaced by a later MAJOR version; maintained for a stated deprecation window.

The current document is v0.1 (RFC). The governance model for how revisions are proposed and accepted is described on the Governance page.

2.5 Relationship to the base protocol and its Extensions framework

This profile targets the 2026-07-28 revision of the Model Context Protocol (see Scope §1.5). Two things about that revision shape how this profile is written:

• This profile is expressed as an MCP Extension, not a fork. The 2026-07-28 revision formalized an Extensions framework: a capability published under a reverse-DNS namespace and advertised in the server's discovery response. This profile uses the namespace io.automotivemcp. A conformant server declares io.automotivemcp/profile in discovery (see Reference §7.1), and the still-unwritten federation and delegated-identity sections are being drafted as their own candidate extensions (io.automotivemcp/federation, io.automotivemcp/agent-identity) rather than as changes proposed against the base spec. Writing them this way gives the "vertical-neutral, extractable" design a real mechanism to extract to.
• Freshness is a profile of native MCP caching, not a new mechanism. The same revision added cacheable list results (ttlMs, cacheScope). Where this profile constrains staleness for a domain (a sold vehicle, a released appointment slot), it does so by profiling those native fields for the automotive case, not by defining a parallel freshness protocol.

A server that is conformant with this profile MUST also be conformant with base MCP at the revision it advertises. A profile-level pass from the conformance suite is not a substitute for base-protocol conformance; it assumes it.