The Two Sides
The Model Context Protocol defines a conversation between two parties. The client is the AI assistant (or whatever hosts the AI model). The server is the tool provider. The client says "I want to use this tool with these parameters." The server executes the tool and returns the result. That's the core interaction.
Confusion arises because people often say "MCP" when they mean "MCP server." When someone says "I installed five MCPs," they mean five MCP servers. The client is usually Claude Desktop, Cursor, or another AI application. You don't install clients the way you install servers; the client is the application you're already using.
What Clients Do
The MCP client is responsible for: discovering which servers are available, connecting to them, learning what tools each server provides, presenting tool calls to the user for approval (if configured that way), and managing the conversation context that includes tool results.
Popular MCP clients include Claude Desktop (the most widely used), Cursor (popular among developers), Windsurf, and several IDE extensions. Each client implements the MCP protocol on its side, which means any server that follows the protocol works with any client. You don't need different server versions for different clients.
The client also handles security. It decides which tool calls to auto-approve and which to present to the user for confirmation. Different clients have different security policies, which is why the same server might behave slightly differently across clients.
What Servers Do
MCP servers are the tools side. Each server exposes one or more capabilities (tools, resources, prompts) through the protocol. When a client sends a tool call, the server executes it and returns the result. Servers can connect to databases, file systems, APIs, or any other data source or service.
Servers run as separate processes. A local server runs on your machine alongside the client. A remote server runs somewhere else (a cloud server, a colleague's machine, a managed service) and communicates with the client over HTTP.
The server doesn't know or care which AI model the client is using. It receives structured requests and returns structured responses. Whether Claude, GPT, or any other model is generating the requests is invisible to the server.
How They Connect
The client's configuration file specifies which servers to connect to. For local servers, this means the command to start the server process. For remote servers, it means the URL to connect to. When the client starts (or when you add a new server), it establishes connections and queries each server for its capabilities.
This discovery step is key. The client asks each server "what can you do?" and receives a list of tools with their names, descriptions, and parameter schemas. The client passes this information to the AI model, which uses it to decide when and how to call each tool.
Why the Distinction Matters
Understanding client vs server helps you troubleshoot issues, evaluate tools, and build your own. If a tool call fails, is the problem in the client (wrong configuration, approval settings) or the server (bug, connectivity, permissions)? If you want to build a tool, you're building a server, not a client. If you want to use a tool, you need a client that supports MCP.
It also clarifies the ecosystem's value proposition. The 137,000+ tools on Skillful.sh are servers. Each one works with any MCP client. Building one server gets you compatibility with every client, and installing one client gives you access to every server. The protocol is the bridge that makes this possible.
Related Reading
- What the Model Context Protocol Actually Does
- How MCP Servers Differ from Traditional APIs
- Getting Started with MCP Servers in 2026
Browse MCP servers on Skillful.sh. Search 137,000+ AI tools.