MCP for non-engineers, explained
If you run an ops or revenue team, you have probably been told that "MCP" is the next big thing and left to figure out what that means. Here is the plain version, without the jargon.
The problem MCP solves
A chat assistant on its own can write you a lovely email. What it cannot do, by default, is look up the actual deal in your CRM, check the real invoice status, and then send that email to the right person. It has no hands. It only has words.
To give it hands, someone has to connect it to each of your tools. Before MCP, every one of those connections was custom plumbing — a bespoke bridge between one assistant and one app, rebuilt again for the next assistant and the next app. It did not travel.
MCP — the Model Context Protocol — is a shared standard for those connections. It is a common plug shape. Build a tool to the MCP standard once, and any MCP-aware assistant can use it. Think of it like USB: before USB, every device had its own cable; after it, one shape fit everything.
What MCP actually is, concretely
An MCP setup has two sides:
- A server that exposes your tools and data — "look up a contact," "create a ticket," "read this document" — in the standard shape.
- A client (the AI assistant) that can discover what the server offers and call those actions when it needs them.
That is the whole idea. The assistant asks the server "what can you do here?", the server answers with a menu, and the assistant picks the right action for the task in front of it.
The useful mental model: MCP does not make the AI smarter. It makes it able to act — on your systems, within limits you set.
What MCP is not
A few things worth clearing up, because the hype blurs them:
- It is not an AI model. MCP is the connection layer. The model still does the thinking; MCP just gives it reach.
- It is not magic autonomy. A good setup is scoped: the assistant can read these records, write those, and nothing else. You decide the menu.
- It is not always necessary. If your need is a simple one-step trigger, a plain workflow or a direct API call is simpler and cheaper. MCP earns its place when an assistant needs flexible, on-demand access to several tools.
Where it is genuinely worth it
The setups I see pay off fastest:
- An internal assistant that can act. "Summarise this account, check its open tickets, and draft a renewal note" — across three systems, in one ask.
- Connecting to tools that already speak MCP. A growing number of platforms ship official MCP servers. Often the work is not building anything — it is setting them up correctly and safely and wiring your assistant to them.
- Letting an AI step inside an existing workflow reach live data instead of working from a stale copy.
Most of my MCP work is exactly that middle one: setup and integration — getting official or platform-native servers connected to your assistant with the right scopes and guardrails. Building a custom MCP server from scratch is a real option, but it is the exception, not the starting point. You usually do not need to build a new plug when the right one already exists.
The part that actually matters
Whatever you connect, the questions are always the same: what can the assistant read, what can it write, who approves the consequential actions, and how do you see what it did? Get those right and MCP is a quietly powerful upgrade. Skip them and you have given a confident intern admin access.
If you are curious whether an MCP setup would help your team — or whether a plain workflow would do the job for a tenth of the effort — send me a short brief. I will give you a straight answer, not a sales pitch.