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 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
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
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
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
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.
Install in this order, test each, then move on:
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.
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.