Model Context Protocol
Securely integrate AI Assistants (like Zo) with your warehouse utilizing standard MCP interfaces over HTTP.
Contents
Overview
The Dock Optimizer MCP (Model Context Protocol) integration allows AI agents to securely interact with your environment. Through this single entry point, agents can discover available data (Resources) and execute actions (Tools) while maintaining strict multi-tenant isolation.
Our implementation strictly follows the JSON-RPC 2.0 message format defined by the MCP specification.
Authentication
All requests to the MCP API must be authenticated using an API Key generated from the Integration Hub.
Authorization: Bearer do_live_Y0uRAp1K3Yh3rE...
Key Features
- Keys are strongly hashed using SHA-256 before storage.
- Keys can be revoked instantaneously via the Admin Dashboard.
- Every key is strictly tied to a single Company context.
- Keys support scoped permissions:
read,write, orread,write. - Optional expiration dates for time-limited access.
Endpoints
/api/mcp/v1/message
The primary gateway for all Agent JSON-RPC calls.
Supported Methods
| resources/list | Returns all available read-only data endpoints with descriptions and filter documentation. |
| resources/read | Fetches data from a specific resource URI. Supports query parameters for filtering and pagination. |
| tools/list | Returns all available tools with input schemas and parameter descriptions. |
| tools/call | Proposes an action request to the Human-in-the-Loop workflow. All write operations require admin approval. |
Resources (Read-Only)
Resources provide read-only access to data. Use resources/read with a URI to fetch data.
dock://appointments
Query appointments with filters and pagination.
Query Parameters
| Parameter | Type | Description |
|---|---|---|
start | date | Start date filter (YYYY-MM-DD) |
end | date | End date filter (YYYY-MM-DD) |
status | string | scheduled, checked_in, checked_out, canceled, flagged, no_show |
flagged | boolean | Filter by flagged status (true or false) |
limit | integer | Results per page (1-200, default 50) |
offset | integer | Skip N results for pagination |
sort | string | startTime (default), status, carrier |
Example: dock://appointments?start=2026-03-01&end=2026-03-07&status=checked_in&limit=20
dock://appointments/{id}
Full appointment detail including uploaded files, question answers, door assignment, check-in/out times, driver contact info, and flag status. Replace {id} with the appointment ID.
dock://appointments/{id}/ocr_output
Coming Soon
OCR-extracted data from uploaded documents. Currently returns a placeholder — full OCR processing is being implemented.
dock://doors/status
All doors across all facilities with current booking status, sensor state (Open/Closed), block/full-load status, and assigned carrier info.
dock://event-types
All appointment types configured for your organization. Includes duration, facility, category, grace period, lock period, and booking method.
dock://users
All users in the organization with their last 5 login events (timestamp, IP, device, location).
dock://reports
All scheduled email reports with configuration, frequency, schedule, and last run status/results.
dock://organization
Organization metadata including name, address, type, facilities (with addresses, timezones, and door counts), and terminology configuration.
Tools (Write Operations)
All tools go through Human-in-the-Loop approval. When called, the action is queued and an admin must approve it before execution.
propose_block_door
Block a facility door or mark as full load.
| Parameter | Required | Description |
|---|---|---|
doorId | Yes | The door ID to block |
reason | No | Reason for blocking |
isFullLoad | No | Whether the door is full load |
propose_update_appointment
Update appointment fields. Only provided fields are modified — omitted fields are left unchanged.
| Parameter | Required | Description |
|---|---|---|
appointmentId | Yes | The appointment ID to update |
carrierName | No | Carrier / trucking company name |
poNumber | No | PO number or reference number |
driverCheckInEmail | No | Driver's email address |
driverCheckInPhone | No | Driver's phone number |
notes | No | Notes to append (tagged with agent name) |
propose_flag_appointment
Flag an appointment for human review when data quality issues are detected.
| Parameter | Required | Description |
|---|---|---|
appointmentId | Yes | The appointment ID to flag |
flagReason | Yes | Reason for flagging (e.g., "Missing checkout time") |
severity | No | low, medium (default), or high |
propose_run_report
Trigger a scheduled report to run immediately.
| Parameter | Required | Description |
|---|---|---|
reportId | Yes | The scheduled report ID to trigger |
Request / Response Examples
List Resources
{
"jsonrpc": "2.0",
"id": 1,
"method": "resources/list"
}
Read Appointments (Last 7 Days, Checked In)
{
"jsonrpc": "2.0",
"id": 2,
"method": "resources/read",
"params": {
"uri": "dock://appointments?start=2026-03-01&end=2026-03-07&status=checked_in&limit=20"
}
}
Read Single Appointment
{
"jsonrpc": "2.0",
"id": 3,
"method": "resources/read",
"params": {
"uri": "dock://appointments/101"
}
}
Flag Appointment (Tool Call)
{
"jsonrpc": "2.0",
"id": 4,
"method": "tools/call",
"params": {
"name": "propose_flag_appointment",
"arguments": {
"appointmentId": 101,
"flagReason": "Check-in time recorded but no checkout — appointment ended 3 hours ago",
"severity": "high"
}
}
}
Tool Call Response (Queued for Approval)
{
"jsonrpc": "2.0",
"id": 4,
"result": {
"content": [
{
"type": "text",
"text": "Action 'propose_flag_appointment' successfully queued for Human-in-the-Loop review. Action ID: a1b2c3d4-... You must wait for an Admin to approve this before it takes effect."
}
]
}
}
Error Handling
Errors follow the JSON-RPC 2.0 error format with an additional data.hint field providing recovery guidance for agents.
{
"jsonrpc": "2.0",
"id": 5,
"error": {
"code": -32001,
"message": "Unknown resource URI: 'dock://invalid'",
"data": {
"hint": "Check the resource URI format. Use resources/list to see available URIs."
}
}
}
Error Codes
| Code | HTTP | Meaning |
|---|---|---|
-32700 | 400 | Parse error — invalid JSON |
-32600 | 403 | Insufficient scope (API key missing required permission) |
-32601 | 400 | Method not found |
-32602 | 400 | Invalid params (missing required fields) |
-32001 | 404 | Resource URI not found |
-32002 | 404 | Resource returned empty result |
-32603 | 500 | Internal server error |
Rate Limits
To ensure system stability, the MCP endpoint enforces strict rate limitations:
60 Requests
Per minute, per API key
Requests exceeding this threshold will receive a 429 Too Many Requests response.
Please implement exponential backoff in your agent retry logic.
Safety & Human-in-the-Loop (HITL)
Dock Optimizer employs a secure Human-in-the-Loop (HITL) architecture for all Agent tool calls that modify data.
When an agent invokes tools/call, the action is not executed immediately. Instead, it is routed to an isolated sandbox queue table.
Facility administrators are alerted instantly via SignalR, and they must manually Review and Approve the payload before execution.
HITL Workflow
- Agent sends a JSON-RPC
tools/callrequest (e.g.,propose_flag_appointment). - The MCP Gateway stores this request in the
AgentActionRequeststable as Pending. - The API returns an immediate response: "Action securely queued for Human review. (ID: XYZ)".
- Administrators receive a real-time Dashboard Alert via SignalR.
- An Admin clicks "Approve". Only then is the database modified.
- The system broadcasts a resolution notification, finalizing the audit trail.