MCP Servers for Commerce Operations, Not Demos

Most commerce AI demos are a chat box over a product catalogue. The useful version connects an agent to the systems your operations team already uses, through a typed tool interface with real permissions. That is what MCP is for.

The AI demo everyone has seen is a chat widget that recommends products. It is easy to build, it impresses in a meeting, and it changes almost nothing operationally — because product discovery was rarely the bottleneck.

The bottleneck is the queue of questions your operations team answers by hand every day. Where is this order. Why was this line short-shipped. What is this account’s available credit. When is the Henderson range back in stock. Each requires looking across the storefront, the ERP and the carrier — which is exactly the kind of multi-system lookup an agent is good at, provided it can reach those systems safely.

What MCP actually gives you

The Model Context Protocol is a standard way to expose tools and data to an AI model. Rather than embedding system access inside a bespoke prompt, you publish a server that declares typed tools — each with a schema, a description and an implementation — and the model calls them.

The advantage is architectural rather than intellectual. Your integration is a normal service with types, tests, logging and access control. It is reviewable. It can be denied permissions. And the same server works with any MCP-capable client, so you are not rebuilding the integration per assistant.

Design tools around questions, not endpoints

The most common mistake is mirroring your REST API as tools — getOrder, getCustomer, getInventoryItem — and expecting the model to compose them. It can, but it takes several round trips and each one is a chance to go wrong.

Design tools around the questions people actually ask. One tool that answers "what is the status of this order, including fulfilment and tracking" is better than four that must be chained to get there.

server.tool(
  'get_order_status',
  {
    description:
      'Full status for a single order: line items, fulfilment state, ' +
      'tracking numbers, and any short-shipped lines with the reason. ' +
      'Use this for any "where is my order" question. Read-only.',
    inputSchema: {
      type: 'object',
      properties: {
        orderNumber: { type: 'string', description: 'Order number, e.g. "88214"' },
        accountId:   { type: 'string', description: 'Company account id — scopes the lookup' }
      },
      required: ['orderNumber', 'accountId']
    }
  },
  async ({ orderNumber, accountId }, { caller }) => {
    // Authorisation happens here, in code — never in the prompt.
    await assertCanReadAccount(caller, accountId);

    const [order, fulfilments, erpLines] = await Promise.all([
      shopify.order(orderNumber, accountId),
      shopify.fulfilments(orderNumber),
      netsuite.salesOrderLines(orderNumber)
    ]);

    if (!order) {
      return { content: [{ type: 'text', text: `No order ${orderNumber} on this account.` }] };
    }

    audit.record({ caller, tool: 'get_order_status', orderNumber, accountId });

    return {
      content: [{
        type: 'text',
        text: formatOrderStatus({ order, fulfilments, erpLines })
      }]
    };
  }
);

Separate reads from writes, permanently

Read tools are low-risk and where nearly all the value is in the first phase. Write tools — cancel an order, issue a refund, adjust stock, release a credit hold — change state in systems that feed your accounts.

Keep them on separate servers with separate credentials, and put every write behind an explicit human approval that shows exactly what is about to happen. An agent that drafts a refund for a human to approve is genuinely useful and entirely safe. An agent that issues refunds autonomously is a liability nobody asked you to accept.

Where to start

1. 1

   Instrument the questions

   Spend two weeks logging what operations and support are actually asked. The top five will account for most of the volume, and they are rarely what leadership expects.

2. 2

   Build read-only tools for the top three

   Task-shaped, not endpoint-shaped. Ship to a small internal group before anyone external sees it.

3. 3

   Measure deflection, not sentiment

   How many of those questions never reached a human? That is the number that justifies phase two.

4. 4

   Add writes last, gated

   Draft-and-approve only. The approval UI is part of the feature, not an afterthought.