Registries list thousands of MCP servers as of mid-2026. In real setups — the configs you actually see on working machines — the same handful shows up again and again. This is a walkthrough of that handful: what each one enables, the gotcha people hit in the first week, and whether it is officially maintained or community work, because that distinction decides who patches it when something goes wrong.

If MCP itself is new to you, start with the cluster pillar, what MCP actually is. And because every entry below is also a trust decision, keep security considerations within reach — this article ends with its checklist compressed. The remaining siblings cover MCP versus function calling and server design.

Filesystem — the one that disappeared into the clients

What it enables. Reading, writing, and searching files under configured directories. This was the original killer demo in November 2024: point Claude Desktop at a project folder and the model can actually read your code.

Status. Started as an Anthropic-published reference server in the modelcontextprotocol org. By mid-2026 the capability is built into several major clients — Claude Desktop, Claude Code, Cursor, and Zed all ship native file access with their own permission UIs — so the standalone server now matters mainly for custom agents and for setups where you want file access confined to an explicit mount.

The gotcha. Over-broad mounts. Pointing it at your home directory grants the model your SSH keys, browser profiles, and credential files in one line of config. Mount the narrowest directory that works, and remember that write access plus an injected instruction equals arbitrary file modification.

GitHub — the official workhorse

What it enables. Issues, pull requests, repository browsing, code search, and workflow queries through tools like create_issue and list_pull_requests. For teams living in GitHub, this is routinely the first server installed after filesystem — triage an issue, draft the fix, open the PR, all in one conversation.

Status. Official. GitHub maintains its own server, which is what working setups run today rather than the early reference implementation, with a remote-hosted option arriving as streamable HTTP matured through 2025.

The gotcha. Token scope. A classic personal access token grants everything your account can touch — every repo, org-wide. Use a fine-grained token scoped to the specific repositories you intend the model to reach, read-only where that suffices. The most common GitHub-MCP incident is not an exploit; it is a confidently wrong model editing the wrong repo with a token that never should have been able to see it.

Slack — search and post, carefully

What it enables. Searching workspace history, reading channels, and posting messages. Genuinely useful for "what did we decide about X in March" queries, and for agents that report their results to a channel.

Status. Began as a reference server; since then, community forks and vendor-side offerings have accumulated alongside it. Check what exactly you are installing and who publishes it — this is one of the muddier lineages among the common servers.

The gotcha. Posting is a write action with an audience. A model that misreads intent and posts a half-finished draft to #engineering is a small workplace disaster, so keep write tools behind confirmation (the consent-gating pattern from the security article) and consider a read-only configuration if search is all you need. Search results also pull other people's messages into model context — think about what leaves the workspace if you are using a hosted model.

Postgres — read-only queries against a real database

What it enables. Schema inspection plus SQL queries against a live database, in the sensible configurations read-only. "How many signups last week, grouped by plan?" answered directly, without exporting a CSV first.

Status. Reference-server origin, with a broad field of community and vendor-maintained variants covering other databases. The read-only convention comes from the design pattern covered in server design basics: schemas exposed as resources, one guarded query tool for the open-ended reads.

The gotcha. Read-only must be enforced by the database, not by the tool description. Connect with a role that has SELECT and nothing else; a server that merely promises to avoid writes is one prompt injection away from breaking that promise. Second gotcha: models write plausible-but-expensive SQL, so point it at a replica, not the primary, if your data is big enough to hurt.

Playwright and Puppeteer — browser automation

What it enables. Driving a real browser: navigate, click, fill forms, screenshot, extract page content. This unlocks the tasks with no API — testing your own UI, filling a form on a site that will never have an integration, or letting an agent verify visually that a deploy worked.

Status. Playwright's server is official Microsoft and, as of mid-2026, generally the default choice, with accessibility-tree-based interaction that models handle more reliably than raw pixels. Puppeteer-based servers circulate too, from a mix of maintainers — check who publishes the one you install.

The gotcha. The web is an injection delivery system. Every page the browser loads becomes tool-result text in the model's context, and pages that instruct LLM agents are no longer hypothetical. Run browser automation in a separate browser profile with no saved logins, assume anything readable on a visited page may steer the model, and gate any tool that submits or purchases.

Sentry — asking your errors questions

What it enables. Querying error and performance data: recent issues, stack traces, frequency, release correlation. The practical win is debugging in one context — the model reads the actual stack trace from Sentry and your actual code via file access, then proposes a fix grounded in both.

Status. Official; Sentry maintains its own server and leaned into MCP early, including hosted remote access.

The gotcha. Volume. Error payloads are enormous, and naive "list recent issues" calls can flood the context window with stack traces, degrading the model before it starts reasoning. Query narrowly — one issue, one release — rather than paging through the firehose. And stack traces plus local variables can contain user data; treat the server's access level accordingly.

Memory — notes that survive the session

What it enables. Persistent storage the model reads and writes across sessions, typically as a knowledge graph or note store: "remember that our staging DB is on port 5433" actually sticks for next week's conversation.

Status. Reference-server origin (the knowledge-graph memory server in the modelcontextprotocol org), now surrounded by a crowded field of community alternatives with fancier retrieval. The reference one remains the sane default: small, readable, local.

The gotcha. Memory is a persistence mechanism for prompt injection. A poisoned instruction written into memory in one session replays into every future session's context — the one place where a transient attack becomes durable. Review what accumulates there occasionally, and keep memory files out of any directory other servers can write.

Before you install: the checklist

Five minutes, every time, no exceptions for popular names:

  1. Verify the publisher. Find the actual GitHub org — github, microsoft, getsentry, modelcontextprotocol — and check the name character by character. Registries carry look-alikes.
  2. Read the tool list. Every tool name and description, before first connection. You are reading text that will be injected into your model's context.
  3. Scope the credentials. Minimum viable token: fewest repos, read-only role, no saved browser logins. Assume the worst call the model could make and cap the damage in the credential.
  4. Pin the version. Track releases deliberately, not latest. Description and behavior changes between versions are how vetted servers go bad.
  5. Decide the consent policy per tool. Auto-approve narrow reads if you must; keep every write behind a confirmation you actually read.

The takeaway

The MCP ecosystem in mid-2026 is thousands of servers wide but, in practice, about seven deep: files, GitHub, Slack, Postgres, a browser, Sentry, and memory cover the large majority of real workflows. Officialness matters more than feature lists — vendor-maintained servers get patched, forks maybe. Install less than you think you need, scope harder than feels necessary, and run the checklist even for the famous ones. The best MCP setup is the boring one: a few well-chosen servers you understand, doing work you can audit.