MCP (Model Context Protocol) is an open standard that sets out how an AI app — for example Claude, ChatGPT or Microsoft Copilot Studio — uses the functions of your systems. A small program on the system’s side, an MCP server, shows the AI app a list of allowed functions, such as “find a customer or supplier” or “prepare an order for approval”, and carries them out within the permissions it has been given. How such a project works with us, from scope to acceptance tests, is set out on the page on connecting an AI assistant to your system (MCP). This article is about something else: what MCP changes in the proposal in front of you.
We write for the person who has a proposal with a line saying “MCP server” or “AI agent with access through MCP” — an agent being an AI program that carries out the steps of a task by itself — and has to decide whether to accept it: a business owner, a department head or whoever is responsible for IT. There is no code here. There are three things MCP actually changes: the quote, the scope of acceptance, and the place where permissions live. There is also a list of things it does not change, even though a “we have MCP” slide might suggest otherwise. Facts about the standard are given as of 12 October 2026; the standard changes quickly, so each comes with a date or a source.
MCP in three sentences
Without a shared standard, connecting a company system to each new AI app usually needed its own adaptation: one for Claude, another for ChatGPT, yet another for your own agent. MCP works like one standard socket: the system exposes its functions once, through an MCP server, and any AI app that supports the standard can use them. The specification calls the AI app the host — the program a person or an agent works in.
A few dates, to make clear how mature the standard is. The current MCP specification is dated 28 July 2026. Anthropic, which created the standard, handed it over on 9 December 2025 to the Agentic AI Foundation at the Linux Foundation. MCP servers can be used in, among others, Copilot Studio and through the Claude and OpenAI APIs — the entrances through which companies build their own apps on these models (Claude marks the feature as a test version, OpenAI describes it in its documentation). n8n can act both as a server and as a program that uses other servers — more on that in the n8n guide.
An MCP server can offer three kinds of things: functions that the AI model uses, data to read (for example, the text of a document) and ready-made instruction templates for the user. From here on we focus on functions, because it is their access and permissions that you assess in a proposal.
What you are buying when the proposal says “MCP server”
The standard itself is simple, and there are plenty of ready-made building blocks for a server. So you are not paying for “MCP”, but for what has to be designed around it for your company. In a sound proposal that line breaks down into several concrete items:
- a list of functions chosen for one use case — not “the whole API”, meaning not everything your system can expose to other programs;
- a description of each function in your company’s language — the AI model picks a function by its name and description, so whether it picks well depends on those descriptions;
- permissions checked every time a function is used, not just once when connecting;
- identity checks: who confirms their identity to the server and with what, and how the server confirms its identity to your system;
- an activity log: what was done, when and on whose instruction;
- acceptance tests: a list of situations that must work correctly, agreed before the build;
- deployment and maintenance instructions for the person who will take the server over.
The second decision is whether to build your own server or use an existing one. More and more software vendors run their own official MCP servers for their products. If such a server does what you need, it often means less development work — but then you are buying someone else’s list of functions and someone else’s permissions. Your own server makes sense when an existing one exposes too much, too little or does not know your company’s language. Either way, the number of functions, the number of systems and whether the functions only read or also write drive the cost more than the standard does. We give no prices, because they depend on your system; where the costs of a whole rollout come from is covered in the article on what an AI agent costs.
What MCP changes in the quote — and what it does not
It changes three things.
- How much work is repeated across several AI apps. If several AI apps are to use the same functions, the function descriptions, permissions and activity log are built once rather than for each connection. Each connection still needs configuration and tests. With a single app this benefit does not exist.
- The cost of switching to another AI app later. If in a year you want to move from one AI app to another that also supports MCP, the server stays. That does not make the switch free: apps differ in which parts of the standard they support and how they ask the user for consent, so the tests have to be run again.
- A place for permissions and the activity log. The server is a natural gate: every use of a function passes through it, so that is the easiest place to check permissions and record what happened. We cover this in more detail below.
What it does not change:
- where the data goes. What a function returns is usually passed by the AI app to the AI model at the provider you chose, on its terms. Which results reach the model and where they are processed is decided by the app and the deployment set-up; MCP itself does not move the processing into your company. Who then acts as the controller of personal data under the GDPR (the General Data Protection Regulation), and who is the processor, is set out on the page on security and GDPR;
- AI model fees or AI app licences;
- the work of describing the process: someone has to decide which functions are needed and what they mean;
- the need for testing and maintenance: your system changes, AI apps change too, and the standard has new versions — the July 2026 version, for example, marked several earlier mechanisms for future removal; under the standard’s rules they stay for at least 12 months before they can be removed (list of changes).
If “MCP server” is a single line in the proposal without a breakdown into the items above, the first question for the supplier is what exactly it contains.
Scope of work and acceptance: what to ask before you sign
This is not about law, but about what you receive and what you control once the project ends. The contract terms are for your lawyer; below are the questions worth having answers to before you talk to them.
- Who owns the server code? Does it come to you — to wherever your company keeps program code — or does it stay with the supplier and get rented to you?
- Where does the server run, and who can access it? On your infrastructure, in your cloud, or as the supplier’s service? The location alone does not decide who sees the data passing through: the supplier may keep administrative or support access even to a server in your cloud. Ask separately who can look at the data, and why, during operation and during technical support.
- Who stores the tokens and other access details, and who controls them? A token is a digital pass that a system issues to a program. If the connection uses passes, the AI app uses a pass for the server, and the server uses separate access details for your system. Where are they stored, who can use them, and are permissions granted by your company’s account or the supplier’s? Who can revoke them — and does the supplier lose access after handover?
- How do you switch to another AI app? Was the server tested with only one app, and what has to be done to connect another?
- What is the list of acceptance tests? Does it include attempts at disallowed operations, expired passes, a repeated save and malicious content in the data — and not only “it works in the demo”?
- What do you receive at handover? The code, a deployment description, maintenance instructions and the list of functions with their permissions. In our implementation methodology handover is a separate stage precisely so that afterwards you do not depend on us.
Permissions: where the four decisions live with MCP
On the page on AI agent implementation we describe four decisions made before an agent gets access to anything: the read scope, the write scope, the operations that need a person’s consent, and the activity log. With MCP each of them has a specific place:
| Decision | Where it lives with MCP | What to ask |
|---|---|---|
| Read scope | The list of functions on the server, plus a check on every use of which data and fields that person may read | Does the server check permissions to specific data, for reads as well? |
| Write scope | Separate write functions, checked by the server every time they are used | Is a read function really unable to change anything? |
| A person’s consent | The AI app — provided it asks the user before a function is used — plus an approval queue in your process | Does your AI app ask for consent, and can that be enforced? |
| Activity log | A log on the server and, if there is one, in the AI app | Where is the log, who can access it and how long is it kept? |
Two points worth knowing before you talk to a supplier. First, consent. The security principles in the specification say the user is to consent explicitly to data access and to the use of functions, and the specification recommends that a person should always be able to refuse the use of a function and that the app should ask for confirmation. At the same time it states openly that the protocol itself cannot enforce this — the specific AI app does (or does not). In the OpenAI API, for example, approval before data is shared with an MCP server is required by default, but it can be switched off. That is why, in the solutions we build, operations that cannot be undone also wait for approval by a person on your side within the process itself, not only in the app’s pop-up.
Second, access passes. This mechanism is optional in the specification. For servers an app connects to over a network, the specification recommends basing it on the draft OAuth 2.1 standard — a widely used way of issuing passes. When it is switched on, the server is to accept only tokens issued specifically for it and not pass them on (authorisation rules). So in a proposal you need to check whether the supplier has implemented it at all. If the AI app communicates directly with a server running as a local program, the specification recommends obtaining its access details from the settings supplied when that program starts — and then the question “who stores the access details” applies to each such place separately. A separate matter is the access details the server uses to connect to your system: that is not the same pass as the one for the server itself. The specification also recommends that the AI app log the use of functions, but the server you are buying should keep its own log — otherwise the activity log depends on which AI app happens to be chosen.
Three risks when granting access through MCP
1. Writing from day one. Reading needs limits too, because it can expose confidential data. Writing additionally lets something in your system be changed or broken. What to ask: does the first version only read, or prepare suggestions for approval — and after which test results is writing switched on?
2. Who wrote the server and who runs it. The server works with the permissions you give it, so you are trusting its author. The specification says a server’s claims about how a function behaves — for example, that it “only reads” — are to be treated as untrusted unless they come from a trusted server. OpenAI says plainly that it does not verify third-party servers and recommends connecting only to trusted ones, preferably official servers run by the vendor; in the Claude Code documentation Anthropic tells users to verify they trust a server before connecting it. What to ask: is this the system vendor’s server, the supplier’s, or a free one from the internet — and who updates it?
3. Hidden instructions in the data. Content a function returns — a product description, a customer’s email, a document — can contain a sentence pretending to be an instruction for the AI, such as “send this data to this address”. This is called “prompt injection”. What to ask: is content from your systems treated as data rather than instructions, and is there a test for it in the acceptance list?
When MCP is overkill
The simplest test: is the order of steps fixed, and does the process involve one system? If yes — fetch a new order from the sales system, ask the model to check the items, ask a person to approve, save the result in the same system — you do not need an MCP server. An ordinary step in an automation tool such as n8n, which connects to your system through its API, is enough. It usually takes less work, is easier to test and is easier to understand for whoever takes over maintenance. We recommend the same on the AI agents page: start with automation, and reach for an agent when the rules become too many.
An MCP server starts to make sense when at least one of two conditions is met:
- the model has to choose for itself among several functions, because what to do in the second step depends on what it found in the first;
- the same functions are to be available in several AI apps, for example in a staff chat and in an agent working in the background.
Nor do you have to choose once and for all: n8n can both expose its workflows as MCP functions and use other MCP servers. You start with ordinary automation and add the server when one of the conditions is met. How we compare MCP with the other ways of connecting AI to systems is shown in the article on connecting AI to business management (ERP) and customer management (CRM) systems: AI integration with ERP and CRM.
What an agent with MCP access adds to the AI systems register
If you keep an AI systems register in your company — an inventory that helps you prepare for the duties under the AI Act, the EU regulation on artificial intelligence — it is worth adding three things to the entry for an agent that uses an MCP server: the list of functions it can access; which of them write data; and where the activity log is. The list tells you what the agent has access to; the activity log shows what it actually did — provided it records the information you need and is kept long enough. Which AI Act duties apply to your system is for a lawyer to determine; how we turn them into concrete changes in your systems is described under the AI Act technical compliance sprint.
Five questions for a supplier who says “we have MCP”
- Who wrote the MCP server, who runs it and who will update it?
- How does the server confirm identity? Who stores the pass to the server, and who stores the server’s access details for your system — and whose account grants and revokes each of them, before handover and after?
- Do the functions only read by default, with writing needing a person’s approval?
- Is content returned by the functions treated as untrusted, and is there a test for it?
- Where is every use of a function recorded — on the server, in the AI app, or in both?
General questions worth asking any AI supplier — about the data processing region, training models on your data or the data processing agreement — are collected on the page on security and GDPR. If you are still wondering whether you need an agent at all, rather than a simpler chat, see the comparison of an AI agent and a chatbot.
What next
If you have a system with an API and a concrete idea — an AI assistant or agent is to do something in it — start with one use case, one AI app and functions that only read at first. On the page on connecting an AI assistant to your system (MCP) we describe the scope we start from and what we check at acceptance.
Tell us about your system and what the AI should do in it. We will tell you whether an MCP server is needed or ordinary automation is enough — including when that means a smaller project.