Skip to content
AutomotiveMCP

Build it once, or build it a hundred times.

Agentic AI is arriving in retail automotive faster than the plumbing beneath it. Here is the math, the moment, and why one shared standard is the only version of this that scales.

The integration math

A dealership runs on a stack: a DMS, one or more CRMs, a website platform, service scheduling, parts, F&I tooling. An agent that wants to be genuinely useful has to reach into several of them. Today every one of those connections gets built by hand.

That is an N×M problem. With N agents and M systems, the industry is on the hook for up to N×M bespoke integrations. Each one takes weeks of engineering and tens of thousands of dollars, and each one is maintained forever against an API that keeps moving. Nobody’s connector is reusable, so the same work gets rebuilt company by company.

A standard collapses N×M into N+M. Each system implements it once. Each agent speaks it once. Everything else interoperates for free. That is the whole economic argument, and it is not subtle.


Why this moment, specifically

The Model Context Protocol already gave AI agents a common way to call tools and read data. It is settled work, now governed under the Linux Foundation with Anthropic, OpenAI, Google, Microsoft and AWS behind it. The current revision is 2026-07-28, and it is the right foundation to build on.

But MCP is general on purpose. It does not know what a repair order is, or a desking scenario, or a trade appraisal. It leaves the domain to profiles like this one. Without an agreed automotive profile on top of it, every dealer system exposes MCP its own way and the N×M problem comes right back, one layer up.

The decisions are being made now. Dealers are already asking vendors a pointed question:

“Do you support MCP, and which version?”

There is no canonical specification to answer against yet. Whoever writes that answer shapes how this industry connects for the next decade. You can see the gap today in the Directory, where vendor after vendor reads “API: yes, MCP: not yet.”


Why it has to be neutral

Any single vendor could publish a connector spec. None of their competitors would ever build to it, and dealers are right to distrust a “standard” that happens to advantage the company that wrote it.

Standards work when they are neutral: governed in the open, versioned predictably, and verifiable by anyone. That is why this is a council with a public draft, an open governance model, and conformance results anyone can re-run. It is a standard, not a product, and it stays free for exactly that reason.


Who this pays off for

A neutral standard pays off for everyone touching the dealership stack, not just the people who build it.

Dealers
Agents that work across your whole stack instead of one tool at a time, and a mark that tells you which vendors actually conform before you sign. See certification →
Vendors
Build it once instead of fielding the same integration request from every partner, and give dealers a real, version-pinned answer when they ask about MCP. Take a founding seat →
Agencies and AI builders
Target one interface and reach every conformant dealer system, instead of negotiating access stack by stack and store by store. Read the spec →
OEMs
A coherent retail data layer that complements vehicle-signal standards like COVESA and VSS rather than colliding with them.

Standards get set once

A standard is easiest to set before the bespoke approaches calcify, and hardest to change afterward. The protocol exists. The demand is here. The canonical answer has not been written yet.

The specification is public and open for comment, and v1 is being written right now with the founding cohort. The organizations at the table for that are the ones who get to define it. Everyone else implements what they decide.

Be at the table.

The integration problem is real and it is current. Dealers join free, vendors take a founding seat, and the spec is open to read and challenge today.