High Gear Collision MCP Server

An MCP server for High Gear Collision (Mico, TX) that gives an AI assistant direct access to insurer labor rates, parts approval policies, and claim status — so an estimator can draft and reconcile a repair estimate against what an insurer will actually approve, instead of a phone/email back-and-forth.

This is a working prototype: the "insurer data" in shop_data.py is mocked in-memory so you can run and test the whole flow without real insurer credentials. Swap shop_data.py's internals for real API calls or a shop-maintained database when you're ready to go live.

Project structure

high-gear-mcp/
├── shop_data.py     # Business logic + mock insurer data (no MCP dependency)
├── server.py        # MCP tool definitions, wraps shop_data.py
├── test_client.py   # Standalone MCP client — talks to server.py over the real protocol
├── requirements.txt
└── README.md

Business logic lives separately from the MCP wiring on purpose — you can test and evolve shop_data.py (e.g. point it at a real insurer API) without touching the tool definitions in server.py.

Setup

python3 -m venv venv
source venv/bin/activate          # on Windows: venv\Scripts\activate
pip install -r requirements.txt

Test the logic directly (no MCP client needed)

python3 -c "
import shop_data as s
print(s.get_insurer_labor_rates('State Farm'))
print(s.get_parts_approval_policy('state_farm', part='bumper'))
"

Run with the MCP Inspector (interactive testing)

mcp dev server.py

This opens a local web UI where you can call each tool by hand and see exactly what gets sent/returned — the fastest way to sanity-check before wiring it into Claude.

Run the standalone test client (full protocol round-trip)

python3 test_client.py

This is different from calling shop_data.py's functions directly — it spawns server.py as a real subprocess, connects over stdio, does the MCP initialize handshake, calls list_tools to discover what the server advertises, then calls all 5 tools (including a deliberate error case and a full estimate → supplement → status flow) exactly the way Claude Desktop would. Good for proving the server works end-to-end before you ever plug it into Claude, and a good artifact to show in an interview: it demonstrates the difference between "the logic works" and "the protocol contract works."

Connect to Claude Desktop

Add this to your claude_desktop_config.json (Claude menu → Settings → Developer → Edit Config on Mac; %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "high-gear-collision": {
      "command": "python3",
      "args": ["/absolute/path/to/high-gear-mcp/server.py"]
    }
  }
}

Restart Claude Desktop. You should see "High Gear Collision" appear under your MCP tools, with all 5 tools available.

The 5 tools

Tool	Type	Purpose
get_insurer_labor_rates	Read	Approved hourly rate by insurer + repair category
get_parts_approval_policy	Read	OEM/aftermarket policy by insurer, with part-level exceptions
get_claim_status	Read	Current approval status + adjuster notes for a claim
submit_estimate	Write	Submit a drafted estimate for insurer approval
request_supplement	Write	Submit a supplemental request on an existing claim

Try it out

Once connected, ask Claude something like:

"I've got a 2021 Honda Civic in for a front bumper repair with State Farm — 3.5 hours of body work and a bumper that costs $240. Check their labor rate and parts policy for a bumper, then draft the estimate."

Claude will call get_insurer_labor_rates, get_parts_approval_policy, do the math, and — after you confirm — call submit_estimate.

Known limitations (worth naming if this comes up in an interview)

• Mock data: shop_data.py's insurer rates/policies are hardcoded, not pulled from real insurer systems. Real insurers don't generally expose clean APIs for this — the realistic path is a shop-maintained internal database, kept in sync on a defined refresh cadence (see the last_verified field returned by every read tool).
• No persistence: claims submitted via submit_estimate live only in memory and reset when the server restarts. A real deployment needs a proper database.
• No real auth: this prototype has no authentication layer at all. A production version needs per-insurer credentials and role-based access so an estimator can only act on claims for their own shop.