Guide · MCP for logistics
MCP for logistics is the use of the Model Context Protocol (MCP) — an open standard that lets AI agents discover and call software tools — to expose logistics operations such as creating shipments, estimating costs, requesting value-added services, tracking parcels and reconciling invoices as typed, agent-callable tools. Instead of a person clicking through a dashboard or writing custom API glue, an authorized AI agent executes the same shipping workflow directly against the logistics provider’s systems.
Agent-native shipping is a logistics service designed so that an AI agent can operate it end to end: every operational step — quote, order creation, service instruction, tracking, settlement — is available as a structured tool call with machine-readable inputs and outputs, idempotent writes and verifiable events, rather than existing only as web pages, emails or chat threads a human must read.
The distinction matters because most cross-border logistics — especially the China leg between a merchant’s suppliers and international carriers — still runs on email threads, chat apps and spreadsheets. An AI agent cannot reliably operate a workflow that lives in unstructured messages. MCP turns that workflow into tools.
A China-leg shipment spans receiving, inspection, value-added work, consolidation, packing, dispatch and international transit over days or weeks. Agents handle this well only when each step is an observable, resumable tool call with recorded state.
Reconciling supplier parcels, deciding what to consolidate, chasing tracking numbers and auditing bills is exactly the repetitive, structured-decision work agents are suited to — if the data is exposed as structured tools instead of PDFs and chat screenshots.
For an agent to act on a merchant’s behalf it needs idempotent writes (retries never duplicate orders), signed events (webhooks the receiver can verify), and line-item settlement it can reconcile. These are protocol-level properties, not dashboard features.
A concrete example: an AI agent (for example Claude or an agent embedded in a merchant’s back office) managing a shipment of supplier parcels through an end-to-end fulfillment operator, using only tool calls.
The agent calls an estimate tool with weight, dimensions, destination and service type, and receives a structured price estimate it can compare across options — no rate card to scrape.
The agent files an idempotent order pre-alert for parcels coming from the merchant’s own suppliers, declaring any value-added services (relabeling, polybagging, repacking) with the merchant’s written instructions attached. A safe retry returns the original response instead of a duplicate order.
China-leg events (receiving, value-added services, consolidation, dispatch) and international carrier events merge into one normalized WooliiPorter shipment ledger the agent can page, poll or receive as HMAC-signed webhooks — so "where is my shipment?" becomes a tool call, not a support ticket.
The final settlement is a list of explainable fee line items that reconciles against the packed quote. The agent can diff estimate versus final bill line by line and flag anything unexplained before payment.
WooliiPorter, a technology-native China fulfillment operator for merchants who source from their own China suppliers, connects physical warehouse execution to an agent-ready operating layer:
Onboarding is account-first and approval-gated: merchant signup, in-account integration application, approval, then API-key management in the active merchant console. Documentation: Merchant API & MCP docs; machine-readable contract: OpenAPI 3.1 JSON.
The tool names are the contract, so they are listed rather than summarised. Grouping is by the question an agent is trying to answer, because that is how a runtime picks a tool.
| Capability | Tools | What the agent can do |
|---|---|---|
| Price before committing | estimate_shipping_cost, list_shippable_countries | Compare options against the same rate engine the final quote uses, and check a destination has a live configured route before promising anything. |
| Create and amend work | create_forwarding_order, cancel_order, get_order, list_orders_updated_since | File an idempotent order pre-alert keyed on your own order id, poll incrementally for what changed, and cancel while the order is still awaiting parcels. |
| Follow the physical leg | get_tracking, get_timeline | Read normalized carrier tracking per outbound package, and one merged China-leg plus carrier-leg timeline instead of six carrier tabs. |
| Settle and reconcile | get_packed_quote, get_settlement, pay_order | Diff the estimate against the packed quote, reconcile the line-item bill against that quote, and pay per shipment. |
| Hold stock, if you choose to | register_sku, create_inbound_shipment, get_inventory, create_fulfillment_order, confirm_fulfillment, get_statement | Register SKUs, pre-alert inbound stocking, read levels computed from the immutable movement ledger, and dispatch from stock with FIFO reservation. |
Polling is not the only option. 12 webhook event types are delivered at least once, HMAC-signed over the raw body and carrying immutable event IDs, so an agent can wait on quote.ready rather than asking every minute whether the quote exists yet. The full event list and the signature scheme are in the Merchant API reference.
All three drive the same backend and enforce the same two human gates. What differs is who is holding the wheel.
| Property | MCP tools | Merchant API V1 over HTTP | Store plugin |
|---|---|---|---|
| Who drives it | An authorized external AI agent, in the merchant’s own runtime. | Your own code — an OMS, a backend job, a storefront. | The store itself, on order status changes. |
| Storefront it works with | Any, because it lives outside the store. | Any. | WooCommerce. |
| Discovery | Tools are self-describing: the agent reads names, inputs and outputs at connect time. | You read the reference and write the client. | Not applicable — the workflow is fixed by the plugin. |
| Authentication | The merchant API key, same model as the API. No agent issues credentials to another agent. | The merchant API key, scoped per environment. | The merchant API key entered in the plugin settings, sandbox or production. |
| Human gates | Identical: packed-quote approval before dispatch, and the mixed-order decision. | Identical. | Identical — a mixed order pauses on the WooCommerce order rather than being split. |
| What it is not | Not checkout, not payment authorization, not agent identity. MCP standardizes discovery and calling. | Not a public unauthenticated API. | Not a Store-hosted MCP endpoint, and not a WordPress Abilities surface. |
Exposing logistics operations — estimating, creating shipments, requesting value-added services, tracking and reconciling — as Model Context Protocol tools that an authorized AI agent can call directly, instead of as web pages a person has to read. The agent executes the same workflow against the provider’s systems that a human would run through a dashboard.
A logistics service designed so an agent can operate it end to end: every operational step is a structured tool call with machine-readable inputs and outputs, writes are idempotent, events are verifiable, and the points where a person must decide are explicit rather than implied.
22, wrapping Merchant API V1. They cover pre-order estimates, idempotent order creation, value-added-service requests, packed quotes, settlement, payment, tracking, the merged timeline, cancellation, SKU registration, inbound shipments, ledger-computed inventory, fulfillment orders, monthly statements and shippable destinations.
No, and that is deliberate. Two decisions stay with the merchant: approving the packed quote before dispatch, and choosing how a mixed order containing both stocked and unstocked lines proceeds. Everything else — routing, reservation, quoting, tracking normalization, settlement write-back — runs without a person.
No. MCP standardizes how agents discover and call tools. It does not handle shopping carts, payment authorization or agent identity — adjacent protocols address those. In logistics its job is to make the operational workflow callable and auditable; commercial terms, account approval and payment still follow the provider’s normal contract.
Through its merchant, not through another agent. Onboarding is account-first and approval-gated: the merchant creates a login, submits the in-account integration application, and approval opens sandbox and production key management. The agent then connects to the standalone MCP server with that merchant API key.
No. The tools coordinate parcels the merchant already owns. WooliiPorter never buys the goods and never handles the supplier purchase payment, so there is no tool that can spend money with a factory on your behalf.
One clarification worth stating plainly: MCP standardizes how agents discover and call tools. It does not by itself handle shopping carts, payment authorization or agent identity — adjacent protocols address those layers. In logistics, MCP’s job is to make the operational workflow callable and auditable; commercial terms, account approval and payment still follow the provider’s normal contract.
Each of these is a protocol-level property rather than a dashboard feature. Without the mechanism that answers it, an agent degrades into a screen-scraper with an API key.
| Where it breaks | Why an agent cannot work around it | The property that fixes it |
|---|---|---|
| Supplier coordination lives in chat threads | Restock timing, parcel counts and domestic tracking numbers move through messaging apps and email. An agent cannot reliably parse a workflow that exists as screenshots. | Typed tool calls for every operational step — estimate, order, instruct, track, settle — rather than pages a human must read. |
| Quotes arrive as spreadsheets | Freight is quoted ad hoc, per conversation. Without a structured estimate call an agent cannot compare options or detect drift between quote and bill. | Estimate and packed quote as separate typed objects, with the binding one produced after measurement. |
| Tracking is scattered across carriers | The China domestic leg, warehouse handling and the international carrier each speak a different system, so the agent polls six tabs a human used to keep open. | One normalized timeline, plus HMAC-signed webhooks with immutable event IDs the receiver can verify and deduplicate. |
| Billing is a PDF at month-end | If charges cannot be reconciled line by line by a program, the agent must either trust blindly or escalate everything — which is not automation. | Settlement as line items that reconcile against the packed quote, so the agent can diff and alert instead of averaging. |
| Retries duplicate real shipments | A network timeout on order creation is indistinguishable from a failure, and an agent retries by default. | Idempotent writes with stored-response replay: the retry returns the original response instead of creating a second order. |
| Nobody knows where a human is required | An agent that escalates everything is a worse dashboard; an agent that escalates nothing spends your money on a guess. | Explicit, documented human-decision points — packed-quote approval and the mixed-order route — with a recorded decision trail. |
The useful version of “can an agent run this?” is operation by operation. Two rows are a hard no by design, and two more are capabilities that simply do not exist to be granted.
| Operation | Agent-operable? | Why |
|---|---|---|
| Get a pre-order cost estimate | Yes | Structured tool call against the same rate engine the final quote uses. |
| Create an order pre-alert | Yes | Idempotent on your own external order id — a retried creation replays the original response instead of shipping twice. |
| Declare value-added services with label files and instructions | Yes | Part of the order payload; an incomplete declaration is refused with every gap listed at once rather than half-executed. |
| Read the packed quote | Yes | It is a distinct object from the estimate, produced after measurement. |
| Approve the packed quote before dispatch | No — human merchant only | This is the point at which real money is committed against a number nobody has seen until now. An agent guessing here is a bug, not automation. |
| Choose how a mixed order proceeds | No — human merchant only | Forward everything, wait for stock, or re-evaluate inventory. All three are defensible and only the merchant knows which is right for that customer. |
| Pay a shipment | Yes | Per shipment, after approval. Sandbox settles instantly; production returns a payment client secret. |
| Follow tracking and the merged timeline | Yes | Normalized across the China leg and the international carrier, including re-registered tracking numbers. |
| Reconcile the settlement against the quote | Yes | Line items are explainable, so the agent can diff estimate against final bill and flag anything unexplained before payment. |
| Register SKUs and stock inventory | Yes | Registration, inbound pre-alerts, ledger-computed inventory reads and fulfillment orders are all tools. |
| Issue itself credentials | No — never | Keys are issued to a merchant account through an approval-gated application. No agent provisions access for another agent. |
| Buy from your suppliers | No — not a capability that exists | WooliiPorter never buys the goods and never handles the purchase payment, so there is no tool that can. |