AAP, explained.

AAP is an independent, open automotive contract. It defines what dealership information, inventory, prices, equipment evidence and consented inquiries mean across Model Context Protocol (MCP), Agent2Agent (A2A) and Personal Agent Protocol (PAP).

Currency and odometer labels preserve native USD/CAD amounts and mi/km readings. Search and facets select one currency and a mileage comparison unit, with explicit capability defaults and result context. Omitted vehicle labels keep their USD/miles meaning. This additive release retains the three native interfaces and frozen 3.0 contract.

The MCP binding specifies a working Streamable HTTP service with tool discovery, complete schemas and structured results. Dealers or their providers implement and host it. The published mcp.json is a reference tool catalog; downloading it does not connect an agent to live inventory.

MCP carries tool calls. A2A 1.0 carries typed automotive DataParts through SendMessage. Poppy draft 0.3 guest OpenAPI uses verified Sessions and DPoP for personal agents. The same automotive payloads and behavior apply to all three.

A full AAP dealer deployment exposes its implemented skill subset through MCP, A2A and PAP OpenAPI. A buyer client only needs the binding it uses. A partial dealer implementation can identify its supported AAP binding, but cannot claim full deployment conformance.

Start with the dealership’s own domain: /.well-known/agent-card.json, /.well-known/poppy.json and /llms.txt. These link the exact working endpoints and capabilities. A hosting provider can run the service while the dealer retains its discoverable identity.

No. An assistant must discover the service, support an advertised interface and choose to use it. A card, llms.txt file or public mention does not install a connector or prove a protocol call occurred. Confirm actual use through request logs and client interoperability checks.

Read dealer locations and hours, discover inventory values, search matching vehicles, inspect a specific listing and send an explicitly consented inquiry. Vehicle interest, trade-in information and an appointment request can share one lead. Payments, financing approval and vehicle reservations are outside the contract.

A known vehicle price includes mandatory dealer charges. Only government-required consumer charges are excluded. Equipment filters require vehicle-specific source evidence; unknown equipment cannot count as present. Listing status and source update time remain explicit.

No. Authentication identifies the calling agent. lead.submit separately requires explicit customer contact consent, permitted channels, matching contact details and an idempotency key. The response distinguishes a received inquiry from a confirmed appointment.

No. Ordinary application code can serve structured inventory queries and lead operations. Existing dealer systems can stay in place. A verified ADF/XML mapping can deliver supported lead fields to a CRM while a separate record retains consent and idempotency.

Use the exact AAP version advertised by the deployment. The current stable release is 3.1.0; released contracts stay immutable. /docs/latest contains editable work and may describe a future release. Protocol revisions for MCP, A2A and PAP are separate from the AAP version.