Some operators already live in a chat window. MoveTheWheels ships an MCP server for them: a thin product shell over the shared Burdenoff tool library that mounts a MoveTheWheels domain module alongside the platform ones — identity, files, tags, conversations, permissions, scheduler, export, support.
The tool surface is the domain, grouped the way the product is: customers, drivers, vehicles, cargo items, orders, shipments, tracking events, routes, warehouses, inventory, marketplace providers, reports and analytics — around ninety product-prefixed tools in total, so two MCP servers can run side by side without colliding. Alongside them sit read-only resources — a domain overview, a dashboard snapshot, fleet statistics, the active-delivery board — and two guided prompts: one that walks an order from booking through pickup, transit and delivery, one for fleet operations.
The agent does not get a private back door. It authenticates through the platform identity layer with a device-code flow, and its calls go to the same workspace GraphQL gateway the web app uses, where every query and mutation carries a declared permission that the gateway enforces at the edge. An agent cannot read a shipment or delete a route that the person who authorised it could not.
One honest caveat, because it matters more than the tool count: the destructive tools — deleting a shipment, route, vehicle, driver or customer, or adjusting inventory stock — do not yet require an explicit confirmation turn before they run. Treat an MCP connection the way you would treat a shell: governed by your permissions and fully recorded today, but not yet gated by a confirmation prompt. Adding that gate is tracked work, not a shipped claim.
Pre-launch scenario for a platform launching in 2026. The MCP server, its tool surface and the permission enforcement are real; the confirmation gate is described here as direction, not as something available today.
Ready to make this your story?
