Loki MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOKI_TOKEN | No | The auth token directly (fallback if no token file) | |
| LOKI_BASE_URL | No | Base URL for the Thor gateway | https://thor.1mg.com/1mg_api |
| LOKI_TOKEN_FILE | No | Path to the file containing the auth token | ~/.loki_token |
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
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| loki_reference_dataA | Fetch valid enumeration values used as filters across Loki. Use this to discover the allowed values for status/type/category/fulfilled_by filters before calling the search tools. |
| loki_search_hubsA | Search logistics hubs. Use this first to find a hub's id (a Mongo ObjectId string) when you only know its name/code -- order and task search require hub_id. Note on hub kinds: pharmacy delivery hubs are business_client="pharmacy" (types like RETAIL); diagnostics phlebo centers (PACs) are business_client="droplet", type="PAC". A "Sec-14 Gurgaon PAC" is therefore a droplet/PAC hub, not the same as the "sec_14_ggn_retail" pharmacy hub. IMPORTANT: the server DEFAULTS business_client to "pharmacy" when it is
omitted, so a search for a diagnostics/phlebo hub returns nothing unless you
pass business_client="droplet". |
| loki_get_hubA | Get full detail for a single hub by its id (Mongo ObjectId string). |
| loki_search_ordersD | – |
| loki_get_orderA | Get full detail for a single order. IMPORTANT: this takes the order's internal numeric id (the |
| loki_get_order_timelinesA | Get the status/event timeline for an order -- the chronological history of state changes. Useful for debugging "why is this order stuck/late". IMPORTANT: takes the order's internal numeric id (the |
| loki_search_tasksD | – |
| loki_get_taskA | Get full detail for a single task by its id. |
| loki_search_ridersB | Search riders (delivery agents / phlebos). Use loki_reference_data('rider_statuses' | 'rider_types') for valid values. |
| loki_get_riderA | Get full detail for a single rider by numeric id. |
| loki_get_hub_ridersB | List the riders attached to one or more hubs (optionally filtered by type). Useful to see who is available to fulfil orders at a hub. |
| loki_get_phlebo_day_metricsA | Daily summary KPIs for one phlebo/rider on a given date: Total Assigned, Completed, Cancelled, Total Distance (planned/actual), SLA Breach, Time, and Sequence edits. The fast "how did this rider's day go" snapshot. |
| loki_get_phlebo_day_tasksA | The chronological day timeline for one phlebo/rider: shift start, login, and each task in expected sequence with status, group, SLA status and order timestamps. Use to debug a rider's route/sequence on a specific day. |
| loki_get_phlebo_planned_routeA | The planned route for a phlebo/rider on a date: ordered [lng,lat] waypoints plus order/home/hub locations. Compare with loki_get_phlebo_actual_route to spot route deviations. |
| loki_get_phlebo_actual_routeA | The actual GPS location history for a phlebo/rider on a date: timestamped lat/long pings with speed, battery % and coolbox temperature. Use to verify where a rider actually went and device/coolbox health. |
| loki_search_phlebo_daily_metricsA | List all phlebos/riders working a hub on a date with their live day-tracking row: status, availability, battery, lat/long, last_seen, tasks_assigned, orders_completed, attendance_status, coolbox temperature, idle/offline time. This is the "Track Phlebos" board for a hub+day. |
| loki_get_hub_attendance_metricsA | Attendance roll-up for one or more hubs on a date: total_present / total_absent. |
| loki_get_rider_monthly_attendanceA | A rider's day-by-day attendance for a month: per-date attendance_status (present/absent) and hours worked. |
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 18 tools
Most tools target distinct resources and actions, but two search tools lack descriptions, causing potential ambiguity. The distinction between similar rider tools is well-managed through detailed descriptions.
All tools follow a consistent `loki_<verb>_<resource>` pattern with underscores separating words. No mixing of convention or case variability observed.
18 tools is well-scoped for a logistics monitoring server, covering hubs, orders, riders, tasks, and reference data without being overwhelming.
The tools focus on reading and analytics but lack any creation, update, or deletion operations. This is acceptable for a monitoring surface, but the missing mutations create notable gaps for full lifecycle management.