Anatomy of an MCP

MCP has five primitives. Understand these and you understand the whole protocol.

1. Tools

Functions the model can call. Same mental model as tool use, the MCP server declares a name, description, and input schema; the model decides when to call it.

{
  "name": "search_email",
  "description": "Search the user's email inbox. Use when the user asks about recent messages or needs context from email.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "description": "Search query" },
      "limit": { "type": "integer", "default": 20 }
    },
    "required": ["query"]
  }
}

2. Resources

Data the model can read. Unlike tools, resources don't execute code, they just return content. Examples: a specific document, a database row, a file.

Resources are addressed by URI (like file:///path/to/doc.md or postgres://table/row?id=123). The server can list available resources and return content on demand.

Why not just use a tool? Resources are declaratively addressable, the client can show the user which resources are available and let them pin specific ones into context.

3. Prompts

Reusable prompt templates the server provides to the client. Less widely adopted than tools/resources, but useful for common workflows.

{
  "name": "summarize_thread",
  "description": "Summarize a conversation thread",
  "arguments": [
    { "name": "thread_id", "required": true }
  ]
}

The client can expose these as slash-commands or menu options. The user picks one, fills in the arguments, and the server returns a filled-in prompt the client sends to the model.

4. Servers

The program exposing tools, resources, and prompts. A server is a process (local) or an HTTP endpoint (remote) that speaks the MCP protocol.

Servers have a lifecycle: initialize → list_tools / list_resources / list_prompts → call_tool / read_resource / get_prompt → shutdown.

See Building servers for patterns.

5. Clients

The program consuming MCP. It connects to one or more servers, discovers what they expose, and makes those primitives available to the model.

The client handles:

• Starting and managing server processes (for stdio transport)
• Connecting to server URLs (for SSE/HTTP transport)
• Exposing tools to the model as tool definitions
• Routing tool calls to the right server
• Formatting results for the model
• Permissions: which tools the model can call without approval

Claude Code is a client. IDE extensions are clients. See Clients.

How they fit together

┌──────────────┐   MCP    ┌──────────────┐
│   CLIENT     │◄────────►│   SERVER     │
│ (Claude Code)│          │  (Gmail MCP) │
└──────┬───────┘          └──────────────┘
       │
       │ tool calls + results
       │
       ▼
┌──────────────┐
│    MODEL     │
│  (Claude)    │
└──────────────┘