Getting started

Everything a client needs is discovered from one URL. For an OAuth-capable client there is nothing to paste and no schema to copy — the server describes itself over the MCP protocol, and auth is negotiated by the OAuth 2.1 flow built into modern MCP clients. Headless clients send an API key or a personal access token as a bearer instead.

Prerequisite: an account. Developers sign up with a package and a card, then create an API key in the portal. Shop accounts are provisioned by a MotorAdvisor administrator with the MCP grant. Signing in is not by itself access: a developer account serves no calls until checkout clears, and a cancelled or unpaid subscription stops calls at the next request. For shop accounts the login and the MCP grant are the gate.

Claude (and other OAuth-capable clients)

Add a custom connector with only the URL:

https://mcp.motoradvisor.app/mcp

Leave any OAuth Client ID / Client Secret fields blank — the client registers itself dynamically. It discovers the authorization server, opens the login and consent page at https://motoradvisor.app, and you sign in — with a developer account you created yourself, or a shop account an administrator provisioned. A client arriving with no session is sent to developer sign-in, which offers signup. That is the whole setup.

The same applies to any client that implements MCP authorization, including mcp-remote for clients that only speak stdio:

{
  "mcpServers": {
    "motoradvisor": {
      "command": "npx",
      "args": ["mcp-remote", "https://mcp.motoradvisor.app/mcp"]
    }
  }
}

Headless and service clients

Two bearer credentials exist for clients that cannot run an OAuth flow:

• An API key (mtr_live_… or mtr_test_…), created by a developer in the portal once their subscription is serving. Shown once, at creation; revocable in the portal at any time, and a revoked key is refused by name so it is not mistaken for an unrecognised one.
• A personal access token, minted by an administrator in the web app's admin console for a shop account (shown once, at mint time).

Either is sent as a bearer token. The examples below use $MCP_TOKEN for whichever you hold:

curl -s https://mcp.motoradvisor.app/mcp \
  -H "Authorization: Bearer $MCP_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Calling a tool is one more request:

curl -s https://mcp.motoradvisor.app/mcp \
  -H "Authorization: Bearer $MCP_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
      "name": "resolve_vehicle",
      "arguments": { "vehicle": { "vin": "2HGFA1F5" } }
    }
  }'

The server is stateless: no session to initialize, every request self-contained.

A first conversation

The tools are designed so an agent can discover the workflow from the descriptions alone, but the shape of a good first exchange looks like this:

1. service_advisor_lookup with a VIN, mileage, symptom, and labor rate — it resolves the vehicle internally and returns due maintenance, candidate diagnostic operations with pricing, and matching bulletins in one call.
2. The candidates are a menu: present them, let the user choose, then re-call with selectedApplicationIds for a selected total.
3. assess_repair_economics with the VIN and the selected total — is this repair proportionate to what the car is worth?
4. send_quote_notification with the quote id — the customer receives their approval link on the channels they consented to, and a channel without consent comes back as a structured refusal rather than a send.
5. issue_invoice once the work is done and the customer's name and email are confirmed.

Try it with the sandbox's demo vehicle:

"2010 Honda Civic, VIN 2HGFA1F5, 62k miles, AC blows warm, $150/hr shop rate — what should I quote for the diagnostic?"

Sandbox coverage

The evaluation sandbox covers model years 2010, 2015, and 2016 only. Empty results for vehicles outside those years are correct behaviour — clients should report the vehicle as not covered rather than retrying. Production coverage spans the full MOTOR vehicle database; the workflow contracts do not change.