10 MCP Servers I Actually Use Every Day: How I Doubled My AI Coding Productivity
I've written about MCP protocol basics and how to build your own MCP server before, but I never put together a list of the MCP servers I actually use daily. Recently a few friends have been asking "what MCPs do you have connected in your Claude Code / Cursor setup?" so I figured I'd write it up.
Honestly, the number of MCP servers out there has gotten kind of ridiculous. The awesome-mcp-servers list on GitHub has hundreds of them, but the ones that actually work well and are stable? Not that many. I've tinkered with probably thirty or forty, and these ten are the ones that stuck. Some I uninstalled within five minutes of trying them. Others took two weeks before I realized they had problems. Today I'm sharing my entire filtering process and what I've learned, so you don't have to repeat my mistakes.
How I Pick MCP Servers
Choosing MCP servers is a lot like choosing npm packages. The failure rate is surprisingly high. Some servers have gorgeous documentation but are either buggy or half-baked in practice. Here's what I've learned:
Prioritize official implementations. For GitHub, use GitHub's own MCP server. For Notion, use Notion's official one. Community forks are hit or miss, especially when OAuth is involved. I tried a community Slack MCP once — the OAuth callback kept failing. Spent an entire afternoon on it before giving up and switching to the official version.
Check the last update date. If it hasn't been updated in three months, hard pass. The MCP protocol itself is still evolving, and when the API changes, old servers just break. There was a big MCP spec update in March 2025 that broke a bunch of older servers.
Just try it first. Most MCP servers are a one-line npx -y command to run. The cost of experimentation is super low. Don't like it? Just delete it.
Look at GitHub stars and issues. Servers with 1000+ stars are generally solid quality. Lots of open issues with no responses? That's a sign the maintainers aren't paying attention.
Watch out for Node.js version requirements. Some newer servers need Node 20+. If you're still on Node 18, you might hit syntax compatibility issues. I got burned by this once — got a SyntaxError: Unexpected token '?' that took me forever to debug before I realized it was a Node version problem.
1. GitHub MCP — The Swiss Army Knife for Code Management
This is a must-have, no question. GitHub's official MCP server lets your AI directly interact with your GitHub repositories.
Once it's set up, you can just tell your AI things like "check what issues this repo has lately," "open a PR to main," or "review the changes in this commit." No browser switching, no copy-pasting code.
My most common use case is having Claude Code handle issues: give it an issue link, it reads the issue, creates a branch, writes the code, and opens a PR. All automated. What used to take me at least 30 minutes now takes five. I once went from issue to merged PR in eight minutes for a frontend bug. My colleague thought I was exaggerating.
The config is straightforward:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
One thing to watch out for: don't give the token too many permissions. I only grant repo and issues access. Never enable delete_repo or other dangerous scopes. Fine-grained tokens are safer than classic tokens — you can control read/write access per repository.
Another common issue is token expiration. Fine-grained tokens default to one year, classic tokens used to default to 30 days. I once had my MCP suddenly stop working and spent ages debugging before I realized the token had expired.
2. Playwright MCP — Browser Automation That Actually Works
Microsoft's Playwright MCP gives your AI real control over a browser. Not screenshot-based guessing — it can actually click buttons, fill out forms, scroll pages, and interact with elements.
I use it for three main things:
E2E testing. Tell the AI "open localhost:3000, log in with the test account, go through the checkout flow, see if there's a bug" and it just runs. Writing Playwright test scripts used to take me half a day of selector tuning. Now the AI handles it using the accessibility tree, which is way more stable than CSS selectors.
One time I changed some form validation logic and had the AI run through the entire signup flow. It didn't just test the happy path — it automatically tested edge cases: empty values, super long strings, special characters, invalid email formats. Writing those test cases manually would've taken me at least an hour.
Data scraping. Some websites have no API and render everything on the frontend. Instead of writing a Playwright scraping script, I just tell the AI "open this page and extract the table data." It handles pagination, lazy loading, even pages that require login.
Bug reproduction. Frontend bugs are notorious for the "works on my machine" problem. With Playwright MCP, I can have the AI reproduce the issue in a clean browser environment and take a screenshot to share with colleagues.
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
No API key needed — just install and go. But heads up: it launches a real Chromium process that eats memory. If you open several at once on a machine with 8GB RAM, things might get sluggish. Also, the first time you use it, it downloads Chromium (about 100+ MB), so be patient if your connection is slow.
3. Supabase MCP — Database Operations Without Leaving Your Editor
After Supabase released their official MCP server, I stopped manually writing SQL and running it in the dashboard. I just tell the AI "show me the 10 most recently registered users in the users table" or "add a status column to the orders table."
It's not just querying data either — it manages table schemas, RLS policies, and Edge Functions. Once I needed to add a complete set of RLS rules to a table. Manually, that would've taken at least 30 minutes. I described what I needed to the AI, and it was done in two minutes. It even caught a couple of scenarios I'd missed.
The most memorable time was a data migration. The requirement was to move data from an old table to a new one where field names and types had both changed. Normally I'd write a SQL script, test it locally, then run it in production. This time I had the AI work through Supabase MCP — it examined both table structures, generated the migration SQL, and I could preview results in Supabase's SQL Editor. The whole thing took under 10 minutes.
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
One warning: don't hand out your production access token casually. I keep a read-only token for daily queries and only switch to a write-capable one when I need schema changes. Supabase supports creating multiple API keys with different permission scopes, which makes this easy.
4. Brave Search MCP — Give Your AI Internet Access
LLMs have a natural weakness: their training data has a cutoff date. Yesterday's npm package, today's CVE, last week's framework update — the AI doesn't know about any of it. Brave Search MCP solves this.
Once installed, your AI can search the internet in real time. I use it constantly to check the latest version of a library, search for solutions to error messages, or see if there's a new technical approach out there. I once hit a Next.js hydration error that the AI's training data didn't cover. A quick search revealed it was a known issue in Next.js 15 with a community workaround available. Without search capability, that bug would've cost me half a day.
Why Brave over Google? Two reasons: first, Brave's API has a free tier — 2,000 queries per month, which is plenty for personal use. Second, privacy. Brave doesn't track search history. Google's Custom Search API requires a credit card and only gives you 100 free queries per day.
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
Just register on the Brave Search API website to get your key. It's free and takes about a minute.
5. Filesystem MCP — The Unsung Hero
This one doesn't look exciting, but it's surprisingly useful. It lets your AI read and write files across your local filesystem — not just the current project directory, but any directory you authorize.
I mainly use it for cross-project file operations: "organize the JSON files in ~/Downloads," "check the config files in ~/.config." Claude Code has built-in file operations, but they're scoped to the current working directory. Filesystem MCP extends that range.
Once I needed to audit all .env files across several projects to check for a deprecated environment variable. Manually checking each one would've been tedious. I had the AI scan all project directories through Filesystem MCP — done in two minutes.
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
Be specific with authorized directories. Don't grant / or ~. Too much permission and the AI might accidentally mess with files it shouldn't touch. I only grant projects and downloads.
6. Figma MCP — Design to Code, No Guessing
Frontend developers will love this one. Figma's official Dev Mode MCP lets your AI read the structural information from Figma designs — layout rules, spacing, color variables, font styles, component properties, everything.
Converting designs to code used to mean either measuring pixels by hand in Figma or showing the AI a screenshot and hoping for the best. Now the AI reads structured design data directly, and the accuracy is way better.
Once I had Cursor read a Figma component, and the Tailwind code it generated barely needed any tweaking — spacing and colors were all correct. The designer asked how I did it. I said "the AI read your design file directly." She didn't believe me. That experience was so much better than the screenshot approach.
One limitation: it can only read the layers you've selected in Figma. It can't traverse the entire file. So you need to select the component you want to implement first, then have the AI read it. If the design is large, selecting an entire frame might return too much data for the AI to process efficiently. I'd suggest working one component or section at a time.
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
You need Figma's Dev Mode access for this — the free plan doesn't include it. Individual plans start at $15/month. Students get free education accounts.
7. Composio MCP — 250 Apps, One Entry Point
This one's different from the others. Instead of one MCP server per service, Composio is a single server that covers 250+ platforms. GitHub, Slack, Gmail, Notion, Jira, Salesforce, HubSpot — all from one place.
I mainly use it for automation scenarios. Like "check Linear for urgent tickets, create a GitHub issue for each one, then notify the #engineering Slack channel." That kind of cross-platform operation would normally require three separate MCP servers. Composio handles it all from one connection.
Another scenario is information aggregation. Once I wanted to learn everything about a client — email threads in Gmail, project docs in Notion, related tickets in Linear. Composio let the AI query all those data sources in one go.
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
The downside is it depends on Composio's cloud service, and authentication goes through their dashboard. If you'd rather avoid third-party services, sticking with individual MCP servers is more straightforward. Also, the free plan has call limits — heavy users will need to pay.
8. E2B MCP — Run Code in a Safe Sandbox
E2B provides a cloud sandbox environment that lets your AI actually execute code, not just write it. Python, JavaScript, shell commands — all running in an isolated virtual machine.
The value here is "safe verification." The AI writes a data processing script and you're not sure if it's right. Have it run in the E2B sandbox and check the output. Way safer than running it locally — if the script has issues, it won't affect your system.
I use it constantly for testing regex patterns, running data conversion scripts, and verifying API call logic. I used to write temporary scripts and run them manually. Now the AI handles it. Once I had the AI write a CSV processing script, debug it through three iterations in E2B, and only then bring it locally. Saved a bunch of time.
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
E2B has free credits, enough for personal use. If you're running lots of code or need long-running sandboxes, you'll need a paid plan. Sandboxes timeout after 5 minutes by default, so keep that in mind for longer tasks.
9. Sentry MCP — Debug Production Errors Without Leaving Your Editor
Production error? The old workflow was: go to Sentry dashboard → copy the stack trace → paste it to AI → ask for analysis. With Sentry MCP, the middle two steps disappear.
Just tell the AI "check Sentry for recent errors and analyze what's going on." It pulls the error data, examines the stack trace, and suggests fixes. Once our production environment threw a mysterious TypeError. I had Claude Code look at it through Sentry MCP, and it identified an async race condition. The fix it suggested worked on the first try.
Another nice feature is error trend analysis. Ask the AI to look at the past week — which error types are most frequent, which ones are new, which are recurring. That kind of analysis used to require manually digging through the Sentry dashboard.
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
| 12 | |
Create auth tokens in Sentry under Settings → Auth Tokens. I'd recommend only granting event:read and project:read permissions.
10. Linear MCP — Project Management Goes AI
If your team uses Linear for project management, this MCP server lets your AI interact with tickets directly. View, create, update, search — all through conversation.
My most common use is having the AI organize my day: "show me my in-progress tickets in Linear, sorted by priority." Or after writing code, having it automatically update the ticket status with a link to the commit.
One pattern I've found useful is sprint retrospectives. Ask the AI to check how many tickets were completed this sprint, which ones were delayed, and why (based on ticket comments and status change history). That kind of analysis used to take me ages to compile manually.
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
If you don't use Linear, Jira and Notion have equivalent MCP servers with similar functionality. I tried Notion's MCP but the API responses were painfully slow — queries regularly took several seconds. Not a great experience.
General Configuration Tips
After spending a lot of time with MCP, here are some practical tips:
Where to put config files: Different tools, different locations. Claude Code uses .mcp.json (project-level) or ~/.claude/mcp.json (global). Cursor uses .cursor/mcp.json. VS Code uses .vscode/mcp.json. The structure is identical — only the file location changes. I'd suggest adding project-level configs to .gitignore to prevent API keys from leaking into your repo.
Don't hardcode environment variables. API keys shouldn't be directly in config files, especially project-level ones. Use environment variable references:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
This way the config file can be safely committed to the repo, and the key comes from system environment variables.
Too many servers slow things down. Each MCP server adds a few seconds to AI startup time and fills up the context window with tool descriptions. I'd recommend keeping 3-5 most-used ones active and enabling others as needed. I keep GitHub + Playwright + Brave Search as permanent fixtures, and toggle others depending on the project.
Debugging tips: How do you troubleshoot MCP server issues? In Claude Code, claude mcp list shows installed servers, and claude mcp logs shows logs. Most problems are API key errors or network issues — the logs will tell you. If a server fails to start, try running npx -y <package-name> manually to see what error comes up.
Don't forget to update. MCP servers are npm packages with version updates. I'd suggest running npx -y @latest every few months to check for new versions. Old versions may have bugs or be incompatible with newer MCP protocol changes.
Security Considerations
After using this many MCP servers, I want to talk about security separately. MCP servers essentially open a door from your AI to the outside world. How wide that door is and where it leads — that's on you to control.
Principle of least privilege. Every API key should only have the minimum permissions it needs. GitHub tokens get repo read/write, never delete. Supabase keys are split into read and write — daily use gets read-only. Figma tokens only have access to the current team. I know configuring permissions is tedious, but it really matters — the AI sometimes "takes initiative" and does things you didn't anticipate.
Watch for prompt injection. Some MCP servers return web content (like Firecrawl, Playwright). That content might contain malicious instructions. If the AI reads carefully crafted text, it could be tricked into performing dangerous actions. So for servers that return web content, try not to give them write access at the same time. Read first, confirm it's safe, then write.
Don't commit config files to Git. .mcp.json contains API keys — make sure it's in .gitignore. I've seen people accidentally commit Sentry tokens to public repos. The consequences are serious. If you really want version-controlled configs, use environment variable references so the config file only contains ${ENV_VAR}.
Regular audits. Every few months, review which MCP servers you have installed. Remove the ones you're not using. Each server is a potential attack surface. Community forks and unmaintained servers carry higher risk.
Ones That Didn't Make the Cut
A few others I've tried but didn't keep in my daily rotation. Quick notes on why:
- Notion MCP: Functionally fine, but the Notion API is painfully slow. Queries regularly take several seconds. The poor experience was a dealbreaker. If you can tolerate the speed, the functionality is comprehensive.
- Docker MCP: Having AI manage containers sounds cool, but I don't actually operate Docker frequently enough to justify keeping it around. I install it temporarily when needed.
- Postgres MCP: Overlaps with Supabase MCP. Since I use Supabase more, I kept that one. If you don't use Supabase, Postgres MCP is a solid choice.
- Cloudflare MCP: Recently released, still testing. Can manage Workers, KV, R2, etc. Worth trying if you're in the Cloudflare ecosystem.
- Zapier MCP: Similar to Composio but more expensive. Free plan is pretty limited. Makes sense for teams already paying for Zapier.
Wrapping Up
The MCP ecosystem is still in its early days, with new servers popping up every day. But more tools doesn't mean more productivity — it's about finding the ones that actually improve your workflow. These ten are what survived my filtering process from thirty-plus attempts, each with a clear use case.
If you're just getting started with MCP, I'd suggest installing GitHub + Brave Search + Playwright first. Those three cover code management, information retrieval, and browser automation — the three core scenarios. Add others gradually. Don't install everything at once, or your AI's context window will be stuffed with tool descriptions, actually hurting its core coding ability.
I'm planning to try Cloudflare MCP and Stripe MCP next. If they work out, I'll write about them. Questions? Drop them in the comments.
- Written June 14, 2026, based on real-world usage. The MCP ecosystem changes fast — configurations and features described here may have been updated since publication. Check official docs for the latest.*