Best MCP servers by job: browser, GitHub, files, docs, fetch

by Ray Svitla

Updated May 14, 2026.

MCP servers are not Pokemon. Do not collect them all. Add one when it gives Claude Code a job-specific capability you can verify and permission-bound.

For the concept layer, read what is MCP . For composition patterns, see MCP server stacking and your first MCP server .

The shortlist

That table is deliberately short. If a server is not tied to a job, trust level, and validation check, it is not a recommendation; it is clutter.

Start with the job, not the server

Use this decision tree:

1. Can shell or local files solve it? Use shell/local files first.
2. Does the agent need browser state? Add Playwright MCP, then test on localhost.
3. Does the agent need SaaS data? Add the SaaS server with the narrowest auth you can manage.
4. Does the agent need current docs? Add Context7 or a fetch/docs path.
5. Does it need write/admin access? Stop and define approval gates before installing.

MCP is just another integration surface. The boring question — “what can this tool touch?” — is the important one.

Claude Code validation loop

The current Claude Code CLI help confirms these checks:

claude mcp list
claude mcp get <name>
claude mcp remove <name>
claude mcp reset-project-choices

Use them from a trusted project directory. Claude’s help warns that list and get can spawn stdio servers from project MCP config during health checks. That is useful, but it means you should not run them casually inside random cloned repos.

A sane loop:

1. Add the server from official docs.
2. Run claude mcp list.
3. Run claude mcp get <name>.
4. Smoke-test a read-only prompt.
5. Check the permission boundary.
6. Only then try a write action.
7. Remove the server if it becomes unused.

Install shapes that are current enough to mention

Prefer official docs over copied blog commands. The command shape matters because MCP package names move.

HTTP server

Claude Code’s help shows HTTP transport like this:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

Use that shape for servers whose official docs expose a remote MCP endpoint. Sentry MCP is a clean example.

Stdio server

For local stdio servers, Claude Code supports command-based add forms. The Playwright MCP README currently shows:

claude mcp add playwright npx @playwright/mcp@latest

For your own commands, Claude help also shows the explicit separator form:

claude mcp add my-server -- my-command --some-flag arg1

Do not cargo-cult old package names from stale lists. Open the official repo/docs first.

Browser/UI: Playwright MCP

Use Playwright MCP when Claude Code needs to interact with a real browser while working on code: open localhost, click through a flow, inspect visible errors, or capture screenshots.

Why it belongs in the starter stack:

• Microsoft maintains the Playwright MCP project.
• The README describes structured accessibility snapshots rather than screenshot-only control.
• It is a natural companion to web app development and QA.

Boundary:

• Start on localhost or a staging app.
• Avoid primary logged-in sessions.
• Treat screenshots and page content as data leaving the browser boundary.

Validation prompt:

Open http://localhost:3000, report the page title, capture a screenshot, and stop before submitting any form.

For browser-agent task design, see browser agents vs Playwright .

Code/repo: GitHub MCP

Use GitHub MCP when the agent needs repository context that is not already in the local checkout: issues, PRs, workflow status, code search across repos, or project metadata.

The GitHub MCP Server README documents a hosted remote server and local deployment options. Use whichever path your client and policy support.

Boundary:

• Start read-only if possible.
• Scope tokens or OAuth permissions to the smallest org/repo set.
• Require human approval before opening PRs, changing labels, editing releases, or touching workflow settings.

Validation prompt:

List the latest open issues in this test repository and do not modify anything.

Local files: Filesystem MCP

Filesystem MCP is powerful because it is boring. It can read, write, move, search, and edit files. That is also why it deserves a tight leash.

The official filesystem README says access is restricted to allowed directories, either passed at startup or supplied through Roots. Use that boundary. Do not point it at your whole home directory because you are feeling optimistic. Optimism is how agents discover tax PDFs.

Boundary:

• one project directory,
• no secrets directory,
• no broad home folder,
• read-only first when your client supports it.

Validation prompt:

Show the allowed directories, read README.md, and do not write files.

Web reading: Fetch MCP

Fetch MCP is for giving the agent a URL reader. The official README says it fetches web content and converts HTML to markdown. It also warns that it can access local/internal IP addresses, which makes it a security boundary, not just a convenience.

Use it for:

• reading public docs,
• checking a source URL,
• extracting article text,
• following a small set of explicit links.

Do not use it as an unbounded crawler over internal services.

Validation prompt:

Fetch this public documentation URL, return the title and the first five headings, and do not follow additional links.

Current docs: Context7

Use Context7 when the agent is writing code against libraries whose APIs move. The current README describes both CLI+Skills and MCP modes, with npx ctx7 setup as the setup path and https://mcp.context7.com/mcp as the manual MCP endpoint.

Boundary:

• docs/context only,
• API key in client config, not pasted into prompts,
• pin library/version in the prompt when you know it.

Validation prompt:

Retrieve current docs for the package I name, cite the library id/version, and do not write code yet.

Error monitoring: Sentry MCP

Use Sentry MCP when the agent needs to inspect errors, stack traces, and project health while debugging. The Sentry MCP docs document a cloud MCP endpoint and a local package path.

Boundary:

• test org/project first,
• no automatic issue resolution in production,
• human approval before muting alerts or changing alert rules.

Validation prompt:

Search this test project for the newest unresolved issue and summarize it without changing status.

Trust levels

If you cannot classify the trust level, do not install the server yet.

Do not install a server yet if…

• shell, git, or local files already solve the job,
• you cannot write a one-line validation prompt,
• the server needs broad credentials for a narrow task,
• nobody owns the permission boundary,
• you cannot remove it cleanly,
• the only reason is “everyone says MCP is the future.”

The future can wait five minutes while you avoid giving a chatbot admin rights.

Migration note from old MCP catalogs

Old MCP server lists age badly. Package names change, hosted endpoints appear, transport support changes, and clients add their own install flows. Treat old catalog commands as hints, not truth.

For this page, the safer pattern is:

1. Find the official project or docs.
2. Confirm the transport: stdio, HTTP, or client-specific install.
3. Add the server.
4. Validate with claude mcp list and claude mcp get <name>.
5. Run one read-only smoke test.
6. Document the permission boundary in your project notes.

That is less glamorous than a 40-item list. It also survives contact with reality.

Practical starter stack

If you are starting from zero, I would add in this order:

1. Playwright MCP if you build web apps and need browser QA.
2. GitHub MCP if repo/issue/PR context lives outside the local checkout.
3. Context7 if your agent writes code against fast-moving libraries.
4. Fetch MCP if your client lacks a safer built-in URL reader.
5. Filesystem MCP only with tight project roots.
6. Sentry MCP only after you know the org/project boundary.

One server per job. Validate it. Remove the ones you do not use. That is the whole trick.