Inside MCP Clients and Servers
See the parts of an MCP connection, what a server can offer, and where the human stays in control.
Let’s open up one MCP connection, between an AI assistant and a calendar.
There are three roles:
- The host is the AI app the user works in. It holds the model, the conversation and the user’s permissions.
- The client lives inside the host, one per connected server, and speaks the protocol.
- The server wraps a real system, here the calendar, and offers its capabilities. It can run on the same computer, or remotely over the internet.
A server can offer three kinds of things:
- Tools: actions the model can call, such as
create_event. - Resources: data the app can read and add to the context, such as this week’s events.
- Prompts: ready-made templates the user can pick, such as “plan my week”.
A session follows a simple script. The client connects and both sides introduce themselves and what they support. The client asks for the list of tools. The host passes their descriptions to the model alongside the user’s request. When the model asks for a tool, the host checks with the user if needed, then the client sends the call and the server returns the result.
That approval step is deliberate. The protocol connects things; the host decides what is allowed. Good hosts show users which servers are connected, ask before risky actions, and let people deny a call. A server’s tool descriptions are also text the model reads, so a malicious server could try to slip in instructions: only connect servers you trust.
Key takeaways
- Host = the AI app; client = its connector, one per server; server = a wrapper around a real system.
- Servers offer tools (actions), resources (data) and prompts (templates).
- A session: initialise, list tools, the model chooses, the host approves, the server runs the call.
- The host enforces permissions and approvals; only connect servers you trust.
Check your understanding
Go deeper (more technical)
MCP messages use JSON-RPC 2.0: small JSON objects with a method name such as tools/list or tools/call and their parameters. Local servers usually talk over standard input and output (stdio); remote servers over HTTP, with authorisation, commonly OAuth.
Servers can also ask things of the client, for example asking the host’s model to generate text (“sampling”) or asking the user for extra information, and can notify the client when their list of tools changes.
The simulation’s messages are simplified.