Blog

My four-year-old learned to use a shape sorter yesterday. Watching her figure it out reminded me of my experience with MCP servers over the last six months. Not because the toy was sophisticated, but because she had the right context. She already understood that objects have properties, that matching matters, and that trying different approaches leads to success. The toy just gave her the right signals at the right time. For the past six months, I’ve been running MCP (Model Context Protocol) servers in my homelab. Not as demos or proof-of-concepts, but as actual tools integrated into my daily workflow. Cloudflare deployments, WordPress content management, GitHub operations, Kubernetes cluster management. Some have transformed how I work. Others burned more time debugging than they saved. Building context for LLMs is the same problem my daughter faced, just exponentially more complicated. LLMs are missing the additional signals like sizes, shapes, and colors. MCP servers aim to close that gap. Here’s what I’ve learned.

Why MCP Servers Exist

LLMs are incredibly capable and frustratingly limited. They can write brilliant code but can’t see your actual codebase. They understand Kubernetes architecture but don’t know your cluster’s current state. Similarly, they can debug WordPress issues but can’t access your actual site. MCP servers solve this by giving LLMs structured access to external systems. Instead of copy-pasting error logs or describing your infrastructure, you connect the AI directly to the source. The promise is beautiful: AI agents that can actually take action, not just give advice. However, there’s a cost. Just like my daughter would have been overwhelmed if I’d dumped all 12 shapes in front of her at once, LLMs have limits on how much information they can actually process. Every LLM has a context window, a hard limit on how much information it can consider at once. For Claude, that’s 200k tokens. Sounds like a lot until you start feeding it MCP responses. A single Kubernetes MCP query for pod status across a namespace? 3,000 tokens. Your entire WordPress site’s page structure? 15,000 tokens. GitHub repository file tree with recent commits? 8,000 tokens. As a result, stringing together a few MCP calls in one conversation eats through that context window fast. Worse, there’s context poisoning. When you give an LLM too much information, it starts losing track of what matters. Flooding an LLM with marginally relevant MCP responses degrades its ability to solve the actual problem. The reality is messier than the demos suggest.

Three Hard Truths About MCP Servers

MCP Server Compatibility Is a Nightmare

Here’s something nobody tells you: just because an MCP server works perfectly in Claude Desktop doesn’t mean it works in Cursor, Claude Code, or whatever oddly named tool ships next month. I spent three hours one night debugging the GitHub MCP server. It worked flawlessly in Claude Desktop. Beautiful integration, clean responses, perfect tool execution. Then I tried to use it programmatically via a Python script for an automation workflow. Complete failure. Different authentication flow, different response structures, different error handling. The time I spent getting it to work exceeded the time it would have taken to just use the GitHub API directly. That’s the pattern I kept hitting. The demo works. But the production integration breaks in subtle ways.

Security and Scale Are Afterthoughts

MCP servers are a security nightmare waiting to happen. Sure, Anthropic, Cloudflare, and a few others have production-quality implementations. However, every developer with a GitHub account has published an MCP server. Random repositories with 47 stars, zero security audits, and authentication patterns that would make your security team cry. Unless you’re doing due diligence on every MCP server you install, you’re giving random code from the internet access to your infrastructure. The MCP protocol itself doesn’t enforce any security standards. It’s just a communication layer, so security is entirely up to the implementation. Want to scale these beyond your laptop? Good luck. Most MCP servers are designed for single-user, local-only scenarios. When you try to make them available to your team, you hit questions nobody’s answered: How do you handle authentication? How do you manage permissions? How do you audit who did what when something breaks at 3am? The transport mechanisms have gaps too. MCP uses different protocols (stdio, SSE, WebSocket) and not every server implements them well. I found this out with the Kubernetes MCP. Querying pod status? Perfect. Streaming logs from a running container? Intermittent failures and timeouts.

{
  "error": "SSE transport timeout",
  "context": "Streaming response exceeded configured limit",
  "duration": "30000ms"
}

These aren’t bugs exactly. Instead, they’re the growing pains of a young protocol. But when you’re trying to scale beyond your homelab, the gaps become glaring.

Token Costs Add Up Fast

This is the silent killer. Every MCP interaction costs tokens. Not just for the query and response, but also for tool definitions, context passing, and response formatting. Consider asking Claude to check a Kubernetes deployment status using the MCP:

