MCP server vs client
One connection, two halves with different jobs. Mixing them up is the most common beginner implementation mistake.
Short version
The server owns capabilities. It defines the tools, validates input, executes work, and returns structured results. The client owns the conversation. It discovers what is available, presents those options to the model, and routes chosen calls to the right server.
A useful rule: the server should be able to run with no idea who is talking to it. The moment it starts making user-facing decisions, the boundary has been crossed.
The server exposes. The client orchestrates. Neither should do the other's job.
Side by side
| Aspect | Server | Client |
|---|---|---|
| Owns | Capabilities and their contracts | The session and the model interaction |
| Defines | Tool names, schemas, permissions, errors | Which servers to connect and how to present them |
| Validates | Input, before touching any real system | Whether a call is appropriate for this task at all |
| Knows the user | No, and it should not need to | Yes, it is driving the conversation |
| Scales by | Exposing more or narrower capabilities | Connecting more servers without changing the model |
| Typical mistake | Encoding business rules or user preferences | Hard-coding which tool to call |
How one call moves
It reaches the server and learns which capabilities exist, along with their names, descriptions, and schemas.
Capabilities are presented as callable options. The model decides whether any of them fits the current request.
Bad input is rejected before anything real is touched. If the call is valid, the capability runs.
The client hands the result to the model, which continues the conversation with usable fields rather than raw text.