best 22 mcp servers

microsoft's playwright server exposes navigation, clicking, typing, form filling, snapshots, console messages, network inspection and tab management. the design decision that matters is that it operates on the accessibility tree rather than pixels, so the model gets structured text instead of an image to squint at. that is both more reliable and dramatically cheaper per turn than every screenshot-based competitor.

install is one line — `npx @playwright/mcp@latest` — with docker and standalone http modes documented, and `claude mcp add playwright npx @playwright/mcp@latest` for claude code.

the risk is proportional to the capability. it drives a browser that may already be logged into your accounts, and one of its tools is called `browser_run_code_unsafe`, which is at least honest. combined with any page containing untrusted text, this is a complete lethal-trifecta setup by default: private data, attacker-controlled content, and an exfiltration channel in one session. use the isolated or docker profile for anything you didn't write.

note that the archived `puppeteer` reference server is its obsolete predecessor — if a guide tells you to install that, the guide is over a year stale.

this is where coding agents actually live, and github's own go implementation covers it properly: issues, pull requests, actions, code scanning, dependabot, discussions, projects, notifications, security advisories and more, grouped into toolsets you can enable selectively.

the remote endpoint at `https://api.githubcopilot.com/mcp/` needs no install at all. locally there's a published docker image. auth is an oauth browser flow with tokens held in memory, or a personal access token if you prefer.

enable subsets rather than everything — the full toolset is a large context footprint, and most sessions need issues and prs, not secret scanning.

the security note is not hypothetical. this server is the subject of the well-documented attack class where a malicious issue filed on a public repo prompt-injects the agent into leaking private repository contents. `--read-only` exists and narrow pat scopes exist; use both.

context7 pulls up-to-date, version-specific library documentation and code examples into the prompt on demand. you can name a library as `/org/project` and pin a version in plain language. it is the rare mcp server whose value is obvious within one session.

setup is `npx ctx7 setup`, which handles oauth, generates a key and installs a skill, with `--claude`, `--cursor` and `--opencode` targeting. the manual path points at `https://mcp.context7.com/mcp` with the key in a `CONTEXT7_API_KEY` header — which is the right pattern, and notably better than the competitors that document putting secrets in url query strings.

at nearly 60,000 stars and over a million npm installs a week it is among the most adopted things in the ecosystem.

one strategic signal worth flagging: upstash now ships a cli-plus-skills mode explicitly described as not requiring mcp at all. when a vendor offers a non-mcp path to its own mcp server's job, that tells you something about where simple documentation retrieval is heading.

seven servers are still maintained by the protocol team: filesystem, git, fetch, memory, time, sequentialthinking and everything. filesystem alone does 471,000 npm downloads a week, second only to playwright.

filesystem does sandboxed read, write, edit, search and move inside directories you explicitly allow. git exposes status, diff, commit, log with timestamp filters, show and branch operations. fetch retrieves a url and converts it to markdown.

the critical thing to know is what is no longer here. github, slack, postgres, puppeteer, gdrive, brave-search, sentry, gitlab, redis, sqlite, everart and google-maps were all moved to an archived repo frozen at may 2025. if a tutorial tells you to `npx @modelcontextprotocol/server-github`, that tutorial is more than a year out of date and every one of those has a first-party replacement.

on risk: `fetch` is a textbook prompt-injection vector, pulling untrusted web content straight into context, and `filesystem` writes wherever you allowed it. a badly scoped root directory is a real incident, not a theoretical one.

there are two official figma servers and they are different products. the remote one at `https://mcp.figma.com/mcp` uses oauth, is link-based (you paste a figma url), and can create and modify content in figma design and figjam as well as read it. for claude code it installs as `claude plugin install figma@claude-plugins-official`.

the desktop one runs at `http://127.0.0.1:3845/mcp` and requires the figma desktop app open with dev mode on and the mcp toggle enabled. in exchange it is selection-based — it acts on what you have selected — and adds design-token extraction and code connect integration. install with `claude mcp add --transport http figma-desktop http://127.0.0.1:3845/mcp`.

the desktop server's manual toggle is the single most common support issue in this category. if your tools aren't appearing, that's why.

there is also a well-known community alternative, framelink's figma-context-mcp — 15,500 stars and 87,000 npm installs a week. it fetches via the rest api and deliberately simplifies the response to reduce context, needs no desktop app, and is read-only with a personal access token in plain config. prefer official for oauth and write access; framelink is the lighter option if you just want layout data into cursor.

config is a single url: `https://mcp.supabase.com/mcp`, with oauth 2.1 handling login and org selection. it manages tables, fetches project config, queries data, reads docs and handles branches. the url accepts parameters — `project_ref`, `read_only=true`, `features=database,docs` — which is a genuinely good scoping primitive.

