MCP for Normal People: What Anthropic Actually Built

Model Context Protocol is how Claude connects to your actual tools — your email, your calendar, your files, your databases — instead of just chatting about them. If you've been hearing "MCP" in every AI conversation for the past year and still don't know what it means in practical terms, this is the explainer. No developer jargon. No architecture diagrams. Just what it does, why it matters, and why the hex framework is built on top of it.

What MCP Actually Is

MCP stands for Model Context Protocol. Anthropic released it as an open standard in late 2024, and it has since become the dominant way to connect AI models to external tools and services. In one sentence: MCP is the plumbing that lets Claude do things instead of just talking about doing things.

Before MCP, your interaction with Claude was a conversation. You typed a question, Claude typed an answer. If you wanted Claude to send an email, you'd ask it to draft the email, then you'd copy that draft, open Gmail, paste it, and hit send. Claude was the brain in a jar — smart, but disconnected from everything. MCP gives Claude hands. When an MCP connector for Gmail is running, Claude doesn't draft the email for you to copy. Claude sends the email. When an MCP connector for Google Calendar is running, Claude doesn't tell you what's on your schedule. Claude reads your calendar and tells you what's there — live data, not a guess.

Each MCP connector is a small server — usually running locally on your machine — that bridges Claude and one external service. There's a connector for Gmail, one for Google Calendar, one for Google Drive, one for your local filesystem, one for various databases, one for browser automation. Each connector gives Claude a specific set of capabilities: read emails, create calendar events, list files in a directory, execute a database query. The connector handles authentication, permissions, and the actual API calls. Claude just asks for what it needs, and the connector translates that into the right API request.

Why This Is Different from ChatGPT Plugins

If you were around for the ChatGPT plugin era in 2023, you might be thinking "we've seen this before." We have. And it failed. Understanding why it failed explains why MCP is architecturally different and why it's worth paying attention to this time.

ChatGPT plugins were cloud-hosted services that OpenAI maintained centrally. Each plugin required a third-party developer to build and host the integration, OpenAI to approve it, and the whole system to work through OpenAI's servers. The result was a plugin store with hundreds of entries, most of which barely worked, many of which were abandoned within months, and all of which routed your data through third-party infrastructure you couldn't inspect. The user experience was browsing a store, installing a plugin, hoping it worked, and being disappointed roughly 60% of the time [VERIFY — based on community reports from 2023, not formal data].

MCP inverts this model. Connectors run locally — on your machine, under your control. There's no app store. There's no approval process. If you can run a small server on your computer (or someone has packaged one for you), you can connect Claude to anything. Your data doesn't leave your machine unless the connector explicitly sends it somewhere — and you can read the connector's code to verify that. The ecosystem is open source, community-driven, and growing fast precisely because the barrier to building a connector is low.

The practical difference is reliability. ChatGPT plugins were flaky because they depended on third-party infrastructure and centralized approval. MCP connectors are reliable because they run on your hardware, connect directly to your accounts, and fail in ways you can debug locally. When your Gmail MCP connector stops working, the error is on your machine. You can fix it. When a ChatGPT plugin stopped working, you opened a support ticket and waited.

What It Means for Non-Developers

Here's where most MCP explainers lose normal people: they start talking about JSON-RPC protocols and server specifications and transport layers. You don't need to know any of that. What you need to know is what MCP lets you do that you couldn't do before.

You can say "check my email for anything from my accountant this week and summarize it" — and Claude actually opens your email, searches for messages from your accountant, reads them, and gives you a summary. No browser tab. No manual search. You didn't paste anything.

You can say "look at my calendar for Thursday, find a 90-minute gap, and create a meeting called 'Content Planning' with a note about the Q2 editorial calendar" — and Claude reads your real calendar, finds the gap, and creates the event. In your actual Google Calendar. With the note attached.

You can say "read the markdown files in my /content/ folder, find the ones tagged 'draft,' and list them with their word counts" — and Claude accesses your filesystem, scans the directory, reads file metadata, and gives you a table. Files on your actual hard drive. Not a hypothetical exercise.

This is the shift. Claude goes from being a tool you talk to — getting advice, generating text, brainstorming — to a tool that acts on your behalf across your actual digital environment. The hex framework exists to answer the question that immediately follows: "If Claude can connect to everything, which things should I actually connect it to?"

The Current State of MCP

Honesty requires a status report. Not everything works equally well, and the gap between "technically possible" and "reliable enough to depend on" is real.

What works well right now: file system access is rock solid. Claude can read, write, create, and manage files on your machine with high reliability. Browser automation — navigating web pages, reading content, filling forms — works and is getting better with each update. Code execution through the terminal is Claude Code's bread and butter and has been production-grade for months. Google Drive integration — reading and writing docs, sheets, and slides — is solid.

What's functional but still maturing: email integration works but can be finicky with authentication flows. Calendar access is reliable for reading events and creating simple ones, but complex recurring events or multi-calendar setups can trip it up. Database connectors work well for simple queries but get unreliable with complex joins or large result sets [VERIFY — based on community reports, varies by database type and connector version].

What's still rough: most third-party SaaS integrations beyond Google's ecosystem are community-built and vary wildly in quality. Some are excellent. Some haven't been updated in months. The MCP ecosystem is growing fast, which means the average quality of connectors is improving, but the variance is high. If the tool you need isn't Google, GitHub, or filesystem-related, check the connector's last commit date before you invest time setting it up.

The trajectory matters more than the snapshot. MCP went from "interesting experiment" to "production infrastructure" in about twelve months. Anthropic is actively developing the specification, the community is building connectors at an accelerating rate, and other AI providers are starting to adopt or interoperate with the protocol. Building on MCP now is not a bet on a speculative future — it's an investment in infrastructure that's already shipping improvements weekly.

How to Think About MCP

The best mental model is plumbing. MCP is the pipes. Each connector is a pipe that runs from Claude to one of your tools. The hex framework is your decision about which pipes to connect. And the work — the emails sent, the files organized, the content published, the calendar managed — is what flows through the pipes.

Most people, when they discover MCP, do the same thing they do with every new technology: they try to connect everything. Every connector they can find. Gmail, Calendar, Drive, Slack, Notion, every database they've ever used, their smart home system, their Spotify account. It's the same impulse that leads to fourteen subscriptions and zero workflows. The technology enables the connection, but the connection isn't the point. The work is the point. The pipes are only useful if something flows through them regularly.

This is why MCP and the hex constraint are complementary rather than redundant. MCP provides the capability — Claude can connect to anything. The hex provides the discipline — Claude should connect to six things. Without MCP, the hex is a nice idea with no infrastructure. Without the hex, MCP is a garage full of pipes and no blueprint. Together, they give you a system that's powerful enough to be useful and constrained enough to actually run.

The next article in this series covers the psychological case for why constraints work — not just for AI tool stacks, but for creative and productive work in general. If you're the person who's already thinking "but what if I need seven connectors," that one's for you.

This is part of CustomClanker's Hex Explained series — you downloaded the hex, here's context.