Introducing MCP

You want to build a chatbot that lets users ask questions about their GitHub repositories, pull requests, and issues. Step one: give Claude a set of tools that wrap GitHub's API. Step two: realise GitHub has dozens of endpoints across repos, PRs, issues, projects, actions, packages, and more. Step three: spend a week writing and maintaining the integration. Model Context Protocol is the pattern that says "stop writing that integration — someone else already did, and you can connect to their work."

What MCP is

Model Context Protocol is a standardised communication layer that lets applications access pre-built integrations through dedicated MCP servers. Instead of every application re-implementing a GitHub integration, a Slack integration, a Jira integration, or any other service, an MCP server for each service can expose those integrations once — and any MCP-aware application can plug into it.

The architecture is simple on paper:

• MCP Client — your application. It speaks the MCP protocol and knows how to discover and invoke tools on MCP servers.
• MCP Server — a dedicated process that wraps some external service and exposes tools, prompts, and resources to any MCP client that connects.

You don't write the GitHub tools. You connect to the GitHub MCP server and use the tools it already provides. Same pattern for AWS, Stripe, Postgres, Slack, filesystems, search engines — whatever someone has written an MCP server for.

Why this matters

The thing MCP actually fixes is the tool function multiplication problem. Tool use, as you built it in Module 6, requires writing a schema and a function for every single capability you want Claude to have. That's fine for a three-tool reminder assistant. It's brutal for anything real:

• GitHub has hundreds of endpoints. A complete GitHub chatbot needs schemas and handlers for every one you want to support.
• AWS has dozens of services, each with its own API. Wrapping even one service deeply is a serious project.
• A company's internal tooling has its own APIs, auth models, and edge cases.

If every application built on Claude has to re-author all of that, the ecosystem is locked into slow, duplicated, brittle integration work. MCP servers break the lock. Someone writes the GitHub MCP server once, and every Claude application that needs GitHub access plugs into it in minutes.

Who writes MCP servers

Anyone can. Some patterns you'll see in practice:

• Official service integrations. Companies publish official MCP servers for their own services — GitHub, AWS, Stripe, and the rest eventually all end up with blessed implementations. This is the cleanest source because the server tracks the underlying API faithfully.
• Community servers. Open-source developers publish MCP servers for services that don't have official ones, or for niche needs. Quality varies, but the ecosystem fills gaps fast.
• Internal servers. Your own company can build an MCP server that wraps your internal APIs and expose it to Claude-powered internal tools. Once the server exists, every new Claude feature can plug into it without re-implementing anything.

The developer ergonomics win — write once, integrate many — is what makes MCP worth understanding even if you start by building your own tools with custom schemas.

How MCP differs from calling an API directly

This is the question everyone asks, and the answer is straightforward: MCP servers provide tool schemas and function implementations already defined for you; calling an API directly requires you to author those tool definitions yourself.

When you make a direct API call (the Module 6 pattern), you own the whole stack: the function that hits the API, the schema that describes the function, the dispatch logic, and any auth management. When you connect to an MCP server, all of that comes pre-packaged. You get a list of ready-to-use tools and you call them — the server handles the schema, the execution, and typically the auth.

"Isn't MCP just tool use?"

This is the single most common misconception. MCP servers and tool use are complementary, not alternatives.

Claude's tool use — the protocol where Claude requests a tool call and your application runs it — is the substrate. MCP sits on top of that substrate and answers a different question: who is responsible for authoring and maintaining the tools?

• Direct tool use (Module 6): your application owns the tool schemas and functions. You write them, you maintain them, you're responsible for tracking the upstream API.
• MCP: a dedicated MCP server owns the tool schemas and functions. Your application connects to the server and uses whatever tools it exposes. You don't write the schemas; you consume them.

Under the hood, MCP still results in tool_use blocks flowing between Claude and your application. The mechanics you learned in Module 6 still apply. MCP is about delegation — shifting the burden of tool authorship from every application to a shared server — not about replacing tool use.

The practical upshot

In the rest of this module you'll build both sides of an MCP connection:

• An MCP server for an in-memory document store with read and edit tools.
• An MCP client that connects to it, discovers the tools, and lets Claude use them.
• Additional MCP features like resources and prompts that extend the protocol beyond tools.

You wouldn't normally build both halves in production — you'd pick one side of the connection and use existing work on the other. For learning purposes, building both is the fastest way to understand what each half is actually doing and why.

By the end of the module you'll know enough to either (a) expose a service as an MCP server for other developers to use, or (b) plug an existing MCP server into a Claude-powered application. Both are legitimate production patterns and both are increasingly common in real systems.