# What is an MCP server? The MCP protocol explained simply > An MCP server exposes tools, data and prompts to an AI agent through the Model Context Protocol. Definition, how the MCP protocol works, examples and the governance questions to settle in the enterprise. Language: en · Category: engineering · Author: Nicolas Corod (Founder & CEO) · Published: 2026-09-28 Since late 2024, one acronym keeps coming up in every conversation about AI agents: MCP. Vendors announce their "MCP server", CIOs wonder whether to allow them, and business teams mostly want to know what it changes for them. **An MCP server is a program that exposes tools, data and instruction templates to an AI agent following the Model Context Protocol, an open standard. The agent connects to it, discovers what is on offer, then reads from or acts in the system concerned: a CRM, an ERP or a document store.** This article explains the MCP protocol without unnecessary jargon, shows how an MCP server works in practice, and raises the governance questions a company should settle before connecting one. It also introduces the idea of a **role**: the work a position on the org chart actually does, with the tools that position is entitled to. That is the right level to decide which agent may reach which server. ## The MCP protocol in brief The Model Context Protocol was [released by Anthropic as an open standard on 25 November 2024](https://www.anthropic.com/news/model-context-protocol). Its goal: one single way to connect AI applications to the data sources and tools they need. Before MCP, every "agent × system" pair required a custom connector. Ten agents and twenty systems meant potentially two hundred integrations. With a common protocol, each system is exposed once, and every compatible agent knows how to plug into it. This integration problem is covered in more detail in [the analysis of composing skills on top of MCP](/en/blog/mcp-vs-skills-composing/). The protocol no longer belongs to a single vendor. On 9 December 2025, [MCP joined the Agentic AI Foundation](https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/), a directed fund hosted by the Linux Foundation and co-founded by Anthropic, Block and OpenAI. The announcement reported more than 97 million monthly SDK downloads and 10,000 active servers at the time. ## Host, client, server: who does what The [specification describes a three-part architecture](https://modelcontextprotocol.io/specification/latest/architecture): - **The host**: the AI application the user opens (Claude, ChatGPT, Copilot, an IDE, an in-house agent). It manages connections, user consent and context aggregation. - **The client**: a connector created by the host. Each client talks to exactly one server. - **The server**: the program that represents a system (your CRM, your drive, your ticketing tool) and exposes its capabilities. One design principle is worth remembering: a server should not be able to read the whole conversation or "see" the other servers. The full history stays with the host, which controls what each server receives. ## What an MCP server exposes A server can offer [three types of primitives](https://modelcontextprotocol.io/specification/2025-06-18/server), each controlled by a different party: | Primitive | What it is | Who triggers it | Example | |---|---|---|---| | **Tools** | Functions the model can call to act or look something up | The model | Create a ticket, query a database | | **Resources** | Data or content supplied as context | The application | The contents of a file, a history | | **Prompts** | Predefined instruction templates | The user | A "/summarize-the-case" command | In practice, tools are what matter most: they turn an assistant that answers into an agent that acts. That is also where the risk concentrates, since the specification points out that a tool represents arbitrary code execution and must be treated with caution. ## How an MCP server communicates Messages are encoded in [JSON-RPC 2.0](https://modelcontextprotocol.io/specification/latest). The specification defines [two standard transports](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports): - **stdio**: the host launches the server as a subprocess on the same machine. This is the typical mode for local servers installed by a developer. - **Streamable HTTP**: the server runs remotely and exposes a single URL, for example `https://example.com/mcp`. This is the mode for hosted servers shared by a team or an organization. For remote servers, the specification describes [authorization based on OAuth 2.1](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization): the client obtains an access token limited to that specific server, with the scopes needed for the operation. Importantly, this authorization is **optional** in the protocol. An MCP server is therefore not secure because it speaks MCP; it is secure because someone configured it that way. ## Concrete examples of MCP servers A few typical enterprise cases: - **Documents**: a server that exposes a drive or a knowledge base, so the agent finds the right procedure instead of making one up. - **CRM**: a server that reads a customer record and logs a meeting summary. - **Ticketing**: a server that creates, comments on and triages support tickets. - **Internal system**: an in-house server that exposes a business API (quote calculation, compliance check) to every compatible agent. In each case, the same server works with any MCP-compatible client. That is the promise of the standard: expose a system once, consume it everywhere. ## MCP servers and skills: two complementary layers An MCP server tells the agent **what it can do**. It does not tell it **how to do it well** in your context: which procedure to follow, which checks to apply, in which order to call the tools. That is the job of skills, packaged instructions in the SKILL.md format, introduced in [the article on skills as the secret weapon of smarter AI agents](/en/blog/skills-secret-weapon-smarter-ai-agents/). Connecting many servers also creates a context problem: each connected server pours its tool definitions into the model's window before the first message is even sent. That effect is quantified in [the article on moving from context bloat to context load](/en/blog/context-bloat-to-context-load/). The answer is to load tools on demand rather than all at once. ## The governance questions to ask An MCP server gives an agent real access to a real system. Before allowing one, an organization should be able to answer five questions: 1. **Who validated it?** A server installed by an employee on their own machine, with no review, is [shadow AI](/en/blog/what-is-shadow-ai/) just as much as a personal ChatGPT account. 2. **With which permissions?** Read-only or write, on which scope of data, with which credentials. 3. **For which use?** A server is not meant to be connected to every agent of every employee. 4. **What happened?** Every tool call should be logged and attributable to the person who triggered it. 5. **How do you remove it?** Access must be revocable centrally, without going machine by machine. ## How skilder uses MCP skilder relies on MCP at two levels. Upstream, each workspace has an **internal, curated registry** of MCP servers: it only holds servers that have been verified, configured and scoped for the organization. It is not a public directory of every server in existence. Adding a server to the registry is the central authorization step. Downstream, skilder exposes **roles** through a single MCP server. A role bundles skills, the MCP tools that position is entitled to, its context and its permissions. Each role starts from a blueprint and is configured on the team's processes; it is never delivered ready-made. The role is the permission boundary: it can only reach servers already in the registry, and skilder keeps an execution trace of every task, which the customer can export. The result: your teams keep Claude, ChatGPT or Copilot, and each agent receives only the tools of its role, loaded when they are needed. ## Key takeaway > An MCP server is a standard socket between an AI agent and a system. The protocol handles the connection; it handles neither rights, nor traceability, nor the quality of the work. Those three remain the organization's responsibility. To see how a role brings skills and MCP tools together, read [the skilder documentation](https://docs.skilder.ai).