MCP or a custom Linnworks API integration? They solve different problems
These get compared as alternatives and they are not really. A custom integration automates a known process. MCP serves unknown questions. Picking the wrong one produces a working thing nobody wanted.
What a custom integration is for
A defined job, done the same way every time, with no human in the loop. Pull orders from a channel Linnworks does not natively support. Push despatch confirmations to a 3PL. Sync stock to a shop front every fifteen minutes. Write nightly figures into a warehouse.
The requirements are deterministic: exact field mappings, idempotency, retries, alerting when it fails at three in the morning. You are building a machine, and the machine must be right every time rather than usually.
What MCP is for
Questions you cannot enumerate in advance. You are not automating a process; you are giving a person a way to interrogate data conversationally. The requirement is coverage of the data surface and clear tool descriptions, because the assistant chooses which tool fits a question nobody anticipated.
Correctness still matters, obviously. But “a human reads this and decides” is a different reliability bar from “this runs unattended at 3am and must not duplicate anything”.
The test
Ask whether you can write down, today, every input and every output. If you can, you want a custom integration — an MCP connector is the wrong shape and introduces non-determinism into a job that wanted none.
If you cannot, because the whole point is that the questions vary, you want MCP. Trying to meet that need with a custom integration means building a reporting tool, and then building more of it every time someone asks something new.
The effort comparison, for the overlap
Where they do overlap — you want people to be able to query Linnworks — the cost difference is large. An MCP server over the Linnworks API is a real piece of work: application token auth with session caching and refresh, a paginated and rate-limit-aware client, tool definitions over HTTP and SSE with bearer auth, deployment, and then the long tail of Linnworks API behaviours you learn about one production surprise at a time. Two to three weeks for a developer who already knows Cloudflare Workers.
A custom reporting integration that serves the same need properly is longer, because you also build the interface, and then you maintain it forever as the questions change.
Most operations end up with both
And they should. The integrations do the machine work where failure is expensive and the process is fixed. The connector serves the humans who need to understand what the machines did. They are complementary layers, not competing options, and the mistake is using either one for the other’s job.
If it is the connector you need
Then the build-or-buy question is the narrow one, and the honest arithmetic is in buy vs build on a Linnworks MCP server. If the connector is plumbing rather than your product, buy the Linnworks MCP source instead — complete TypeScript, deployed to your own Cloudflare account, and modifiable, which means your custom tools start from a working base rather than from the API docs.
Questions, or want a tool we don't have yet? Email hello@grafto.co.uk — a real person replies.