Model Context Protocol explained

In short

MCP is an open standard for how an AI assistant calls tools and accesses data – comparable to a single connector standard instead of a separate cable per device.
The difference from a classic interface is not the technology but the direction: you don't hand over data, the model fetches it when needed.
The practical benefit only emerges with clear permissions. Without them, access to company data is not progress but exposure.
Using it no longer requires programming skills – but setting it up, and answering who may see what, still requires someone accountable.

Most companies today use AI like a very well-informed counterpart that does not know their business. You explain the context, paste in data, get an answer – and next time it starts over. That works, but it does not scale.

The Model Context Protocol, MCP for short, addresses exactly that. It describes how an AI assistant talks to tools and data sources: which capabilities a source offers, how they are called, and in what form the answer comes back. Anthropic published and opened the standard at the end of 2024; since then other providers have adopted it too.

A central node with channels of light leading to four different geometric forms — One connector, many sources: the assistant speaks to every source in the same language instead of needing a bespoke connection for each.

What MCP actually is

The comparison that holds up best: MCP is to AI connections what a single connector standard is to charging cables. Before, every device needed its own. Afterwards, one is enough.

The three roles

The server: Offers capabilities – "read the latest campaign data", "create a contact", "search the document store". A server typically stands for one system: your files, your CRM, your analytics.
The client: Sits inside the AI tool and talks to the servers. The client does not decide what happens – it only establishes the connection.
The model: Decides, within the task, which capability to call. It only sees what the servers offer it, and may only do what you have permitted.

What matters about this split: the model does not get free access to a system. It gets a list of permitted actions. Anything not on the list is impossible – not because the model behaves itself, but because there is technically no route there.

Worth knowing

The name sounds more technical than the thing is. "Context" here simply means everything the model needs to know for a task. The protocol governs how that context is assembled – not what the model does with it.

And because the standard is open, a server you build once works with any tool that speaks MCP. That is the real gain: you build the connection once, not again per provider.

The difference from a classic interface

The obvious question: we already have interfaces for that. True – and MCP does not replace them, it uses them. The difference lies in the direction of the flow.

	Classic interface	MCP
Who decides	the programmed flow	the model, within permitted bounds
Sequence	hard-wired	chosen at runtime
Change needed for	every new case	new capabilities
Strength	predictability	adaptability
Weakness	rigid	harder to predict

That yields a clear assignment: for processes that always run the same way and must do so – invoicing, data synchronisation, dispatch – the classic interface remains the right choice. For tasks where it is not known in advance which information will be needed, MCP plays to its strength.

What has to be settled before the first connection

A translucent threshold with particles of light passing through in an orderly stream — Access is not a yes-or-no question. What matters is what gets through – and what is held at the threshold.

Careful An MCP server with read access to your document store makes every item in that store visible to the model – including the ones nobody is thinking about right now. The server's access rights are the actual security boundary, not the wording in the prompt.

Four points belong settled before the first server runs:

Scope instead of full access

A server should offer exactly the capabilities a task needs – not the full feature set of the underlying system. Reading and writing belong apart.

Question: what exactly must this task be able to do?

Separate credentials per server

Do not use the administrator account. A dedicated account per connection with the minimum rights needed – then access can be withdrawn later without disturbing anything else.

Question: can this be switched off on its own?

Logging

Every call should be traceable: who, when, which capability, what result. Without a log there is no way to reconstruct what happened when it matters.

Question: can we check this after the fact?

Confirmation where there are consequences

Anything that changes something or goes outward – sending mail, deleting records, publishing – belongs behind an explicit confirmation, not inside an automatic flow.

Question: what happens if this goes wrong?

Provenance of the servers

An MCP server is executable code. For third-party servers the same rule applies as for any other software: check the origin, look at the permissions, and when in doubt do not deploy it.

Question: who wrote this?

Where it pays off in marketing

Twelve glowing modules linked by fine threads of light into one whole — The benefit does not grow with the number of connections but with how well they work together.

Not every connection is worth it. The following four have proven to have the best ratio of effort to effect.

From practice

