Introducing MCP

A user types into your chat interface: "What open pull requests are there across all my repositories?" To answer, Claude needs to reach into GitHub. GitHub has repositories, issues, pull requests, projects, releases, actions — a sprawling API surface. Without MCP, you are the one writing and maintaining tool schemas for every endpoint you want Claude to touch. Every new feature request turns into more integration code you have to test, ship, and keep alive.

Model Context Protocol is a communication layer that gives Claude context and tools without requiring you to hand-author and maintain every integration. MCP shifts the burden of tool definition and execution off your server and onto dedicated MCP servers that specialise in wrapping a single outside service.

The architecture, in one picture

An MCP Client lives inside your server. It connects to one or more MCP Servers, each of which exposes a standard set of primitives: tools, resources, and prompts. Each MCP Server is an interface to an outside service — GitHub, AWS, a database, whatever — and packages that service's capabilities behind a consistent protocol.

Your application code never talks to GitHub directly. It talks to the MCP client, which talks to the GitHub MCP server, which talks to GitHub. The boundaries are clean, and the surface area you maintain collapses.

The problem MCP solves

Without MCP, building that GitHub-aware chatbot looks like this:

• Before: You write a get_repos tool schema. Then list_pull_requests. Then get_pr_details. Then list_commits. Then get_issue. You test each one, handle each one's edge cases, and keep them all in sync as GitHub's API evolves. Multiply by every other service your product needs to touch.
• After: You connect to a GitHub MCP server. It already has those tools, already tested, already maintained — often by the service provider themselves.

The work does not disappear — someone has to write those tools. The point is that it does not have to be you, for every service, forever.

How MCP servers actually work

An MCP server is a standardised interface to some outside capability. It wraps a service's functionality as a set of pre-built tools (and, as you will see later, resources and prompts). Your application connects to the MCP server instead of reimplementing the service from scratch.

In the GitHub example, the GitHub MCP server exposes something like get_repos(), handles the HTTP calls and authentication, and returns structured results. Your code stays focused on the chat loop and the model — not on the shape of a pull request JSON response.

Questions that come up first

Who authors MCP servers? Anyone can. In practice, service providers increasingly publish their own official implementations — AWS, GitHub, and others have an obvious incentive to control the canonical integration. Community-authored servers fill in the rest.

How is this different from calling an API directly? If you call an API directly, you are also writing the tool schemas and the functions that back them. MCP gives you those for free. Same underlying HTTP call at the bottom — different question about who does the wrapping work.

Isn't MCP just tool use by another name? No, and this is the misconception to kill early. Tool use is how Claude calls a tool: the model decides it needs a capability, emits a tool call, and your code executes it. MCP is about who wrote the tool in the first place. The two are complementary — MCP servers expose tools that Claude then uses via normal tool use. MCP's contribution is the standardised packaging and the shifted authorship.

The practical value is simple: instead of maintaining a sprawling set of integrations yourself, you lean on MCP servers that handle the heavy lifting. Your server becomes a much thinner thing — orchestration and product logic, not endless integration plumbing.