What an MCP Server Is
A small program that exposes capabilities to an AI agent over the Model Context Protocol. It advertises a list of tools, resources and prompts with machine readable schemas, and the agent discovers and calls them without any integration written specifically for that pairing.
What it actually is
The word server misleads people who come from web development. An MCP server is most often a small program running on the same machine as the agent, communicating over standard input and output. There is no port, no URL, and frequently no network involved at all. Remote transports exist, but the local process is the common case.
What makes it a server is the relationship rather than the deployment. It waits, it is asked things, it answers.
When an agent starts, it launches the servers it has been configured with and asks each one what it offers. The server replies with a structured list: here are my tools, here are their names and descriptions, here are the parameters each accepts. The agent now knows what it can do without anyone having written code that couples the two together.
That discovery step is the whole idea. Before it, giving an agent a new capability meant writing an integration for that specific agent. After it, you write the capability once and any compatible agent can use it.
One further practical point about the shape. Because the server is a separate process, it has its own lifetime, its own dependencies and its own failure modes. It can be written in a different language from the agent, it can be restarted without restarting the agent, and it can crash on its own. That independence is mostly an advantage, and it means a server holding state between calls is making a choice worth thinking about rather than an obvious default.
The three things a server exposes
Tools. Functions the agent can call with arguments, producing a result. Query a database, read a ticket, run a search, send a message. This is the category people mean when they say MCP server, and it is where the action is.
Resources. Content the agent can read, addressed by URI. A file, a record, a document. The distinction from a tool is that a resource is fetched rather than executed, and it is the agent or the user who decides what to pull in.
Prompts. Reusable templates the server offers, which a user or agent can invoke by name. The least used of the three, and useful where a server wants to ship a known-good way of asking for something.
A server can expose any combination. Many expose only tools, and that is a perfectly ordinary shape.
The part worth attention is the descriptions. Every tool carries a name, a human readable description and a parameter schema, and those descriptions are what the model reads when deciding whether this tool applies. They are load bearing in a way that ordinary API documentation is not, because there is no developer in the loop reading them and choosing.
Why the schema matters more than the code
Two servers can wrap the same underlying system and behave completely differently, because one describes its tools precisely and the other does not. A tool called query with the description runs a query is unusable in practice: the model cannot tell when to reach for it. Naming and description are the interface an agent actually consumes.
What it is not
Not knowledge. A server provides access to a system. It does not make the agent understand your domain, your conventions or your data model. Agents connected to a database through a well built server still write bad queries if they do not know what the tables mean.
Not instruction. Telling an agent how to work is a separate concern that belongs in an instruction file or a skill. Conflating the two produces servers that try to teach through tool descriptions, which is both expensive and ineffective.
Not a security boundary by itself. A server can expose a destructive tool as easily as a safe one. What the agent may reach is decided by which servers you configure and what those servers permit, so the boundary is a choice you make rather than something the protocol provides.
Not always worth building. If the capability already exists as a skill, or the knowledge could be retrieved instead of fetched, a server is more machinery than the job requires.
The useful mental model: a server is a socket. It says here is what can be reached from here. Everything about whether the agent uses it well is decided elsewhere.
Frequently asked questions
- What is an MCP server in AI?
- A program that exposes capabilities to an AI agent over the Model Context Protocol. It advertises tools, resources and prompts with machine readable schemas, and any compatible agent can discover and call them at runtime without an integration written for that specific pairing.
- Is an MCP server a web server?
- Usually not. Most run as a local process communicating over standard input and output, with no port and often no network involved. Remote transports exist, but the local process is the common case. What makes it a server is the relationship: it waits, it is asked, it answers.
- What can an MCP server expose?
- Three things. Tools, which are functions the agent calls with arguments. Resources, which are content fetched by URI rather than executed. And prompts, which are reusable templates invoked by name. Many servers expose only tools, which is an ordinary and sufficient shape.
- Does an MCP server make an agent smarter about my systems?
- No. It provides access, not understanding. An agent connected to a database through a well built server will still write poor queries if it does not know what the tables mean. Knowledge belongs in a retrieval layer and instruction belongs in a skill or conventions file.