Open editor's draft · Version 0.1

Give every shopping agent the same retail truth.

Dealer Agent Protocol gives AI agents one precise way to read dealer-published vehicles, verify availability, and explain prices and offers—without exposing the DMS or CRM.

  • 6read tools
  • 4profiles
  • 7JSON schemas
  • 24conformance checks

The adoption problem

Dealer facts exist.
Agent-ready meaning does not.

Inventory feeds, website pages, incentive programs, and availability signals describe different parts of the retail offer. An agent that scrapes and guesses can merge them incorrectly.

The protocol defines the answer contract: what a fact means, who published it, how fresh it is, and what remains conditional or unknown.

One boundary · many consumers

Keep the integrations behind the gateway. Publish only the retail facts agents need.

Dealer Agent Protocol is the open contract between the gateway and agents. MCP carries the calls. The protocol supplies the retail vocabulary, schemas, disclosure rules, and conformance claims.

Walk through the complete system

From question to grounded answer

Five steps an agent can follow instead of improvising.

  1. 01Discover

    Learn the gateway, supported profiles, dealer, and rooftop.

    get_manifest
  2. 02Search

    Find published vehicles with stable filters and cursors.

    inventory.search
  3. 03Inspect

    Read the exact vehicle facts, media, and source lineage.

    get_vehicle
  4. 04Verify

    Check a fast-changing availability fact against authority.

    verify_availability
  5. 05Explain

    Separate advertised price, required charges, and conditional offers.

    get_disclosure

Why each side adopts

One contract. Three practical wins.

01

For dealers

Control what an agent can claim.

Publish only approved retail facts and policies. Keep internal systems, customer records, and transactional workflows outside the boundary.

Dealer path →
02

For retail technology providers

Build one agent-facing contract.

Map existing feeds and APIs behind a gateway, then expose consistent schemas across rooftops without replacing systems of record.

Provider path →
03

For agent builders

Stop reverse-engineering every dealer.

Use typed, discoverable read tools for inventory and offers, with explicit freshness, authority, and uncertainty in every result.

Builder path →

A deliberate first boundary

Retail facts in.
Dealer systems out.

Version 0.1 focuses on the smallest useful surface for vehicle shopping. It is not a generic dealership API and does not authorize actions.

+ In version 0.1

  • Dealer and rooftop identity
  • Published vehicle inventory
  • Authoritative availability
  • Advertised price and dealer charges
  • Discount and incentive conditions
  • Provenance, freshness, uncertainty

Outside version 0.1

  • DMS or CRM access
  • Customer records and leads
  • Appointments, holds, or desking
  • Credit and lender decisions
  • Payments and contracts
  • Service, parts, and marketing

Open by design

Evaluate the draft in human language. Implement it from normative artifacts.

Read the guide Implementation quickstart

Apache-2.0 · Synthetic reference data · No certification claim