Spoke Dispatch MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SPOKE_API_KEY | Yes | Your Spoke Dispatch API key, generated under Settings > Integrations > API. Sent as the HTTP Basic username with an empty password. | |
| SPOKE_BASE_URL | No | The base URL for the Spoke API. Defaults to https://api.spoke.com/public/v1. Used by the tests. | https://api.spoke.com/public/v1 |
| SPOKE_ALLOW_WRITES | No | Set to true to register the write tools: create_plan, import_stops, optimize_plan and distribute_plan. Off by default. | false |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_plansA | Plans (one per working day, each with its drivers and routes) in the order the API returns them. Filter by an exact title and/or a start-date range. Plan titles are free text: email addresses and phone numbers in them are redacted unless include_contact_details is true. |
| get_planB | One plan: start date, depot, optimization and distribution state, driver IDs, route IDs and route overrides. |
| list_plan_stopsA | Every stop of one plan with its type (start/stop/end), route, position, delivery state and outcome, ETA, time window and packages. By default recipients are withheld, addresses are summarised to the locality, and proof-of-delivery links, signee names and recipient tracking links are left out; set include_contact_details to get them. |
| list_route_stopsA | The stops of one route (one driver's run) in the order the API returns them, with delivery state and outcome, ETA, time window and packages. By default recipients are withheld, addresses are summarised to the locality, and proof-of-delivery links, signee names and recipient tracking links are left out; set include_contact_details to get them. |
| search_stopsA | Full-text search across all stops (assigned and unassigned) within the team's data retention, by keyword and/or the API's filter language, e.g. |
| list_routesB | Routes (one driver's run within a plan) with stop count, driver, plan and state (distributed, started, completed, recipients notified, with timestamps). |
| get_routeA | One route with its stop count, driver, plan and state. Use list_route_stops for the stops. |
| list_driversA | Drivers on the team with their active status, depots and route overrides (working hours, vehicle, max stops). Email, phone and a driver's own start/end address are only returned with include_contact_details. |
| get_driverA | One driver: name, active status, depots and route overrides. Email, phone and start/end address only with include_contact_details. |
| list_depotsB | Depots (the team's operating bases) with their default route settings: start time, start and end address, round trip, time at stop, max stops, vehicle type. |
| list_operationsB | Long-running operations (currently only plan_optimization) with whether they are done, who started them, the target plan and the result (stops optimized, stops skipped with reasons, or an error). |
| get_operationA | One operation, to poll a plan optimization started with optimize_plan: done, timestamps, and the result or error once finished. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Each tool has a distinct scope: get_* retrieves a single entity, list_* retrieves collections, list_plan_stops and list_route_stops differ by parent scope, and search_stops provides cross-cutting full-text search. Overlaps between get_route and list_routes (or get_plan and list_plans) are cardinality differences, not ambiguities.
All tool names use consistent snake_case with a clear verb_noun pattern: get_route, list_plans, get_plan, list_plan_stops, search_stops, etc. No mixed conventions or confusing verb choices.
The 12 tools are well-scoped: each covers a distinct resource and action (plans, routes, stops, drivers, depots, operations) without obvious filler or duplication. This is an appropriate size for the dispatch domain.
The surface covers read access to plans, routes, stops, drivers, depots, and operations, but has no mutation or lifecycle tools (create/update/delete for core entities). Crucially, get_operation references optimize_plan as the source of operations, yet no optimize_plan tool is provided, creating a dead end for a key workflow.