MCP Server

The TrackOut MCP server lets AI agents access your garage data through the Model Context Protocol. No local install required -- just configure your agent with a URL and API key.

Setup

Prerequisites

• An API key from your TrackOut Settings page

Configure your agent

Add TrackOut to your agent's MCP configuration. For Claude Code, add to .claude/mcp.json:

{
  "mcpServers": {
    "trackout": {
      "type": "url",
      "url": "https://trackout.app/api/mcp",
      "headers": {
        "Authorization": "Bearer tok_..."
      }
    }
  }
}

Replace tok_... with your API key from Settings.

Available tools

Once connected, the following tools are available to your agent:

Cars

Parts

Service records

Installers

Track sessions

Maintenance

Tires

Documents

Receipt workflow

The MCP receipt flow mirrors the TrackOut UI:

1. Call upload_document with a PDF or receipt image.
2. Call scan_receipt with the returned fileId to start extraction.
3. Wait for the extraction to finish, either way round:
   • Let the server wait. Pass wait: true and the call holds open for up to 25 seconds, returning the finished extraction as soon as it is ready. If it is still running when the wait ends, you get the same in-progress response as below -- call again with its receiptId.
   • Poll yourself. Call scan_receipt again with either the same fileId or the returned receiptId until the receipt is ready for review. fileId stays valid after the file is stored encrypted.
4. Create linked records with either:
   • create_service_record for a single record and pass receiptId
   • create_records_from_receipt for a multi-line-item receipt import

create_service_record accepts a receiptId. (The HTTP API and the local stdio server also accept receiptDocumentId as a compatibility alias.)

Streaming and progress

Tools that can take a while -- today that is scan_receipt with wait: true -- report progress while they run, so your agent can show "still scanning" instead of sitting silent.

This happens automatically: if your MCP client asks for progress on a call, TrackOut answers that call as a text/event-stream and sends progress updates on it until the result arrives. Clients that do not ask for progress get the same single JSON response they always have. Nothing to configure either way.

Two things worth knowing:

• Progress is scoped to the call that asked for it. TrackOut never opens a long-lived stream of its own, so there is no background connection to keep alive or reconnect.
• A wait: true call is bounded at 25 seconds. That is a ceiling, not a delay -- the call returns the moment extraction finishes.

Example usage

Once configured, you can ask your agent things like:

• "List my cars"
• "Show service records for my M3"
• "Log an oil change for my 911 at 42,000 miles, cost $85"
• "What tires are installed on my track car?"
• "Add a new installer called Track Performance Shop"
• "Create a new car named 'Track Beast' -- 2024 Porsche 911 GT3"
• "Add an oil filter part for my M3"
• "Set up a recurring oil change every 5,000 miles"
• "Upload this receipt, scan it, and show me the extracted line items"
• "Create linked service records from this scanned receipt for my M3"

The agent will use the appropriate MCP tools to read or write your TrackOut data.

HTTP API

The MCP server calls the TrackOut HTTP API under the hood. If you want to build your own integration, you can call these endpoints directly:

The HTTP API also covers update and delete operations that are not yet exposed as remote MCP tools (tires, parts, track days, track sessions, maintenance rules, and deletes generally). The locally-run @trackout/mcp-server stdio package exposes these as update_* / delete_* tools over the same endpoints.

All endpoints require an Authorization: Bearer tok_... header. The base URL for direct API calls is https://site.trackout.app.

curl -H "Authorization: Bearer tok_..." \
  https://site.trackout.app/api/v1/cars

Error responses

All error responses are JSON shaped { "error": "<message>" } with an appropriate HTTP status code. The MCP route passes user-facing 4xx messages through unchanged; 5xx responses are mapped to a generic Upstream service temporarily unavailable. message on the MCP client so internal errors never leak through a tool call.

Upload limits

The upload_document tool (and POST /api/v1/documents/upload) enforces:

• Encoded request body: up to 14 MB
• Decoded file: up to 10 MB
• Allowed content types: application/pdf, image/jpeg, image/png, image/webp, image/heic, image/heif, image/gif, text/plain
• Uploads per minute: up to 60 per account, the same cap the web app uses. Past that, the tool returns Upload limit reached. Please try again later. until the minute rolls over.

Requests that exceed these limits fail fast with a 4xx before bytes are persisted.

Security notes

• Authorization is driven exclusively by your API token — the MCP session ID plays no role in authorization. Every request is independently authenticated.
• The MCP endpoint is intentionally per-request stateless: it issues no mcp-session-id at all, and keeps no server-side session store -- not even for streamed calls. There is no session key two users could collide on.
• API tokens are SHA-256 hashed at rest. Revoke a compromised token from the API keys page; revocation takes effect on the next request.
• Rotate tokens periodically and prefer creating one token per agent/tool so you can revoke narrowly.
• Uploaded documents are not served at a public URL. upload_document returns url: null; receipt images and part attachments are encrypted at rest and shown only through authenticated decrypt actions.
• Requesting Delete Account in Settings immediately invalidates the API token. HTTP API calls then receive 401. MCP tools return an authentication error -- even while garage data is still being removed.