Remember when every printer needed its own driver? Every phone needed its own charger? Every SaaS product needed its own API wrapper, its own auth flow, its own SDK, its own breaking changes every six months?
Model Context Protocol just ended that era for AI.
If you haven't heard of MCP yet, you will. Anthropic open-sourced it in late 2024, and by mid-2026 it's become the connective tissue of every serious AI system I've seen. Not because it's trendy — because it solves a problem that was silently killing AI adoption.
The Integration Tax
Here's what building AI agents looked like before MCP:
You want your agent to send emails? Write a Gmail API wrapper. Read Notion pages? Another wrapper. Check Stripe revenue? Another one. Manage DNS? Deploy to Vercel? Post to Slack? Query a database?
Every integration meant:
- Learning a different API surface
- Managing separate auth flows
- Handling different error formats
- Writing custom serialization
- Maintaining it all when APIs change
I've built agents that touch 15+ services. Before MCP, that meant 15+ custom integrations, each one a potential point of failure. The integration tax alone consumed more engineering time than the actual agent logic.
Most teams never get past three integrations before they give up and go back to Zapier.
What MCP Actually Is
MCP is a standard protocol — JSON-RPC over stdio or HTTP — that lets any AI model talk to any tool through a universal interface. Think of it as USB-C for AI.
An MCP server exposes three things:
1. Tools — functions the AI can call (send email, query database, take screenshot)
2. Resources — data the AI can read (files, database records, API responses)
3. Prompts — reusable templates for common operations
The AI model doesn't need to know how Gmail works internally. It just sees a tool called create_draft with typed parameters. The MCP server handles everything else — auth, API calls, error handling, rate limiting.
AI Model ←→ MCP Client ←→ MCP Server ←→ Gmail API
←→ MCP Server ←→ Stripe API
←→ MCP Server ←→ Notion API
←→ MCP Server ←→ Your Database
One protocol. Every service. The model speaks MCP. The servers speak whatever they need to speak.
Why This Changes Everything
1. Composability without complexity.
Before MCP, adding a new capability to your agent meant writing hundreds of lines of integration code. Now it means adding three lines to a config file:
{
"mcpServers": {
"gmail": { "command": "npx", "args": ["gmail-mcp-server"] },
"stripe": { "command": "npx", "args": ["stripe-mcp-server"] },
"notion": { "command": "npx", "args": ["notion-mcp-server"] }
}
}
Your agent instantly gains the ability to read email, check revenue, and update project docs. No SDK. No wrapper code. No maintenance burden.
2. Tool discovery is automatic.
When an MCP server connects, it announces its capabilities. The AI model knows exactly what tools are available, what parameters they accept, and what they return. No hardcoded tool lists. No stale documentation. The integration is self-describing.
3. Auth is the server's problem.
Each MCP server manages its own authentication. Your AI agent never touches API keys directly. The Gmail server handles OAuth. The Stripe server handles API keys. The database server handles connection strings. Separation of concerns, enforced by architecture.
4. Community servers are multiplying.
The MCP ecosystem is growing fast. There are production-quality servers for Slack, GitHub, Google Calendar, Supabase, Vercel, Notion, and dozens more. The barrier to connecting a new service dropped from "write a custom integration" to "install a package."
How We Actually Use MCP
At Like One, MCP isn't theoretical — it's the backbone of our entire operation. Our primary AI agent connects to 15+ MCP servers simultaneously:
- Gmail — reads and drafts emails autonomously
- Google Calendar — schedules meetings, checks availability
- Slack — monitors channels, sends updates
- Notion — manages project databases
- Vercel — deploys code, checks build logs
- Stripe — monitors revenue, manages subscriptions
- Namecheap — manages DNS records
- Supabase — runs database queries
- Ollama — runs local AI models for processing
- Custom servers — design auditing, music production, social posting
One agent. One protocol. Fifteen services. Zero custom API wrappers.
When the agent needs to check revenue and send a summary to Slack, it doesn't call two different APIs with two different auth flows. It calls stripe_dashboard and slack_send_message through the same protocol. The cognitive overhead is zero.
Building Your Own MCP Server
The real power unlocks when you build custom servers for your own workflows. Here's the skeleton — it's surprisingly simple:
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
const server = new McpServer({
name: "my-custom-server",
version: "1.0.0"
});
server.tool(
"check_inventory",
"Check current inventory levels for a product",
{ product_id: z.string().describe("The product ID to check") },
async ({ product_id }) => {
const level = await db.query("SELECT stock FROM products WHERE id = ?", [product_id]);
return {
content: [{ type: "text", text: JSON.stringify(level) }]
};
}
);
const transport = new StdioServerTransport();
await server.connect(transport);
That's a working MCP server. Your AI agent can now check inventory by calling check_inventory with a product ID. Add more tools for updating stock, creating orders, generating reports — each one is just another server.tool() call.
We've built custom MCP servers for:
- Site design auditing — takes screenshots, runs accessibility scans, checks against Apple HIG guidelines
- Chrome browser automation — navigates pages, fills forms, handles logins through a real browser
- Music production — generates tracks, separates stems, masters audio
Each server encapsulates domain expertise behind a clean tool interface. The AI doesn't need to understand Playwright internals or audio processing pipelines. It just calls the tool.
The Architecture Pattern That Works
After running MCP in production for months, here's the pattern that actually scales:
Layer 1: Core MCP servers (cloud-hosted, always available)
Gmail, Calendar, Slack, Notion, Vercel — the services your agent needs daily. Use community servers. Don't reinvent.
Layer 2: Custom MCP servers (local, domain-specific)
Your business logic. Inventory checks. Client management. Internal tools. Build these yourself. They're small, focused, and easy to maintain.
Layer 3: Local AI servers (Ollama, embeddings, RAG)
Keep sensitive processing local. Run models on your own hardware. Use MCP to expose them to your agent alongside cloud services. Your agent doesn't care where the computation happens.
Layer 4: Automation servers (browser control, file management)
For interacting with systems that don't have APIs. Browser automation. Desktop control. File processing. MCP makes these feel native.
The key insight: MCP servers are composable. Your agent can call a tool from Layer 1, pass the result to a tool from Layer 2, then report via Layer 3 — all through the same protocol. No glue code. No orchestration framework. Just tools calling tools.
What Most People Get Wrong
Mistake 1: Too many tools.
Every tool you expose is a decision the AI has to make. Twenty tools is fine. Two hundred is chaos. Curate aggressively. If a tool isn't called weekly, remove it.
Mistake 2: Vague tool descriptions.
The AI chooses tools based on their descriptions. "Handle email stuff" is useless. "Search Gmail threads by query string, returns thread IDs and snippets" is actionable. Write descriptions like you're writing function documentation for a junior engineer.
Mistake 3: No error context.
When an MCP tool fails, return useful error messages. "Failed" tells the AI nothing. "Authentication expired — re-run OAuth flow" tells it exactly what happened. Good error messages let the AI self-correct.
Mistake 4: Ignoring security boundaries.
MCP servers run with whatever permissions you give them. A server with database access can drop tables. A server with email access can send to anyone. Run servers with minimum required permissions. Audit tool calls. Log everything.
MCP vs. Function Calling vs. LangChain
If you're wondering how MCP compares to what you're already using:
Function calling (OpenAI, Anthropic) is how the model formats a tool request. MCP is how that request gets routed to the actual service. They're complementary, not competing. MCP standardizes the transport layer that function calling leaves unspecified.
LangChain/LlamaIndex are orchestration frameworks. They define how to chain calls together. MCP defines how to make the calls in the first place. You can use MCP inside LangChain, or you can skip the framework entirely — MCP works fine with a simple agent loop.
Custom REST wrappers are what MCP replaces. If you're writing bespoke API clients for every service your agent touches, MCP eliminates that entire category of work.
Where This Goes Next
MCP is still early, but the trajectory is clear:
Every major AI platform will support it. Every SaaS company will ship an MCP server alongside their API. The competitive moat for integration platforms (Zapier, Make, n8n) will narrow dramatically when any AI agent can connect to any service through a universal protocol.
The winners will be the teams that build domain-specific MCP servers — the ones that encode real business knowledge into tools, not just API pass-throughs. A "check inventory" tool that also calculates reorder points and flags anomalies is worth ten times more than a raw database query.
The companies that treat MCP as plumbing will miss the point. It's not plumbing. It's the nervous system of autonomous AI operations.
Start Here
If you're building AI agents and haven't adopted MCP yet:
1. Pick one integration you're maintaining manually. Email, Slack, whatever is most painful.
2. Replace it with a community MCP server. Most take under 10 minutes to set up.
3. Measure the difference. Lines of code removed. Maintenance hours saved. Reliability gained.
4. Build one custom server for a workflow unique to your business.
5. Repeat until your agent runs your entire operation.
That last step isn't hypothetical. We're living it. One protocol. Every service. Zero integration tax.
The future of AI isn't smarter models. It's smarter connections.
MCP Server Examples for Common Workflows
Here are proven MCP configurations for the most common AI agent workflows, based on what we run in production daily.
Customer Support Agent
Connect Gmail (read tickets), Notion (knowledge base lookup), and Slack (escalation alerts). The agent reads incoming emails, searches your docs for answers, drafts replies, and escalates edge cases to your team channel. Three MCP servers replace an entire support tool subscription.
Content Publishing Pipeline
Connect a custom CMS server (draft management), Google Search Console (performance data), and social media servers (distribution). The agent checks which posts need updating based on search performance, makes edits, publishes, and distributes — all through MCP tool calls.
DevOps Monitor
Connect Vercel (deployment status), GitHub (PR checks), Supabase (database health), and a custom alerting server. The agent monitors builds, catches failures, reads logs, and either fixes issues autonomously or alerts with full context. We run this pattern 24/7 on a $0/month cron.
Financial Operations
Connect Stripe (revenue tracking), a custom invoicing server, and email (client communications). The agent monitors subscription changes, generates invoices, follows up on failed payments, and sends revenue reports — turning manual bookkeeping into an autonomous loop.
MCP Troubleshooting: Common Issues and Fixes
After running MCP in production for months across multiple machines, here are the issues you'll actually hit and how to solve them.
Server won't connect: Check that the command path is correct and the binary exists. MCP servers launched via npx need Node.js installed globally. Python servers need the right virtual environment activated. Run the server command manually first to verify it starts.
Tools not appearing: The MCP client discovers tools on connection. If tools are missing, the server might be crashing silently during initialization. Check stderr output. Most frameworks log to stderr by default — pipe it to a file for debugging.
Authentication failures: Each MCP server manages its own auth. If a tool returns auth errors, the issue is between the server and the external API, not between the AI and the server. Check that API keys, OAuth tokens, or service account credentials are configured in the server's environment.
Slow tool responses: MCP adds minimal overhead — the bottleneck is almost always the external API. For time-sensitive operations, consider caching responses in the MCP server itself. A server that caches DNS lookups or database schemas will respond 10x faster than one that queries fresh every call.
Server crashes mid-session: Use a process supervisor like launchd (macOS) or systemd (Linux) to auto-restart MCP servers. In production, we wrap every server in a launchd service with automatic restart on failure. The MCP client reconnects transparently.
Too many concurrent servers: Each MCP server is a separate process. Running 20+ servers on a machine with limited RAM will cause problems. Monitor with ps aux | grep mcp. Consider consolidating related tools into fewer servers — one "Google" server can expose Gmail, Calendar, and Drive tools together.
Keep Reading
MCP Implementation
Ready to integrate MCP into your AI infrastructure? Our consulting team specializes in Model Context Protocol deployments for enterprise teams.
- MCP Server Security: The Checklist Nobody Wrote Yet
- How to Build a RAG System in 2026 (The No-Hype, Actually-Works Guide)
- Build Your First AI Agent with Claude Agent SDK
- How to Build an AI Agent That Actually Works in 2026
- Persistent Memory in AI Systems: Complete Guide
---
Sophie Cave is the founder of Like One, where AI agents run the entire company. She builds autonomous systems, teaches AI engineering, and publishes everything she learns along the way.