Scope, Goals & Non-Goals

1.1 Purpose

This specification defines how retail automotive dealership systems expose their data and actions to AI agents over the Model Context Protocol (MCP). It establishes a common set of resources, tools, naming conventions, and a security profile so that any conformant agent can work with any conformant server without bespoke, per-vendor integration.

The protocol layer is MCP. This specification is the automotive retail profile of MCP: the agreed-upon resource and tool surface for the dealership.

1.2 Goals

• Make any conformant dealership server interchangeable from an agent's point of view.
• Cover the operational core of the dealership: inventory, leads and CRM, deals and desking, service, parts, F&I, and marketing/analytics signals.
• Keep the surface small, stable, and versioned, so vendors can implement it once and rely on it.
• Treat security and PII as first-class, automotive data carries real compliance weight.
• Be implementable on top of existing DMS, CRM, and platform APIs without forcing a re-platform.

1.3 Non-Goals

This specification is the retail / dealership data-and-tool layer. It is explicitly distinct from, and does not attempt to replace:

• Vehicle and OEM signal standards such as COVESA / VSS (Vehicle Signal Specification). Those describe signals from the vehicle itself; this describes the systems of the dealership.
• The Model Context Protocol itself. MCP is the transport and capability model; this profile rides on top of it and does not redefine it.
• Proprietary vendor APIs. A conformant server may be a thin adapter in front of an existing DMS or CRM API. This spec standardizes the agent-facing surface, not the system of record.

Claiming the dealership, not the vehicle, is deliberate: it avoids confusion with vehicle-signal efforts and gives implementers an unambiguous target.

Related work: WebMCP

WebMCP is a second, complementary standard, and it is not in tension with this one. It answers a different question: how a webpage exposes tools to an AI agent that is already inside the browser (via document.modelContext), as opposed to how a backend dealership system exposes tools to any agent over the network, which is what this profile and base MCP both describe. A dealer's website is a webpage; WebMCP is how that page could offer "check availability" or "book a test drive" directly to a browser-resident shopping agent, independent of whether the dealer's DMS/CRM has a conformant server at all. A fully agent-ready dealer implements both surfaces.

This specification is aware of WebMCP but does not adopt or profile it, deliberately. WebMCP is early: it is W3C Web Machine Learning Community Group incubation, explicitly "not a W3C Standard nor on the W3C Standards Track," shipping only behind Chrome and Edge origin trials, with Firefox and Safari standards-positions still open. Standardizing its tool shapes is out of our lane and premature. We note where it fits and leave it there.

1.4 Audience

DMS, CRM, and website/platform vendors implementing a conformant server; AI-agent vendors consuming it; and the dealers and agencies who will ask "do you support MCP, and which version?"

1.5 Base protocol currency

This profile targets the 2026-07-28 revision of the Model Context Protocol for its transport and authorization mechanics. That revision is a large one: it replaces the initialize / initialized handshake and Mcp-Session-Id with a stateless core, adds a mandatory server/discover RPC that carries a protocolVersion per request, adds cacheable list results (ttlMs / cacheScope), and formalizes an Extensions framework under which a vertical like this one can publish net-new capabilities under its own reverse-DNS namespace. See Conformance §2.5 for how this profile uses that framework, and Reference §7.1 for a manifest written against the current discovery model.

MCP itself is now governed as "Model Context Protocol, a Series of LF Projects, LLC": on 2025-12-09 it was donated into the Agentic AI Foundation under the Linux Foundation. It is no longer an Anthropic-owned mark, and the naming constraints on "MCP" follow the LF Projects trademark policy rather than any single company's rule.

This section is a draft (RFC). Boundaries, especially the line between this profile and vehicle-signal standards, are exactly the kind of thing the council expects to refine with its partners.