there are local cli and self-hosted paths too, both with a reduced tool subset and no oauth 2.1.

the reason it doesn't rank higher is the risk profile it demonstrates. this is the server behind the widely-cited lethal-trifecta writeup: an agent with database access, reading attacker-controlled rows from a support-ticket table, being induced to exfiltrate other tables. supabase's own readme links to a security-risks section and tells you to read it before setup, which is more honest than most vendors manage.

for anything touching production, `read_only=true` with a scoped `project_ref` is the minimum sane configuration.

linear ships remote-only, which sounds like a limitation and is actually the point. there is nothing to install, nothing to keep updated, and no long-lived credential sitting in a config file. oauth 2.1 with dynamic client registration handles consent in the browser once and reuses it after.

the toolset covers reading issues, projects, teams, users, documents, cycles and comments, plus creating and updating issues, projects, comments and labels. a february update added initiatives, initiative updates, project milestones, project updates and project labels.

tool descriptions are unusually well written, which matters more than it sounds — the model's ability to pick the right tool depends almost entirely on how they're described.

the flip side of remote-only is no self-hosting and no on-premise story, and we could not verify a read-only mode. for regulated environments that may be disqualifying regardless of how clean the implementation is.

the gateway runs each mcp server in its own container, keeps api keys in docker desktop's secret store instead of environment variables, handles oauth flows, and gives you a single unified endpoint plus call tracing and logs.

given that the ecosystem's security model is fundamentally trust-the-publisher, and that most install instructions are `npx -y something@latest` — unpinned remote code execution on every client start — this is the most practically valuable security control available.

it doubles as an aggregator, so it also addresses the tool-bloat problem that hits once you're running more than a handful of servers.

the costs are real: it works best if you're already on docker desktop, the catalogue lags the long tail of community servers, and you're adding a hop plus container startup latency to every call. worth it for anything you didn't write yourself.

the hosted server at `https://mcp.notion.com/mcp` uses oauth and needs no setup, and that's the one to use. the open-source local server runs via `npx @notionhq/notion-mcp-server` with stdio or http transports, an auth token flag, and an honestly-named `--unsafe-disable-auth` option.

notion has reportedly said the local open-source server is no longer actively maintained and may be sunset in favour of the hosted one. the repo's activity is consistent with that. we could not find a formal announcement, so treat it as likely rather than confirmed — but don't build a long-term dependency on the local path.

at 137,000 npm downloads a week the adoption is real regardless.

worth thinking about the injection surface: notion pages are shared workspaces, and anyone who can add a page can plant instructions that your agent will read as though they came from you. that isn't a flaw in the server, it's the nature of connecting an agent to a collaborative document store.

sentry's server handles issue, error, trace and performance inspection plus ai-powered search, and it is the most thoughtfully designed thing we reviewed. you can narrow the tool surface with `?skills=inspect,triage` or `?disable-skills=seer`, which directly addresses the context-bloat problem most servers ignore.

the auth design is unusually careful: it uses a distinct `Sentry-Bearer` header for pass-through sentry tokens, reserving plain `Bearer` for mcp oauth tokens, and documents that the worker does not store, validate, exchange or refresh the upstream token. that is the kind of detail that only shows up when someone has thought about failure modes.

remote at `https://mcp.sentry.dev/mcp`, stdio via `npx @sentry/mcp-server@latest`, self-hosted sentry supported with a `--host` flag, and it ships as a claude code plugin with a subagent.

two caveats. the ai search tools need your own openai, anthropic, azure or openrouter key or they quietly vanish. and the stdio path asks for `project:write` and `event:write` scopes, which is broader than a read-only triage workflow actually needs.

exa is neural search designed for machine consumption. the tools are `web_search_exa`, `web_fetch_exa`, `web_search_advanced_exa` with full filter control over domains and dates, and `agent_run`, which kicks off a multi-step research or enrichment task and returns structured output.

that last one is the differentiator. every other search server on this list returns results; this one will go and do a piece of research.

install is `claude mcp add --transport http exa https://mcp.exa.ai/mcp`, with a documented `mcp-remote` bridge for stdio-only clients and snippets for around twenty clients.

the criticism is the same one that applies to tavily and firecrawl: several documented configurations put the api key directly in the url. urls end up in shell history, proxy logs, crash reports and screenshots. use the header form where your client supports it.

firecrawl covers scraping, crawling, site mapping, search and structured extraction, which makes it the tool of choice when you need a website turned into data rather than just read once. 79,000 npm downloads a week and 7,000 stars.

both hosted and self-hosted paths are documented — `env FIRECRAWL_API_KEY=fc-... npx -y firecrawl-mcp` locally, or the hosted endpoints including a search-only variant if that's all you need.

