MCP Explained in 10 Minutes

Every new developer tool gets explained like it requires a PhD to understand.

MCP doesn't. I'm going to explain it in plain language, show you a real example from my daily setup, and tell you why it matters even if you're not building AI products.

MCP in Three Sentences

1. MCP (Model Context Protocol) is a way to give AI models access to tools.
2. A "tool" is just a function the model can call — read a file, query a database, send an email, search the web.
3. You describe what each tool does, and the model figures out when to use it.

That's the whole concept. Everything else is implementation detail.

A Real Example From My Setup

I use a tool called gog — a Google Workspace CLI. It connects to my Google account and can:

• Read my calendar • Send and search emails • Search my Drive • Manage contacts and tasks

When I tell Claude "check my calendar for tomorrow," here's what happens:

1. Claude sees that gog is available and knows its capabilities
2. It recognizes that "check my calendar" maps to calendar access
3. It calls gog calendar list --date tomorrow
4. It parses the response
5. It gives me a human-readable summary

I didn't program "if user asks about calendar, then call this specific command." I described what the tool can do once. The model handles the matching from then on.

Same tool, different request: "Draft a reply to the last email from David about the supplier quote." Claude searches emails, finds the thread, reads the context, and drafts a reply — all by chaining gog commands together. I didn't build a workflow for "reply to emails about supplier quotes." The model understood the intent and used the available tools to get it done.

Why This Is Different From Traditional Integrations

In a traditional automation setup (Zapier, n8n, Make), you build explicit connections:

• Trigger: new email arrives • Action: if from [these people], extract [these fields], send to [this place]

Every connection is a path you defined in advance. Every new path needs new configuration. Miss a scenario, and it falls through the cracks.

With MCP, you define capabilities, not paths:

• "This tool reads email" • "This tool manages calendar" • "This tool searches the web"

The model creates the paths at runtime based on what you ask for. It can combine tools in ways you never explicitly configured.

"Find the email David sent about the kitchen tiles, check when I'm free this week, and draft a reply suggesting a meeting" — that chains three tool calls together without me having built a three-step workflow. The model understood the intent and figured out the sequence.

The mental model flips from "what paths exist" to "what tools are available." The paths emerge from the conversation.

More Tools From My Actual Setup

Beyond gog, here's what my MCP-connected Claude has access to:

• Browser control — navigate web pages, fill forms, take screenshots, interact with web apps. I use this for tasks that live in dashboards and admin panels where there's no API.

• Node management — I have paired devices (Mac, phone) that Claude can interact with. Run commands, take photos, check device status.

• Web search — Brave Search API for real-time information retrieval when Claude needs current data.

• File operations — read, write, search, and organize files across my workspace.

Each tool is described once. Claude uses them as needed, often in combinations I didn't anticipate when I set them up. The tool definitions are stable. The usage patterns are dynamic and emergent.

That's the power of capability-based design. You build the tools. The model figures out the workflows.

Why Builders Should Care

If you're building products, MCP changes the integration story:

Instead of building a custom API connector for every service your AI needs to talk to, you build an MCP server once. That server exposes your service's capabilities as tools. Any MCP-compatible model can use them immediately.

It's the USB-C of AI integrations. One protocol, many tools, any model.

For internal tools, this is even more powerful. Your company has a CRM, an ERP, a project management tool, a support desk. Each of those can be exposed as MCP tools. Suddenly your AI assistant can "check the client's order status, update the ticket, and send them a notification" without you building a bespoke workflow for that exact sequence.

You don't need to anticipate every possible request. You need to describe what your systems can do. The model handles the rest.

The Deeper Shift

The real insight isn't about the protocol itself. It's about the design philosophy underneath it.

Traditional integrations ask: "What will the user want to do?" Then you build that specific path.

MCP asks: "What can our system do?" Then you describe those capabilities and let the model figure out what the user needs in the moment.

You're designing for capability, not for intent. This means you build fewer things that cover more scenarios. Instead of dozens of specific automation recipes, you have a handful of tool descriptions that can combine into hundreds of workflows dynamically.

Less configuration. More emergence. And every new tool you add multiplies the possible combinations without you having to wire them up manually.

Getting Started

If you want to try MCP yourself:

1. Read the spec at modelcontextprotocol.io — it's genuinely well-written and not overly academic. You can understand the core concept in an afternoon.

2. Look at example servers on github.com/modelcontextprotocol/servers — there are dozens of community-built servers for common services like file systems, databases, and APIs.

3. Try Claude Desktop with MCP enabled — it supports MCP tools out of the box. Install a file system server or a web search server and watch the model use them naturally.

4. Build one simple tool. A function that does one thing your AI doesn't currently have access to. A database query. A webhook trigger. An internal API call. Describe it in MCP format and connect it.

5. Watch what happens when the model decides on its own that this tool is relevant right now. That moment — when it reaches for a tool you provided without being told to — is when MCP clicks.

The hard part isn't the protocol. It's accepting that you don't need to program every decision path anymore. The model will surprise you with how it combines tools you gave it. And that's a feature, not a bug.

What tool would you build first?

---

Related Guides

• AI Agents Setup Guide — Patterns and stacks for building agents
• Moltbot Bridge Guide — Agent-to-agent communication
• CLI Automation Guide — Practical automation with gog, oracle, and qmd

Related Stories

• Running 15 AI Agents Daily — The full architecture and costs
• How to Migrate From Workflows to Agents — A practical migration guide

Learn More

For the full agent build system, start with the AI Product Building Course.