There are thousands of MCP servers now.
Most of the ones I tried added noise instead of signal.
These six earned a permanent spot in my setup, and each one closes a specific gap between my agent and reality.
Share this post & I’ll send you some rewards for the referrals.
1. Context7: docs that match your installed versions
Every model ships with a knowledge cutoff. Ask for a Next.js or TanStack Query pattern and there's a decent chance you get the API from two major versions ago, delivered with complete confidence.
I've reviewed agent code that called methods which no longer exist.
Context7 fixes exactly this. It pulls current, version-specific documentation and working code examples straight into the agent's context.
The prompt:
Add optimistic updates to this mutation. use context7
Add it to your agent rules and it triggers automatically for any library question. You stop thinking about it, and the deprecated-API class of bugs mostly disappears.
2. GitHub MCP: the memory around the code
The code tells the agent what exists. The pull requests and issues tell it why.
Review threads, linked issues, CI runs. That history answers questions the code can't.
With the official GitHub MCP server, my agent reads the review comments on my open PR and applies them. It checks why CI is red and fixes the failing test. It finds the PR that last touched a file and reads the discussion before changing that file again.
The prompt:
Read the review comments on my open PR, apply the requested changes, and summarize what you changed.
To be honest, a terminal agent with the gh CLI already covers some of this. The MCP server matters for agents without a shell, and you can scope it to exactly the repos and permissions you want the agent to have.
3. Postgres MCP: the schema is the truth
Agents guess your schema from ORM models and migration files. Those drift from reality more often than anyone admits, and every guess becomes a subtle bug in a query.
A database MCP server removes the guessing. Mine can inspect the live schema, run read-only queries, and check query plans against a staging database.
The prompt:
This endpoint takes 900 ms. Find the query it runs, EXPLAIN ANALYZE it on staging, and propose the right index.
One rule I never break:
The agent gets read-only credentials and staging or local data, nothing more.
An agent with write access to production is an incident report waiting for a timestamp.
4. Playwright MCP: eyes on the running app
Without a browser, I am the agent's QA department.
It edits a component, I click around, I paste the console error back, we repeat. That loop is slow, and I'm the bottleneck in it.
Playwright MCP hands the agent the browser. It opens the app, clicks through the flow, reads the console and the network tab, and takes screenshots along the way.
The prompt:
Open localhost:3000/checkout, apply coupon SAVE10, and reproduce the bug where the total doesn't update. Check the console, fix the cause, then verify in the browser.
The part that matters is "then verify". The agent checks its own fix before I ever look, and most of the back-and-forth disappears.
5. Atlassian MCP: the ticket is the spec
Requirements don't live in the repo. They live in Jira, in the acceptance criteria, and in the comment thread where scope got cut and edge cases got decided. Pasting the description by hand loses exactly that thread.
With the Atlassian MCP server, the agent reads the whole ticket. Description, criteria, comments, the linked Confluence page.
The prompt:
Read WTRAV-841 including all comments, implement it, and comment on the ticket with what shipped and what was left out of scope.
The comments are the valuable part. Scope changes and edge-case decisions land there, and they rarely make it back into the description. An agent that reads only the description builds last week's version of the feature.
6. Sentry MCP + Seer: production bugs, fixed from the editor
Sentry sponsors this post. This section describes the workflow I actually run, and it would be on this list either way.
Everything above helps the agent while I'm building. This one takes over after the code ships, which is where the real pain lives.
My old flow for a production bug went like this. An alert fires. I open the dashboard, stare at a stack trace, try to reproduce locally, fail, add a log line, deploy, and wait for the error to fire again.
The new flow is one prompt in my editor:
Find the top unresolved issue in production, work out the root cause, and fix it.
Here's what happens, end to end:
Find. Through the Sentry MCP server, the agent lists unresolved issues and picks the top one by users affected.
Diagnose. It kicks off Seer, Sentry's root cause analysis, straight from an MCP tool call. This is the step I care about most. Seer doesn't guess from the stack trace alone. It starts from everything Sentry already captured for that issue (the stack trace, the breadcrumbs, the distributed trace, even the session replay of what the user clicked) and checks its hypothesis against the actual code before committing to an answer. Back comes the root cause: what broke, where, why, plus a proposed fix. Every tab I used to open by hand, read for me.
Fix. My agent takes Seer's analysis and writes the fix in my editor. My branch, my code style, my review before anything merges.
I never opened the dashboard.
Seer is the debugger, because it holds the production context and verifies its analysis against the code. My agent is the implementer, because it knows my codebase and my conventions. Each side does the half it's genuinely good at.
You can turn the automation up or down from there. Seer can open the pull request itself if you want the loop fully hands-off, it works from Slack alerts, and the same analysis reaches Claude or Cursor through Sentry's first-party integrations. I keep my own agent in the loop because I want the fix to land like my code and get reviewed like my code.
Try it yourself: Seer in Sentry.
📌 TL;DR
Context7 feeds it docs that match your installed versions. No more deprecated APIs suggested with full confidence.
GitHub MCP gives it the repo's memory: issues, PR reviews, CI runs.
Postgres MCP shows it the real schema and real query plans.
Playwright MCP gives it a browser, so it can reproduce bugs and verify its own fixes.
Atlassian MCP hands it the ticket, the acceptance criteria, and the comments where the decisions actually happened.
Sentry MCP + Seer closes the loop with production: one prompt goes from "top unresolved issue" to a fix in my editor. Full walkthrough in section 6.
Follow me on LinkedIn | Twitter(X) | Threads
Thank you for supporting this newsletter.
Consider sharing this post with your friends and get rewards.
You are the best! 🙏
Press the Like button if you found this post helpful