How MCP Works at a Glance

+15 Mana ✨
MCP Getting Started Guide(DOCUMENTATION)MCP Concepts Overview(DOCUMENTATION)

Introduction

You know what MCP is and why it exists. Before diving into the technical details of architecture and transports in later sections, let us walk through how MCP actually works from the perspective of an end user and a developer. This lesson gives you the mental model you need to understand everything that follows.

Key Concepts

  • MCP Server: A program that exposes tools, resources, or prompts over the MCP protocol. A server might wrap a database, a file system, an API, or any other service.
  • MCP Host: An application (like Claude Desktop or Cursor) that connects to MCP servers and presents their capabilities to an LLM.
  • Tool Call: When an LLM decides it needs to perform an action, it requests a tool call. The host routes this request to the appropriate MCP server, which executes the action and returns the result.
  • Configuration: Users configure which MCP servers their host should connect to, typically through a JSON configuration file.

Real World Context

Imagine you are using Claude Desktop and want the AI to help you manage files on your computer. You add the filesystem MCP server to your Claude Desktop configuration. When you start Claude Desktop, it connects to the filesystem server, discovers its tools (read_file, write_file, list_directory), and makes them available to Claude. When you ask Claude to "read my README file," Claude decides to call the read_file tool, the host routes the request to the filesystem server, and the file content is returned to Claude for its response. All of this happens through MCP without any custom integration code.

Deep Dive

The MCP Flow in Practice

Here is what happens step by step when you use MCP:

text
1. Configuration: User adds server to host config
2. Connection:    Host starts server and connects via MCP
3. Discovery:     Host asks server what tools are available
4. User Prompt:   User sends a message to the LLM
5. Tool Decision: LLM decides it needs to call a tool
6. Tool Call:     Host sends the tool call to the server
7. Execution:     Server runs the tool and returns results
8. Response:      LLM uses the results in its answer

This flow explains every MCP interaction. Steps 4 through 8 repeat as the conversation continues.

Configuring an MCP Server

In Claude Desktop, you configure MCP servers in a JSON file. Here is what a typical configuration looks like:

json
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "ghp_your_token_here"
      }
    }
  }
}

This configuration tells Claude Desktop to start two MCP servers: one for filesystem access and one for GitHub. The host manages the lifecycle of these servers automatically — starting them when Claude Desktop launches and stopping them when it closes.

What the LLM Sees

When an MCP host connects to a server, it discovers the available tools and presents them to the LLM in a format the LLM understands. From the LLM perspective, MCP tools look like any other function it can call:

text
Available tools:
- read_file(path: string): Read a file from disk
- write_file(path: string, content: string): Write to a file
- create_issue(title: string, body: string): Create a GitHub issue

The LLM does not know or care that these tools come from different MCP servers. It simply sees a list of available tools and decides which ones to use based on the user request.

The Developer Experience

As a developer building an MCP server, your job is straightforward: define your tools with clear names, descriptions, and input schemas. The MCP protocol handles everything else — discovery, serialization, transport, and error handling. You focus on what your tool does, not how it communicates with the host.

Common Pitfalls

  1. Overcomplicating the mental model — MCP is fundamentally simple: servers expose capabilities, hosts connect to servers, and LLMs use those capabilities. Do not overthink the protocol details at this stage.
  2. Forgetting that the LLM decides — The MCP server exposes tools, but it never decides when to use them. The LLM (with optional human approval) makes all tool-calling decisions. Servers are passive providers of capabilities.

Best Practices

  1. Start as a user, then become a builder — Before building your own MCP server, use existing ones with Claude Desktop or your preferred host. This gives you an intuitive understanding of how MCP works from the user perspective.
  2. Think of MCP servers as microservices for AI — Each server should have a clear, focused purpose. A filesystem server handles files. A database server handles queries. Keep them small and composable.

Summary

  • MCP works through a simple flow: configure servers, connect, discover tools, and let the LLM decide when to call them.
  • Users configure MCP servers in their host application through a JSON configuration file.
  • The LLM sees MCP tools as regular functions it can call, regardless of which server provides them.
  • Servers are passive: they expose capabilities and wait for calls. The LLM always decides when to use a tool.
  • As a developer, you define tools with names, descriptions, and input schemas — MCP handles the rest.

Code Examples

json
{
  "mcpServers": {
    "my-tools": {
      "command": "node",
      "args": ["./my-mcp-server.js"]
    }
  }
}
✓ Completed