The MCP ecosystem exploded fast. Every week there’s a new server claiming to connect AI to some other tool, unlock some workflow, change how you interact with your codebase. I’ve tried a lot of them. Most lasted a few days in my config before I quietly removed them.

Here’s what’s actually in my daily rotation and what I uninstalled.

Table of Contents

What Makes an MCP Server Actually Useful

The pattern I’ve noticed: useful MCP servers do one thing reliably. The overhyped ones try to do many things and end up doing none of them well enough to replace the native tool.

Utility also scales with how often the underlying action requires context-switching. If I’m in Claude working on code, asking it to query my database removes a context switch. Asking it to check my email doesn’t — I’m already checking email in a dedicated client and don’t need AI in that loop.

GitHub MCP

This is the most useful MCP server I’ve found, by a significant margin.

What I actually use it for: “Summarize PR #847 and flag areas that need a closer look.” “What issues assigned to me have been open more than a week?” “Show me what changed in this file across the last three commits.”

The key: it puts code review context inside the conversation where I’m already thinking about code. Instead of switching to GitHub, reading a PR, coming back to Claude to describe it — I just ask.

One caveat: it’s only as good as your PR descriptions. Minimal PR descriptions produce thin summaries.

Postgres MCP

I run this against a read replica. It lets me ask data questions without writing SQL first.

Where it earns its place: exploratory analysis during debugging (“how many events of type X in the last 24 hours, by source?”), schema inspection (“what columns reference this table?”), and quick sanity checks during incidents.

The limitation: it generates SQL I sometimes need to review before trusting the answer. Simple queries are fine. Anything involving multiple joins on large tables — read the generated SQL before accepting the result.

Never connect this to a writable production database. Read replica, scoped credentials. Similar cautions apply as for AI debugging in production.

Filesystem MCP

This one sounds boring but earns its place for large codebases.

The use case: when working with Claude on a problem spanning multiple files, I used to manually copy-paste relevant code into the conversation. With filesystem MCP, Claude can navigate the directory structure and read files directly. I can say “look at the handler, the service layer, and the relevant schema” and Claude figures out what to pull.

The tradeoff: scope it tightly. Most default configs are too permissive — point it at your projects directory, not your home directory.

The Overhyped Five

Slack MCP: Two problems. First, Slack is async — I check it when I choose to. Having Claude pull Slack into a coding session adds a context-switch I didn’t want. Second, the privacy surface is uncomfortable. I uninstalled after two weeks.

Email MCP: Email is already a context-switch destination. The main use case (“summarize my inbox”) is something I do in my email client, where I have the full UI and threading. Doing it inside Claude adds nothing I couldn’t accomplish by copy-pasting.

Browser Automation MCP: Slow, unreliable on JavaScript-heavy pages, breaks constantly on sites that update their DOM structure. For simple scraping it works sometimes. For anything requiring form interaction or session management, it’s not reliable enough to depend on.

Universal MCP Aggregators: The “one MCP to rule them all” projects that connect dozens of services through a single interface. The problem is depth, not breadth. Each service gets a thin integration — enough to demo, not enough to replace actually using the service. When the aggregator breaks, everything breaks together.

Calendar MCP: Calendar interactions require enough precision — timezone handling, attendee management, conflict checking — that the MCP layer introduces more uncertainty than convenience. I’ve had it create events in the wrong timezone. Correcting those mistakes takes longer than just opening the calendar.

Config Snippets

~/.config/claude/claude_desktop_config.json:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "your-token" }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres",
               "postgresql://readonly_user:password@replica-host/dbname"]
    },
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/projects"]
    }
  }
}

Notes: read-only DB user for Postgres. GitHub token needs repo and read:org scopes only. Filesystem path scoped to projects, not home directory.

For broader context on the MCP ecosystem, see MCP fragmentation and how to navigate it.

The Honest Assessment

MCP is a useful primitive, not a category killer. The servers that survive daily use remove genuine context-switching friction from tasks you’re already doing in the AI environment. The ones that fail are trying to pull new categories of work into that environment — categories that already have good dedicated tools.

My filter: “Would I keep this browser tab open while I code?” If yes, MCP for it makes sense. If no, the MCP version probably won’t survive either.

Three useful servers, configured well, are worth more than twenty mediocre ones that bloat your context and create unpredictable tool calls.