← All posts
For developers · 6 October 2026 · 5 min read

What happens when you ask “how many of these have we got?” — one question, end to end

Worth tracing once, because understanding the path tells you exactly what the connector can and cannot do — and where answers go wrong when they go wrong.

Step 1: you type a sentence

“How many of the 40mm brass elbows have we got, and are any on order?” Two questions in one, which matters shortly.

Step 2: the assistant reads the tool list

Your assistant already knows what the connector offers, because on connection the server published its tools with descriptions: search stock items, get stock levels, search purchase orders, and so on. The assistant is matching your sentence against those descriptions. This is why tool descriptions are not documentation — they are the thing that decides whether your question gets answered.

Step 3: it searches for the item

It does not know your SKU. So first it calls the stock search tool with “40mm brass elbow”, which returns candidate items with their identifiers. If three near-identical SKUs come back, a good assistant asks which you meant rather than picking one. This is the first failure point, and it is a catalogue problem rather than an AI problem.

Step 4: the server calls Linnworks

The connector authenticates to Linnworks with your application credentials, held as secrets in your own Cloudflare account, caching the session token rather than re-authenticating per call. It issues the API request, handles pagination, respects rate limits, and returns a tidied result. None of this is visible to you, which is the point.

Step 5: it gets the levels

With the identifier in hand, the assistant calls the stock levels tool. Back comes stock by location, with available and in-stock as separate figures — available having deducted what is allocated to open orders. If you asked a selling question, available is the number you meant. Second failure point: an assistant that reports in-stock when you wanted available is answering a slightly different question, which is how this goes wrong invisibly.

Step 6: the second half of your question

“Are any on order?” is a separate tool — purchase order search, filtered to that item. Another call, another round trip. This is why compound questions sometimes come back half-answered: each clause is a separate tool call, and a long chain has more places to drop one. Short questions, then follow-ups.

Step 7: the answer

The assistant writes it in a sentence, with the figures and the location split and the inbound purchase order named with its due date. Elapsed time: a few seconds. Exports involved: none.

What this tells you

It cannot do what no tool does. Every step was a published tool. Nothing improvised, nothing reached past the list.

Live means live. No cache, no sync, no snapshot. The figure is what Linnworks returned a second ago.

Your catalogue quality is the ceiling. Ambiguous SKUs produce ambiguous answers delivered confidently.

Nothing here wrote anything. That entire exchange used three read tools. Which is the argument for deploying without the write tools at all until you need them.

All seventeen tools, and which thirteen only read, are listed on the page for the Linnworks MCP tool set, with the full endpoint detail in the documentation. On the available-versus-in-stock trap: why multi-location numbers disagree.

Questions, or want a tool we don't have yet? Email hello@grafto.co.uk — a real person replies.