Skip to content
AutomotiveMCP
RFC / v0.1Draft for public comment

The Automotive MCP Specification

One conformant way for dealership systems to expose their data and actions to AI agents over the Model Context Protocol: stable resources to read and tools to act on, so any compliant agent works with any compliant server.

This is v0.1, an RFC open for public comment. Saying so is the point: a standard that has not been challenged by the people who have to implement it is not worth much. Every section carries a link to propose a change, and v1 is being written now with the founding cohort.
Base protocol

This is a profile of the Model Context Protocol, not a replacement for it. It adds the automotive domain, what a repair order is and what a desking scenario is, on top of the transport, tool and resource semantics MCP already defines.

This profile targets MCP 2026-07-28, the current revision: a stateless core, a server/discover RPC, and the Extensions framework. This profile is published as the extension io.automotivemcp/profile. MCP itself is now a Linux Foundation project rather than any one company’s. Changes are tracked in the open on the Updates page.

Build against this without reading it

The specification is published as machine-readable artifacts, not only as prose. Point an agent or a build step at these and it has everything needed to scaffold a conformant server.

  • /llms.txtstart here: the map, the hard rules, and the known gaps
  • /tools.jsonevery tool, its conformance level, and the schema it returns
  • /schemas/index.jsonall 26 object schemas, each served at its own $id
License

The specification text and the JSON Schemas are published under the Apache License 2.0, which carries an explicit royalty-free patent grant from every contributor. Documentation and site copy are published under CC BY 4.0. You may implement, share and adapt all of it, including commercially.

Why the split, and what it means for a legal review: Governance › Licensing and IP.


  1. 1Scope, Goals & Non-GoalsWhat this specification covers, the retail dealership data and tool layer for AI agents, and the adjacent territory it deliberately leaves to others.
  2. 2Conformance & VersioningLevels of conformance, how versions are numbered, and the lifecycle a release moves through from draft to ratified.
  3. 3Core ConceptsThe building blocks every conformant server shares: resources, tools, errors, pagination, and eventing, expressed in MCP terms.
  4. 4Canonical DomainsThe operational domains of the dealership, each a stable resource and tool namespace that a conformant server implements.
  5. 5Naming ConventionsStable, predictable names for resources, tools, and fields, the mechanism that makes any conformant server interchangeable.
  6. 6Auth & Security ProfileHow agents authenticate, how access is scoped, and how PII is handled. Automotive data carries real compliance weight; this section is normative.
  7. 7Reference MaterialNon-normative examples: a conformant server manifest and a representative tool schema, to anchor the prose in concrete shapes.
  8. 8The Reference FlowOne end-to-end task, broken into the eleven steps a real implementation has to perform, with an honest mark against each showing what this specification covers and what it does not yet.
  9. 9Consent PortabilityHow one party proves to another what a person actually consented to, so a system that did not capture consent can verify it before acting on it. Normative, and deliberately domain-neutral.