Top 5 MCP Servers Worth Setting Up If You Work Solo

Robert — Tue, 11 Aug 2026 10:00:01 +0000

MCP servers are leverage, not toys

The first thing to internalise about Model Context Protocol: every server you wire up adds tool-use tokens to every Claude request, whether you use the tool or not. The browser-automation MCP server alone often adds 4-6K tokens of tool descriptions to your context. Wire up six servers and you've spent your premium context on advertising tools that won't fire in this conversation.

That's why "more MCP servers" isn't the right question. The right question is: which workflows do I want Claude to handle without copy-pasting? Then pick the smallest MCP that answers each one.

/ #1 FILESYSTEM

The one nobody talks about because it's boring

The official filesystem MCP server lets Claude read, write, and search files in a scoped directory. It sounds underwhelming. It is the highest-ROI MCP server for a solo dev, by far.

Why: most of your context loss with Claude isn't intellectual, it's logistical. You spend tokens copy-pasting file contents, asking Claude to remember layouts, re-explaining what's in the repo. With filesystem MCP, Claude can read the file once instead of you describing it twenty times.

Setup is one block in your mcp.json. Lock it down to one or two project directories, don't let it browse $HOME.

/ #2 GIT

Diff, log, blame, for free

The git MCP server gives Claude git diff, git log, git blame, and a few related read-only operations. Set it up once and Claude can answer "when did this function change last?" without you copy-pasting log output.

Pair it with filesystem MCP and you've got 80% of what code review tools sell as a product, running in your terminal for zero ongoing cost.

/ #3 OBSIDIAN

If you take notes outside code, this changes the game

The Obsidian Local REST API plugin + a thin MCP wrapper lets Claude read and write Obsidian notes directly. We use this every day on NeuraGrowth: project memory, daily logs, brainstorming docs, feedback memos all live in Obsidian and Claude reads/writes them in-conversation.

The win isn't the writing, it's the reading. When a session compacts and you need Claude to recall what you decided two weeks ago, having that decision in a markdown file that Claude can pull up is the difference between continuity and re-litigating every choice.

/ #4 BROWSER AUTOMATION

For when you need eyes on the live site

Playwright or Puppeteer MCP servers let Claude open a browser, navigate, take screenshots, fill forms. Heavy on tokens, install it last, not first.

Where it earns its weight: UI regression checks on local dev servers, scraping data from sites without APIs, sanity-checking that a fix actually fixed the rendered page. Don't enable it globally; turn it on per-task when you have a browser-shaped job.

/ #5 POSTGRES

Read-only query access to your DB

The Postgres MCP server (or similar for MySQL / SQLite) lets Claude run SELECT queries against a connected database. Configure it READ-ONLY, that's the only safe mode for daily use.

The use case: "how many users signed up in the last 30 days?" stops being a five-minute task. Claude writes the query, runs it, returns the number. Same for ad-hoc data debugging during a bug investigation. Don't grant write access from Claude unless you have very specific reasons and a backup strategy.

Three classes of MCP server I uninstalled

"All-in-one AI agent" servers. These bundle filesystem, git, browser, search, code-exec into one big MCP. Token cost explodes, scope creep makes them fragile, and the abstractions hide what's actually happening.
SaaS MCP wrappers for tools you don't use. Notion, Linear, Jira, Slack, each has an MCP server. If you don't use the tool, the tool descriptions still eat context. Only install what you actually touch weekly.
Anything that re-implements Claude's own search. Vector search MCPs, semantic-search-over-codebase MCPs, Claude's built-in grep/glob is plenty for repos under ~100K LOC. Skip the index-builder layer until you genuinely need it.

If you have one hour

Install in this order, test each, then move on:

Filesystem, scoped to your active repo. 10 minutes.
Git, same repo. 10 minutes.
Obsidian (if you note in Obsidian), 15 minutes including the REST API plugin setup.
Postgres, only if you have a production DB. 15 minutes for read-only config.
Browser automation, install last and toggle per-session. 20 minutes.

Don't try to set up all five in one session. Each is a small commitment of muscle memory; cramming them in one Saturday leads to forgetting how to invoke half of them by Tuesday.

Less is more, until it isn't

The temptation with MCP is the same as the temptation with VS Code extensions: install everything that looks shiny, accumulate cruft, never use 80% of it. Resist. Two well-configured servers beat ten lazily configured ones every single time. When you genuinely hit the limit of what your current setup can do, add the next one deliberately.

Originally published at neuragrowth.co. I run a one-person digital-products studio and write up what breaks in production.

DEV Community: Robert