What Is an MCP Server? A Plain-English Guide
Key Takeaways
- An MCP server is a program that exposes tools, data and prompt templates to an AI application through one open standard, the Model Context Protocol.
- The three things a server can offer are tools (actions the model can take), resources (data the model can read) and prompts (reusable instruction templates).
- A host application runs one MCP client per server connection; the client asks the server what it offers, then routes tool calls and returns results to the model.
- Local servers usually talk over stdio, while remote servers use Streamable HTTP; the choice affects where your data travels and how you authenticate.
- Connect servers with least privilege, require approval for destructive actions, and treat tool results as untrusted data, never as instructions.
An MCP server answers a simple question: how does an AI assistant reach your tools and data without a custom integration for every pairing? Before the Model Context Protocol, every new data source needed its own implementation. MCP replaces that tangle with one standard. The protocol is, in the official documentation’s words, an open standard for connecting AI applications to external systems. Anthropic open-sourced it in November 2024, and in December 2025 it was donated to the Agentic AI Foundation under the Linux Foundation.
Think of it like a USB-C port for AI applications, the comparison the official documentation itself uses. One port, many devices. A tool built once as an MCP server can work with any host application that speaks MCP, and a host that speaks MCP can connect to many servers without learning a new integration each time.
What an MCP server actually is
An MCP server is a program that runs either on your own device or on the internet and exposes capabilities to an AI application. It does not contain the AI model. The model lives in the host application — Claude, ChatGPT, Cursor, VS Code or a similar tool. The host opens a client for each server it connects to, and that client carries the conversation between the model and the server.
When you connect a server, the client first asks what the server offers. This discovery step matters because the model can only use tools it knows about. The client then routes calls: when the model decides it needs a tool, the host sends the call to the right server, and the server’s result comes back into the model’s context. The model never runs the tool directly; the server does the work, and the model reads the result.
Tools, resources and prompts: the three building blocks
| Building block | What it is | Who decides to use it | Example |
|---|---|---|---|
| Tools | An action the model can take | The model, during a conversation | Search a database, send a message, create a ticket |
| Resources | Data the model can read | The host application or you | The contents of a file, rows from a database |
| Prompts | A reusable instruction template | You, typically from a menu | A template for writing a release note or a bug report |
A useful memory aid: tools are the model’s hands, resources are its eyes, and prompts are its recipes. Tools change something. Resources only provide context. Prompts structure how a task is asked, so you do not have to retype the same instructions every time.
Not every server offers all three. A file-search server may offer only tools. A documentation server may offer mostly resources. That is normal. The point of the standard is that the host does not need to care which combination a server provides; it discovers what is there and uses it.
How a client discovers and calls tools
Discovery works like a menu. The client asks the server for its list of tools, and the server replies with each tool’s name, description and the shape of input it expects. The model reads those descriptions when it decides what to call. This is why clear tool descriptions matter so much: a vague description can lead the model to call the wrong tool, and a misleading one is a security risk, covered below.
Calling works in a loop. You ask a question. The model decides a tool might help. The host sends the call to the server. The server runs it and returns a result. The model reads the result and either answers, calls another tool, or asks you for more information. If a tool needs information the model does not have, a good host asks you rather than guessing.
One detail worth knowing: tool results become part of the model’s context. That means anything a tool returns — a document, a ticket, a web page — is text the model will read and may act on. Treat tool output as data, not as instructions from you. This distinction is the foundation of MCP security.
Local servers vs remote servers: stdio and Streamable HTTP
An MCP server can run in two places, and the transport differs between them.
Local servers over stdio
A local server runs on your own machine and talks to the host over stdio, the standard input and output channels of a process. This is the common setup for personal tools: a server that reads your local files, runs a local database query, or drives a browser on your computer. Your data stays on your machine, but the server runs with your local permissions, so a malicious or compromised server is a real risk. Install only servers whose source you have checked, and keep them updated.
Remote servers over Streamable HTTP
A remote server runs on the internet and talks over Streamable HTTP. This is the setup for team and hosted tools: a server run by your company or a vendor, reached from any device. Remote servers need authentication, because anyone who can reach the server can potentially call its tools. Good remote setups use OAuth-style delegation, so you grant limited permissions instead of handing over a broad secret, and they validate tokens for issuer, audience, signature and expiry on every call.
The practical rule: choose local when the data should not leave your machine and you can manage the software yourself. Choose remote when a team needs shared access, or when the tool itself lives in the cloud. Do not choose remote just because it looks easier, and do not choose local just because it looks private, if you will never update the software.
How to connect an MCP server safely
Connecting a server is a permission decision, not just a setup step. Before you connect, work through these checks.
- Check the source. Read the server’s code or at least its documentation and author. A public catalogue lists servers and how to run them; it does not vouch for their code. Typosquatted or backdoored packages are a known supply-chain risk.
- Scope the permission. Give the server the narrowest access that does the job. A server that only needs to read one folder should not get your whole drive. A server that only needs to search tickets should not get permission to delete them.
- Separate read from write. Start with read-only tools. Add write tools only when a real task needs them, and require human approval for destructive actions such as deleting, sending, publishing or paying.
- Keep secrets in the server, not in prompts. Never paste live API keys into a prompt or a shared configuration. The server should hold credentials, and tools should use them without showing them to the model.
- Log tool calls. Record who called which tool, with what arguments, and what happened. Without a log, you cannot reconstruct what an agent did, which is exactly what you need when something goes wrong.
- Revoke on a schedule. Review connected servers regularly. Remove servers you no longer use, and rotate credentials when a team member leaves or a server is updated by an unknown author.
Two risks deserve special attention. Tool poisoning is when a server’s tool description or response hides instructions that steer the model somewhere you did not approve; the model trusts the description it receives, so vetting the server matters more than any prompt rule. Prompt injection through tool results is when attacker-controlled content inside a returned document or ticket steers the model; the defence is scoping, so an injected instruction has nothing dangerous to reach, not a cleverer prompt.
What MCP does not do
MCP does not make a model smarter, and it does not guarantee that a tool’s answer is correct. It standardises how the model reaches tools and data; the quality of the tool, the data and the model still decides the result. MCP also does not replace your application’s own access control. If a server exposes a broad query tool, MCP will faithfully deliver it, and the damage is a design problem, not a protocol bug.
MCP also does not mean every server works with every host in every way. Hosts differ in which MCP features they support, and some features are still evolving. If a server works in one host but not another, check the host’s documented MCP support before assuming the server is broken.
When an MCP server is worth it
An MCP server is worth connecting when you repeat the same task across a tool: searching the same knowledge base, filing the same kind of ticket, checking the same dashboard. It is less useful for one-off questions, where pasting the relevant text into the chat is faster and safer. Start with one read-only server for your most repeated task, learn how tool calls behave, and only then add write access. That order — read first, write with approval, revoke regularly — is the whole discipline in one sentence.
For how agents use tools in general, see what AI agents are and how they work. For a concrete example of governed tool access inside an enterprise system, see how OpenAI and ServiceNow connect workflows to ChatGPT, and for how agent trust is scored, see Socure’s agent trust scores.
Limitations
This guide explains the protocol from its public documentation and reputable guides; it is not a hands-on test of any particular server, and no server was installed or run for this article. Host support for MCP features varies, and the specification continues to evolve, so check the current documentation for the host and server you actually use before relying on a specific feature. The security guidance here reduces risk; it does not guarantee security.
