What Is an MCP Server? – Definition and How It Works
Learn what an MCP server is, what it exposes, how clients connect over stdio and HTTP, and how it differs from writing tool functions by hand.
An MCP server is a process that publishes capabilities — tools, resources, and prompts — over the Model Context Protocol, so any compatible client can discover and call them without bespoke integration code.
1. What Is an MCP Server?
It is an adapter between a capability and any model client that speaks the protocol.
- Key idea: write the integration once as a server; every compatible client gains it.
- Mechanism: JSON-RPC messages over a transport, with a discovery handshake that lists what the server offers.
- Goal: stop re-implementing the same tool wrapper for each assistant, IDE, or agent framework.
2. What a Server Exposes
| Primitive | What it is | Typical use |
|---|---|---|
| Tools | Callable functions with JSON schemas | Search, fetch a page, query a database |
| Resources | Readable content addressed by URI | Files, records, documents |
| Prompts | Reusable prompt templates the client can offer | Named workflows a user can invoke |
Tools are what most servers ship, and what most clients use.
3. How a Client Connects
Two transports are common, and the choice is about where the server runs.
- stdio — the client launches the server as a child process and speaks over standard input and output. Simple, local, no network exposure, credentials supplied as environment variables.
- Streamable HTTP — the server runs as a network service and the client connects over HTTP. Suits shared or remote deployments, and requires real authentication.
After connecting, the client calls the discovery method, receives the tool list with names and schemas, and presents those tools to the model.
4. The Call Path
model requests tool → client validates against schema
→ client sends a JSON-RPC call to the server
→ server executes and returns a result
→ client appends the result to the conversation
The server does the real work; the client mediates. Authorisation belongs on both sides — the client decides whether to offer a tool, and the server enforces what its credentials actually permit.
5. Compared With Hand-Written Functions
- Reuse. One server serves several clients; a hand-written function serves one application.
- Discovery. Tool lists are fetched at connect time, so a server can add capability without client changes.
- Operational cost. A server is a process to run, version, and secure — overhead a local function does not have.
- Context cost. Every published tool consumes context in the model's tool list, so large servers should be scoped per task.
6. What to Check on a Server
- The exact tool names and schemas, fetched live rather than copied from documentation.
- Which environment variable carries the credential — a wrong name often produces a silent hang rather than an error.
- Whether tools are read-only or can mutate state, and whether that is configurable.
- How errors are returned, since readable errors let a model correct a bad argument.
7. Common Misconceptions
- "MCP is a model feature." It is a protocol between a client and a capability provider. The model only ever sees the resulting tool list.
- "Connecting a server makes an agent smarter." It widens what the agent can do and enlarges the tool list it must choose from; scoping matters.
- "A server is safe because the client validates." The server must enforce its own limits; a client is not a trust boundary for it.
8. Summary
An MCP server publishes tools, resources, and prompts over a standard protocol so any compatible client can use them. It turns an integration into a reusable component, at the cost of a process to operate.
Verify the live tool list before building on one, keep the exposed set narrow, and treat the server's own permissions as the real security boundary.