MCP (Model Context Protocol)

1. Introduction: why is everyone talking about MCP right now?

The first big wave of AI was conversation. The user typed a question, the AI answered. That alone was impressive. Suddenly a machine could summarize reports, write emails, explain legal text and suggest marketing campaigns.

But it quickly hit a wall. The AI didn't know what was happening in the company's CRM. It couldn't see the tickets in project management. It couldn't reach internal documents, calendars, databases, customer data or developer tools — at least not in a controlled way.

Back then, AI was like a brilliant consultant sitting blindfolded in a meeting room. It could think, but it couldn't see the company's reality.

MCP, the Model Context Protocol, aims to solve exactly this problem. It is an open standard that lets AI applications connect to external tools, data sources and systems in a consistent way. Anthropic introduced MCP in November 2024 as an open standard designed to build secure, two-way connections between AI tools and data sources.^[1]

That's why MCP is often compared to a USB-C connector for AI. The analogy is good, but slightly dangerous. USB-C sounds harmless: plug in the cable and the device works.

With MCP, it's not just about a connector. It's about who gets to use company data, with what permissions, in which situations and under whose responsibility.

2. What does MCP, the Model Context Protocol, mean?

MCP, the Model Context Protocol, is an open protocol that lets AI applications connect to external systems. In plain terms: MCP is a common language between AI and tools.

Without MCP, every AI application needs its own separate integrations with every system. One integration for Google Drive. Another for Slack. A third for GitHub. A fourth for the company's own database. A fifth for the CRM. A sixth for the calendar. This quickly turns into integration spaghetti.

The idea behind MCP is simple: build a common interface through which an AI application can discover and use tools, data sources and ready-made workflows. The official documentation describes MCP as an open-source standard for connecting AI applications to external systems.^[2]

If AI is the new interface for work, MCP is one way to give it controlled access to the real systems of the workplace.

The key word is controlled. MCP doesn't mean giving AI free access to everything. Done well, it means the opposite: access, permissions, tools and limits are defined more precisely.

3. What problem does MCP solve?

Above all, MCP solves a context problem. An AI model can be extremely capable, but if it has no access to the right information, it has to guess. It can give general advice, but it may not be able to answer questions like:

Which customers are at risk of churning this quarter?
Which project phase is behind schedule?
Which contracts are due for renewal?
What was decided in the latest board materials?
What code changes were made last night?
Has the customer's complaint already been handled?

These aren't generic questions. They're questions tied to the company's internal reality. MCP aims to close the gap between AI and the company's systems.

Before MCP, developers often had to build custom connectors between every AI application and every data source. When Anthropic announced MCP, it described this problem specifically as a challenge of data silos and fragmented integrations.^[1]

This matters, because in most companies information doesn't live in one place. It's scattered across documents, emails, Slack or Teams conversations, CRMs, ERP systems, project management tools, ticketing systems, data warehouse environments, code repositories, BI reports and people's heads.

The promise of MCP is that AI could use all of this in a more controlled, consistent and secure way.

4. How does MCP work in practice?

MCP is built on a client–server model. The AI application acts as the host. Inside it, an MCP client connects to an MCP server. The MCP server, in turn, gives the AI access to specific tools, data sources or ready-made prompts.

Example 1: A company has an internal document archive. An MCP server is built on top of it. Through MCP, the AI application can query the archive, retrieve relevant documents or run predefined search operations.

Example 2: A developer uses an AI code editor. An MCP server gives the AI access to the project's issues, test results and documentation. Instead of suggesting code out of thin air, the AI sees the project's context.

Example 3: A sales team uses a CRM. An MCP server can give the AI a tool for retrieving a customer's latest contacts, open deals and support requests — but only within the user's own permissions.

So MCP isn't a single application. It's a way to build a connection. A bit like how the power grid isn't a lamp, but the infrastructure that lets the lamp work.

5. The building blocks of MCP: host, client, server, tools, resources and prompts

Host

The host is the AI application the user works with. It might be a chat app, a code editor, an agent platform or the company's own AI tool. The host is the environment where the user says: “Find the latest information on this customer and suggest our next message.”

Client

The client is the component inside the host that connects to the MCP server. Users don't usually think about the client separately — it's a technical middle layer that handles the communication.

Server

An MCP server is a server that gives the AI access to specific capabilities: file search, database queries, calendar functions, project management tasks, CRM lookups, code repository data, or browsing and analysis tools.

Tools

Tools are actions the AI can take: “fetch the customer's details,” “create a calendar invite,” “open a new ticket,” “run an SQL query,” “run the tests,” “send a draft for approval.” A tool is an active function. It can change things in the real world. That's why permissions matter especially for tools.

Resources

