Skip to content
AutomotiveMCP
Spec§4RFC / v0.1

Canonical Domains

The operational domains of the dealership, each a stable resource and tool namespace that a conformant server implements.


4.1 Overview

The dealership is divided into canonical domains. Each domain is a stable namespace of resources (reads) and tools (actions), and every resource is dealership-scoped. A conformant server declares which domains it supports and implements the full required surface for each.

Within a domain, tools follow a predictable set, list, get, and, where the domain is writable, create and update, so the surface is learnable and mirrors a conventional REST resource (see Naming).

The eight domains below are the v0.1 set. Each domain's concrete object shapes are published as versioned JSON Schemas, read, validate against, or export them from Schemas, linked per domain below.

4.2 The domains

inventory, Inventory

New, used, and in-transit vehicles. Core resource: a vehicle with vin, condition, year, make, model, trim, options, media, status, and price. Representative tools: inventory.search, inventory.get.

Schemas: Vehicle · Inventory Snapshot · Appraisal

leads, Leads & CRM

The people and the opportunities. Two core resources:

  • A customer (the person) with a primary_contact, location, lifetime value, the latest_lead and latest_sale, and any vehicle_of_interest.
  • A lead (an opportunity) with source, status, owner, and the vehicle in play.

Representative tools: leads.list, leads.get, leads.create, leads.update, customers.list, customers.get. A customer resource generalizes to:

{
  "id": "cus_4Qd9",
  "type": "customer",
  "dealership_id": "dlr_001",
  "primary_contact": {
    "name": "Dana Ruiz",
    "email": "dana@example.com",
    "phone": "+15125550143"
  },
  "location": { "city": "Austin", "region": "TX", "country": "US" },
  "lifetime_value": { "amount": 4120000, "currency": "USD" },
  "latest_lead": { "id": "led_88", "status": "working" },
  "latest_sale": { "id": "sal_12", "closed_at": "2025-11-02T17:30:00Z" },
  "vehicle_of_interest": { "make": "Toyota", "model": "RAV4" }
}

Schemas: Lead · Customer · Activity / Task · Appointment

deals, Deals & Desking

Quotes, payments, trade valuations, incentives, and desking scenarios. Representative tools: deals.create_quote, deals.request_trade_value, deals.apply_incentive.

Schemas: Deal

service, Service

Repair orders, appointments, technician time, and service history. Representative tools: service.find_open_appointments, service.book_appointment, service.get_repair_order.

Schemas: Service Order

parts, Parts

Catalog, availability, pricing, supersessions, and ordering. Representative tools: parts.search, parts.check_availability, parts.create_order.

Schemas: Part

fni, F&I

Finance and insurance products, lender programs, menus, and compliance artifacts. F&I tools carry heightened security and PII obligations (see Auth & Security).

Schemas: Credit Application

signals, Marketing & Analytics

Who a customer is to the marketing stack, and what they have done. Two parts:

  • Audiences: named segments a customer belongs to. Tools: signals.list_audiences, signals.get_audience, signals.list_audience_members, signals.list_customer_audiences.
  • Events: a time-ordered stream of engagement, sale, and service signals. Tools: signals.list_events (scoped to a customer or dealership).

Event type is drawn from a controlled vocabulary so agents can reason across vendors. The v0.1 set generalizes the common automotive engagement signals:

GroupEvent types
Webpage_view, input_tracking, ad_click, conversion
Leadlead, enrichment
Salesale
Emailemail_sent, email_open, email_click
SMSsms_sent, sms_click, sms_replied
Serviceservice_lead, service_appointment, service_ro
Schedulingappointment

This domain is read-only; it exposes signals, not write actions.

Schemas: Campaign

consent, Consent & Compliance

Communication consent is a first-class resource in automotive retail, TCPA and privacy law make it load-bearing, not optional metadata. A consent record captures whether a contact has granted or revoked permission to be contacted, on what channel, and how that was established.

Representative tools: consent.list, consent.get, consent.create, consent.update. A consent record generalizes to:

{
  "id": "con_7f3a",
  "type": "consent",
  "dealership_id": "dlr_001",
  "consent_status": "granted",
  "channel": "sms",
  "purpose": "marketing",
  "source": "website_form",
  "method": "double_opt_in",
  "contact": { "phone": "+15125550143" },
  "captured_at": "2026-01-14T15:04:00Z"
}
  • consent_status is one of granted, revoked, unknown.
  • channel is one of email, sms, phone, mail.
  • purpose distinguishes marketing from transactional consent.
  • contact carries exactly one of email or phone, the identity the consent applies to.

Servers MUST treat consent as authoritative: an agent SHOULD check consent before initiating contact through the leads or signals surfaces, and writes that would contact a customer MUST respect a revoked status. Consent records are PII and fall under the security profile.

Schemas: Consent Record

4.3 Domain support is declared

Because a real server may front only some systems, a server MUST advertise the domains it implements and the conformance level per domain. An agent MUST NOT assume a domain is present without checking. A CDP, for example, might implement leads, signals, and consent at a high level while not exposing parts or deals at all.

Something wrong, missing, or impossible to implement in §4?Propose a change →Opens an email with this section and version already filled in. No account needed, and you keep your copyright.