Guide · Connect your AI agents to InfiPlex
The objection is always the same. An inventory set goes to every listing. A price change goes to every channel. A cancellation reaches the marketplace and cannot be undone. So the person who owns operations says no to the AI, and the team keeps clicking through five seller centrals. The InfiPlex MCP server was built so that person can say yes: five independent layers between what an agent asks for and what actually changes, enforced by the server, not by the agent's good manners. This page shows each layer with the exact messages the server returns.
Why this matters now
InfiPlex has always been the engine behind the screens: it pulls orders from 130+ channels, routes them across warehouses, syncs inventory, pushes to NetSuite, QuickBooks, 3PLs, and EDI retailers. The MCP server makes that engine callable by whatever AI agent your team already uses. You do not have to log in to InfiPlex to ask what shipped, why it shipped from Reno, what needs reordering, or why Amazon pulls failed overnight. You ask Claude or ChatGPT, and InfiPlex answers through its tools.
That is what makes the safety model the whole product, not a footnote. A headless system that lets agents write to it has to prove, mechanically, that the agent cannot do more than you allowed. The five layers below are that proof.
The model
Every tool declares the REST scope it needs, for example shop_order_read or shop_inventory_write. On connect the server publishes only the tools whose scope the key carries. A read-only key never sees inventory_set; there is nothing for the agent to call.
Arguments are checked against the tool's JSON schema: types, enums, minimums, required fields. order_update_status accepts six statuses and nothing else. inventory_set rejects a negative absolute quantity. Invalid calls return the field name and the reason, and nothing runs.
The ten tools that change stock, prices, shipments, products, warehouses, or settings return a preview on the first call and an HMAC-SHA256 token bound to the key, the tool, the exact arguments, and the issue time. Only a second call carrying that token executes. Tokens expire in 10 minutes.
shop_setting_set is refused unless the key also has MCP Allow Setting Writes, independent of the write scope. Reading settings still works, so the agent can explain behavior without being able to change it.
Settings whose names match live-traffic patterns (pull orders, send tracking, send inventory, enabled, active, connect) are classified as arming and refused unless MCP Allow Arming is on the key. Credential settings are refused outright.
Layer 3 in detail
This is the server's response, verbatim in structure, when an agent calls a previewed write tool without a token. The agent is instructed to read the current value first, so you see both the current state and the proposed change before you approve.
Three properties make this more than a courtesy prompt. The token is issued by the server and signed with a server-side secret, so the agent cannot mint one. It is bound to the exact arguments, so the agent cannot preview 24.99 and execute 2.49. And it expires 10 minutes after issue, so a stale approval from earlier in a conversation cannot be replayed later. If any of those checks fail the server answers:
For batch tools, inventory_set_bulk and products_create, one preview lists every row and one token covers the batch, so a cycle-count spreadsheet is approved as a whole, not row by row.
Which tools sit behind which gate
Not every write needs a preview. Five writes execute on the first call because none of them changes a quantity, a price, or anything a marketplace or customer sees: an internal note, the processed flag, the workflow status, an additional info field, a bin location. They are still gated by the write scope. The full per-tool breakdown is in the tools reference; the summary:
| Gate | Tools | Why |
|---|---|---|
| Read | order_search, order_get, order_warehouse_routing_explanation_get, inventory_get, inventory_search, inventory_change_history_get, inventory_restock_list, price_get, price_search, pim_sku_get, pim_nightly_file, warehouse_search, warehouse_get, shop_setting_search, shop_setting_get, marketplace_connect_link_get, log_types_get, log_search |
Nothing changes. Credential settings return only whether a value is set. The connect link issues a URL for the account owner to click; it does not connect anything itself. |
| Write, no preview | order_note_create, order_additional_info_create, order_processed, order_update_status, bin_location_set |
Internal to InfiPlex. No channel, listing, quantity, price, or customer is affected. |
| Write, preview + token | order_create, order_cancel, order_tracking_create, inventory_set, inventory_set_bulk, price_set, products_create, warehouse_create, warehouse_set |
Channel-visible or structural. Cancellations and tracking reach the marketplace; inventory and price reach every listing; warehouses change routing for every order. |
| Preview + token + opt-ins | shop_setting_set |
Account-wide behavior. Needs the write scope, MCP Allow Setting Writes, and for live-traffic settings MCP Allow Arming. |
Layers 4 and 5 in detail
Every setting name is classified before a write is allowed. The classification is by name pattern, so it applies to every channel InfiPlex supports, including ones added after this page was written.
| Tier | How it is recognized | Read | Write |
|---|---|---|---|
| Connection authorization | Names beginning eal__, for example eal__sp_api_connect, eal__walmart_connect |
Refused; the agent is redirected to marketplace_connect_link_get |
Refused |
| Credential | Names containing secret, password, private_key, or ending in _api_key, _token, _access_key, _auth_key, _signing_key, _credential(s), _cert, _certificate, _pem | Returns only whether a value is set, never the value | Refused |
| Arming | Names containing _pull_orders, _send_tracking, _send_inventory, _push_inventory, _send_orders, or ending in _pull_order, _enabled, _active, _connect, _connected, _sync_enabled | Allowed | Preview + token, plus MCP Allow Arming on the key |
| General | Everything else, for example restock_report_email, restock_delivery_lead_time, amazon_pull_orders_delay |
Allowed | Preview + token, plus MCP Allow Setting Writes on the key |
The refusals the agent relays to you, verbatim:
Note the last one: if the scope itself is missing, the tool is not published at all, so an agent only sees that message when a scope is removed from a key mid-session.
Practical setup
Because gates are per API key, you shape what an agent can do by shaping the key. Create as many as you need; revoke any one independently. These three cover nearly every case we see.
*_read scope (orders, inventory, price, PIM, warehouse, settings, log). No write scopes.shop_order_write and shop_inventory_write.Hard limits
Credential values are never returned through MCP, on any key, in any tier. Credential settings are never writable through MCP. Connection authorization is only ever a one time link handed to the account owner; the agent never holds marketplace tokens. order_create does not accept payment card data. No tool exposes a way to bypass the preview for a previewed write. These are not settings; they are the shape of the server.
Frequently asked
Then it executes the exact arguments it previewed, within the scopes on the key, and nothing more. The token binds the write to those arguments, so a prompt injection cannot change the target after the preview. That is why the key profile matters more than the agent's behavior: a read-only or warehouse key bounds the worst case regardless of what the agent is told.
Only on a key with MCP Allow Arming enabled, and only after you approve the preview. Setting names containing _pull_orders, _send_tracking, _send_inventory, or ending in _enabled, _active, or _connect are classified as arming automatically, so this covers Amazon, Walmart, Temu, Shopify, NetSuite, and every other channel without a per-channel list.
The preview shows the tool, its effect, and the exact arguments. The current value comes from the read the agent is instructed to do first: price_get before price_set, shop_setting_get before shop_setting_set, warehouse_get before warehouse_set. In practice you see "currently 27.50, change to 24.99, confirm?" in one message.
Ten minutes from issue. After that the server rejects it and tells the agent to request a fresh preview. An approval you gave earlier in a long conversation cannot be replayed later.
Yes. Every MCP tool call is translated into the same internal API request a REST call would make, under the same API key, so it appears in your API activity by key exactly like any integration. Issue one key per agent or per person and the log tells you who did what.
Create a key with read scopes only, enable MCP, connect your assistant, and use it for a week. You will get order lookups, routing explanations, restock lists, log searches, and setting explanations with zero write risk. Add shop_order_write and shop_inventory_write when you want tracking and receiving, and leave settings and arming off until you have a specific reason.
Resources
Start with a read-only key and see what your team asks in the first week. Widening the key later is one checkbox.
Send them over and we will answer against the server code, not a slide. Contact us, email info@infiplex.com, or call 888‑770‑0857.
Refusal messages, tier patterns, token binding, and the 10-minute expiry are reproduced from the InfiPlex MCP server as deployed September 2026. Claude is a trademark of Anthropic, PBC. ChatGPT and Codex are trademarks of OpenAI. Model Context Protocol is an open standard.
InfiPlex provides eCommerce companies, warehouses, and 3PLs with a robust platform to manage their sales channels.
©2026. All Rights Reserved. Privacy Policy | Terms & License