The Best MCP Servers for Claude: The 7 We Actually Run
Not a 50-item link dump: the working stack — files, browser, GitHub, search, memory, Slack, Notion — plus the three setup mistakes that eat afternoons and the security paragraph most lists skip.
Most “best MCP servers” lists are 50-item link dumps by people who installed nothing. This is the opposite: the seven servers a real AI-operated company runs daily, what each one is actually for, the setup mistakes that cost beginners an afternoon, and the context-window rule that matters more than any server you install.
What MCP actually is, in one paragraph
MCP (Model Context Protocol) is the open standard that lets Claude use tools — real ones. Out of the box, Claude can only talk. With MCP servers connected, it can read and write your files, drive a browser, manage your repos, search the live web, and post to your team chat. Each “server” is a small program that exposes one system to the model. That's the whole concept: MCP turns Claude from an advisor into an operator.
The trap: more servers make Claude dumber
Here's what the link-dump lists never tell you. Every connected server injects its tool definitions into Claude's context window on every request — whether or not those tools get used. Stack 15 servers and a meaningful slice of the model's working memory is spent reading tool manuals instead of doing your task. The practical symptom is unmistakable: you add servers and responses get slower, vaguer, and more distractible.
Install for the systems you touch weekly. Capability collecting is context vandalism.
The 7 we actually run, by job
1. Filesystem — the workhorse.Read, write, and organize real files and folders. This is the server that turns “Claude wrote me a draft in the chat window” into “Claude saved the report where it belongs.” If you install exactly one server, it's this one.
2. Playwright (browser automation) — the web as the API of last resort. Most of the web has no API. A browser server lets Claude open pages, fill forms, click through flows, and read what a site actually renders. In our operation this is the single most-used capability after files — checking a live page, pulling a dashboard number, verifying that something we shipped actually shows up.
3. GitHub — where the work lives.Issues, pull requests, file contents, reviews, searches across repos. If your business has code — or you just version your documents like code — this closes the loop between “Claude suggested a change” and “the change is in the repo.”
4. Web search — eyes past the training cutoff.Models are frozen at training time; a search server (Brave's is the common choice) gives Claude current prices, current docs, current news. Without it, “research this” means “recall this from memory” — and memory ages badly.
5. Memory — continuity between sessions. A knowledge-graph store the model reads and writes across conversations, so decisions, preferences, and facts survive the chat window. The difference between an assistant you brief once and one you re-brief forever.
6. Slack — where output meets the humans.Post summaries, read a channel, answer into the thread where the question happened. For a team of one this is still useful — it's how finished work lands somewhere you actually look.
7. Notion — the structured brain. Databases, docs, project trackers. If Notion (or a tool like it) is where your business state lives, connecting it means Claude reads and updates real state instead of asking you to paste it.
Setup: the 5 minutes and the 3 mistakes
Installing a server is genuinely small — for Claude Desktop it's a JSON entry in claude_desktop_config.json (Settings → Developer), for Claude Code it's one claude mcp add command. The shape is always the same:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem",
"/path/you/allow"]
}
}
}The three mistakes that eat afternoons:
- Not restarting the app. Config is read at launch. Edit, then fully quit and reopen — “it's not showing up” is this, 90% of the time.
- Wrong transport for the surface. Desktop wants local (stdio) servers; web/remote setups want HTTP servers with OAuth. Mixing these up produces servers that install fine and never connect.
- Vague scopes. Granting the filesystem server your whole drive, or a GitHub token with every permission. Scope to the folders and repos you actually want touched — see below.
The security paragraph most lists skip
An MCP server runs with the permissions you give it, and Claude will use those permissions confidently. Three rules keep this sane: install servers only from sources you trust (the official modelcontextprotocolorg and the vendor's own repos, before anything else); give least-privilege tokens (a GitHub token scoped to one repo, a filesystem root scoped to one project folder); and treat every added server as attack surface that must earn its place. The context-window rule and the security rule agree with each other: fewer, better servers.
When the stack starts running the business
Files + browser + repos + search + memory + chat + structured docs is not a developer toy — it's an operations layer. It's the same categories our company runs on agents every day: drafting products into real files, verifying live pages, logging decisions where the next session finds them. The write-up of that larger system is how one person runs a whole company on AI agents; the prompts that drive it are in AI prompts that actually run a business.
The bottom line
Start with Filesystem. Add the browser server the first time you catch yourself copy-pasting a webpage into the chat. Add GitHub, search, memory, Slack, and Notion as your actual work touches them — and stop there until something earns its slot. Seven well-chosen servers beat fifty installed ones, every time. If you'd rather run our exact setup than reverse-engineer it, the Claude Power Stack ($17) is the documented version, install commands included.