Quick answer
An MCP server is a program that uses the open Model Context Protocol to give AI assistants and agents access to data and tools: searching documents, reading support tickets or creating a task in a system, for example. One connection to your CRM or knowledge base then works across many AI applications instead of needing a separate integration for each. Companies that want AI to work with their real systems, not just the model's general knowledge, are the ones that need it most.
What is MCP (Model Context Protocol)?
MCP is an open protocol that standardizes how applications built on language models connect to external data sources and tools. Its maintainers compare it to a USB-C port: one connector standard instead of a different charger for every device (MCP documentation).
Anthropic open-sourced MCP on November 25, 2024 (Anthropic, 2024). A year later, on December 9, 2025, it donated the protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. The same announcement reported more than 10,000 active public MCP servers and over 97 million monthly SDK downloads across Python and TypeScript (Anthropic, 2025).
Before MCP, every AI application needed its own connector for every system. Three assistants and five systems meant fifteen integrations to maintain. With MCP, each system exposes one server and each AI application has one client that can talk to any server.
How does an MCP server work?
An MCP server describes what it can do, the AI application asks for that list and hands it to the model, and the model decides what to use. The specification defines three roles (MCP specification):
- Host: the AI application a person uses, such as Claude, ChatGPT, a code editor or your own agent.
- MCP client: a component inside the host. The host creates one client for each server it connects to.
- MCP server: a program that provides context and capabilities from a specific system.
A server can offer three kinds of things, called primitives (MCP architecture):
| Primitive | What it is | Who controls it | Business example |
|---|---|---|---|
| Tools | Functions the model can call to take an action | The model, with user consent | Search documents, open a ticket, get an order status |
| Resources | Data provided as context | The application or the user | A database schema, a contract, a policy |
| Prompts | Reusable interaction templates | The user | "Prepare the weekly sales report" |
Messages use JSON-RPC 2.0. A typical flow: the client fetches the tool list (tools/list), the model picks a tool and its arguments, the client calls it (tools/call), and the result goes back to the model as context for the next step.
In the current specification (2026-07-28) the protocol became stateless: every request carries the protocol version and client capabilities, and the server advertises its capabilities through a mandatory server/discover call. Sampling, Roots and Logging were deprecated, and long-running operations moved to an optional Tasks extension (2026-07-28 changelog). For a business, that means remote servers are easier to scale behind an ordinary load balancer.
Local or remote server: which one?
A local server runs on the user's computer and talks to the application over standard input and output (the stdio transport). A remote server runs on a server and accepts HTTP requests (the Streamable HTTP transport). The older HTTP+SSE transport is deprecated (MCP transports).
| Local server (stdio) | Remote server (Streamable HTTP) | |
|---|---|---|
| Where it runs | On the user's machine, launched by the app | At a vendor or in your own infrastructure |
| Users | Usually one client | Many clients at once |
| Authentication | Local user permissions | Tokens, OAuth recommended |
| Good fit | Local files, a local repository, developer tools | Company systems: CRM, ERP, document store, helpdesk |
| Main risk | Code running with the user's permissions | Leaked tokens, over-broad scopes |
Early write-ups about MCP often say that "everything runs locally." That is a simplification. Even with a local server, tool results are sent to the language model, which usually runs in a provider's cloud. If personal data under GDPR or trade secrets must not leave the company, the whole chain has to be local: the MCP server, the agent and the model. We show what AI on your own infrastructure looks like on our AI infrastructure page.
Who needs an MCP server?
Any organization that wants AI to work with its systems in more than one application, or in agents that carry out tasks. In practice, that means three groups.
Companies with internal systems. An ERP, a ticketing system, a product database, technical documentation. One MCP server in front of such a system lets a chat assistant, a background agent and a developer tool all use it, without three separate integrations.
Teams building AI agents. An agent is a model that picks tools in a loop and carries out step after step (more in what is agentic AI). MCP gives it a standard way to discover and call those tools, and gives you the option to swap the model without rewriting integrations.
Software vendors. A SaaS vendor that ships an MCP server makes its product reachable from ChatGPT, Claude, Gemini and Copilot, which Anthropic lists among the products supporting the protocol (Anthropic, 2025).
An everyday example: a team lead asks what shipped last week. Without integrations, someone opens the repository, the task tracker, the chat app and the calendar, then pieces it together from memory. With MCP servers for those systems, the assistant pulls closed tasks, merged changes and meeting decisions, and a person gets a draft summary to review.
When is MCP overkill?
When you have one AI application and one stable connection to one system. A plain API call in the agent's code is then simpler to maintain than a separate server. MCP starts paying off as the number of applications, agents or systems to connect grows.
How do we use MCP in our agents?
In our AI agents, MCP-based agent tools are part of the shared agent-core that our helpdesk, operations assistant, outreach agent and pentester are built on. Three rules come out of that work and apply to every server we connect:
- A narrow tool allowlist. Each agent gets only the tools its role needs. The helpdesk has no access to the pentester's tools.
- Human approval for sensitive actions. An MFA reset in the helpdesk runs only after someone clicks "Approve," and no outreach message goes out without sign-off.
- An audit log and local models. Every step is written to an append-only audit log, and the model runs on our own GPUs, so data never leaves the company.
What are the risks of MCP and how do you reduce them?
An MCP tool is code running against your systems, so the risks are those of any programmatic access plus the ones specific to language models. The specification explicitly requires the host to obtain user consent before invoking a tool, and says tool descriptions from an untrusted server should be treated as untrusted (MCP specification).
The main threats, according to the MCP security best practices:
- Over-broad scopes. A leaked token with an "everything" scope gives access to everything. The recommended model is least privilege, with elevation only when a specific action needs it.
- Token passthrough. A server must not accept tokens issued for another service and forward them to downstream APIs.
- Untrusted local servers. One-click configuration can run any command with the user's permissions. The client must show the full command and ask for consent.
- Prompt injection. Agents read emails, tickets and web pages, which can contain hidden instructions. You need a guard on the input and human approval for irreversible actions.
We go deeper in our article on AI agent and MCP server security.
Where should a company start with MCP?
With one process and one system, not by connecting everything at once.
- Pick a task where people manually gather information from several places today (order status, the weekly report, answers to customer questions).
- Check for a ready-made server for that system, ideally from the vendor. If there is none, plan your own.
- Start read-only. Read-only tools deliver value at low risk. Add write actions later, with human approval.
- Set data boundaries: which data can go to a cloud model and which needs a model in your own infrastructure.
- Measure and log: which tools the agent calls, how often it gets things wrong, how much time it saves.
MCP does not make a model smarter. It gives the model context it did not have before, and missing context is usually what separates an impressive demo from a tool people use every day.
Sources
- Model Context Protocol: What is MCP?
- Model Context Protocol: Specification (2026-07-28)
- Model Context Protocol: Key changes 2026-07-28
- Model Context Protocol: Architecture overview
- Model Context Protocol: Transports
- Model Context Protocol: Security Best Practices
- Anthropic: Introducing the Model Context Protocol (2024)
- Anthropic: Donating the Model Context Protocol and establishing the Agentic AI Foundation (2025)
