EXPERIMENT_040 // MOCK.MCP.RETAIL-INVENTORY.CONNECTOR
This experiment demonstrates a live agent tool-calling loop against a mock, Zod-validated MCP-shaped inventory server — search, stock check, and reservation tools — that reacts on a simulated in-store display streamed over Server-Sent Events. It reconstructs the MCP tool-surface shape, not an integration with any real retailer.
LOADING EXPERIMENT...
Tencent opened its WorkBuddy platform to third-party developers with MCP, Skills and CLI as extension interfaces covering more than 20 industries including retail, and Anthropic open-sourced commerce-agent templates for retail, travel, telecom, and ticketing under Apache 2.0. This experiment reconstructs the tool-surface shape both point at: an in-repo mock MCP server exposing three Zod-validated inventory tools, called by a live LLM tool-calling loop to satisfy a plain-language shopper request, with the outcome — a matched item, a confirmed reservation, or a rejected stock check — rendered live on a simulated in-store display over a real Server-Sent Events connection.
HOW IT WORKS
MockRetailMcpServer plays the role an MCP server plays in the real spec: a fixed list of named tools — search_inventory, check_stock, reserve_item — each with a Zod input schema, called by name with arguments and returning a typed result. There is no real retailer or WorkBuddy/commerce-agent-template integration behind it — eight seed items across four categories, freshly re-seeded for every shopper session so one visitor reserving the last unit never depletes stock for the next. callTool() never throws: an unrecognised tool name or arguments that fail their schema return a safe rejection, the same untrusted-input discipline EXP_039's capability-manifest validation established.
Typing a request and clicking Send starts a multi-turn loop against OpenAI's gpt-5.4-mini via @diabolicallabs/llm-client's withTools(), wired directly to the same Zod schemas the mock server validates against. The model decides which tool to call and with what arguments each turn — not a single structured-output batch — and every tool result is fed back as the next turn's message so the model can search, then check stock, then reserve, up to a six-turn cap before the agent gives its final answer.
Each tool call executes immediately against the session's MockRetailMcpServer instance: search_inventory filters the mock catalogue, check_stock reads live availability, and reserve_item is the sole mutator of a simple reservation state machine — it decrements available stock and assigns a reservation ID only if the requested quantity is still available at call time, rejecting with a plain reason otherwise. Every step publishes to a server-side event bus keyed by the browser's session ID.
A GET /events route subscribes to that same session's event bus and streams every tool call, tool result, and display reaction to the browser over Server-Sent Events — a real network transport, not an in-process shortcut — matching the pattern this repo's own chat-streaming endpoint already uses. The in-store display panel renders one tile per mock SKU, reacting live: a shelf tile highlights when search_inventory matches it, and flips to a green "reserved" state the moment reserve_item succeeds — the full shopper-request-to-visible-reservation cycle runs live, not as a static mock.
WHAT THIS PROVES
A published, public protocol's TOOL-SURFACE shape — named tools, Zod/JSON-Schema-validated arguments, call-by-name-with-result — is reconstructable end to end with this repo's existing dependencies (Zod, @diabolicallabs/llm-client's native withTools()) without adding an MCP SDK dependency at all, while being explicit in the code, the in-app copy, and this description that no wire-protocol MCP transport or real retailer integration is involved.
The same untrusted-tool-output discipline this repo applies to LLM-generated hardware commands (EXP_039) applies just as directly to LLM-generated commerce tool calls: every argument the model supplies is re-validated against the live mock inventory state before it can change a reservation, regardless of what @diabolicallabs/llm-client already parsed it against — a model confidently calling reserve_item with a stale quantity is still caught at the state-machine boundary, not trusted because the request looked well-formed.