You connect an AI coding agent to a database, a file system, and a Slack workspace. Three different integrations, three different APIs, three different ways of passing data back and forth. Every new tool means another custom integration to build and maintain.
The Model Context Protocol fixes this by defining a universal standard for how AI agents connect to external systems. But to use MCP effectively, you need to understand its core building blocks. These are the MCP primitives: server, client, transport, sampling, and elicitation.
MCP Server vs MCP Client Explained
The MCP architecture follows a client-server model that separates responsibilities cleanly between two sides.
What Is an MCP Server
An MCP server is a process that exposes capabilities to AI agents. It wraps an external system like a database, an API, or a file system and makes it available through a standardized interface. The server defines what tools are available, what data can be accessed, and what actions can be performed.
Think of it as an adapter. Your Postgres database speaks SQL. Your AI agent speaks natural language. The MCP server sits between them, translating tool calls from the agent into database queries and returning results in a format the agent understands.
A single MCP server can expose multiple tools. A database server might offer tools for querying tables, listing schemas, and running migrations. Each tool has a name, a description, and a JSON schema that defines its parameters. Poor descriptions can lead to tool poisoning risks.
What Is an MCP Client
An MCP client is the component inside the AI application that connects to MCP servers. It manages the connection lifecycle, discovers available tools, and routes tool calls from the agent to the correct server. The client is typically built into the host application, whether that is an IDE, a CLI tool, or a chat interface. Understanding this relationship is key to context engineering.
The relationship is one client to many servers. A single client in your coding agent might connect to a file system server, a Git server, and a browser automation server simultaneously. The client handles the complexity of maintaining multiple connections so the agent sees one unified set of tools. This is part of the broader AI-driven development shift.
| Aspect | MCP Server | MCP Client |
|---|---|---|
| Role | Exposes tools and data from external systems | Connects to servers and routes agent requests |
| Multiplicity | One server per external system | One client connects to many servers |
| Who builds it | Tool providers or teams with specific integrations | AI application developers |
| Lifecycle | Runs as a separate process or service | Embedded inside the host application |
| Discovery | Advertises its capabilities on connection | Queries servers for available tools at startup |
MCP Transport Types: Stdio vs Streamable HTTP
Transport is the layer that defines how the client and server communicate. MCP supports two primary transport types, each suited to different deployment scenarios.
Stdio Transport
Stdio transport runs the MCP server as a child process of the client. Communication happens through standard input and output streams. The client spawns the server process, writes JSON-RPC messages to its stdin, and reads responses from its stdout.
This is the simplest transport and the most common for local development. There is no network configuration, no authentication setup, and no port management. The server starts when the client needs it and stops when the client exits. It works well for tools that run on the same machine as the agent.
Streamable HTTP Transport
Streamable HTTP transport runs the MCP server as a network service that the client connects to over HTTP. This is the transport you use when the server needs to run on a different machine, serve multiple clients, or persist between sessions.
It uses server-sent events for streaming responses from server to client and standard HTTP POST requests for client-to-server messages. This makes it compatible with existing web infrastructure like load balancers, proxies, and authentication middleware.
| Factor | Stdio | Streamable HTTP |
|---|---|---|
| Deployment | Local, same machine | Local or remote, any network |
| Setup complexity | Minimal, just run the process | Requires HTTP server configuration |
| Multi-client support | One client per server instance | Multiple clients can share one server |
| Authentication | Inherited from OS process permissions | Standard HTTP auth (OAuth, tokens) |
| Best for | IDE plugins, local CLI tools | Shared team servers, cloud deployments |
"Stdio gets you running in five minutes. Streamable HTTP gets you running in production."
What Is Sampling in Model Context Protocol
Sampling is the MCP primitive that lets a server ask the AI model to generate text. Instead of the usual flow where the client sends requests to the server, sampling reverses the direction. The server sends a prompt to the client, the client passes it to the model, and the model's response goes back to the server.
This enables agentic behavior inside MCP servers, similar to how a subagent delegates work. A server can use the model's intelligence to make decisions during tool execution rather than following rigid predetermined logic. For example, a code analysis server could use sampling to ask the model to classify a code pattern before deciding which analysis to run.
Sampling requests go through the client, which acts as a gatekeeper. The client can modify the prompt, apply safety filters, or require user approval before forwarding the request to the model. This keeps the human in the loop even when the server is driving the interaction.
"Sampling turns a passive tool server into an active collaborator that can think for itself."
What Is Elicitation in MCP
Elicitation is the MCP primitive that lets a server request information directly from the user. When a server needs input that the model cannot provide, like a confirmation before a destructive action that could expand the blast radius, a choice between options, or credentials for authentication, it sends an elicitation request through the client to the user.
The server defines what kind of input it needs using a structured schema. It can ask for free text, a selection from a list, a boolean confirmation, or other typed inputs. The client presents this to the user in whatever format fits its interface, collects the response, and sends it back to the server.
Elicitation solves the problem of human-in-the-loop workflows without breaking the MCP abstraction. The server does not need to know how the client displays the prompt. It just declares what information it needs and gets a structured response back.
How to Build Your First MCP Server
Building an MCP server follows a consistent pattern regardless of the language you use.
- Choose an MCP SDK. Official SDKs exist for TypeScript and Python. Both handle the protocol details so you can focus on defining tools.
- Define your tools. Each tool needs a name, a description that helps the agent understand when to use it through progressive disclosure, and a JSON schema for its input parameters.
- Implement tool handlers. Write the function that runs when the agent calls each tool. This is where your actual logic lives, the database queries, API calls, or file operations.
- Configure the transport. For local development, use stdio. For shared or remote deployment, configure streamable HTTP.
- Register the server with your client. Add the server configuration to your AI tool's settings, similar to how you configure an AGENTS.md file, so the client knows how to connect to it.
A minimal MCP server in Python looks like this.
from mcp.server import Server
from mcp.types import Tool, TextContent
server = Server("my-first-server")
@server.tool()
async def get_weather(city: str) -> str:
"""Get the current weather for a city."""
# Your logic here
return f"Weather in {city}: 72°F, sunny"
if __name__ == "__main__":
server.run(transport="stdio")
Start simple with one or two tools. Test them with your AI coding tool to make sure the descriptions are clear enough for the agent to use them correctly. Expand from there as you identify more capabilities worth exposing.
Conclusion
MCP primitives are the five building blocks that make the Model Context Protocol work: servers expose tools and data, clients manage connections and route requests, transports handle the communication channel between them, sampling lets servers leverage the AI model's intelligence, and elicitation lets servers collect input directly from users.
Understanding these primitives is essential for anyone building or configuring AI agent integrations. Stdio transport works best for local development while streamable HTTP handles production deployments.
As MCP adoption grows across AI coding tools, knowing how to build and configure servers will become a standard skill for development teams working with AI agents. Pairing MCP servers with agent skills creates a complete automation layer where raw capabilities meet repeatable workflows.
