# 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

```bash
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)

```bash
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)

```bash
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)

```bash
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):

```json
{
  "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.