In December, Anthropic released Model Context Protocol. By March, everyone was building MCP servers.
I built several. Here's what I learned.
What MCP actually is
MCP is a standard way for AI models to use external tools. Instead of copy-pasting results between your tool and Claude, you give Claude direct access to the tool.
Before MCP:
- You ask Claude to search your memory
- Claude tells you to run a command
- You run the command, copy the output
- You paste it back to Claude
- Claude analyzes it
With MCP:
- You ask Claude to search your memory
- Claude calls the MCP server directly
- Done
The model talks to your tools natively. No copy-paste. No context switching.
What I gave the model access to
Each direction is a separate MCP server or a group of tools within one. The model picks the right tool automatically based on what you ask.
Semantic memory and knowledge search
The model can search through thousands of documents by meaning, not keywords. It finds past decisions, worklogs, research notes, project history. It saves new documents with automatic tagging. It tracks versions and shows how a document evolved over time.
Every conversation starts with context. The model searches memory before answering questions about projects, checks recent worklogs before suggesting next steps, saves summaries after completing tasks.
Multi-agent workflows and orchestration
The model can launch complex workflows where multiple AI specialists work in parallel, review each other's output, debate, vote, and produce a synthesized result. Workflows have dependencies, conditional branching, and error recovery.
"Run a deliberation on whether we should use Redis or PostgreSQL for caching" -- and the system launches specialist agents that debate the topic across multiple rounds and return a final recommendation.
AI specialists and intelligent routing
52 domain experts -- security auditor, architect, content strategist, code reviewer, and dozens more. Each specialist is a focused prompt with deep domain knowledge. Instead of asking a general model, you route the question to the specialist who knows the domain best.
A routing layer classifies intent and picks the right specialist automatically. You don't need to remember which agent handles which question. You just ask.
Browser automation
Three levels of web access. Fast HTTP fetch for APIs and simple pages. Headless browser for JavaScript-heavy sites. Full page screenshots and PDF generation for visual analysis.
"Take a screenshot of the staging site and check if the new header is visible" -- the model fetches the screenshot, looks at it, and answers.
Virtual desktops with real browsers
Each agent gets its own isolated desktop -- a virtual display, a window manager, a real Chrome with its own profile, extensions, and session cookies. No shared state between agents. No anti-bot detection. VNC streaming for visual debugging.
"Log into LinkedIn and check post analytics" -- the model acquires an isolated desktop with saved credentials, navigates, extracts metrics, and releases the desktop. No session collisions. No cookie leaks.
Media processing
Image recognition, audio transcription, image generation. The model can analyze a screenshot, transcribe a voice message, or generate an illustration -- all through MCP tool calls.
Notifications and alerts
Send messages through Telegram or email. The model can notify you when a long-running task completes, when diagnostics detect an issue, or when it needs your input on something.
System diagnostics
Health checks, resource monitoring, process management. The model can check CPU, memory, disk usage, Docker container status, and running services.
Document management
Create, version, and discuss documents with AI-powered threads. Each document has a revision history and can be discussed through threaded comments where AI specialists contribute their perspective.
Project planning and task management
Tasks, objectives, roadmaps, progress tracking. The model can create tasks, assign priorities, link them to project milestones, track completion, and generate progress reports.
What makes a good MCP server
After building several, some patterns emerged:
Keep tools atomic. One tool does one thing. Search searches. Save saves. Don't create a do_everything tool that takes 15 parameters.
Return structured data. JSON, not prose. Let the model decide how to present results. If your tool returns "I found 3 documents matching your query about authentication...", you're doing the model's job.
Handle errors gracefully. The model will retry on failure. If your server crashes, the whole conversation stalls. Return error messages, not stack traces.
Document the tools. The model reads your tool descriptions to decide when and how to use them. Vague descriptions lead to wrong tool calls. Be specific about what each parameter does and what gets returned.
The integration effect
The magic isn't in any single server. It's in having everything connected simultaneously.
In one conversation the model can:
- Search memory for context ("what did we decide about the API design?")
- Browse a website for current state ("take a screenshot of the docs page")
- Launch a multi-agent workflow ("run a code review on this PR")
- Use a real browser with saved credentials ("check LinkedIn analytics")
- Ask a domain specialist ("review this auth flow for security issues")
- Save the results to memory for next time
All in one conversation. No switching tools, no copy-pasting, no manual orchestration.
What's still rough
Startup time. Each MCP server is a separate process. Multiple servers mean 5-8 seconds of extra startup.
No streaming. MCP tools return results all at once. For a long-running workflow (3 minutes), you wait 3 minutes for the result. No progress updates in between.
Discovery. With 80+ tools across multiple servers, the model sometimes picks the wrong one. Naming and descriptions matter more than I expected.
Should you build one?
If you have a tool that you use alongside an LLM -- yes. The investment is small (a few hundred lines of Python) and the payoff is large (the model can use your tool directly instead of you copy-pasting).
Start with one server, one tool. Add more as needed.
The protocol itself is the important part. Today it's Claude. Tomorrow it could be any model that supports MCP. Your tools become portable.