How MCP Works: Clients, Servers, Tools, and the Request Lifecycle

An MCP client is an AI application — Claude Desktop, Cursor, Windsurf, etc. A client can connect to multiple MCP servers simultaneously. Each server is a separate process that exposes a set of capabilities. When the client starts, it initializes connections to all configured servers and receives a list of their capabilities.

A tool is a function the AI can call. Each tool has a name, a description (which the AI reads to decide when to use it), and a JSON schema describing its input parameters. When the AI decides a tool is useful, it sends a tool-call request; the server executes it and returns a result. Examples: execute_query, read_file, search_web.

Resources are read-only data endpoints — think of them like files or API responses the AI can read without executing code. A resource has a URI scheme (e.g., file:// or postgres://) and returns structured content. Resources are less commonly used than tools today, but they're part of the spec.

MCP supports two transports: stdio (the server reads/writes JSON-RPC messages on stdin/stdout — common for local servers) and HTTP SSE (server-sent events over HTTP — used for remote/hosted servers). Most servers you'll install locally use stdio.

1. You ask your AI a question. 2. The AI determines a tool call is needed. 3. The client sends a JSON-RPC request to the server process. 4. The server executes the tool (queries the DB, reads the file, etc.). 5. The server returns the result. 6. The AI reads the result and continues composing its response. This all happens in milliseconds.

By default, MCP servers run as local processes you start. They inherit only the permissions you configure (API keys, DB credentials). The AI client cannot call a server's tool without the server being listed in your config file — so you're always in control of what the AI can access.