Resources are information and context. They can be documents, files, database rows, guidelines or other data the AI can read. A resource doesn't necessarily do anything — it gives the model information.

Prompts

Prompts are ready-made message templates or workflows. A company might, for example, define a ready-made prompt for analyzing customer feedback, drafting a security report or summarizing a sprint retrospective.

The official MCP specification names exactly these as the core capabilities: resources, prompts and tools. Resources provide context and data, prompts provide ready-made message templates and workflows, and tools are the actions available to the model.^[3]

This trio is the core of MCP: information, action, workflow.

6. Why does MCP matter for AI agents?

An AI agent is a system that doesn't just answer questions but can plan, use tools and carry out tasks.

A chatbot answers: “Here's how you could do it.” An agent acts: “I retrieved the data, compared the options, created a draft, requested approval and prepared the next step.”

This is where MCP gets interesting. If an agent is allowed to use tools, it needs to know which tools exist, what they do, with what permissions they may be used, what data they return, what actions they can perform and when a human has to approve an action.

Without this kind of structure, agent development easily becomes the Wild West. MCP offers one way to describe to the AI what it's allowed to do and how it's allowed to do it.

For agents, this is both an opportunity and a risk. An opportunity because AI can finally do useful things in real systems. A risk because a poorly configured agent can do the wrong things quickly, convincingly and with broad access.

AI becomes more useful once it gets hands. But so does the need to make sure it doesn't swing them in the wrong place.

7. The business perspective: AI can't be a standalone chatbot

In many companies, AI adoption starts with enthusiasm. A chatbot gets rolled out. A few training sessions are held. People write better emails. Meeting notes get summarized. Marketing copy gets generated. There are benefits, but often limited ones.

The real productivity leap only happens when AI connects to the core of the work: data, processes and decision-making. This is where MCP can be an important piece.

From a company's point of view, MCP isn't just a technical standard. It's a governance model. It lets you ask:

Which systems can the AI access?
Can it only read data, or also change it?
Can it send messages to customers?
Can it create quotes?
Can it update the CRM?
Can it run code?
Can it run database queries?
When is human approval required?
How is everything logged?

These aren't just IT questions. They're leadership questions. MCP forces a company to think about AI use as a process, not just a tool.

8. The perspective of startups and growth companies

For a startup, MCP can be both an opportunity and a strategic choice. If you're building an AI product, MCP can reduce the burden of building integrations. Instead of creating a separate connector to every system for every customer, you can build an MCP-compatible architecture.

You can tell customers: “We support MCP. If you have an MCP server for these systems, our product can use them in a controlled way.” That sounds minor, but it can be a big advantage in enterprise sales. Enterprise refers to large companies and organizations where purchasing is slower, security requirements are stricter and there are more integrations.

For a startup, MCP can help in three ways:

The product scales better. The same integration model works across more environments.
Customer trust grows. An open standard is easier to justify than a black box.
The ecosystem adds momentum. If MCP becomes widespread, compatibility can become a selling point.

But a startup needs to be careful. It's not enough for a product to “support MCP.” You also have to be able to explain how permissions, logging, security, auditing and human approval work. A business customer doesn't just buy a feature. It buys risk management.

9. The developer perspective: less integration spaghetti, more control

For developers, MCP's promise is tempting. Instead of every AI tool building its own way to use databases, files, APIs and developer tools, MCP offers a common model.

An API is an application programming interface: a way for programs to talk to each other. MCP doesn't remove the need for APIs, but it can make them easier for AI to use.

A developer can build an MCP server that packages a complex system into tools the AI can understand. For example, a database doesn't have to look to the AI like a chaotic jungle of tables. Instead, the MCP server can offer scoped tools:

“fetch the customer's active contracts”
“list open support requests”
“show the latest invoices”
“calculate utilization for the last 90 days”

This matters, because you shouldn't give AI raw access to everything. A good MCP server isn't just a pipe to the data. It's an interpreted, scoped and secure interface to the system.

10. Practical examples: what could MCP do day to day?

Example 1: Preparing for a management team meeting

The CEO asks: “Prepare a status overview for tomorrow's management team meeting. Go through the sales figures, customer feedback, recruiting status and open risks. Draft a concise agenda.” Through MCP, the AI can pull information from the CRM, project management, the HR system and documents. A good implementation doesn't let the AI send anything automatically — it creates a draft that a human approves.

Example 2: A salesperson preparing for a customer meeting

A salesperson is heading to a meeting. Through MCP, the AI retrieves the customer's latest interactions, open quotes, support requests, contract history, news about the customer and earlier notes. The result: “Three things worth paying attention to in the meeting.” This is no longer just text generation — it's assembling the context of the work.

Example 3: A developer's workday

