What MCP Actually Is — Signal Over Noise Members

Module 1: What MCP Actually Is

Claude is good at thinking. It’s less good at knowing what’s in your calendar, or what emails arrived this morning, or what’s currently in your database. Not because it can’t reason about those things — it can — but because it can’t see them. By default, Claude only knows what you put in the chat window.

MCP fixes that.

Model Context Protocol is an open standard that lets Claude connect to external systems. Tools, data sources, services. Instead of you copying content into a prompt, Claude can reach out and fetch it directly. Instead of you running a command and pasting the result, Claude can run the command itself.

It’s like plugins, but built on an open standard that anyone can implement. Anthropic published the spec, other companies adopted it, and now there’s an ecosystem of servers that connect Claude to the things you already use.

The Problem It Solves

Here’s a common pattern before MCP: you want Claude to help you plan your week. So you open your calendar, copy the events, paste them into Claude, explain the format, and then ask your question. If the calendar changes, you start over.

With an MCP calendar server, Claude can read your calendar directly. You ask “what’s my week looking like?” and Claude checks. No copying, no pasting, no format explanations. The information is live, not a snapshot.

Same pattern applies to email, files, databases, APIs. Any system you currently copy-paste from into Claude is a candidate for an MCP connection.

How It Actually Works

MCP has three parts:

The host — Claude Code (or Claude Desktop) is the host. It manages connections and decides which servers are available.

The server — A small programme that exposes tools. A calendar server exposes tools like get_events, create_event, check_availability. A file search server exposes search_files, read_file. The server is what connects to the actual service.

The protocol — The standard that host and server use to talk to each other. JSON-RPC over stdio. The host asks “what tools do you have?” The server lists them. The host passes a tool call. The server executes it and returns the result.

When you ask Claude to check your calendar, Claude picks the right tool, the server fetches the data, and Claude uses it to answer. The whole exchange happens in milliseconds and you see only the answer.

Why the Open Standard Matters

Anthropic could have built proprietary integrations. They didn’t. They published MCP as an open spec and other AI companies adopted it — which means servers built for Claude can often work with other AI tools, and servers built for other tools can work with Claude.

This matters because it changes the economics. If there’s a useful MCP server in the ecosystem, you can just install it. You don’t need Anthropic to strike a partnership with the service provider. The ecosystem grows independent of any single company’s roadmap.

It also means you can build servers. If your company has an internal system that isn’t covered by existing servers, you can write one. The protocol is documented, the tooling exists, and Module 4 walks through the whole process.

What MCP Is Not

MCP is not magic. A server can only expose what the underlying service makes available. If your email provider’s API doesn’t support attachments, the MCP server can’t read attachments. The server is a bridge, not a bypass.

MCP is also not a security boundary. When you install an MCP server, you’re giving Claude access to whatever that server can reach. Think about what permissions the server needs and whether you’re comfortable with those. The same judgement you’d apply to any other integration.

The Current Ecosystem

As of early 2025, there are MCP servers for most things you’d want: Google Calendar, Gmail, Slack, GitHub, Notion, various databases, web search, file systems. Anthropic maintains a reference list. There’s also a growing community of independently published servers.

Some of those servers are well-maintained and production-ready. Some are proof-of-concepts someone put on GitHub after a weekend. Part of what Module 3 covers is how to evaluate what you’re actually getting before you install it.