Skip to content

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.

August 1, 20268 min readShift The Culture

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:

claude_desktop_config.json — the general shape
{
  "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.

SharePost on X
Free · 13 pages · no upsell inside

Get the Operator Field Kit — free

Six production prompts, the five-step operator setup, and nine rules from our own failure log.

  • 6 complete prompts — printed in full, not previews
  • The five-step setup, each step with a pass/fail test
  • 9 rules from the failure log that produced them

The kit, then the occasional operator note. One click unsubscribes and we never sell the address.

Keep reading