What Is MCP and Why It Matters for Business

Why this matters

• Understanding what the invoice covers when a model is connected to working systems
• Asking a vendor whether the integrations will still be usable on the next project
• Telling the work on the connection apart from the work on the task itself

What is MCP in plain words

Every device used to come with its own socket. A printer, a mouse, an external drive — three cables and three drivers. Then USB arrived, and manufacturers began building a single port that fit everything.

MCP is the shared socket for language models. The name is straightforward: Model Context Protocol, a protocol for passing context to a model. It describes how an application with a model gets data out of an external system and triggers an action inside it.

Before the shared format, every pair was wired up separately. Three applications and five systems mean fifteen separate links, each written and then maintained by somebody. With a shared protocol, a system is wrapped once and becomes visible to all three applications.

How it works

1. The system is wrapped in a server. The server is a small adapter program sitting on top of a CRM, a mailbox or a document store. Inside, it calls the ordinary API; outside, it speaks the protocol.
2. The server announces its list of capabilities. Three types: data to read, actions to run, ready-made request templates. Every action is described in words — what it does and what fields it takes.
3. The application connects the server. The list of capabilities reaches the model together with the user's task. From there, tool calling takes over: the model picks a suitable action and fills in the fields.
4. The action runs on the server side. The model never touches the database itself. It formulates a request, and the server checks permissions and returns a result.
5. The result comes back into the conversation. The model reads the response and carries on: asking a clarifying question, calling the next action or answering the person.

Why connections grow slower than pairs

The difference shows up in the arithmetic of links. Separate integrations grow by multiplication: applications times systems. Connections built on a shared format grow by addition.

An example from practice

A sales manager's assistant puts together a briefing before a call. It needs the client record from the CRM, the latest emails, warehouse stock and the terms of the contract. Four systems, four different ways in.

Each of those systems is wrapped in its own server. The assistant receives a list of actions: find the client, read the correspondence, check stock, pull a clause from the contract. The model calls them one after another and assembles an answer.

A month later a second task goes live — triaging incoming enquiries. It needs the same CRM and the same mailbox. The servers already exist, and connecting them takes hours instead of weeks. The saving is counted honestly: the time spent on the new task is compared with the time the first one took, with the same set of systems involved.

What business gets out of it

• Integrations outlive the project. A CRM server is not tied to one particular assistant. Changing the model or the application does not send the connections to the bin.
• The second scenario costs less than the first. The bulk of the money goes into connecting a system the first time. After that, the payment is for the task, not for access to the data.
• Permissions live in one place. Exactly what may be read and changed is described on the server side. Security can review that separately from the text of the model's instructions.
• Vendors can be compared by scope of work. The estimate shows how much each system connection costs and how much the logic itself costs. Sizing up the scope for a specific task is easier with the solution finder.

When it can be skipped

One system and one scenario are covered by a direct integration. An assistant that only reads a document store has no need for a shared format: the wrapper adds work and never pays for itself.

The protocol is also unnecessary wherever a one-off export settles the matter. If the data changes once a month, it is simpler to put it into a knowledge base and refresh it on a schedule. A live connection to a system costs more and needs watching.

The benefit starts at the third or fourth connection, or when the same data is needed by several tasks. The threshold is calculated on a company's own numbers: the cost of a single integration multiplied by the number of application-to-system pairs.

What is worth checking

First: permissions. The server gets access to a working system, and the extent of that access is set during configuration. Operations that change data — sending an email, moving a deal to another stage, posting a document — are routed through human confirmation until enough error statistics have accumulated.

Second: where the servers come from. Off-the-shelf solutions are taken from open catalogues, and the code there belongs to somebody else. Before it is connected, it is read, restricted in its permissions and, where possible, hosted inside the company's own perimeter. The data the server hands to the model is also checked: text from an external email or document may contain an instruction addressed to the model.

Third: the log. Every call is written down in full — which action, with which fields, what came back. Without a log, sorting out a disputed case comes down to guesswork, and the share of correct actions cannot be measured at all.