AI agents for inventory planning: what works today, and how MCP fits

AI assistants have become genuinely useful for operations work — but not in the way the hype suggests. The useful version isn't an AI that "runs your inventory". It's an assistant that can look things up in your systems, explain what it finds, and prepare work for a person to approve. This guide covers what that looks like in practice, how the Model Context Protocol makes it possible, and the patterns that keep it safe.

Key takeaways

• Language models are good at finding, explaining and summarising. They are not a reliable calculator over thousands of rows. Let your planning system do the maths and let the assistant call it.
• The Model Context Protocol (MCP) is an open standard that lets AI assistants call tools in other applications. Your inventory system exposes tools; the assistant decides when to use them.
• Start read-only. When you add actions, make them create drafts that a person reviews in the system of record.
• Scope access to one organisation, with credentials you can revoke, and treat anything the assistant reads from your data as untrusted input.
• The test of a good AI workflow: a planner gets to a better decision faster, and nothing important happens without a person approving it.

What AI assistants are good at

Answering questions across your data

"Which products will run out before their next delivery?" "What's late from our main supplier?" "Where is SKU 1042 in the Melbourne warehouse?" These are lookups across several reports that would take a person a few minutes of clicking each. An assistant with the right tools can answer them in one step, in plain language.

Explaining numbers

"Why is the suggested order for the blue mug 360 units?" The assistant can fetch the forecast, lead time, safety stock and stock on order, and walk through how they combine. That's useful for new team members and for founders who want to check a buyer's work.

Summarising and drafting

Morning summaries of open alerts, a first draft of an email to a supplier chasing a late order, a summary of what changed since last week. Writing is where these models are strongest.

Preparing work for approval

Turning "draft a PO for everything critical from our main supplier" into a draft purchase order that a buyer opens, checks and sends. The assistant saves the assembly time; the buyer keeps the decision.

What they're not good at (yet)

• Being the forecasting engine. Ask a language model to forecast from a pasted table of sales and you'll get a plausible-sounding number that you can't reproduce or audit. Forecasting, safety stock and reorder maths belong in deterministic code that gives the same answer every time.
• Arithmetic over large tables. Models can make mistakes summing hundreds of rows. A tool that returns the computed total is far more reliable than a model adding up raw data.
• Knowing what isn't in the data. The assistant doesn't know your supplier's factory is closed next week unless someone recorded it.
• Taking responsibility. Sending purchase orders, changing prices or committing to a supplier are decisions with consequences. They need a person who's accountable for them.

How the Model Context Protocol works

MCP was introduced by Anthropic in late 2024 as an open standard and is now supported by a range of AI assistants and developer tools. It separates two roles:

• An MCP client is the AI application — a desktop assistant, an IDE or an agent framework.
• An MCP server is a service that exposes tools (functions the model can call, each with a name, a description and typed inputs), and optionally resources and prompt templates.

When you connect a client to a server, the assistant sees the list of tools and their descriptions. During a conversation, the model decides that a tool would help, the client calls the server with the inputs, and the result comes back for the model to use in its answer. Servers can run locally or over HTTP; remote servers are typically authenticated with an API key or OAuth.

The important design point: the server decides what's possible. If the server only offers read tools, the assistant can only read. If its only write tool creates drafts, the assistant can only create drafts. Safety comes from the tools you expose, not from hoping the model behaves.

A worked example

A buyer asks: *"What's at risk of stocking out from Harbour Ceramics, and can you draft a PO to cover it?"*

1. The assistant calls a stockout-risk tool filtered to that supplier. It returns one product: 120 units available, nothing on order, forecast 15 a day, supplier lead time 21 days.
2. Days of cover: 120 ÷ 15 = 8 days, well short of the 21-day lead time.
3. The planning system's suggestion, using a 10-day safety buffer: (21 + 10) × 15 − 120 = 465 − 120 = 345 units, rounded up to the supplier's case pack of 24: 345 ÷ 24 = 14.4, so 15 cases = 360 units.
4. The assistant calls a draft-PO tool with that line. A draft purchase order is created in the inventory system.
5. The assistant replies with a summary and a link. The buyer opens the draft, checks it, perhaps adjusts the quantity, and sends it.

The key detail is step 3: the planning system computed the quantity, and the assistant reported it. If the assistant had worked it out itself from raw sales, you'd have no guarantee it used the same method as your replenishment report.

Safe patterns

Read-only by default

Start with tools that only read: stock levels, forecasts, alerts, open purchase orders. Most of the value is in answering questions, and read-only tools can't damage anything.

Drafts only for writes

When you add actions, make them produce drafts in your system of record — draft purchase orders, draft transfers — never sent or committed results. The person approving works in the normal interface, with its usual checks and history.

Scoped, revocable credentials

Give the assistant its own API key, scoped to one organisation and the minimum permissions it needs. Never share a person's login. If something looks wrong, revoke the key without locking anyone out.

Return computed results, not raw dumps

Good tools return the answer — "these 6 products have less cover than lead time" — rather than 10,000 rows for the model to sift. That's more accurate, cheaper and faster.

Treat data as data, not instructions

Product descriptions, supplier notes and order comments can contain any text, including text written to look like instructions to an AI. That's known as prompt injection. Read-only and drafts-only tools limit what a manipulated assistant could do; a human approval step catches the rest.

Keep a record

Log which tools were called, by which key, with what inputs. If a strange draft appears, you want to know where it came from.

Getting started

1. Pick three questions your team asks every week that require clicking through several screens.
2. Connect an MCP-capable assistant to your inventory system with a read-only key, and try those questions.
3. Compare the answers with your reports. Where they differ, find out why — usually a tool description or filter that needs tightening.
4. Only then add a drafts-only action, and agree who reviews drafts and how often.

Where Stokrio fits

Stokrio's MCP server is authenticated with an API key or a signed-in session, and every tool is scoped to that one organisation and the key's permissions. Its tools are get_stockout_radar, get_forecast, get_abc_inventory_analysis, get_open_alerts, get_warehouse_stock, locate_sku_in_warehouse and draft_purchase_order — and draft_purchase_order only ever creates a draft for a person to review and send. The numbers the tools return come from the same forecasting and replenishment engine as the app.