Five MCP servers actually worth wiring into your dev workflow

The Model Context Protocol turned one year old in November 2025 and the ecosystem has finally hit "useful." Most registries now list 500+ servers, but only a handful actually move the needle on day-to-day developer work. Here are the five I'd wire into Claude Code, Cursor, or whatever agentic tool you use — in roughly the order I'd add them.

1. Filesystem (your local files, scoped)

The official @modelcontextprotocol/server-filesystem server is unsexy and table-stakes. Without it, your agent can't read or write the project it's supposed to be helping with. With it, scoped to specific directories, you get safe read/write access without the "please paste your code" dance.

Setup: npx -y @modelcontextprotocol/server-filesystem /path/to/project. Restrict to the exact project directory — never ~ or /. The agent has the rights of whoever invoked it.

2. GitHub (issues, PRs, code search across the org)

The official GitHub MCP server turns "find the PR that introduced this regression" from a 5-tab archaeology session into a single sentence. Repo search, issue triage, PR comments, branch operations — all available without leaving the agent context.

The real win is multi-repo. If your work spans 4-5 repos in an org, the agent searching code across all of them at once is genuinely a step-change. Setup: GitHub personal access token with repo + issues + pull_request scopes, then add the server to your MCP config.

3. Postgres / Supabase (your database, in plain English)

Most SaaS work is database work. @modelcontextprotocol/server-postgres (or the Supabase MCP if you're on their platform) lets the agent introspect schemas, query data, and propose migrations against your dev DB without you copy-pasting \d users output back and forth.

One critical rule: connect it to a read-only role on a dev or staging database. Never production-write. The agent will run the queries it suggests, and a creative interpretation of "clean up duplicate rows" can ruin your day.

4. Sentry (production errors, surfaced to the agent that's fixing them)

Sentry's MCP server is the most underrated of the bunch. The agent can pull stack traces, group related errors, and propose fixes — all without you context-switching to the Sentry dashboard. Closing the loop between "production broke" and "here's the PR" in a single conversation is the fastest debugging UX I've used.

Pair it with the GitHub MCP and the agent can write the fix, the test, and the changelog entry without you ever opening a second tab.

5. Vercel (deploys, env vars, build logs)

If you're shipping to Vercel, their MCP server exposes deploy status, env var management, and build logs to the agent. The killer use case: "why did the last deploy fail?" → agent reads the build log, identifies the failing step, fixes it, redeploys. End-to-end without leaving the editor.

Cloudflare Workers has an equivalent if that's your stack. Pick the one that matches your host.

The pattern: pick MCPs for things you do daily, not things you might do

The mistake everyone makes early is installing 15 MCP servers because the registry is exciting. Don't. Every MCP server you load adds context to the agent's prompt — which costs tokens, slows responses, and crowds out the actual work.

The right number of MCP servers is the smallest number that covers everything you do every day. Anything you do once a month is a tab, not an MCP.

Honorable mentions

• Linear / Jira — if your team lives in a tracker, having the agent triage tickets is solid. Skip if your team uses GitHub Issues.
• Cloudflare — DNS, KV, R2, Workers analytics. Critical if you're on Cloudflare; ignore otherwise.
• Stripe — the official MCP server can query products, prices, subscriptions, and webhook event logs. Useful when debugging billing flow regressions.

A note on cost

Every MCP server lives inside the agent's context window. Five servers loaded simultaneously can add several thousand tokens of tool definitions to every request. If you're paying per-token, that adds up. EcoToken's per-project calibration accounts for this when computing savings — but it's worth knowing the tradeoff regardless of which optimizer you use.