Exposing the dispatch system as an MCP server and hooking Claude Desktop to it let drivers ask plain-English questions that replaced 92% of dispatch escalations—built in 4 days for $420 in API tokens.
The Routing UI Was Beautiful. Drivers Hated It.
After I made our delivery team's route planning 4x faster with a GPT agent last year, I thought the tooling problem was solved. Then I actually rode along with a driver for a day.
The routing UI had all the information — stop times, traffic alerts, vehicle weight limits, access restrictions, customer notes — but accessing it required 3-4 taps and knowing which screen had what. Drivers were calling dispatch to ask questions the system could already answer. "Is the loading dock at Riverside still closed?" "Can I run this 18-wheeler down Oak Street?" "If I skip stop 7 and come back at end of day, does that work?"
The information existed. The interface was the problem. I decided to expose the dispatch system as an MCP server and let drivers just ask in plain English.
What I Picked and Why
The Model Context Protocol (MCP) from Anthropic is the piece that makes this work. MCP is a standard for exposing tools and data sources to LLMs in a way that's portable — once you write an MCP server, any MCP-compatible client can use it. Claude Desktop supports MCP natively.
I didn't want to build a custom app. I wanted to give drivers Claude Desktop with our dispatch system wired in. Four days of work.
MCP server written in Python using the official mcp SDK. I exposed 11 tools:
# dispatch_mcp_server.py
from mcp.server import Server
from mcp.server.models import
InitializationOptions
from mcp.types import Tool, TextContent
import mcp.server.stdio
server = Server("dispatch")
@server.list_tools()
async def list_tools() -> list[Tool]:
return [
Tool(name="get_route", description="Get the full route
for a driver today",
inputSchema={"type":"object","properties":{"driver_id":{"type":"string"}}}),
Tool(name="get_stop_details", description="Get details
about a specific stop including access restrictions, customer notes, and
current status",
inputSchema={"type":"object","properties":{"stop_id":{"type":"string"}}}),
Tool(name="check_road_restriction", description="Check
if a specific road/street has weight, height, or access restrictions for our
vehicle types",
inputSchema={"type":"object","properties":{"street_name":{"type":"string"},"vehicle_class":{"type":"string"}}}),
Tool(name="reorder_stops", description="Propose a new
stop order and get ETA impact — does NOT change the actual route without
confirmation",
inputSchema={"type":"object","properties":{"driver_id":{"type":"string"},"new_order":{"type":"array","items":{"type":"string"}}}}),
# ... 7 more tools
]
@server.call_tool()
async def call_tool(name: str, arguments:
dict) -> list[TextContent]:
if
name == "get_stop_details":
stop = dispatch_db.get_stop(arguments["stop_id"])
return [TextContent(type="text",
text=format_stop_details(stop))]
#
... etc
|
Drivers run Claude Desktop on a company-issued Android tablet mounted in the cab. I added our MCP server to Claude Desktop's config file, which took about 5 minutes per device. No custom app. No app store submission. No IT procurement process.
How It Works In Practice
Driver: "Hey, stop 7 is the Riverside warehouse — is the loading dock still closed this week?"
Claude calls get_stop_details(stop_id="stop-7"), gets the customer notes field which says "Loading dock closed Mon-Wed for renovation. Use side entrance off Oak.", and responds: "The loading dock at Riverside is closed Monday through Wednesday for renovation. You'll need to use the side entrance off Oak Street instead."
Driver: "If I push stop 7 to the end of the day and do stops 8 and 9 first, does that work?"
Claude calls reorder_stops with the proposed new order, gets back the ETA impact ("reordering pushes stop 7 to 4:42pm, within the 5pm delivery window"), and responds: "That works — stop 7 would land at 4:42pm, which is still within their 5pm window."
All read-only. The reorder_stops tool only proposes changes and shows impact — it doesn't commit them without the driver explicitly confirming. This was a deliberate design choice to keep humans in the loop on actual route changes.
What Broke
The tablet mounting was the hardest part. I'm not joking — getting a tablet securely mounted in a delivery van without blocking sightlines took longer than writing the MCP server. We ended up with a RAM mount system that works.
On the software side: Claude Desktop's context window gets saturated on long shifts when drivers have been asking questions for 6+ hours. The conversation history grows and starts affecting response quality. I fixed this by adding a "start new session" button that clears context every 3 hours.
Also: drivers occasionally ask questions that require live data I hadn't exposed — "is there a cop on Highway 9 right now?" type queries. I added a tool that hits Waze's data API for real-time traffic and incident reports, which covers about 80% of these cases.
What I Learned
MCP is genuinely the right abstraction for this class of problem. I wrote 11 tools that describe our dispatch system, and Claude figured out how to use them without any prompt engineering on the query side. The protocol just works.
The 92% dispatch-escalation-free rate is the metric I care about. Each escalated call costs the dispatcher 3-5 minutes. Across 6 drivers doing 38 queries per shift, we were generating ~228 queries per day. At 8% escalation rate that's ~18 escalated calls per day vs ~228 before — a massive reduction in dispatcher load.
If I Were Doing This Again
I'd build a lightweight MCP client instead of relying on Claude Desktop — a custom mobile app with a simple chat interface that's less intimidating for drivers who aren't comfortable with a full AI assistant interface. The Claude Desktop UX is great for technical users but a bit much for the average driver.
GitHub gist coming soon — the full MCP server code plus the Claude Desktop config setup.
Figure 11. Isometric delivery van interior view: driver with tablet mounted on RAM mount showing Claude Desktop chat interface. MCP protocol arrow from tablet → company MCP server in cloud → dispatch database…
REFERENCES
1. Model Context Protocol Specification. Anthropic (2024).
https://modelcontextprotocol.io/specification
2. FMCSA Hours of Service and Dispatch Regulations. Federal Motor Carrier Safety Administration (2024).
https://www.fmcsa.dot.gov/regulations/hours-of-service
3. Routific Route Optimization Platform. Routific (2024).
4. MCP Python SDK Documentation. Anthropic / GitHub (2024).
https://github.com/modelcontextprotocol/python-sdk
5. Claude Desktop MCP Integration Guide. Anthropic (2024).
https://docs.anthropic.com/en/docs/build-with-claude/model-context-protocol
Comments (0)
Join the conversation!