CargoMind MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HOST | No | Dashboard bind address. | 0.0.0.0 |
| PORT | No | Dashboard port (Cloud Run sets it automatically). | 8080 |
| LOG_LEVEL | No | Uvicorn log level for the dashboard. | info |
| PYTHONUTF8 | No | UTF-8 I/O for LiteLLM and child processes on Windows. Set to `1` in the example MCP client configuration for the cargomind-logistics server. | 1 |
| CARGOMIND_DB | No | SQLite database file. | <data dir>/cargomind.db |
| GEMINI_API_KEY | No | Alias for GOOGLE_API_KEY. | |
| GOOGLE_API_KEY | No | Gemini API key. Enables all Gemini tiers and Gemini vision. Alias: GEMINI_API_KEY. | |
| OPENAI_API_KEY | No | GPT as the second vendor if no Anthropic key is set. | |
| CARGOMIND_CHAOS | No | Chaos Monkey fault-injection rate, `0`…`1` (also adjustable live in the dashboard). | 0 |
| ANTHROPIC_API_KEY | No | Claude as the second vendor (critic + failover). | |
| CARGOMIND_OFFLINE | No | `1`/`true` forces the offline rule-engine and network-free tool fallbacks. | false |
| CARGOMIND_DATA_DIR | No | Where the SQLite DB and uploaded photos live. | ./data |
| CARGOMIND_MCP_LOCAL | No | `1`/`true` serves the MCP tool set in-process instead of spawning the stdio server. | false |
| GOOGLE_MAPS_API_KEY | No | Google Routes API v2 + Geocoding API key. | |
| CARGOMIND_GEMINI_PRO | No | Deep-reasoning model for the planner (and critic fallback). | gemini-4-argon |
| CARGOMIND_WATCHTOWER | No | `0`/`false`/`no`/`off` stops the dashboard from starting the Watchtower background scan. | 1 |
| CARGOMIND_GEMINI_FAST | No | Fast conversational / routing model. | gemini-3.8-flash |
| CARGOMIND_CLAUDE_MODEL | No | LiteLLM model id for Claude. | anthropic/claude-sonnet-5-5 |
| CARGOMIND_HTTP_TIMEOUT | No | Seconds per external HTTP call before falling back. | 8 |
| CARGOMIND_OPENAI_MODEL | No | LiteLLM model id for OpenAI. | openai/gpt-5-mini |
| CARGOMIND_TOOL_RETRIES | No | Retries per failed tool call (exponential backoff 0.3 s, 0.6 s, …). | 2 |
| CARGOMIND_GEMINI_BACKUP | No | Same-vendor backup, tried before switching vendors. | gemini-2.5-flash |
| CARGOMIND_GEMINI_VISION | No | Multimodal model for proof-of-delivery photos. | value of CARGOMIND_GEMINI_FAST |
| GOOGLE_GENAI_USE_VERTEXAI | No | `true` uses Vertex AI (with GOOGLE_CLOUD_PROJECT / GOOGLE_CLOUD_LOCATION and ADC) instead of an API key. | false |
| CARGOMIND_BREAKER_COOLDOWN | No | Seconds a breaker stays open before a half-open trial. | 60 |
| CARGOMIND_BREAKER_THRESHOLD | No | Consecutive failures that open a circuit breaker. | 3 |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| track_shipmentA | Track a shipment: current status, location, ETA vs promised delivery, carrier, vehicle and recent events. |
| list_shipmentsA | List shipments, filtered and sorted (active first, critical first, then earliest promised delivery). |
| shipment_historyA | Full chronological event trail (scans, checkpoints, delays, assignments) for one shipment. |
| update_shipment_statusA | Change a shipment's status and log a history event (e.g. mark delayed, delivered, exception). |
| check_inventoryA | Check stock levels per SKU and warehouse, including low-stock flags and any open purchase order. |
| create_reorderA | Raise a purchase order to replenish a SKU at a warehouse. Safe to retry: if an open PO already exists for the line it is returned with duplicate=true instead of creating another. |
| list_vehiclesA | List own-fleet vehicles with capacity, current load, driver hours remaining and fuel. |
| assign_vehicleA | Assign an own-fleet vehicle to a shipment. Checks capacity and maintenance status; idempotent. |
| list_carriersA | List carrier partners with modes, INR rate card (base_rate_per_km, per_kg_rate), reliability (0-1) and average speed - use for quoting and choosing a carrier. |
| list_warehousesA | List warehouses with city, coordinates, utilisation %, cold-chain capability and low-stock line count. |
| get_kpisB | Network health snapshot: on_time_rate (%), in_transit, delayed, exceptions, delivered_today, low_stock_skus, fleet_utilization (%), open_pos, critical_active and counts by status. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| kpis | Live network KPIs (JSON). |
| warehouses | Warehouse directory (JSON). |
TDQS
Scored across 11 tools
Tools are cleanly separated by resource and action: shipment tracking/list/history/status update, inventory/warehouses/reorders, fleet assignment, carriers, and KPIs. Overlaps are minimal; track_shipment and shipment_history differ in scope (current status plus recent events vs full event trail).
Names are consistently snake_case and mostly follow a verb_noun pattern such as track_shipment, list_shipments, update_shipment_status, check_inventory, create_reorder, assign_vehicle, and get_kpis. The main deviation is shipment_history, which is noun_noun rather than action-first, but it remains readable and predictable.
11 tools is well-scoped for a logistics control tower, covering shipments, inventory, warehouses, fleet, carriers, and KPIs without obvious filler. Each tool maps to a clear operational task.
Core operational workflows are covered: track/update shipments, inspect inventory, raise reorders, assign vehicles, and monitor KPIs. Gaps remain around shipment creation/cancellation and purchase-order or vehicle lifecycle management, but these are minor for a monitoring and dispatch-oriented server.