A developer asks: “Find out why the integration tests failed in the overnight run. Look at the latest commits, test logs and open issues. Suggest a fix.” MCP servers can connect the AI to GitHub, the CI/CD system, the logging service and documentation. CI/CD refers to software development automation in which code changes are tested and deployed to production in a controlled way.

Example 4: Customer service

A customer service agent asks: “What's this customer's situation and how should I respond?” The AI retrieves the customer's order, earlier messages and delivery status. It suggests a reply but doesn't send it without a human. This is where MCP's permission model is decisive: the customer service agent may only see the data they would otherwise have access to. The AI must not become a back door to information the user shouldn't see.

11. MCP and security: where can things go wrong?

MCP's greatest strength is also its greatest risk: it gives AI access to external systems. If that access is poorly scoped, the problems can be serious.

Research and security analyses have highlighted risks in the MCP ecosystem, such as malicious servers, tool manipulation, leakage of sensitive data and poorly maintained community servers. One large study analyzed 1,899 open-source MCP servers and found both common vulnerabilities and MCP-specific risks, such as tool poisoning issues.^[4]

Tool poisoning refers to a situation where a tool offered to the AI, or its description, has been manipulated so that the model misuses it or discloses information. Another study examined hosts, registries and servers in the MCP ecosystem and highlighted, among other things, that malicious servers can manipulate the model's behavior and cause sensitive data to leak.^[5]

MCP doesn't make AI secure on its own. It provides a structure. Security comes from how that structure is implemented.

Key risks

1. Overly broad permissions — the AI is given access to “everything, just in case.”

2. Insufficient approval controls — the agent can make changes without human confirmation.

3. Poorly described tools — the model doesn't understand what a tool actually does.

4. Malicious MCP servers — a server downloaded from the community may contain risky or deliberately malicious behavior.

5. Lack of logging — afterward, no one knows what the AI did, with what data and on whose behalf.

6. Prompt injection — an external document or web content may contain instructions that try to manipulate the AI into behaving incorrectly.

Prompt injection is an attack in which hidden or misleading instructions are fed to the AI, for example through a document, a web page or data returned by a tool.

When AI only has a conversational role, prompt injection can lead to a wrong answer. When AI has access to tools, the same attack can lead to a wrong action. That's a huge difference.

12. Governance, access rights and human approval

In business use of MCP, the most important question isn't: “What can we connect AI to?” The more important question is: “What should we connect AI to, with what permissions and under what oversight?”

A good starting point is to divide permissions into four levels.

Level 1: Read access to public or low-risk information

For example, guidelines, product documentation, public price lists or internal process descriptions. This is usually the safest place to start.

Level 2: Read access to internal business information

For example, CRM data, project status, financial reports or customer data. This requires user-specific permissions and logging.

Level 3: Limited write access

For example, adding notes, creating drafts or opening a ticket. Human approval is often sensible here.

Level 4: Critical actions

For example, sending a contract, initiating a payment, releasing production code, sending a customer message or changing user permissions. For these, human approval should be the default, not the exception.

MCP's official authorization specification covers how MCP clients can make requests to restricted MCP servers on behalf of resource owners, particularly over HTTP-based transports.^[6]

In practice, this means a company has to design identity, permissions and approval paths properly. It's not enough that the AI “knows how to use the tool.” You need to know whether this particular user, in this particular situation, for this particular purpose, is allowed to use it.

13. MCP as part of a bigger shift: from chatbot to a digital colleague that gets work done

MCP points to a bigger shift in AI. The first phase was content creation: AI wrote, summarized and translated. The second phase was information retrieval and analysis: AI started helping people understand documents, data and decisions. The third phase is action.

AI no longer just tells you what could be done. It can do part of the work. This changes companies' AI strategy. It's no longer enough for an organization to ask: “Which AI tool should we use?” It has to ask: which work processes will change, what data does the AI need, which systems will it connect to, which tasks will be automated, where does a human remain the decision-maker, how are errors detected, and who is responsible if the agent acts wrongly?

This is very similar to the early days of cloud services. At first, the cloud was “just a new way to host servers.” In the end, it changed software development, cost structures, security, procurement and the whole of IT management.

MCP may be a similar infrastructural shift in the world of AI. Not necessarily the most visible part, but one of the parts that a lot of other things are built on.

14. The future: where is MCP heading?

MCP's future isn't settled yet. The standard is young, the ecosystem is growing fast and practices are still taking shape. Even so, a few directions look likely.

1. MCP becomes part of enterprise AI architecture

Companies don't want dozens of disconnected AI integrations. They want a manageable way to connect AI to their systems. MCP can serve as one layer here — not necessarily the only one, but an important one.

2. MCP gateways become common

A gateway is an intermediate layer that traffic passes through. A company can build an MCP gateway that handles user authentication, permissions, logging, tool approval, security rules and data filtering. This is the likely direction for enterprise use.

