Agents UI
Best MCP Servers for Developers in 2026: A Curated Guide
A year after Anthropic released Model Context Protocol, the ecosystem is no longer empty. There are hundreds of MCP servers on GitHub, dozens of curated lists, and at least a few attempts at "MCP marketplaces." Most of them are not worth installing.
The useful ones are useful for a reason. They expose a small, well-defined surface that an AI agent can actually reason about, and they solve a real problem in the developer loop — not a hypothetical one.
This guide is the shortlist. The MCP servers worth wiring into Claude Code, Cursor, or whatever agent you run, organized by what they unlock.
What "Good" Looks Like in an MCP Server
Before the list, a quick filter. A worthwhile MCP server has three properties:
- Tight, named tools. Five well-scoped operations beat thirty fuzzy ones. An agent reading the tool list should be able to pick the right one without guessing.
- Stateful enough to be useful, stateless enough to be safe. It remembers the things you want remembered (current project, open connections) and forgets the things you don't (pre-loaded credentials, ambient permissions).
- Verifiable side effects. When the agent acts, you can see what changed. Logs, diffs, status output. Black-box tools that mutate things invisibly are not safe to give an autonomous agent.
If a server fails any of those, skip it. The ecosystem moves fast enough that a better one will appear.
Filesystem Access
The first capability any agent needs: the ability to read and write files outside the chat.
Filesystem MCP server (official, by Anthropic). Still the baseline. Read, write, list, and search inside a configured root directory. Boring on purpose, which is the point — the agent gets predictable file operations without you having to wire up a custom shell.
The version that ships with Claude Desktop and Claude Code is fine for most local work. Configure the root carefully — broad roots like ~/ are a footgun. Scope it to the project directory you are actually working in.
Why it matters: Without filesystem access, every "look at this file" turns into a paste. With it, the agent can navigate the codebase on its own.
Git and Version Control
Git MCP server. Exposes git status, git log, git diff, git branch, and a controlled set of mutating operations like commit and checkout. The good versions refuse force-push, refuse reset --hard, and require explicit confirmation for destructive operations.
This is where most "agentic coding" workflows actually live. The agent reads the diff, understands what changed, writes a commit message, and creates a branch. You review and merge.
GitHub MCP server. A step up from raw git. Issues, pull requests, comments, code review. Useful when the agent needs to operate not just on your local working copy but on the project's collaborative surface — opening a PR, leaving a review comment, linking an issue to a commit.
Be careful with PR creation permissions. An agent that can open PRs against main without a draft state is one bad prompt away from publishing something embarrassing.
Databases
Postgres MCP server. Schema inspection, query execution against a read-only role. The right way to set this up is with a dedicated database user that has SELECT-only access. The agent can answer "what tables exist?" and "show me a sample row" without being able to drop anything.
For local development, you can give it write access. For anything connected to a production-shaped database, read-only is the only sane default.
SQLite MCP server. Lightweight, useful for local development databases and the surprisingly common case where your project's "real" data lives in a single SQLite file (Tauri apps, CLI tools, smaller backends). Same advice — scope it to specific files, not the entire filesystem.
ClickHouse, BigQuery, Snowflake MCP servers. Niche but high value for data engineering work. The agent can write SQL, run it, and read back the result. Combined with a schema-introspection tool, this turns "write me a query" from a one-shot guess into something the agent can iterate on with feedback.
Browsers and Web
Playwright MCP server. This is the one that changed end-to-end testing for AI agents. The agent can open a real browser, navigate, click, screenshot, and verify that a feature actually works in the UI. Combine this with a dev server and the agent can implement a frontend change and visually verify it before declaring success.
Puppeteer MCP server. Same idea, slightly older surface. Pick one — running both creates ambiguity in tool selection.
Fetch MCP server. The minimal version: HTTP GET against allowlisted URLs. Useful for docs lookups and API exploration. Less useful than you'd expect for general web browsing — the open web is too noisy to be useful tool surface for most coding tasks.
Terminal and Sessions
This is where most setups are weakest. Most MCP servers treat the terminal as a single "run this command" tool, which is fine for one-shot operations and terrible for actual development workflows.
Agents UI MCP server. Full disclosure — this is the one we built. It exposes terminal sessions as first-class objects: list sessions, create sessions, send commands, read output, wait for command completion, manage projects. The agent can run a build in one session, watch tests in another, and tail logs in a third — all while you keep working in the same windows yourself.
The model matters more than the brand. If your agent only has a "shell" tool, it cannot run anything long-lived. If it has session primitives, it can supervise its own background work.
Shell MCP server (basic). The one-shot version. Run a command, get the output. Fine for simple operations. Hits a wall the moment you want the agent to run anything that doesn't terminate in five seconds.
For a deeper look at how session-aware MCP changes agentic workflows, see Automate Terminal Workflows with the Agents UI Python SDK.
SSH and Remote Access
SSH MCP server. Connect to remote hosts, list files, read and write across the network. The right pattern is to expose this through a controlled host allowlist — not arbitrary SSH access, but "the dev box," "the GPU server," "the staging deploy target." Each one is a named connection the agent can use.
Useful for the increasingly common workflow where heavy compute lives elsewhere — a remote GPU box for ML work, a cloud dev environment, a shared staging server. See Remote GPU Server AI Coding Workflow for the broader pattern.
Documentation and Knowledge
Context7 MCP server. Live documentation lookup. The agent asks "what's the current API for library X?" and gets the actual current docs, not whatever it learned at training time. This eliminates one of the most common AI coding failures: confidently using an API that changed two versions ago.
Anthropic's docs MCP server. Specifically for Claude's own API. Niche, but if you're building AI applications, having the agent able to look up the current SDK reference saves a lot of guessing.
Notion, Linear, Jira MCP servers. Read your team's tickets and docs. Useful for context — the agent can pull the acceptance criteria from a Linear ticket before implementing — but be conservative about write access. An agent that can close tickets is one wrong prompt away from closing them in bulk.
Cloud Infrastructure
AWS, GCP, Azure MCP servers. Cloud SDKs as tools. Powerful and dangerous in equal measure. The reasonable pattern is read-only for production, scoped write access for development environments. Letting an agent terminate EC2 instances or delete S3 buckets is not a workflow choice — it's a wager.
Cloudflare, Vercel, Netlify MCP servers. Deploy and inspect. Smaller blast radius than the full cloud SDKs, more practical for typical web development. The agent can check deploy status, roll back a bad release, or trigger a preview build.
Observability
Sentry, Datadog, Grafana MCP servers. Query your monitoring data. The agent looks at a recent spike in error rate and pulls the actual stack traces, then reads the relevant code and proposes a fix. This is where AI coding starts to feel like having an extra engineer rather than an autocomplete.
These are read-only by design. There is no reason an agent needs to modify your monitoring config — only query against it.
Servers You Probably Don't Need
The flip side of curation: some categories sound useful and aren't.
"Web search" MCP servers. Usually just wrap a search API. The results are noisy, the agent rarely uses them well, and the cost adds up. Specific docs servers (Context7, library-specific) are better.
"Memory" MCP servers. Persistent agent memory sounds great until you realize it's just an opinionated key-value store the agent treats as gospel. A CLAUDE.md or AGENTS.md file in the repo is more discoverable, version-controlled, and reviewable.
"Email" or "messaging" MCP servers. Tempting for "agent automation," but the failure modes are severe. An agent that can send email or post to Slack on your behalf can also do so when it misreads a prompt. Keep these humans-in-the-loop.
Multi-purpose "do everything" servers. A single server exposing forty tools across ten domains. The agent gets confused, picks the wrong tool, and you can't debug which surface caused the failure. Prefer narrow servers composed together.
How to Choose for Your Setup
Don't install all of these. Pick by what your loop actually needs.
A typical productive starter set:
- Filesystem (scoped to project root)
- Git (or GitHub if you do PR-driven work)
- A session-aware terminal MCP server
- One database server, if your project has a database
- Playwright, if you have any UI to verify
Add specialized servers when a specific friction point shows up — when you find yourself manually pasting Sentry stack traces to the agent, install the Sentry MCP server. Not before.
The trap is treating MCP servers like browser extensions: install a bunch and see what sticks. Each server you add increases the tool surface the agent has to choose from, which makes tool selection worse. Lean is better than complete.
The Direction This Is Heading
MCP is settling into the same shape that "good IDE plugins" did fifteen years ago. The early phase had a long tail of barely-maintained servers and a handful that were genuinely load-bearing. The mature phase has clearer winners by category.
The interesting frontier in 2026 is not more MCP servers — it's better composition between them. Agents that can chain filesystem, git, and Playwright operations to "make the change, verify it works in the browser, commit, open a PR" are already routine. The next step is agents that can do that across multiple repos and infrastructure surfaces without losing the thread.
That's a tooling problem more than a model problem. Which is to say: the MCP servers you pick in 2026 matter more than the model you pick.
Building an agentic coding workflow with multiple MCP servers? Agents UI gives you session-aware terminal primitives designed for exactly that — multiple agents, scoped projects, programmable from a Python SDK.