• Tool definition: ~800 tokens
• Query processing: ~200 tokens
• Response formatting: ~1,500 tokens
• Total: ~2,500 tokens for information I could get with kubectl get deployment

For one-off queries, that’s fine. For automation or frequent operations, though, the costs compound quickly. Here’s a real example: a morning deployment check. You ask Claude to verify last night’s release went smoothly. First, it checks Kubernetes deployment status (2,500 tokens). Then it lists the pods (3,200), pulls logs from a failing pod (8,400), checks recent GitHub commits (4,100), grabs the diff (6,800), and reviews Cloudflare traffic (5,200). Six MCP calls, 30,000+ tokens, roughly $0.09 in input costs alone. Do that five times a week and you’re at $24/month for something a bash script could do for free. The value proposition has to be crystal clear. “Slightly more convenient” doesn’t justify the cost. MCP shines when you need Claude to reason across systems or explain findings to someone else. Conversely, it’s overkill for routine checks you could automate.

The GitHub MCP Rabbit Hole

Last week I needed to debug how two services communicate. Different repos, shared message contracts, something wasn’t matching up. I figured the GitHub MCP would help Claude understand both codebases. What followed was a token bonfire. The MCP started searching and listing directories. Next, it pulled file trees and searched for “message” and “contract” and “schema” across both repos. Then it found tangentially related files, asked clarifying questions, and searched some more. Each step burned tokens building context it didn’t actually need. After watching this for five minutes, I killed the conversation. I opened both repos in my browser, grabbed the two Helm manifests I already knew were the problem, and pasted them directly into a fresh chat. Thirty seconds. Zero MCP calls. Claude immediately spotted the mismatch. The MCP approach made sense if I didn’t know where to look. But I did. I just needed Claude to analyze two specific files. Feeding them directly was faster, cheaper, and got me to the answer without the search expedition. The lesson: MCP servers are discovery tools. If you already know what context the LLM needs, skip the MCP and provide it directly. Don’t pay for search when you already have the answer in hand.

Build Your Own MCP Servers

Here’s my take: don’t wait for vendors to build the perfect MCP server for your use case. Instead, build your own. The barrier is lower than you think. You need Python, an LLM to help write the boilerplate, and a clear understanding of what context your AI actually needs. I built a custom MCP server for an internal deployment system in an afternoon:

from mcp.server import Server, stdio_server
from mcp.types import Tool, TextContent

# Initialize the MCP server with a unique name
server = Server("custom-deploy")

# Define what tools this MCP server exposes to the LLM
@server.list_tools()
async def list_tools() -> list[Tool]:
    return [
        Tool(
            name="check_deployment_status",
            description="Check status of application deployment",
            # Input schema tells the LLM what parameters are available
            inputSchema={
                "type": "object",
                "properties": {
                    "app_name": {"type": "string"},
                    "environment": {"type": "string"}
                },
                "required": ["app_name"]
            }
        )
    ]

# Handle incoming tool calls from the LLM
@server.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
    if name == "check_deployment_status":
        # Replace this with your actual deployment status logic
        status = await get_deployment_status(
            arguments["app_name"],
            arguments.get("environment", "production")  # Default to production
        )
        # Return structured text that the LLM can parse
        return [TextContent(type="text", text=status)]

That skeleton gets you 80% of the way there. The remaining 20% is your domain-specific logic, which you already have. Don’t spend money with companies that gate their MCP servers behind unnecessary paywalls. The protocol is open and the tooling is available. Support the companies building real value, like Cloudflare and Anthropic, who are releasing production-quality servers and contributing to the ecosystem. For everything else, build your own.

The Right Context at the Right Time

MCP servers aren’t perfect. They’re expensive and they break in frustrating ways. But they’re solving a real problem: giving LLMs the context they need to be genuinely useful. Just like that shape sorter, it’s not about the sophistication of the tool. It’s about providing the right context at the right time. Show too little and the AI can’t help. Show too much and it loses focus. We’re still figuring out where that line is. I’ll be writing more about individual MCP servers, what works, and what doesn’t. Next up: WordPress MCP in production.

Working on AI tooling for your infrastructure? I help teams figure out what actually works in production, whether that’s custom MCP servers, Kubernetes architecture, or cloud deployments. Let’s talk.