MCP After the Hype: How to Use It Well in a Real Company
MCP has become a key standard for connecting AI agents with tools and data. But using it correctly requires permissions, a tool catalog, logs, internal servers, and clear security criteria.
The Model Context Protocol, or MCP, quickly transitioned from being a technical novelty to becoming a central piece of the agent ecosystem. Anthropic introduced it in November 2024 as an open standard for connecting AI assistants with data, tools, and work environments. In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, with support from companies like OpenAI, Google, Microsoft, AWS, Cloudflare, and Bloomberg.
The leap is significant: MCP is no longer just "a way to connect Claude to your data." It is a common infrastructure for agents from different platforms to access external systems.
But precisely because of this, it must be used with care. A poorly configured MCP server can turn a useful agent into an operational risk.
What MCP Solves
Before MCP, every integration between a model and a tool required specific code. If you wanted to connect an assistant to Google Drive, Notion, GitHub, Slack, a CRM, and a database, you ended up building distinct connectors for every case.
MCP proposes a common pattern:
- The agent speaks a standard protocol.
- Each tool exposes an MCP server.
- The agent discovers which tools exist.
- The agent requests data or executes actions through that server.
Anthropic described it as a kind of universal connector for AI. The analogy is useful, but incomplete: in a real company, simply plugging things in is not enough. Governance is required.
The Mistake: Treating MCP as an Infinite List of Tools
A common temptation is to connect everything:
- CRM
- ERP
- Drive
- Notion
- Calendar
- Billing
- Database
- Tickets
- Slack or Teams
The problem is that more tools do not always mean a better agent. They mean a larger attack surface.
An agent with too many tools can:
- Choose the wrong tool.
- Confuse sources.
- Execute actions out of context.
- Mix sensitive data.
- Generate logs that are difficult to audit.
- Be vulnerable to prompt injection from documents or messages.
The practical rule: every agent must have the minimum set of tools necessary for its task.
Tool Catalog
In a company, MCP should be managed as a catalog. Not as a collection of loose scripts.
Every MCP tool should document:
- Name and purpose
- Systems it accesses
- Type of data it reads
- Actions it can execute
- Required permissions
- Risks
- Internal owner
- Available logs
- Permitted environments: development, testing, production
This allows you to know what capabilities each agent has and prevents a dangerous tool from becoming available in a general assistant.
Permissions Per Agent, Not Per Server
An MCP server can expose many operations. That does not mean that all agents should be able to use them.
For example, an MCP server for a CRM might allow:
- Search customer
- View commercial history
- Create note
- Change opportunity status
- Create quote
- Apply discount
- Delete record
A support agent might only need to search for a customer and create a note. A sales agent might be able to create an opportunity. An administrative agent might be able to prepare a quote, but not approve it.
Permissions must be defined by role, use case, and risk level.
Logs and Traceability
MCP allows the agent to act. Therefore, every action must leave a trace.
A useful log should answer:
- Which agent called the tool.
- Which user initiated the conversation.
- Which operation was executed.
- With what parameters.
- What the system returned.
- If human approval was required.
- What the final response seen by the user was.
Without logs, MCP becomes a black box connected to your systems. That is unacceptable in production.
Internal vs. Public Servers
The community has thousands of public MCP servers. They are useful for prototypes and development, but in a company, it is advisable to distinguish:
| Server Type | Reasonable Use |
|---|---|
| Public and Community | Testing, low-risk tools |
| Official Provider | Common integrations with support |
| Internal | Critical systems, sensitive data, proprietary rules |
| Corporate Gateway | Central point for permissions, logs, and auditing |
For customer data, internal documents, ERP, or billing, the standard practice is to build or control your own MCP servers.
MCP and Knowledge Bases
MCP does not replace a knowledge base. It complements it.
A base like Polp allows you to centralize documents, index them, and answer with sources. MCP can be used for an agent to consult that information and, if necessary, execute an action in another system.
Example:
- The user asks about an internal policy.
- The agent consults Polp and gets the answer with a source.
- If the policy requires creating a request, the agent calls the MCP of the ticketing system.
- The ticket is created and audited.
This flow is much more robust than an agent connected directly to ten folders and three systems without criteria.
Specific MCP Risks
The main risks are not theoretical:
- Prompt injection in external documents or data.
- Overly powerful tools.
- Lack of enterprise authentication.
- Unaudited actions.
- Dependency on third-party servers.
- Deployments without security review.
- Mixing testing and production environments.
This is why MCP must be treated as infrastructure, not as a plugin.
How to Start Right
Recommended order:
- Create a specific use case.
- Define what data the agent needs.
- Expose only those tools.
- Activate logs from the start.
- Separate reading and writing.
- Use human approval for sensitive actions.
- Evaluate quality with real conversations.
- Expand tools only if they provide measurable value.
How We Can Help
At Navel Digital, we implement MCP with an enterprise focus: internal servers, permissions per agent, auditing, integration with CRM/ERP, knowledge bases like Polp, and human fallback.
MCP is not magic. It is a good connection layer. The difference lies in whether you connect it with governance or with improvisation.