MCP connector documentation

• US buyers only, shopping for a new, used, or certified pre-owned vehicle at a franchise dealer.
• A Motrix account, created during the OAuth authorization flow below.
• A phone number, verified once before a deal can start — a car deal is a five-figure purchase and Motrix needs to be able to reach the buyer directly. This happens on a short usemotrix.com page the user opens from the conversation (see phone_verification_required below); codes are never relayed through the chat.

OAuth 2.1, authorization-code flow with PKCE (S256), dynamic client registration supported. Motrix is the OAuth resource server; the buyer's Motrix account is the authorization server's identity — sign-in / account creation and a one-time consent screen both happen on usemotrix.com during the flow, not inside the calling agent.

Discovery:

That document's authorization_servers entry points at the actual OAuth authorization server (token issuance, JWKS, and its own metadata all live there — Motrix's backend never issues or signs tokens itself).

Streamable HTTP transport, stateless (no session id). Requires a valid OAuth bearer token.

start_car_deal — starts a new Motrix mandate for a specific vehicle. Every field (condition, year/make/model/trim, colors, zip, timeline, financing preference, budget or target payment, credit tier, trade-in, phone) is optional on the call itself — Motrix asks for whatever it actually needs. If required info is missing, the response is { needs_info: [{ field, question_for_user }] }; ask the user each question_for_user and call start_car_dealagain with the answers, rather than guessing. If the response contains needs_user_action with reason consent_required, relay its url to the user, then call this again. If reason is phone_verification_required, relay its url (a usemotrix.com phone-verification page) to the user the same way, then call this again once they confirm they've finished. On success, returns a deal id to use with get_deal_status and get_quote_summary. Never sends anything to a dealer directly — outreach is drafted and held for a human approval gate, same as every other Motrix mandate.

get_deal_status — read-only mandate status (stage, progress, open questions) for a mandate the caller's account owns, plus a plain-language summary and next_action — relay both to the user rather than reconstructing your own from the raw fields. Any other mandate id returns a permission error.

get_quote_summary — read-only written dealer offers for a mandate the caller's account owns, as an out-the-door price (or lease monthly payment) plus itemized fee lines. These are real written dealer quotes, not estimates.

check_car_market — before a user commits to a deal, gives a no-commitment read on the market: how many similar vehicles are listed for sale near a ZIP code and the asking-price range. This is third-party/aggregated listing data, not a written dealer offer or a Motrix quote — never present it as a price the user can get. Good for "is this a fair price" or "what's out there" questions; when the user is ready for a real negotiated price in writing, call start_car_deal.

Standard Motrix API rate limiting applies per account/IP, same as every other authenticated Motrix endpoint.

• Never contacts a dealer or a buyer directly — every outbound message goes through Motrix's existing human-approval gate.
• Never accepts or processes payment. Deals started this way are Pay-on-Close (nothing charged unless and until a deal closes).
• Never reads or writes another user's data — every tool call is scoped to the authenticated account only.