3. Certified and trusted MCP servers gain value

As MCP servers multiply, quality varies. Companies can't install just any server they find on GitHub in a production environment. They need trusted, audited and maintained servers.

4. Human approval gets built into workflows more effectively

The agent of the future won't ask permission for every little thing, because that leads to approval fatigue. But it mustn't act freely either. A good model is risk-based: low-risk tasks automatically, medium-risk tasks with approval, critical tasks always by human decision.

5. MCP converges with RAG, knowledge graphs and enterprise search

RAG, or Retrieval-Augmented Generation, is an approach in which AI first retrieves relevant information and then builds its answer on it. MCP doesn't replace RAG — they complement each other. RAG helps find the right information, MCP helps use tools and systems, and knowledge graphs can help describe how things relate to each other. Tomorrow's enterprise AI isn't a single model. It's an entire architecture.

15. Conclusions: why understand MCP even if you're not a developer?

MCP sounds technical. And partly it is. But its significance isn't limited to developers.

For a leader, MCP raises the question: how do we connect AI to the company's processes safely? For an entrepreneur, it's an opportunity to build products that integrate more easily with customers' systems. For an expert, it means AI may soon do much more than write text. For IT management, it's a new governance layer. For security, it's a new attack surface.

And for the organization as a whole, it means AI becomes less of a standalone assistant and more a part of the infrastructure of work.

MCP's most important promise: AI can get closer to real work.

MCP's most important warning: when AI gets closer to real work, its mistakes get closer to real consequences.

That's why MCP shouldn't be seen as just a technical standard. It should be seen as a new agreement between people, AI and the organization's systems.

16. Practical models and templates for companies

1. The beginner's MCP model

If your company is just getting started, don't begin with your most critical systems. Start like this:

Pick one low-risk use case.
Give the AI read-only access.
Scope the data sources tightly.
Add logging.
Test with a small group of users.
Collect the errors, misunderstandings and most useful ways of using it.
Only then should you expand.

A good first target might be an internal knowledge base, product documentation or a project status overview. A bad first target is payments, production code releases or automatically sending customer contracts.

2. The MCP permissions matrix

Assess every MCP connection with two questions: (1) Can the AI only read, or also act? (2) Is the data low-risk or critical?

Read + low-risk data (e.g., internal guidelines) → a good place to start
Read + critical data (e.g., customer data, financial data) → user-specific permissions and logging
Action + low-risk process (e.g., drafting a ticket) → human approval at first
Action + critical process (e.g., contracts, payments, production changes) → strong approval and auditing

3. An MCP checklist for leadership

Before rollout, ask: What business problem are we solving? Why is MCP better for this than a traditional integration? Which systems does the AI need? What data can it read? What actions can it perform? Whose permissions does it act under? How is usage logged? How are errors detected? At what point does a human approve the action? Who owns the risk?

If these questions don't have answers, the MCP project isn't ready for production yet.

4. An MCP template for teams

Fill this in before your first pilot:

Use case: What is the user trying to do?
User group: Who will use the solution?
Systems: Which systems will MCP connect to?
Data: What information can the AI read?
Tools: Which actions can the AI use?
Restrictions: What must the AI not do?
Approval: At what point does a human decide?
Logging: What gets recorded?
Risks: What could go wrong?
Success metric: How will we know the pilot was worth it?

5. A good MCP pilot

A good pilot is scoped, measurable and safe. Example: “We'll build an MCP connection to our internal product documentation and customer service guidelines. The AI may search for information and suggest replies to customer service agents, but not send messages to customers. All searches and suggestions are logged. The pilot runs for four weeks.”

There's a lot that's good here: a clear use case, scoped data, no automatic external actions, a human approves the reply, and the impact can be measured.

6. A bad MCP pilot

“Let's connect AI to all our systems and see what benefits we get.” It sounds fast, but in reality it's risky: the use case is unclear, permissions balloon, security becomes an afterthought, success can't be measured, and users don't know what the AI has access to.

With AI, “let's see what happens” is a bad strategy if your systems contain real customer data, money, contracts or production environments.

7. The advanced user's MCP model

Once the basics are in place, a company can build a broader governance model around MCP: a centralized MCP gateway, a registry of approved servers, user-specific permissions, tool-specific risk classes, logging and auditing, prompt injection protections, automated tests for MCP servers, regular security assessments, human approval for critical actions, and clear ownership between the business, IT and security.

That sounds heavy, but it's exactly what separates an experiment from a production-ready enterprise solution.

8. A practical tip in one sentence

If you're building an AI solution for a company, don't just ask: “What can we connect AI to?”

Ask: “What can the AI see, what can it do, on whose behalf — and at what point must a human stop or approve the action?” That's the real core of MCP.