Canonical Domains

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 nine 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:

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

core, Core & Reference

The records every other domain points to: the dealer (the dealership itself, the tenant of §3.2), its employees, outside vendors, and documents. They are not a business process like the eight domains above; they are shared reference data, given a canonical namespace of their own so that their tools conform to §5.2.

Representative tools: core.get_dealer, core.list_dealers, core.get_employee, core.list_employees, core.get_vendor, core.list_vendors, core.get_document, core.list_documents. All are reads in this version. Access uses the amcp:core:read scope of §6.2. Employee and document records can carry PII and fall under the security profile.

Added in this revision as R09, a backwards-compatible (MINOR) change: the core.* tool names and the /schemas/core/* schemas are unchanged; only the namespace became canonical.

Schemas: Dealer, Employee, Vendor, Document

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.