the thing to avoid: one documented endpoint format is `https://mcp.firecrawl.dev/{FIRECRAWL_API_KEY}/v2/mcp`, putting your secret in a url path. that is worse than a query string, which is already bad. use the header or environment-variable form.

crawl operations also get expensive quickly, and the legal question of what you're allowed to scrape is yours, not firecrawl's.

slack's own server went generally available in february at `https://mcp.slack.com/mcp`, replacing the archived reference server. it covers search across messages, files, users, channels and emoji, messaging, canvas operations and user management.

the enterprise posture is the selling point: confidential oauth with granular scopes per tool family, standard slack app approval, mcp-specific audit logs, and tier-based rate limits. it also refuses sse outright — json-rpc over streamable http only.

the constraint is that only directory-published or internal apps may use it. casual personal use is much harder than it used to be, which is deliberate.

there is a popular community alternative worth knowing about mainly so you can avoid it at work: it offers a 'stealth mode' using your browser session tokens so it needs no workspace permissions at all. that is by design a bypass of your admin's controls, and in most organisations using it is a policy violation and possibly a security incident. use the official one.

canva's server at `https://mcp.canva.com/mcp` exposes roughly thirty-three tools: design generation, search, export, resize, import, asset upload, brand templates and kits, comments, folders and thumbnails.

the standout is transactional editing — `start-editing-transaction`, `perform-editing-operations`, `commit-editing-transaction`, `cancel-editing-transaction`. an agent that can roll back a batch of edits is a categorically safer thing than one that can't, and almost nothing else in mcp models this.

auth uses client id metadata documents, the newer mechanism the 2025 spec recommends, with dynamic client registration kept as a deprecated fallback. that puts canva ahead of most vendors on spec currency.

two frictions: features are plan-gated in ways that will confuse readers — resizing needs pro, brand kits need enterprise — and the per-tool rate limits of twenty to a hundred requests a minute are low for bulk work. note also that canva runs a second, unrelated 'canva dev' mcp server for people building canva apps; mixing them up is an easy mistake.

desktop commander does terminal command execution with shell selection, long-running process management, filesystem search and surgical diff-based file editing. setup is one command — `npx @wonderwhy-er/desktop-commander@latest setup` — and it auto-configures across claude desktop, claude code, codex and others.

it is very actively maintained, well documented, and genuinely excellent at what it does. 8,700 stars.

it is also arbitrary local code execution running with your user's privileges and no auth boundary whatsoever. there is no read-only mode, no sandbox, and no meaningful constraint beyond what your user account can do. if the agent reads a poisoned web page in the same session, the consequences are unbounded.

our recommendation is unambiguous: run it in a container or a vm, or don't run it. it also sends telemetry by default, which is opt-out rather than opt-in.

the official remote server covers jira, confluence, jira service management, bitbucket and compass, with oauth 2.1 or api tokens. the primary endpoint is `https://mcp.atlassian.com/v1/mcp/authv2`, with `/v1/mcp` also supported and a legacy `/v1/sse` you are explicitly told to migrate off.

that endpoint sprawl is genuinely confusing and worth getting right before you file a support ticket about it.

the community alternative, `sooperset/mcp-atlassian`, has 5,600 stars against atlassian's 894, exposes ninety-eight tools, installs with `uvx mcp-atlassian`, and supports stdio, sse and streamable http with a multi-user mode. more importantly it is the only real option for jira and confluence server and data center, which atlassian's cloud server doesn't serve.

ninety-eight tools is a lot of context though — filter them unless you want your tool list to dominate every turn.

full kubernetes and openshift resource management with kubeconfig detection, multi-cluster support and live config reload. install is `npx kubernetes-mcp-server@latest` or `uvx`, with a `--port` flag that starts streamable http and sse.

what earns its place is the safety surface: `--read-only`, `--disable-destructive`, `--toolsets` and `--disable-multi-cluster`. it also offers a `--stateless` mode, which aligns with where the protocol spec is heading and makes load-balanced deployment straightforward.

an agent holding a cluster-admin kubeconfig is the highest-consequence configuration anywhere in this ranking. the fact that this server makes it easy to not do that is the whole reason to prefer it.

a simpler alternative exists in `Flux159/mcp-server-kubernetes`, also actively maintained, more kubectl-shaped and with fewer guardrails.

brave's own server replaces the archived reference brave-search implementation. install is `npx -y @brave/brave-search-mcp-server --transport http` with `BRAVE_API_KEY` in the environment, plus a docker image and a stdio mode.

the security detail worth calling out is `BRAVE_MCP_ALLOWED_HOSTS`, an opt-in host-header allowlist providing dns-rebinding protection on the http transport. unset, the host header isn't validated; set, anything not on the list gets a 403. essentially no other mcp server does this, and it is the kind of thing that separates people who have thought about the threat model from people who haven't.

