I Run 5 MCP Servers. Here's What They Actually Do.

Sometime last year I started seeing "MCP" everywhere. Twitter threads. Dev newsletters. Conference talks. Most of the explanations were either too abstract ("it's a protocol for connecting AI to tools!") or too enterprise ("IBM's new MCP-powered agentic framework transforms business operations"). Neither one told me what I actually wanted to know: what does this thing do, in practice, for a working developer?

So I built some. I now run five MCP servers as part of my daily development workflow. They connect to Claude Code — the AI coding assistant I use in my terminal — and give it access to different AI tools and models. I'll walk through what MCP actually is, why it exists, and what my specific setup looks like.

MCP in Plain English

Model Context Protocol is a standard for connecting AI assistants to external tools and data sources. That's it. It's a communication format — think of it like USB for AI.

Before MCP, if you wanted an AI assistant to do something outside its built-in capabilities — search the web, query a database, call an API — you had to write custom integration code for each combination of AI and tool. Claude talks to Notion one way, ChatGPT talks to Notion a different way, and if you switch assistants you start over.

MCP standardizes that. You build an MCP server that exposes tools (functions the AI can call), and any MCP-compatible client (Claude Code, Cursor, Windsurf, whatever) can use them. Build once, works everywhere.

My Setup

I have five MCP servers configured globally on my machine. They're all Node.js apps that I built. Each one wraps a different AI provider and exposes its capabilities as tools that Claude Code can call while I'm working.

What the Day-to-Day Looks Like

Here's a real example from last week. I was building a new page for a client site and needed to:

1. Research their competitor's SEO approach
2. Generate a first draft of page content
3. Write the HTML template
4. Review the code for issues

Claude Code handled the orchestration. It called gemini-research to research the competitor. It called groq-fast to generate a quick content draft. It called opencode_kimi_free to scaffold the HTML. Then it called ollama-local to do a code review pass. All of this happened within a single conversation. I didn't manually switch between tools or copy-paste between windows.

Building Your Own MCP Server

The barrier to entry is lower than most tutorials make it seem. An MCP server is a Node.js app that:

1. Declares a list of tools (name, description, input parameters)
2. Handles incoming tool calls and returns results
3. Communicates via stdin/stdout (the simplest transport) or HTTP

My servers are each around 100-200 lines of code. The bulk of the work is setting up the API client for whatever provider you're wrapping and defining sensible tool descriptions so the AI knows when to use each one.

You configure MCP servers in a JSON file. For Claude Code, it's ~/.claude/settings.json. Each server entry specifies the command to run it and any environment variables (like API keys). Once configured, the tools are available in every project automatically.

When MCP Makes Sense (and When It Doesn't)

The other thing to know: MCP is still young. The spec is stable but the tooling around it is evolving. Debugging can be annoying — when a tool call fails, the error messages aren't always helpful. I've spent more time than I'd like staring at stderr output trying to figure out why a server isn't connecting. It gets better with each update, but set your expectations accordingly.

Where This Is Going

I think MCP or something like it becomes standard infrastructure for developers within the next year. The pattern of "AI assistant + specialized tool servers" is just too useful to stay niche. I've already written about how this integrates into a broader knowledge management workflow. Microsoft, Google, and Amazon are all building MCP-compatible systems. The ecosystem is growing fast.