TLDR

MCP separates “what to do” from “how to do it” by decoupling business logic (Host) from tool execution (Server), with Clients as the standardized bridge between them. Hosts manage user interaction and AI reasoning, while Servers expose capabilities as reusable interfaces. Through standardization, MCP enables agentic AI that dynamically discovers, orchestrates, and composes capabilities across systems.

The Problem: Combinatorial Explosion of Developmental Effort

Suppose we want to send emails from our AI application serving doctors for a hospital. Before MCP, you’d write the integration logic to call an email API, handle its response, wire it to the model and glue on business logic. Now imagine doing this for appointment reminders over patient phone-calls, and for other apps like e-commerce sale notifications — all using the same email API. Without MCP, you’d re-implement the same integration logic across multiple clients and use cases. Any breaking change in the email API? I hope you enjoy refactoring all over the place. 😤

MCP ✨ is a linear solution to the quadratic problem of integration complexity. It’s like what React components did for UI — modular, declarative, and composable.

What is MCP?

Just as USB-C eliminated the need for multiple cables and ports, MCP provides a universal way for AI apps to talk to external tools and data sources. The key components are:

• 💻 MCP Hosts: AI applications that initiate requests and handle user interaction — like Claude Desktop. A host can connect to multiple MCP servers through clients.
• 🔌 MCP Clients: Built into hosts, they take care of server interaction. Each client connects to a single MCP server.
• ⚙️ MCP Servers: Expose tools, prompts, or resources for the client to use.

Anyone can write their own host, client, or server — or simply plug into the 4200+ existing capabilities on Smithery.ai.

How It Works

User starts your AI application → makes a request (e.g. “Remind so-and-so about their appointment”) → the MCP client checks if it has the right tool (like send_email) and enough context → it invokes the tool via an MCP server — a small process running locally (via stdio) or remotely (via HTTP Streamable or even custom) → the server processes the request and returns the result → the AI includes it in its response → user sees the final reply.

For more details into its inner workings, see specification of architecture here.

Why MCP?

MCP enforces separation of concerns, promotes reusability, and drastically simplifies maintenance.

Beyond APIs

APIs are limited compared to MCP in two key ways:

1. Function vs. Architecture - APIs expose functions within a single application. MCP provides architecture that works across applications. Build once, use anywhere.
2. Fixed vs. Adaptive - APIs use hardcoded triggers. MCP allows AI to decide what tools to use based on context, enabling flexible, intelligent workflows.

MCP turns APIs into agent-ready capabilities - enabling agents to autonomously reason and compose over APIs as necessary. It’s the difference between calling a service and orchestrating intelligent, flexible workflows at scale. Just as web devs moved from static HTML to reusable components, MCP helps AI engineers move from integrations that are brittle and fixed to dynamic, context-aware agentic software that respond to user needs in real-time. 🚀

Beyond Anthropic

Introduced by Anthropic, MCP is growing rapidly with support from major LLM players and community contributions.

• OpenAI officially supports MCP in their Agents SDK, with OpenAI API and ChatGPT desktop app coming soon
• Microsoft developed the official C# SDK for MCP, integrating the protocol into Copilot Studio, VS Code’s GitHub Copilot agent mode, and Semantic Kernel
• Major platforms like GitHub, Slack, and Cloudflare added official MCP connections
• Many official language SDKs available: Python (Anthropic), TypeScript (Anthropic), Java (Spring AI), C# (Microsoft), Kotlin (JetBrains), Swift (Loopwork AI), and Rust (Anthropic)
• Authorization using OAuth 2.1 was released on March 26

The ecosystem is in its early days, and the quickest way to test waters is to connect a host to tools yourself.

Limitations & Potential

The usual LLM caveats apply. Already when I installed some servers to try them out, the Obsidian one was failing. MCP is still experimental and mostly local, and I see it as a blueprint for an emergent future. It’s the missing piece for building truly modular, recursive, self-extending AI-native applications.

Getting Started

I’ve found it easiest to try MCP out as a user as follows:

1. Get a Client: Download Claude Desktop: claude.ai/download or any existing host.

2. Handle Dependencies: Install Node.js if you do not already have it.

3. Find Servers: Browse smithery.ai and use it to set things up for you.

What Will You Build Next? 👩🏻‍💻

With MCP, I could consolidate my blog writing workflow (currently split between Claude, Obsidian, and ChatGPT across different devices) into a single, cohesive experience instead of context-switching constantly.

The next time you are tempted to write another API integration, remember: MCP lets you write once, use everywhere, and focus on what matters - building great AI applications. So what will you build next?