Claude Code knows your code. It reads your files, understands your architecture, and can debug a NullReferenceException in seconds. But ask it to check whether your last deployment succeeded, query a database, or read an email — and it draws a blank.

That always felt like a missed opportunity to me. The AI understands my codebase, but it can’t talk to the systems I work with every day.

What if you could change that?

What is MCP?

MCP stands for Model Context Protocol. It’s an open standard that lets AI tools like Claude Code communicate with external systems through so-called “MCP servers.”

Think of it as a USB port for AI. Your laptop doesn’t know what device you’ll plug in — a keyboard, a webcam, an external drive — but it can talk to all of them through a standard interface. MCP works the same way. You build a server that exposes “tools,” and Claude Code can call those tools when it needs them.

No custom integrations. No API glue code in your prompts. Just a standardized protocol.

What can you build with it?

The possibilities are broader than you’d expect. Some examples:

  • CI/CD status — Ask Claude Code: “Did the build pass?” and it queries your build server directly.
  • Database queries — “How many users signed up this week?” without leaving your terminal.
  • Deployment triggers — “Deploy the staging branch to test” — Claude Code calls your deployment pipeline.
  • Email — “Are there urgent messages in my inbox?” — Claude Code reads your mail and summarizes.
  • Monitoring — “Any errors in the last hour?” — Claude Code checks your logging platform.

The key idea: anything you can script, you can expose as an MCP tool.

Building your first MCP server

Let’s build a simple one. A server that checks build status and test coverage — the kind of thing you’d normally alt-tab to a browser for.

You need Python and the fastmcp package:

pip install fastmcp

Then create a file, say build_server.py:

from fastmcp import FastMCP

mcp = FastMCP("build-status")

@mcp.tool()
def get_build_status(project: str) -> str:
    """Get the latest build status for a project."""
    # In practice: call your CI/CD API here
    return f"Build for {project}: passed"

@mcp.tool()
def get_test_coverage(project: str) -> str:
    """Get the test coverage for a project."""
    # In practice: fetch from SonarQube, Coverlet, etc.
    return f"Coverage for {project}: 87%"

if __name__ == "__main__":
    mcp.run()

That’s it. Two decorators, two functions, and you have an MCP server with two tools.

The @mcp.tool() decorator registers the function as a tool that Claude Code can discover and call. The docstring becomes the tool description — Claude Code uses that to decide when to call it. The type hints tell it what parameters are expected.

Connecting it to Claude Code

Open your Claude Code settings file (~/.claude/settings.json or the project-level .claude/settings.json) and add your server:

{
  "mcpServers": {
    "build-status": {
      "command": "python",
      "args": ["path/to/build_server.py"]
    }
  }
}

Restart Claude Code. Your tools are now available. Ask “What’s the build status for my-api?” and Claude Code calls get_build_status("my-api") behind the scenes.

No prompt engineering. No copy-pasting API responses. Claude Code handles the tool selection and parameter mapping itself.

From toy example to real tool

I didn’t stop at build status. I built an MCP server for Apple Mail — apple-mail-mcp — with over 25 tools. Reading emails, searching by sender, moving messages, managing drafts, exporting conversations.

It started small. One tool to read the inbox. Then one to search by subject. Then one to move emails to folders. Before I knew it, I had a full email management layer that Claude Code could operate.

The practical result: I can say “Check my inbox for anything from the client about the migration” and Claude Code reads my mail, finds the relevant messages, and summarizes them. No switching apps, no scrolling through threads.

Some things I learned building it:

  • Docstrings matter. Claude Code uses them to decide which tool to call. Vague descriptions lead to wrong tool selection.
  • Keep tools focused. One tool per action. Don’t build a “do everything” tool — Claude Code works better with many small, specific tools.
  • Add safety limits. My mail server caps batch operations at 10 messages. You don’t want an AI accidentally archiving 500 emails.
  • Test with real scenarios. The tool works differently when Claude Code decides the parameters versus when you hardcode them in tests.

The honest nuance

MCP is still young. Here’s what you should know:

The ecosystem is growing, but it’s not mature. There are MCP servers for GitHub, Slack, databases, and more — but many are community-built and vary in quality. Don’t expect plug-and-play for every service yet.

Debugging can be tricky. When a tool fails, the error messages aren’t always clear. Sometimes Claude Code calls a tool with unexpected parameters. Logging everything in your server helps.

It adds a dependency. Your workflow now depends on an external server process. If it crashes, Claude Code loses access to those tools. A startup wrapper script (like a start_mcp.sh) that handles venv creation and restarts helps.

Security is your responsibility. An MCP tool that queries your production database is powerful — and dangerous. Think about what you expose and add appropriate guards.

None of this is a dealbreaker. But it’s good to know what you’re getting into.

Where to start

If this sparked something, here’s my suggestion:

Pick one thing you alt-tab to five times a day. Your build server. Your issue tracker. Your deployment dashboard. Then build an MCP server with one tool that gives you that information.

Start with a hardcoded response — just to see it work in Claude Code. Then swap in the real API call. Then add a second tool. You’ll be surprised how quickly it becomes useful.

The FastMCP documentation is solid. And if you want to see a full example, my apple-mail-mcp server is open source.

MCP turns Claude Code from a code assistant into something closer to an actual colleague — one that can check the build, read the logs, and tell you what’s going on. That’s worth the twenty minutes it takes to build your first server.

Have you built an MCP server, or are you planning to? I’m curious what tools you’d connect first. Drop me a message via the contact page.