there are also `--enabled-tools` and `--disabled-tools` allow and deny lists, and a `--stateless` flag.

on results, it is a genuinely independent index rather than a reseller, which matters for some use cases. for pure agentic research quality it sits behind exa and tavily — a different product rather than a worse one.

this covers gmail, calendar, drive, docs, sheets, slides, chat, forms, tasks and search, and works with free google accounts as well as workspace plans. install is `uvx workspace-mcp --tool-tier core`, with `extended` and `complete` tiers above it and docker configs documented.

that tier mechanism deserves the credit it gets. instead of loading fifty tools you'll never call, you pick a tier or name specific services. it's the cleanest solution to context bloat anyone has shipped.

the readme's transport guidance is also unusually clear: streamable http for modern clients, connectors for claude desktop, stdio as a legacy fallback, and oauth 2.1 stateless mode for deployments.

the honest problem is what it is: a community-maintained server holding oauth access to your email, calendar and documents — the most sensitive credential most people have. there is no google-official general-purpose alternative because the reference gdrive server was archived and never replaced, which is a real gap in the ecosystem. the google cloud oauth app setup is also the fiddliest onboarding on this list.

metamcp is a proxy that aggregates multiple mcp servers into one unified server, and because it is itself an mcp server it plugs into any client. you group servers into namespaces, host each namespace at its own authenticated endpoint, remix and override tools, and get an inspector, rate limiting and oidc for enterprise sso.

this whole category exists because once a team passes about ten servers, the combined tool list eats the context window and there is nowhere central to enforce auth or audit. gateways fix both.

the caveat is in metamcp's own readme: the maintainer apologises for a recent maintenance delay, flags a new development branch users should test before building images from, and points at a community-maintained fork. that is admirably honest and it is also a real risk signal. if you want the safer option in this category, docker's gateway adds container isolation and is shipping daily.

a note on the name, because people mean two different things. 'meta mcp' among developers usually means this — aggregation and proxying. but meta, the company, also shipped its ads mcp server to general availability on 16 july 2026 at `https://mcp.facebook.com/ads`, with oauth via facebook login for business and seven permission-scoped tool categories covering reporting, ad and catalog management, signals, troubleshooting, a/b tests and activity logs. the two are entirely unrelated and share only a word.

beehiiv ships an official server at `https://mcp.beehiiv.com/mcp`, with multi-workspace support via an account parameter. it covers content creation and editing, templates and tags, subscriber management, segments, surveys and polls, growth tools, monetisation, automation workflows, podcast data and transcripts, website analytics and seo metadata.

auth is oauth scoped to your beehiiv workspace role, so the server inherits exactly the permissions you already have in the dashboard. setup is an in-app flow with guides for claude, claude code, cursor and codex — there is no cli command published, so be wary of any article that gives you one.

the guardrails are the best part and worth praising: publishing a post and activating an automation both have to be done in the app. the server deliberately cannot press the big red buttons. more vendors should do this.

the reasons it ranks here rather than higher: it's closed-source, so there is no repo, no commit history, no stars and nothing to audit; beehiiv publishes capability categories rather than a tool manifest, so you can't know the exact surface in advance; and its own two documentation pages disagree about what free plans get. the community beehiiv servers are all near-zero adoption and several are abandoned — use the official one.

wiro's server is a gateway to its model catalogue, and the tool design is better than most: `search_models`, `explore` and `recommend_model` for discovery, `get_model_schema` for parameters and pricing, `run_model` to execute, `get_task`, `get_task_price`, `cancel_task` and `kill_task` for lifecycle, plus `upload_file` and `search_docs`. that discovery-to-schema-to-run-to-price flow is more complete than most model gateways, which typically omit cost tools entirely.

the hosted endpoint is `https://mcp.wiro.ai/v1` with an `Authorization` header — credentials in a header rather than a url, which is the right call. it's stateless streamable http, which is exactly where the july 2026 spec is heading. self-hosting via `npx -y @wiro-ai/wiro-mcp` is documented for claude, cursor and windsurf with copy-paste-correct configs.

the reason it sits last is adoption, and there's no polite way to put it: two github stars, twelve npm downloads a week, and no repo commits since march. the hosted server is the primary distribution channel so repo quiet doesn't mean dead — but the download number is not ambiguous. you would be an early user with no community to ask for help.

two smaller notes. the `Bearer apiKey:apiSecret` format is non-standard — not http basic, not a signed jwt — and works fine but follows no common convention, and oauth isn't offered. and because every run costs money, an agent looping on a video model is a billing incident waiting to happen. set a spend cap.