I want to tell you about a Tuesday morning.
Dwight finishes a research brief. The brief lands in intel/data/. Jim dispatches Karen to write a blog post from it. Karen drafts the post, saves it to content/drafts/, and publishes it to Notion, a real Notion URL, in my publishing workspace, with the right page type and the right parent. Jim sends me a Telegram message: “Draft ready. Here’s the link.”
I’m making coffee. My phone buzzes. I open the link.
Nothing I just described required me to open a browser, copy text, navigate to Notion, paste anything, or check a queue. The agents went from research to draft to published page to notification with no manual handoff.
That’s MCP. Not the spec, the experience.
What MCP actually is
Model Context Protocol is an open standard Anthropic published in December 2024. It defines how AI models connect to external tools and data sources. The analogy that works best for me: it’s like a universal adapter. Instead of each AI vendor building custom integrations for every tool (Notion, Slack, GitHub, Gmail, Google Calendar, etc.), MCP defines a standard protocol that any tool can implement once.
As of early 2026, MCP had 97 million monthly downloads. I’m personally one of those downloads. Knowing you’re one of 97 million users of something is a different relationship to a statistic than reading it in a press release.
The spec has been adopted widely: Google’s A2A protocol and Microsoft’s Agent Framework 1.0 both interoperate with MCP. The Linux Foundation governs the standard now. It’s not going anywhere.
How it works in my setup
In Claude Code, MCP servers are configured in .mcp.json at the project root. Each agent can also specify mcpServers in its YAML frontmatter — scoped so that agent only gets the tools it needs.
Here’s what my current integrations look like:
Notion — the publishing gate. Every piece of finished content (blog drafts, research briefs, newsletter sections) gets published to Notion before a task is considered done. The Notion MCP server handles the API calls. Karen publishes blog drafts. Dwight publishes research briefs. Rachel publishes newsletter drafts. None of them need to open a browser to do this.
This matters more than it sounds. Before this integration, “done” meant “file saved to repo.” After it, “done” means “Notion URL exists.” That’s a meaningfully different standard. A file in a repo is a working artifact. A Notion page is a deliverable I can open, share, and review.
Telegram — mobile access. The Telegram MCP integration lets agents send me messages, and lets me dispatch tasks from my phone. When a long overnight task finishes, I get a Telegram message with the result. When I’m away from my desk and want to queue something, I can send a message and it lands in the session.
The Claude Code Channels docs describe this as the canonical mobile-access pattern for Claude Code. /plugin install telegram@claude-plugins-official is the command. It requires Bun. Setup takes maybe 20 minutes.
Gmail and Calendar — context. Not for sending emails — just for reading. When an agent needs to know what’s on my calendar today, or whether I’ve already addressed something in an email thread, it can check. This kind of ambient context makes briefings more relevant. Dwight’s daily intel summary is more useful when it knows I have calls in the morning and can flag high-priority items accordingly.
What I tried that didn’t work
Canva.
The vision was: agent designs the visual header for a blog post, publishes it to Canva, links it to the Notion draft. Design integrated into the publishing workflow.
In practice: the designs had garbled text, wrong brand colors, and elements I couldn’t edit in the way I expected. The integration worked technically — the agent could interact with Canva — but the outputs weren’t usable. I’d fix them manually and think “this is saving me no time.”
I stopped using Canva through MCP for finished design work. I use it occasionally for rough templating, with the expectation that I’ll fix it before anything gets published.
This is worth saying out loud: MCP makes the connection possible, but the quality of the connection depends on what the external tool can actually do programmatically. Some tools (Notion, Telegram, GitHub) are well-suited to API-driven interaction. Others (design tools that require pixel-level judgment) aren’t there yet.
The failure taught me something: MCP is most valuable for information exchange and structured actions. It’s less valuable for anything where the quality of the output depends on subjective visual judgment.
The protocol layer view
Here’s the part that’s easy to miss from inside the day-to-day: MCP changes the architecture of what’s possible, not just what’s convenient.
Before MCP, each AI vendor had to build custom integrations for every tool. Claude had a Notion integration. GPT had a Notion integration. They were separate, maintained separately, with different APIs and different behaviors.
MCP means you build the Notion server once, and any MCP-compatible model can use it. You build the Slack server once, and it works across vendors. You build the GitHub server once, and it works in Claude Code, Cursor, the OpenAI Agents SDK, Microsoft Agent Framework.
This is what makes harnesses portable. If you switch from Claude to GPT-5.5 for a specific task, the tools stay the same. You’re swapping the model, not the entire integration stack.
That’s not theoretical. It’s what LiteLLM plus MCP actually enables in practice: model-portable, tool-portable agent systems. Build the harness once, route to the best model for the job.
Why the number matters
97 million monthly downloads of the MCP spec.
What that means, practically: every major tool worth connecting to has either already built MCP support or is building it. The network effects are in place. The bet has been made. You’re not an early adopter anymore, you’re using the thing that won.
The right mental model is infrastructure. When you use HTTPS, you’re not thinking about the spec. You’re thinking about whether your browser connected. MCP is becoming that, the protocol you don’t think about because it just works.
I think about it a little, because I built the connections. But when I’m dispatching a task to Karen and a Notion URL appears in my Telegram 20 minutes later, I’m not thinking about the Model Context Protocol. I’m thinking about whether the draft is good.
That’s the point.