I used to be skeptical of MCP. The first time someone pitched it to me I rolled my eyes a little, because the whole thing sounded like yet another protocol that would live for six months and then quietly die in a GitHub archive. Six months on, I would rather lose my keyboard than my MCP config. The chat is no longer just a chat. It is a remote control for the things I work on, and the servers below are the buttons that actually get pressed.
This is not a survey of every MCP server that exists. It is the five I actually have installed in June 2026, across Claude Code and Claude Desktop, and a short note on what each one saved me this past week. If a tool does not pass that weekly bar, it gets uninstalled. I will say more about that at the end.
1. Filesystem MCP, the official one
The official filesystem server turns the chat window into a real file editor. The model can list a directory, read a file, write a file, and patch existing files. That sounds boring until you realise it removes the copy-paste dance that used to eat half of every coding session. No more pasting a function in, asking for a fix, pasting it back, and then noticing the indentation drifted.
This week the concrete win was a small refactor across nine files in one of my Go packages. I described the rename, the model walked the tree, edited every call site, and ran the formatter. I reviewed the diff in git. Total time was maybe four minutes, and three of those were me reading the diff carefully because I am paranoid.
Install: it ships with the official Anthropic MCP examples repo, point it at the project root and you are done.
2. Postgres MCP
The Postgres server lets the model query a database directly. I point it at a read replica of production with a tightly scoped role, so the worst case is a slow query, never a destructive write. Schemas and table names are exposed as resources, which means the model can introspect the database before it writes SQL, instead of guessing column names from training data that is two years out of date.
Last week I needed to figure out why a specific cohort of users had stopped logging in. I asked the question in plain English. The model wrote three exploratory queries, narrowed the cohort, and surfaced that they all sat behind a single OAuth provider whose certificate had rotated. I would have spent an hour writing those queries by hand. It took six minutes.
Install: there is a community Postgres MCP server on GitHub. Use a read-only role and a read replica. Do not be a hero with a write role.
3. GitHub MCP
The official GitHub server reads issues, pull requests, comments, and repo metadata. I do not let it write yet, because I want a human in the loop on anything that touches a real PR, but the read side alone is a quiet productivity multiplier. I can ask "what is the state of PR 482" without leaving the editor, and the model pulls the title, the description, the latest comments, and the failing CI logs into one summary.
This week the win was triage. I had thirty something open issues across two repos after coming back from a short trip. I asked for a grouped summary by theme. It came back with five clusters, each with the three or four issue numbers that belonged together. I closed two as duplicates and turned one cluster into a single milestone in about fifteen minutes.
Install: gh auth login first, then the GitHub MCP server from the official examples. Token scopes matter, be conservative.
4. My personal Squilla MCP
Squilla is my own CMS, and I run an MCP server in front of its CoreAPI. That means the same interface my admin UI uses is also the interface Claude uses when it edits the site. New blog post, new menu item, fix a typo on the homepage, all of it goes through the same chat. I do not open the admin UI to write anymore. I open it to look at things.
This week, this very post was a win. I drafted it in chat, asked the model to publish it as a blog node in the ai-mcp category with a backdated publish date, and it called the right tools without me babysitting. The hardest part of writing was deciding which of the five servers got which number.
Install: this one is bespoke, but the pattern works for any product with a clean internal API. The MCP server is a thin adapter, not a parallel codebase. If you have a CoreAPI you are proud of, you are most of the way there.
5. A browser MCP, in my case playwright-cli
The last one is the most under-appreciated. A browser MCP lets the agent open a URL, see the rendered DOM, click things, and screenshot the result. Tests prove the backend is correct. A browser MCP proves the human-facing layer is correct, which is a different question and the one that actually matters to users.
This week the win was a footer that looked perfect locally and shipped broken in production. I asked the agent to open the live URL, snapshot the page, and tell me what it saw. It came back with "the language switcher is missing on mobile widths." One CSS variable, one commit, one redeploy. Without the browser MCP I would have noticed that on a weekend, from a friend, with screenshots in WhatsApp.
Install: I use playwright-cli wired through a small MCP adapter. Any real browser-driving MCP server will do, the point is that the model sees what the user sees.
The honest filter
The right question for any tool, MCP or otherwise, is whether it actually saves you time at least once a week. Not in theory, not on a good day, not in the demo video. Once a week, in the real flow, with a real task. If it does, keep it and tune it. If it does not, uninstall it.
I have removed three MCP servers this year that I was sure I would love. They were beautifully built and I never reached for them. The five above earn their slot every week. That is the whole bar.