MCP tools

The proposed MCP surface lets an assistant help an authorised operator find, explain, and prepare shipping work without becoming a new source of authority.

No MCP server is released today. There is no public endpoint, install command, tool catalogue, credential flow, or production action surface. The classes below are design requirements, not callable tools.

Proposed tool classes

Class	Purpose	Default control
Discover	Find authorised records within the active workspace.	Read only; server-derived scope.
Explain	Summarise a named state using cited record evidence.	Read only; no hidden cross-workspace lookup.
Draft	Prepare a bounded correction or next-step proposal.	No write; show before-and-after evidence.
Act	Apply a separately authorised, reviewed operation.	Unavailable until an explicit contract and approval model exist.

Authority model

The assistant can use only capabilities already granted to the authenticated person and active workspace.
Changing workspace must clear stale results and re-resolve authority.
A suggestion, validation pass, or model confidence score cannot replace a required human approval.
Provider-visible or customer-visible work must expose the exact action, evidence, and confirmation boundary.
Unknown or conflicting outcomes must stop and route to reconciliation.

Audit and privacy expectations

A future server must record the actor, workspace, tool class, requested operation, evidence references, decision, and outcome without logging credentials or unnecessary customer data. Refusals and denied scope changes are part of the audit story, not errors to hide.

Client implementation expectations

A released guide must publish transport, discovery, authentication, tool schemas, confirmation behaviour, error contracts, version compatibility, rate limits, data handling, and revocation. Until those exist, do not configure an MCP client from examples or infer tools from the scripted Qortex demonstration.

See rules and approvals and reliability for the underlying control model.