What is MCP, and what does it actually solve?
MCP, the Model Context Protocol, is an open protocol that describes in one uniform format which tools and data sources an AI agent can reach. The benefit is organisational: you write the integration once, and any model or agent framework can use it afterwards. What it does not solve: authorisation, data quality, and the question of whether the agent should be allowed to write at all.
The starting problem is simple arithmetic. Wire four models to five internal systems and you maintain twenty integrations. Put an MCP server in front of each system and you maintain nine: five servers and four client configurations. That is the whole promise. Not more than that, but not nothing either, because each of those twenty integrations would carry its own authentication, its own error handling and its own logging.
−98.7%
token use on a Drive-to-Salesforce copy task when the agent runs code over MCP: 2,000 tokens instead of 150,000
Anthropic, 2025-11-04
41%
share of software companies running MCP in limited or broad production
Stacklok, 2026-01 (quoted from a secondary source)
2026-07-28
date of the current MCP specification: stateless core, protocol-level human approval, header-based routing
modelcontextprotocol.io
Anthropic released MCP in November 2024, and in December 2025 it went to the Agentic AI Foundation under the Linux Foundation, so governance is now vendor-neutral. I think that matters, but I would not call the question settled: one year of vendor-neutral stewardship does not make a protocol a standard in the way SQL or HTTP are standards. If you build on MCP today, build so that the business logic behind the server stays usable on its own.
Why is connecting AI to business systems hard the traditional way?
Three reasons keep coming back. Every integration is a bespoke piece, because every model and every framework describes tools differently. The permissions of the signed-in user do not carry over to the agent, since the agent typically runs under its own technical account. And there is no single audit trail showing which human triggered which operation through the machine intermediary.
Every integration is a bespoke piece
A tool definition on its own is not complicated. The trouble starts with everything around it: authentication, rate limit handling, retries, translating error messages, schema versioning. All of it gets rewritten in each integration, slightly differently each time. A year later nobody can tell you which of the six partner-lookup implementations filters by business unit and which does not.
Permissions do not carry over
This is the part people underestimate most. Business systems have accumulated a permission model over years, and the agent walks around it with one technical account. From that point on, access is protected by the chat interface, which is not access protection. The OWASP LLM list puts it precisely: the system prompt is neither a secret nor a security control, and authorisation belongs in a deterministic system.
There is no audit trail
If the log says the integration user modified a record, you have nothing to show in a dispute. You need the real user identifier, the name of the tool called, the parameters, the response and the model version. Compliance aside, debugging stands or falls on this, because there is no other way to reconstruct what happened.
| Question | Per-model bespoke integration | MCP layer |
|---|---|---|
| Introducing a new model | every tool has to be rewired | client configuration changes, the server stays |
| Authentication | solved separately in each integration | in one place, in front of the server |
| Logging | scattered, in varying formats | one entry point, one format |
| Tool inventory | spread across the codebase | a listable, versionable tool catalogue |
| Authorisation | not solved | not solved either, only concentrated in one place |
How does an MCP server work in practice?
The agent is the client, and the process placed in front of the business system is the server. A server publishes three kinds of thing: tools (executable operations with a JSON schema), resources (readable content addressed by URI) and prompts (server-side templates). The model reads the tool descriptions and decides from them what to call. So a tool description is part of the prompt, not documentation.
A tool is basically a function with a name, an input schema and a human-readable description. The schema is what keeps the model from producing free text instead of a parsable call. Here is a real, deliberately narrow read tool sitting in front of an ERP:
{
"name": "stock_availability",
"description": "Returns the current free stock of one SKU in one warehouse. Returns only warehouses the calling user is entitled to see. Does not return prices and does not return partner data.",
"inputSchema": {
"type": "object",
"properties": {
"sku": { "type": "string", "pattern": "^[A-Z0-9-]{3,24}$" },
"warehouse_code": { "type": "string", "enum": ["BUD01", "BUD02", "VIE"] }
},
"required": ["sku"],
"additionalProperties": false
}
}Four things in there are deliberate. The name describes a business operation rather than table access. The description states what the tool does not return. The schema narrows the input with a regex and an enum, so the model cannot send arbitrary values. And additionalProperties: false stops a creative call from smuggling extra fields in.
Tool, resource or prompt: which one when
Mixing up the three primitives is the most common design mistake. A tool does something, a resource is readable content, a prompt is a template stored on the server. If you turn everything into a tool, the model has to make a call for every small piece of data, and the number of calls is what drives cost and latency.
| Primitive | What it means | Business example | When to pick it |
|---|---|---|---|
| Tool | parameterised operation with a JSON schema, called by the model | stock_availability, quote_draft_create | when the answer depends on parameters, or when something happens |
| Resource | readable content addressed by URI, loaded by the client | current price list, terms of service, invoice data pulled from the tax authority | slow-moving reference material that does not need searching |
| Prompt | server-side template with a fixed structure | the steps of building a quote, the flow of a complaint investigation | when you want to dictate the sequence, not the model |
What the 28 July 2026 specification brought
| Change | Why it matters in an enterprise setting |
|---|---|
| Stateless protocol core | every request is self-describing, so it goes behind a plain load balancer and scales without shared state |
| Multi Round-Trip Requests (MRTR) | the server can return an input_required response and the client resumes, which moves human approval to protocol level |
| Header-based routing (Mcp-Method, Mcp-Name) | your existing API gateway and WAF can decide from the header instead of parsing a JSON body |
| Authorization hardening | mandatory RFC 9207 issuer validation, and Client ID Metadata Documents in place of dynamic client registration |
| Enterprise Managed Authorization (EMA) | an extension that points towards SSO-bound, centrally managed access |
| Tier 1 SDKs | TypeScript, Python, Go and C# straight away, Rust in beta, which covers most enterprise stacks |
The 2026 roadmap treats audit trails, SSO-integrated authentication and gateway behaviour explicitly as extensions rather than parts of the protocol core. That is an honest position from the maintainers, but for you it means part of your enterprise requirements is still yours to build.
Which tools should an MCP server expose in front of an ERP?
Few of them, named individually, with reads sharply separated from writes. In practice it is worth running two servers: a reader that a wide group can use, and a writer that knows a handful of operations behind separate authentication and an approval step. A tool should always be a business operation, never raw database access. That is the most important rule in this article.
| Tool | Type | Who can call it | Control |
|---|---|---|---|
| stock_availability | read | any signed-in user | the caller warehouse entitlement |
| partner_search | read | sales, finance | masked bank account number, no bulk export |
| open_invoices | read | finance | only partners in the caller business unit |
| quote_draft_create | write, reversible | sales | draft state, a human does the sending |
| delivery_note_post | write, hard to reverse | warehouse manager | approval, idempotency key, daily volume cap |
| sql_query | do not expose | nobody | there is no business question that justifies it |
| partner_delete | do not expose | nobody | deletion stays a human action in its own interface |
Four rules that matter over time
- A tool should map to a business operation. If its name is a table or a technical concept, the level is wrong, and the model has to supply business knowledge it does not have.
- Keep the return value narrow. Do not hand back the whole record, only the fields that are needed. This is a token cost question and a data protection question at the same time.
- Leave no universal escape hatch. A single
executeorrun_querytool undoes every other restriction you put in place. - Keep the tool count low. Every tool description goes into the prompt on every call. With sixty tools you pay for those descriptions on each question asked.
If the task moves a lot of intermediate data, look at the code execution pattern: instead of chaining separate tool calls, the agent writes code that uses the MCP servers as an API, and the filtering happens inside the sandbox. In the Anthropic measurement, a Drive-to-Salesforce copy task went from 150,000 tokens to 2,000 this way. It does not fit every job, but for data movement the difference is an order of magnitude.
How do the permissions of a user carry over to the agent?
By having the tool call run under the identity of the end user rather than a shared technical account. In practice that means passing the token of the signed-in user through to the backend system, on-behalf-of style. Without it your permission model drops out of the picture, and the agent becomes the highest-privileged user in the company.
Look closely at what happens in the service account trap. The agent reads with one technical account that has rights to everything, because that was the quickest way to get started. From then on, financial data is protected by the fact that the marketing team does not know what to ask for. That is not a control. And the audit log records that the integration user queried the customer master, which is useless in a data protection investigation.
| Model | How it authenticates | What the audit log shows | When it is acceptable |
|---|---|---|---|
| Service account | one technical user, every call runs as that user | the technical account name, never the real person | internal prototype with no live data |
| User token pass-through | the token of the signed-in user, on-behalf-of | the real user and the tool that was called | this should be the default in production |
| Mixed | reads with the user token, writes with a narrowly scoped technical account | both the initiator and the approver | when the backend cannot do on-behalf-of authentication |
The security part your client will raise in the meeting
Rightly so. Tool descriptions are read by the model itself, so hidden instructions can be planted in them, which is tool poisoning. The 2026 paper introducing the MCPTox benchmark found that most of the seven MCP clients examined perform inadequate static validation. On top of that, unauthenticated MCP Inspector instances allowed arbitrary command execution (CVE-2025-49596, CVSS 9.4).
The defence is architectural rather than content filtering. As Simon Willison frames it, an agent becomes exploitable when three capabilities are present at once: access to private data, exposure to untrusted content, and the ability to communicate outwards. Remove any one leg and the attack does not close. So it is worth putting the write tools and the outbound tools into an agent that does not read incoming email or web content.
When should an AI agent get write access to a production system?
When the operation is narrowly defined, its effect is measurable, and five controls hold together: human approval on irreversible steps, a hard-coded value and volume limit, a reversible intermediate state, an idempotency key on every call, and a full audit log. If any one of those is missing, keep the agent read-only.
| Operation | Reversible? | Required control |
|---|---|---|
| Creating a quote draft | yes | user permission is enough |
| Posting a stock movement | partly, the reversal leaves a trace | idempotency key, daily volume cap |
| Issuing an invoice | no, the tax report has already gone out | human approval, value limit |
| Initiating a payment | no | human approval, four-eyes rule |
| Message sent to a customer | no | approval or a strict template, plus disclosure that AI is involved |
| Deleting master data | no | do not build a tool for it, leave it in its own interface |
Idempotency: the cheapest control, and the one most often skipped
Agents run loops, and loops retry. If the network drops the response after a successful write, the next round fires the same operation again. So every write tool should take a client-generated key, and the server should return the first result for that key without creating a new record. Without it you will eventually get two identical delivery notes, with no clear answer about which run produced them.
Approval: where it actually lives
At protocol level, the MRTR mechanism in the 28 July 2026 MCP spec provides it: the server sends an input_required response and the client resumes with the approval, without holding a connection open. At framework level, the LangGraph pairing of interrupt() and Command(resume=...) does the same with a durable checkpoint, so the approval can arrive the next day. The point is that approval should be enforced in code, not asked for in the prompt.
Keep the content of the audit log fixed: who initiated it, which tool ran, with which parameters, what came back, which model and which prompt version made the decision. Tracing tools give you this per run; we wrote about choosing between them in our Langfuse and LangSmith comparison. For anything that reaches customers, remember that the transparency obligations under Article 50 of the EU AI Act have applied since 2 August 2026, so you have to disclose when an AI is answering.
What if the system has no usable API?
For reads, build a read replica and have the server read views rather than tables. For writes, use the vendor import routine over a file exchange, which keeps ERP validation where it belongs. RPA is the last resort, not the first idea. This is not theoretical on the legacy end of the market: exPanda, to name one Hungarian example, is a Windows desktop client on a Firebird database, where the database is the integration entry point.
| Route | What it is good for | What the risk is | When to pick it |
|---|---|---|---|
| Read replica and views | fast reads that do not load the production system | the schema changes quietly and the view breaks in silence | when you only need reads |
| File-based exchange | writes through the vendor own import routine | latency, and it is hard to get feedback on failures | when the ERP has import and export functions |
| RPA, screen automation | writes even when nothing else exists | every UI change breaks it, and there is no idempotency | when there is no API and no import, and the process is still worth it |
A view is a contract here. If the MCP server reads tables directly, you are the one explaining yourself after the first ERP upgrade. If it reads through views, the view definition becomes the interface you version, test and document. The same holds for file-based writes: the file format is the contract, and the processing result has to be readable back, otherwise the agent is working blind.
My view on RPA is firm: it works, and it is the first thing that breaks at two in the morning, with nothing in it to protect you from duplication on retry. If it is the only option left, put it in its own agent, give it a daily operation limit, and capture a screenshot of every run into the log. We covered the migration and parallel-running questions in more depth on our system integration page.
What does an MCP layer cost, and what has to be operated?
The build sits in our process automation band: a multi-system integration with error handling runs 500,000 to 2,500,000 Ft, roughly EUR 1,300 to 6,500 at 385 HUF per EUR. Complex AI-driven automation with an approval flow runs 2,500,000 to 10,000,000 Ft, about EUR 6,500 to 26,000. Operations are 30,000 to 150,000 Ft a month, about EUR 78 to 390.
| Item | Order of magnitude | Note |
|---|---|---|
| Read-only MCP server with 5 to 10 tools | 500,000 – 2,500,000 Ft (EUR 1,300 – 6,500) | multi-system integration with error handling, AppForge price list |
| Write tools with approval and audit log | 2,500,000 – 10,000,000 Ft (EUR 6,500 – 26,000) | the complex, AI-driven automation band |
| Operations | 30,000 – 150,000 Ft/month (EUR 78 – 390) | monitoring, schema updates, bug fixes |
| Observability (tracing) | 0 licence cost with self-hosted Langfuse | in the cloud, Langfuse Core is USD 29/month and LangSmith Plus USD 39/seat/month, with 14-day base retention |
| Model cost | Claude Sonnet 5: USD 2 per 1M input tokens | every tool description is an input token on every call |
Two items tend to surprise people on the operations side. One is schema change in the backend system, which never announces itself in advance. The other is cost control: a monthly budget ceiling is not protection, because it fires after the fact, and the run that overspent has already finished. What you need is a per-run token or dollar ceiling in real time, with a step limit and a timeout. The TechCrunch piece from June 2026 reports that Uber had burned its entire annual AI coding budget by April. That is not an MCP problem, but it shows how quickly a system running in a loop can get away from you.
When should you not use MCP?
If you are wiring one system to one agent and the branches of the process can be drawn in advance, MCP is a layer you do not need. A direct API client has fewer moving parts: no extra process, no extra authentication, no extra version dependency. MCP starts paying off when several consumers use the same data, or when model independence and central logging become requirements.
| Situation | What to use | Why |
|---|---|---|
| One system, one agent, a fixed process | direct API client or SDK | MCP here is an extra process and an extra failure mode |
| Branches that can be drawn in advance | a workflow with LLM calls | this is also what Anthropic recommends; the workflow usually wins |
| No evals, no measurement | measurement first, integration second | without it you never find out when the system starts degrading |
| Two or more consumers on the same data | MCP layer | this is where the M plus N arithmetic pays off |
| Model independence or an audit requirement | MCP layer | access can be logged and swapped in one place |
It is worth putting the numbers next to that. The Gartner forecast from 25 June 2025 says more than 40% of agentic AI projects will be cancelled by the end of 2027, typically over cost, unclear business value or inadequate risk management. The MIT Project NANDA survey from summer 2025 found that 95% of enterprise generative AI pilots produced no measurable P&L impact. The same research measured a 67% success rate where an internal expert and an external partner worked together, against 22% for projects built by internal IT alone.
What follows from that, for me, is that the integration layer question cannot be decided on its own. With no measurable goal and no measurement, your choice of protocol will be the smallest of your problems. We wrote separately about choosing between an agent, a chatbot and a workflow in our agent, chatbot, RPA and n8n comparison, and about the rollout steps in AI integration into existing systems.
Summary and frequently asked questions
What is MCP (Model Context Protocol)?
An open protocol that lets an AI agent reach external tools and data sources through one uniform interface. It is a client-server model: the agent is the client, and an MCP server placed in front of a business system publishes tools, resources and prompts. The goal is to turn an M models by N systems integration matrix into M plus N.
What does MCP not solve?
Authorisation, data quality and business logic. MCP describes that a tool exists and what parameters it expects, but it does not say whether this particular user may call it. If your master data is wrong, it stays wrong over MCP. Security control lives behind the server, not in the protocol.
Can an AI agent get write access to a production ERP?
Yes, but only for narrow, named operations, and only with five controls in place: human approval on irreversible steps, a hard-coded value limit, a reversible intermediate state such as a draft, an idempotency key on every write call, and a full audit log. Never expose a generic SQL tool or a delete tool. Approval also exists at protocol level in the 28 July 2026 MCP specification.
What is the service account trap?
It is when every agent call runs under a single technical account. Anyone who can reach the agent effectively sees whatever that account sees, your permission model is bypassed, and the audit log records the technical user instead of the real person. In production, passing the user token through (on-behalf-of) should be the default.
What do I do if the system has no API?
Three routes, in this order. For reads, a database read replica, with the server reading views rather than tables. For writes, the vendor import routine over a file exchange, so ERP validation stays in place. RPA is the last resort: any UI change breaks it, and it has no idempotency.
What does an MCP integration layer cost?
In our price list a multi-system integration with error handling runs 500,000 to 2,500,000 Ft, roughly EUR 1,300 to 6,500 at 385 HUF/EUR. Complex AI-driven automation with an approval flow runs 2,500,000 to 10,000,000 Ft, about EUR 6,500 to 26,000. Operations are 30,000 to 150,000 Ft a month, about EUR 78 to 390. Model cost is usually small next to that, as long as the number of tools stays under control.
When is MCP unnecessary?
When you are wiring one system to one agent and the branches of the process can be drawn in advance. A direct API client has fewer moving parts then: no extra process, no extra authentication, no extra failure mode. MCP starts paying off when two or more consumers use the same data, or when model independence and central logging are requirements.
Is it safe to use an MCP server?
Only if you know what is running on it. Tool descriptions are read by the model itself, which makes them an attack surface: against tool poisoning, the MCPTox benchmark found that most clients perform weak static validation. Do not let a third-party public MCP server near company data. Run your own, with an allowlist and logging.
If you have an ERP or a CRM and you are working out what to let an agent do with it, our process automation page shows how we usually build this, and the RAG knowledge base article covers the search side that tends to run alongside MCP tools. Or book a 30-minute call and we will go through your actual systems.
Sources
- Model Context Protocol: the 28 July 2026 specification release (stateless core, MRTR, header routing, EMA)
- Model Context Protocol: 2026 roadmap and governance (Agentic AI Foundation, Linux Foundation)
- Anthropic: Code execution with MCP, from 150,000 tokens to 2,000 (2025-11-04)
- Anthropic: Building Effective Agents, choosing between a workflow and an agent (2024-12-19)
- MCPTox: a tool poisoning benchmark for MCP clients (arXiv 2603.22489)
- MCP security overview, CVE-2025-49596 (CVSS 9.4)
- Simon Willison: the lethal trifecta (2025-06-16)
- OWASP LLM01:2025 Prompt Injection: the system prompt is not a security control
- NAV Online Invoice 3.0 interface: queryInvoiceDigest and queryInvoiceData
- exPanda: Windows desktop client and Firebird SQL server (system requirements, retrieved 2026-08-14)
- Langfuse pricing: self-hosted under the MIT licence, Core USD 29/month
- LangSmith pricing: Plus USD 39/seat/month, 14-day base trace retention
- Anthropic official price list: Claude Sonnet 5 input USD 2 per 1M tokens
- Gartner: over 40% of agentic AI projects will be cancelled by the end of 2027 (2025-06-25)
- MIT Project NANDA: The GenAI Divide, State of AI in Business (2025-07)
- TechCrunch: the token bill comes due, with the Uber and Priceline examples (2026-06-05)
- Summary of MCP adoption figures, including the Stacklok 41% data point (secondary source)
- EUR-Lex: Regulation (EU) 2026/1744, the Digital Omnibus on AI
