The Model Context Protocol (MCP) is an open standard for connecting AI assistants and agents to your company's systems (ERP, CRM, databases, document stores) through one common interface. Instead of building a separate integration for every assistant, you build an MCP server once and reuse it across every compatible client. Done well, it saves months of integration work; done carelessly, it gives an easily manipulated model a direct line into your data.
What MCP is and who governs it
MCP is an open protocol that standardizes how an AI application discovers and uses external data, tools and workflows. The official documentation compares it to a USB-C port: one connector that lets any compatible AI application plug into any system that exposes it.
Anthropic introduced MCP as an open standard on November 25, 2024. On December 9, 2025, Anthropic donated it to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg. For a buying decision this matters: MCP no longer depends on a single vendor, it has neutral governance, and it is supported by clients such as Claude, ChatGPT, Gemini, Microsoft Copilot, Visual Studio Code and Cursor. At the time of the donation, Anthropic reported more than 10,000 active public MCP servers.
The specification is versioned by date and still evolving (the current revision at the time of writing is 2026-07-28), so your engineering team should confirm which revision each client supports before building.
How it works: hosts, clients, servers and three primitives
There are three moving parts. The host is the AI application people use (a desktop assistant, an IDE, your own chatbot). Inside the host, an MCP client holds the connection to each MCP server, the program that exposes a specific system: your CRM, your inventory database or your document repository. Messages use JSON-RPC 2.0, either locally (stdio) or over the network (HTTP).
| Primitive | What it is | Business example |
|---|---|---|
| Tools | Functions the model can execute | Look up an account balance, open a support ticket, create an order |
| Resources | Data and context the model or user can read | Product catalog, an internal policy, a database schema |
| Prompts | Reusable instruction templates the user picks | "Weekly accounts receivable summary", "Contract review" |
The security-relevant detail: tools are model-controlled. The model decides when to call them, which is why the specification says there should always be a human in the loop who can deny tool invocations.
Why it matters for your business
Before MCP, connecting an AI assistant to your systems meant custom glue code for every model-and-system pair, and switching AI vendors meant rebuilding integrations. MCP collapses the "N assistants times M systems" problem into one server per system.
- Integrate once, reuse everywhere: the same MCP server for your ERP can serve an internal assistant, your developers' IDE and a customer support agent.
- Less vendor lock-in: you can swap models (Claude, GPT, Gemini or open source) without rewriting the integration layer. See our guide on choosing between Claude, GPT and open-source models.
- One control point: the MCP server is where you enforce permissions, audit logging and rate limits, instead of scattering them across integrations. That makes SOC 2 and HIPAA evidence collection far easier.
- An existing ecosystem: many software vendors already publish official MCP servers, and there is an official registry at registry.modelcontextprotocol.io.
Practical use cases
MCP is the plumbing that lets an AI agent act on your systems. Where we see the most value for mid-sized US companies:
- Natural-language ERP queries: "Which customers are more than 60 days past due?" against your accounting system, read-only.
- Context-aware customer support: an assistant that checks order or claim status in your CRM before replying.
- Internal knowledge: policies, runbooks and procedures exposed as resources. For large document collections, pair it with enterprise RAG.
- Engineering and IT operations: connecting the code repository, ticketing system and technical docs to the coding assistant.
- Recurring reports: predefined prompts that regenerate the same report with fresh data every week.
MCP security: the risks you need to know
Connecting a language model to real systems changes your risk profile, because the model can be steered by the content it reads. The official MCP site publishes security best practices, and the specification is blunt: tools represent arbitrary code execution and must be treated with caution. The main risks:
- Tool poisoning: documented by Invariant Labs in April 2025. A malicious server hides instructions in a tool description; the user never sees them, the model does, and it may read sensitive files and send them out. A variant is the "rug pull", where the server changes a tool description after you approved it.
- Untrusted servers: a local MCP server runs with your user's privileges. OWASP documents a malicious email MCP package that silently BCC'd outgoing messages to an attacker. Treat servers like any software dependency: verified source, pinned version, code review.
- Confused deputy: an MCP server that proxies a third-party API can hand access to the wrong party if it skips per-client consent. The official guidance makes per-client consent mandatory for these proxies.
- Token passthrough: a server that accepts tokens issued for another service and forwards them breaks audit trails and downstream controls. The specification forbids it: an MCP server must not accept tokens that were not issued for it.
- Over-privileged connections: a server connected to your database with admin credentials turns any model manipulation into a serious incident.
- Prompt injection through tool results: a ticket, email or document read by a tool can carry malicious instructions. Our guide on prompt injection in AI agents covers the defenses in depth.
Baseline controls we recommend: least-privilege, progressively granted scopes; OAuth-based authorization as defined in the spec; human approval for every write action (payments, outbound messages, deletions); an allowlist of approved servers; sandboxing for local servers; logging of every invocation; and reviewing tool descriptions on approval and whenever they change.
Build your own MCP server or use an existing one?
| Criterion | Use an existing server | Build your own |
|---|---|---|
| Best for | Popular SaaS tools with an official vendor server | Internal systems, custom ERPs, proprietary business logic |
| Time | Hours to days of setup | Weeks, depending on tool count and integrations |
| Security control | You depend on the vendor; review scopes and provenance | Full: you decide what is exposed and with which permissions |
| Main risk | Unmaintained or malicious community servers | Your own authorization and validation bugs |
Rule of thumb: use official vendor servers when they exist and are maintained; avoid anonymous community servers for anything touching sensitive data; build your own for what is unique to your business, and expose narrow operations ("get_invoice") rather than open-ended tools ("run_sql").
How to roll out MCP, step by step
- Pick one narrow use case: a frequent business question that today requires someone to pull data by hand.
- Inventory and classify the data: which systems are touched, whether there is PII, PHI or data covered by state privacy laws, and whether the model provider will process it.
- Start read-only: your first server should not be able to change anything.
- Design narrow tools: few functions, validated parameters, capped results (for example, 50 rows maximum).
- Wire identity and permissions: each user acts with their own permissions, not through an all-powerful service account.
- Add human approval before enabling any write tool.
- Log and measure: which tool was called, with what parameters, by whom, and whether the answer was right. Our guide on evaluating AI assistants explains how to measure quality.
- Security-test it before widening access, including injection attempts through the data it reads.
On timelines: a read-only pilot over one or two systems fits the real-data prototype format of our AI development services, starting at USD 4,000 in 2 to 4 weeks. Our team works from Quito in UTC-5, which overlaps the US business day. Final cost depends on the number of systems, the quality of their APIs and your audit requirements.
Common mistakes
- Installing community MCP servers on machines with production access without reviewing their source.
- Using an admin service account "to make it work".
- Exposing a generic SQL or shell tool instead of specific business operations.
- Auto-approving all tools for convenience.
- Not logging invocations, which makes incident investigation impossible.
- Assuming MCP is "secure by default": the protocol defines mechanisms, but the implementation is your responsibility.
Frequently asked questions
Is MCP only for Claude?
No. Anthropic created MCP, but in December 2025 it donated the protocol to the Agentic AI Foundation under the Linux Foundation, co-founded with OpenAI and Block. MCP is supported by ChatGPT, Gemini, Microsoft Copilot, Visual Studio Code and Cursor as well as Claude. A well-built MCP server works with any compatible client, which reduces your dependence on a single AI vendor.
How is MCP different from a regular API?
An API is the interface to one specific system; MCP is a standard protocol that lets AI applications discover and use such interfaces. An MCP server usually wraps one or more existing APIs and describes them so the model understands which tools exist, which parameters they take and what they return. It does not replace your APIs; it makes them usable by AI assistants in a consistent way.
Is it safe to connect MCP to our ERP or database?
It can be, with the right controls: read-only access first, per-user permissions, specific tools instead of open queries, human approval for any write, and logging of every invocation. The real risk is not the protocol itself but connecting a manipulable model to systems with broad permissions. A security assessment before production is strongly recommended, especially for regulated data.
How much does an MCP implementation cost?
Configuring official servers for SaaS tools can cost little more than a few hours of setup and review. Building a custom server over an internal system is a development project: as a reference, a real-data prototype starts at USD 4,000 in 2 to 4 weeks. The biggest cost drivers are the quality of your existing APIs, the number of tools and your audit and compliance requirements.
What company data does the model provider see?
Whatever an MCP tool returns enters the model's context, and if you use a cloud model, that provider processes it. Keep results to the minimum necessary, mask personal data where possible, and review the provider's retention and data-use terms. For HIPAA-covered data, confirm a business associate agreement is in place before any PHI flows through the integration.
Conclusion
MCP has become the standard way to connect AI to business systems, with neutral governance and broad client support. Its value is integrating once and reusing everywhere; its risk is giving a manipulable model access to real data and actions. Start with one narrow, read-only use case, least-privilege permissions and full logging, and expand once you have evidence it works and is safe.
If you want to connect your systems to AI without opening new holes, our AI development services team designs and builds MCP servers with security built in from day one. Book a free consultation and we will review your use case.