Introducing MCP

Thu, 15 Oct 2026 00:00:00 +0000

Model Context Protocol (MCP) is a communication layer that provides Claude with context and tools, without requiring you to write a bunch of tedious integration code.

The basic structure:

An MCP Client (your server) connecting to MCP Servers that contain tools, prompts, and resources.
Each MCP Server acts as an interface to some outside service.

The Problem MCP Solves & How MCP Works

Example:

Let’s say you’re building a chat interface where users can ask Claude about their GitHub data. A user might ask “What open pull requests are there across all my repositories?” To handle this, Claude needs tools to access GitHub’s API.
GitHub has massive functionality - repositories, pull requests, issues, projects, and tons more. Without MCP, you’d need to create an incredible number of tool schemas and functions to handle all of GitHub’s features.

This also means writing, testing, and maintaining all that integration code yourself. -> That’s a lot of effort and ongoing maintenance burden!

With MCP:

MCP shifts this burden by moving tool definitions and execution from your server to dedicated MCP servers.
Instead of you authoring all those GitHub tools, an MCP Server for GitHub handles it.
- The MCP Server wraps up tons of functionality around GitHub and exposes it as a standardized set of tools. Your application connects to this MCP server instead of implementing everything from scratch.
MCP Servers provide access to data or functionality implemented by outside services. They act as specialized interfaces that expose tools, prompts, and resources in a standardized way.
- In our GitHub example, the MCP Server for GitHub contains tools like get_repos() and connects directly to GitHub’s API. Your server communicates with the MCP server, which handles all the GitHub-specific implementation details.

How communication works:

Common Questions

Who authors MCP Servers?

Anyone can create an MCP server implementation.
Often, service providers themselves will make their own official MCP implementations. For example, AWS might release an official MCP server with tools for their various services.

How is this different from calling APIs directly?

MCP servers provide tool schemas and functions already defined for you.
If you want to call an API directly, you’ll be authoring those tool definitions on your own. MCP saves you that implementation work.

Interactive example: MCP vs. Calling APIs Directly

Isn’t MCP just the same as tool use?

MCP servers and tool use are complementary but different concepts.

MCP servers provide tool schemas and functions already defined for you, while tool use is about how Claude actually calls those tools.
The key difference is who does the work - with MCP, someone else has already implemented the tools for you.

Benefit: Instead of maintaining a complex set of integrations yourself, you can leverage MCP servers that handle the heavy lifting of connecting to external services.

MCP Clients

Thu, 15 Oct 2026 00:00:00 +0000

The MCP client serves as the communication bridge between your server and MCP servers. It’s your access point to all the tools that an MCP server provides, handling the message exchange and protocol details so your application doesn’t have to.

Transport Agnostic Communication

One of MCP’s key strengths is being transport agnostic - a fancy way of saying the client and server can communicate over different protocols depending on your setup. In other words, MCP’s messages are the same whatever channel carries them.

Example:

Both the MCP client and server can run on the same machine, communicating through standard input/output. But you can also connect them over:

HTTP
WebSockets
Various other network protocols

Local MCP server	Remote MCP server

Analogy: the same letter can go by post or by email. The words don’t change, only the delivery.

Interactive example: Transport Agnostic Communication

## MCP Message Types

Once connected, the client and server exchange specific message types defined in the MCP specification.

Most typicals are:

ListToolsRequest/ListToolsResult: The client asks the server “what tools do you provide?” and gets back a list of available tools.
CallToolRequest/CallToolResult: The client asks the server to run a specific tool with given arguments, then receives the results.

How It All Works Together

A complete example showing how a user query flows through the entire system - from your server, through the MCP client, to external services like GitHub, and back to Claude.

A user asks “What repositories do I have?”

User Query: The user submits their question to your server
Tool Discovery: Your server needs to know what tools are available to send to Claude
List Tools Exchange: Your server asks the MCP client for available tools
MCP Communication: The MCP client sends a ListToolsRequest to the MCP server and receives a ListToolsResult
Claude Request: Your server sends the user’s query plus the available tools to Claude
Tool Use Decision: Claude decides it needs to call a tool to answer the question
Tool Execution Request: Your server asks the MCP client to run the tool Claude specified
External API Call: The MCP client sends a CallToolRequest to the MCP server, which makes the actual GitHub API call
Results Flow Back: GitHub responds with repository data, which flows back through the MCP server as a CallToolResult
Tool Result to Claude: Your server sends the tool results back to Claude
Final Response: Claude formulates a final answer using the repository data
User Gets Answer: Your server delivers Claude’s response back to the user

Note

In practice it’s usually cached.

In the example above, the tool list is being fetched for each question to make the flow clear. Real apps usually fetch the list once when they connect, and again only when the server sends notifications/tools/list_changed. Claude Desktop and Claude Code work this way: they call tools/list at startup, not for every message.