Document store, read-only. The assistant can reach tone-of-voice guidelines, positioning and earlier texts instead of having them pasted in with every request. The single biggest gain, because it applies to every writing task.

Analytics data, read-only. Questions about numbers can be answered at the source instead of exporting tables. Important: work with an evidence requirement, otherwise plausible statements appear without any basis.

Contact data, read and narrowly scoped write. Creating and enriching yes, deleting no. That boundary saves the entire data set when something goes wrong.

Your own website. Structure, addresses, content – that lets you check internal links and find gaps without anyone walking the site by hand.

Tip Start with a single read-only connection and let it run for four weeks. Whatever went unused in that time, you do not need. That sounds banal, but it prevents the most common failure mode: twelve connections, three of which get used and nine of which are attack surface.

How setting up works

Using it no longer requires programming skills – many tools ship ready-made servers for common systems that can be activated through a configuration file or an interface. What it still requires is someone who answers the permissions question.

Describe the task. Not "we want to use MCP" but "the assistant should know our tone-of-voice guidelines without us pasting them in every time".
Identify the source. Where does that information actually live? Often in several places – then tidy up first, connect second.
Set up access. Dedicated account, minimum rights, read-only, logging on.
Watch for four weeks. Is the connection being used? Are the answers better? If not: switch it off rather than extending it.

A prompt that shows the difference

With sources connected, the way you brief changes too. The prompt below assumes the document store and analytics are connected read-only – and forces an evidence requirement.

Prompt

Task: Draft three subject lines for the next campaign
to the audience [AUDIENCE].

Procedure:
1. Check our document store for the tone-of-voice guidelines
   that apply. Name the file you took them from.
2. Check the analytics data for subject lines from the last
   six months with above-average open rates.
   Name the rows you are relying on.
3. Only then draft the three suggestions.

If either source yields nothing usable, say so
instead of papering over it.

The third sentence is the most important. Without it the model fills the gap with something plausible – and you only notice when somebody asks where the number came from.

Where the limits are

Three things MCP does not solve, even though it is occasionally presented that way.

Bad data does not get better. An assistant with access to a messy store answers wrongly faster than before. The connection amplifies what is there – order as much as disorder.

The process does not appear by itself. Anyone who cannot describe which flow should be automated gains nothing from connecting things. The tool does not answer that question, it presupposes it.

Accountability stays. If the assistant writes something wrong on the basis of outdated data and it goes out, it was still your company. Confirmation steps are not distrust of the technology, they are the point where a person looks.

In closing

MCP is not a product you buy but an agreement about how systems talk to each other. The gain lies not in the technology itself but in the fact that the connection is built once and then works with any tool that speaks the standard.

For companies without an IT department that is the actual headline: access to this kind of automation no longer depends on whether someone in house can program interfaces. It depends on whether someone answers the permissions question properly – and that is an organisational task, not a technical one.

Common questions

What is the Model Context Protocol in one sentence?

An open standard for how an AI assistant calls tools and accesses data sources – a single connector instead of a bespoke connection per provider.

Do you need programming skills to use MCP?

To use it, no: ready-made servers exist for common systems and can be activated through configuration. To decide which rights a server receives, yes – you need someone accountable, and that is an organisational rather than a technical question.

Is it safe to give an AI access to company data?

It is as safe as the permissions allow. The server's access is the actual boundary – not the instruction in the prompt. Read-only access with a dedicated account, minimum rights and logging is manageable; an administrator account is not.

What is the difference between MCP and a normal interface?

The direction. With a classic interface a programmed flow determines what happens when. With MCP the model chooses at runtime from the permitted capabilities. One is more predictable, the other more adaptable – both have their place.

Which connection is worth doing first?

The document store, read-only. It applies to every writing task, because tone of voice, positioning and examples then no longer have to be pasted in with each request.

Does MCP work with every AI tool?

With every tool that supports the standard. Since it is open, that circle is growing – but check before deciding whether the tool you use is part of it, rather than assuming.

AI tools Automation Practice Data protection

Marketing that sets itself up

The Studio Engine beta is live. Claim your spot and help shape it from the start.

Join the beta →

← Back to overview