What Is an MCP? (And When Should You Use One)

The last article covered APIs, the standard fittings that let software talk to software. This one covers the newer standard that lets AI talk to software, because you are going to start hearing the term MCP in sales pitches very soon, and it is worth knowing what it actually is before someone charges you for it.

The problem it solves

MCP stands for Model Context Protocol. It is an open standard, started by Anthropic, the company behind Claude, and now adopted well beyond them.

Here is the problem it exists to fix. An AI model on its own is a brain in a jar. It can reason and write, but it cannot check your calendar, search your CRM, or create an invoice. Giving it those abilities used to mean custom integration work: one bespoke connection per tool, per AI product, rebuilt whenever either side changed. Ten tools and three AI products meant thirty integrations. Nobody sane maintains thirty integrations.

MCP standardises the connection. A tool exposes its capabilities once, through an MCP server, and any AI that speaks the protocol can use them. Same idea as standardised fittings in the API article, applied one level up. Build the socket once, and every compliant plug fits.

How it works, in plain language

An MCP server is a small piece of software that sits in front of a system and describes what that system can do, in a form a model can read. "Search customers by name." "List this week's jobs." "Draft an invoice." Each capability has a description of what it does and what information it needs.

The clever part is what happens next: nothing, until it is needed. The model reads the menu, and when your request actually calls for a tool, it decides to use one, makes the call, and folds the result into its answer. Ask Claude "what does Thursday look like?" with a calendar MCP connected, and it checks the real calendar rather than guessing. That is the difference between the chatbot rung and the agent rung on the ladder from the agents article: tools, plus the judgement about when to use them.

MCP and APIs: cousins, not competitors

The relationship is simple: your software's API is the socket, and an MCP server is usually a smart adapter that wraps it, translating "here are my API endpoints" into "here are tools an AI can understand and choose between."

APIs are for connections you can fully specify in advance: when a form is submitted, create a row, every time, no judgement. MCP is for connections where the AI decides what to do and when: which tool fits this request, what to search for, whether it needs more information first. Rules get APIs and workflow automation. Judgement gets a model with MCP tools. Most real systems, as with agents and automation, end up a braid of both.

When you should use one

When you want your AI assistant working with your real data. The connectors you can switch on in Claude, for calendars, email, drives, and a growing list of business tools, are MCP under the hood. If your team uses AI daily, connecting it to the systems where work actually lives is the single biggest usefulness upgrade available, and it is mostly a matter of turning things on.

When you are building an agent that needs several tools. Every agent we deploy at D3ploy touches multiple systems. MCP means each system is wrapped once, cleanly, and any agent, present or future, can use it. It is the difference between wiring a house properly and running an extension lead to each appliance.

When you do not want to marry one AI vendor. Because the protocol is open, an MCP server you build for your job management system today works with whatever model you run next year. In a field moving this fast, that portability is worth real money.

When you do not need one

If a workflow has no judgement in it, plain API automation is cheaper and perfectly predictable, per the rule above. If you just need AI to answer questions from documents, a project with files, from the projects article, may be all you need. And if a ready-made connector already exists for your tool, use it rather than commissioning a custom server. Custom MCP work earns its keep when the system is yours, or the judgement calls are specific to how your business runs.

The guardrails clause

One warning, and it is the same one as always. MCP gives AI hands, and hands need rules. A well built MCP setup distinguishes reading from acting: looking up a customer is low risk, sending an email or moving money is not, and the high risk tools should sit behind the approval gates described in the trust article. When someone offers to connect AI to your systems, your first question is not "what can it do?", it is "what can it do without asking?"

That is the fittings tour complete: APIs connect your software, MCP connects your AI to it, and both exist so that information moves without a human playing courier. Which is, if you have been following the series, where every automation story in your business begins.