11 Best MCP Servers Worth Installing in 2026

Fourteen of the original Model Context Protocol reference servers now sit in a separate servers-archived repository whose README opens with "IMPORTANT: This repository is archived and no longer maintained" and states that "NO SECURITY GUARANTEES ARE PROVIDED FOR THESE ARCHIVED SERVERS." Among them: GitHub, GitLab, Slack, PostgreSQL, Sentry, Google Maps and Puppeteer. Seven reference servers remain current. That single fact is why most MCP server lists are dangerous: they were assembled from other lists, and half of what they recommend has not shipped a security fix in a year.

The biz collect team checked every server below against its own repository or vendor documentation during this session: who maintains it, whether it is official or community-run, what it actually exposes, whether it mutates anything, and whether it is still being worked on. Where a project says something uncomfortable about its own future, that sentence is quoted rather than smoothed over. If you are building a server rather than choosing one, the MCP server build guide is the companion piece to this one.

How we chose the best MCP servers

There is no single best MCP server, because an MCP server is not a product category, it is a connector. The right list for an engineer wiring an agent to production Postgres has almost nothing in common with the right list for someone automating a browser. So these are ranked by how much useful, low-risk capability you get per unit of installation effort, for a developer or agent builder deciding what to add to a client today.

Six criteria decided the order, and every entry is described against all six: whether the vendor maintains the server themselves or a volunteer does; what it actually exposes, listed as real tool names read out of the repository rather than marketing categories; transport, stdio for a local process your client launches or Streamable HTTP for a remote URL that updates without you reinstalling anything; the auth model, which is the biggest difference in blast radius between two servers that look identical in a tool list; whether it mutates, and whether a read-only mode exists; and what it costs, separating the server, which is almost always free, from the usage it drives, which usually is not.

The 11 best MCP servers at a glance

The biz collect API is built for agent builders, so this list is the one we maintain for our own tool belt as much as for readers. Here is the complete mcp server list before the detail, in the order argued below:

1. GitHub MCP Server
2. Filesystem MCP Server
3. Playwright MCP
4. Context7
5. AWS MCP Servers
6. Azure MCP Server
7. Linear MCP Server
8. Postgres MCP Pro
9. biz collect
10. Notion MCP
11. Slack MCP Server

Now let's review each MCP server in detail.

How an MCP server gets registered

Registration is the same shape in every client, so learn it once. A local server is a command your client launches over stdio; a remote server is a URL. Both usually live in one JSON block:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/projects"]
    },
    "linear": {
      "type": "http",
      "url": "https://mcp.linear.app/mcp"
    }
  }
}

That is the entire orientation. The exact file path and key name differ per client, and per-client setup is not this article's job. What matters for choosing is the pattern: the local entry hands a process a directory argument that bounds everything it can ever touch, and the remote entry hands a URL an OAuth flow will authorise. Every decision below is a variation on those two lines.

The 11 best MCP servers, reviewed

1. GitHub MCP Server

GitHub maintains its own MCP server at github/github-mcp-server, and it is the single highest-leverage install for most developers because so much of an engineer's context already lives in GitHub. It is official, it is actively developed, and it is unusually honest about its own surface area: rather than dumping every tool into one namespace, it groups them into toolsets you enable selectively.

The toolsets are named in the repository documentation and cover context, repos, issues, pull_requests, actions, code_security, secret_protection, dependabot, discussions, projects, notifications, orgs and copilot, among others, with copilot_spaces and github_support_docs_search additionally available in remote mode. It runs locally or as a hosted remote server at https://api.githubcopilot.com/mcp/. Authentication is OAuth with the token held in memory, a personal access token, or a GitHub App for non-interactive deployments.

It mutates a great deal: issues, pull requests, files, branches, repositories and CI workflows are all writable with the right scopes. The mitigation ships with it. The documentation states that "write tools are skipped if --read-only is set, even if explicitly requested" - the correct default for an agent that is exploring rather than shipping.

Highlights:

• Maintainer: Official, GitHub
• Exposes: Tools grouped into named toolsets covering repos, issues, pull requests, Actions, security and Copilot
• Transport: stdio locally, or remote at https://api.githubcopilot.com/mcp/
• Auth: OAuth, personal access token, or GitHub App
• Mutates: Yes, extensively. --read-only skips every write tool
• Cost: Server is free; needs a GitHub account, and remote mode is tied to Copilot infrastructure

2. Filesystem MCP Server

The filesystem server is one of the seven surviving reference implementations in modelcontextprotocol/servers, a repository the README describes as "Managed by Anthropic, but built together with the community." It is the most-installed MCP server in existence for a boring reason: almost every agent task eventually needs to read or write a file, and this is the version whose access control was designed rather than bolted on.

Thirteen tools are exposed: read_text_file, read_media_file, read_multiple_files, write_file, edit_file, create_directory, list_directory, list_directory_with_sizes, move_file, search_files, directory_tree, get_file_info and list_allowed_directories. It runs over stdio and has no authentication at all, because authentication is not the control here. Directory scope is.

Access is bounded two ways: allowed directories passed as command-line arguments at startup, or the MCP Roots protocol, where roots sent by the client "completely replace any server-side Allowed directories when provided." If neither is supplied, the server throws during initialization rather than defaulting to your whole disk. That refusal to start is the best-designed detail on this list, and a fair benchmark for judging any other server that touches local state.

Highlights:

• Maintainer: Official reference server, modelcontextprotocol organisation
• Exposes: 13 tools for reading, writing, moving, searching and inspecting files
• Transport: stdio
• Auth: None; scope is enforced by allowed directories or MCP Roots
• Mutates: Yes, write_file overwrites and edit_file edits in place
• Cost: Free

3. Playwright MCP

Maintained by Microsoft alongside Playwright itself, this is the Playwright MCP server that made browser automation for agents usable. The design decision that matters is stated plainly in its documentation: it "uses Playwright's accessibility tree, not screenshots," so a text model can drive a browser without a vision model in the loop and without the cost and flakiness of pixel matching.

The core tool set is deliberately small and readable: browser_navigate, browser_click, browser_type, browser_snapshot, browser_fill_form, browser_evaluate, browser_wait_for, browser_take_screenshot and their siblings, around twenty in all. Beyond that, capability groups are opt-in rather than always-on: network interception, storage and cookies, devtools and tracing, coordinate-based mouse control for the cases where the accessibility tree is not enough, and PDF export. It runs over stdio by default and as a standalone HTTP server with --port.

Install it with npx @playwright/mcp@latest. Note what "mutates" means for a browser server: it does not change your repository, it acts on live web pages while logged in as you. Snapshot and screenshot tools are read-only; clicking a button in a production admin panel is not.

Highlights:

• Maintainer: Official, Microsoft
• Exposes: Around twenty core browser tools, plus opt-in network, storage, devtools, coordinate and PDF groups
• Transport: stdio by default, HTTP with --port
• Auth: None at the protocol layer; it inherits whatever the browser profile is logged into
• Mutates: Yes, it performs real actions on live pages. Read-only tools are marked as such
• Cost: Free

4. Context7

The Context7 MCP server is maintained by Upstash and does one narrow thing extremely well: it pulls current, version-specific library documentation and code examples into the model's context so the agent stops writing against an API that was renamed two releases ago. On a list where most entries can break something, this is the one that only ever adds information.

It exposes exactly two tools, which is the point. resolve-library-id turns a general library name into a Context7 library ID, taking query and libraryName. query-docs then retrieves documentation for that ID, taking libraryId and query. Two tools means two tool descriptions in your context window and almost no chance of the model picking the wrong one.

It is available as a remote server at https://mcp.context7.com/mcp, or locally via the @upstash/context7-mcp npm package. An API key is not required to start, and the documentation notes you can "get a free API key at context7.com/dashboard for higher rate limits," sent as an Authorization: Bearer header. It is strictly read-only, which makes it the cheapest server on this list to trust.

Highlights:

• Maintainer: Official, Upstash
• Exposes: Two tools, resolve-library-id and query-docs
• Transport: Remote at https://mcp.context7.com/mcp, or stdio via @upstash/context7-mcp
• Auth: Optional API key as a bearer token, for higher rate limits
• Mutates: No, retrieval only
• Cost: Free tier, with a free key available for higher rate limits

5. AWS MCP Servers

AWS publishes a whole suite rather than one server, at awslabs/mcp. Alongside the core AWS server, which is in preview, there are servers for documentation, AWS Knowledge, DynamoDB, PostgreSQL, MySQL, EKS, ECS, Lambda and Bedrock Knowledge Bases, among many others. This is the right model for a cloud provider: you install the two or three that match your stack instead of handing an agent the entire AWS API surface.

Authentication is the strongest argument for using these over a community wrapper. The core server describes IAM-based permissions with no credential exposure to the model and CloudTrail audit logging, meaning every action an agent takes is recorded through the same mechanism as every other action in your account. Installation follows one consistent pattern across the suite, uvx <package-name>@latest with environment variables for configuration.

Mutation is opt-in per server through flags, notably --allow-write and --allow-sensitive-data-access, which are off unless you turn them on. One historical detail worth knowing when reading older tutorials: Server-Sent Events support was removed in 2025 to align with the protocol specification, so any guide telling you to configure an SSE endpoint here is out of date.

Highlights:

• Maintainer: Official, AWS Labs
• Exposes: A suite of separate servers per AWS service, plus documentation and knowledge servers
• Transport: stdio via uvx
• Auth: IAM permissions, with CloudTrail audit logging
• Mutates: Off by default; --allow-write and --allow-sensitive-data-access opt in
• Cost: Servers are free; AWS usage they trigger is billed normally

6. Azure MCP Server

Microsoft's Azure MCP Server lives in microsoft/mcp and takes the opposite structural bet to AWS: "All Azure MCP tools in a single server." Microsoft Learn documents its tool areas individually, including Azure AI Search, App Configuration, Cosmos DB, the Azure Developer CLI, Key Vault, Azure Monitor with KQL queries, Azure RBAC and Azure Cache for Redis, plus an Azure best practices tool.

Authentication is Entra ID through the Azure Identity library, and access is bounded by Azure role-based access control, so "tool availability reflects your Azure subscription permissions." That is a genuinely good property: the agent can never exceed the human whose credentials it is using. Microsoft also states the prerequisites plainly, a GitHub Copilot subscription and an Azure account with appropriate RBAC, and notes that Azure MCP Server tools are disabled by default in supported hosts until you enable them.

One line from Microsoft's own overview belongs in any honest write-up: "The local MCP server is intended strictly for developer use within your organization. Don't use these tools for external applications or scenarios outside the approved development environment." Take that at face value when planning a deployment.

Highlights:

• Maintainer: Official, Microsoft
• Exposes: One server covering many Azure services, documented tool area by tool area
• Transport: stdio through IDE integrations; self-hosted remote deployment is documented
• Auth: Entra ID via Azure Identity, scoped by Azure RBAC
• Mutates: Yes, within the permissions of the signed-in identity
• Cost: Server is free; requires a Copilot subscription and an Azure account

7. Linear MCP Server

Linear runs its own remote MCP server, and it is the cleanest example on this list of how a SaaS vendor should ship one. There is nothing to install. You point a client at https://mcp.linear.app/mcp and authorise it.

Transport is Streamable HTTP with an SSE fallback endpoint. Authentication is OAuth 2.1 with dynamic client registration, so a client that has never seen Linear before can register itself and complete the flow without you pasting a token, though bearer tokens and Linear API keys also work. The documentation describes tools "for finding, creating, and updating objects in Linear like issues, projects, and comments," and does not publish a fixed tool name list, which is the honest tradeoff of a hosted server: it can add tools without your involvement.

The read-only story is the best of any entry here, because it is enforced two independent ways. There is a separate endpoint, https://mcp.linear.app/mcp/readonly, and there is scope-level enforcement: requesting only the read OAuth scope means "the underlying token can't reach write APIs." Belt and braces. Use the readonly endpoint for any agent that is summarising rather than filing.

Highlights:

• Maintainer: Official, Linear
• Exposes: Tools for finding, creating and updating issues, projects and comments
• Transport: Remote, Streamable HTTP with SSE fallback
• Auth: OAuth 2.1 with dynamic client registration; bearer tokens and API keys also accepted
• Mutates: Yes by default. Use /mcp/readonly or the read scope only
• Cost: Included with Linear

8. Postgres MCP Pro

The reference PostgreSQL server is archived, so every current postgres mcp server is a community project, and the strongest is Postgres MCP Pro from Crystal DBA at crystaldba/postgres-mcp. Community here means a company maintains it rather than the PostgreSQL project, which is worth knowing before you point it at production.

It goes well past "run my SQL." Nine tools are exposed: list_schemas, list_objects, get_object_details, execute_sql, explain_query, get_top_queries, analyze_workload_indexes, analyze_query_indexes and analyze_db_health. The index tuning tools explore large numbers of candidate indexes and simulate hypothetical ones in query plans, and the health checks cover buffer cache, vacuum health and connection utilisation. That is a database consultant's toolkit, not a SQL passthrough.

Its access control is why it ranks above the alternatives. Two modes ship: unrestricted, with full read and write access, for development; and restricted, which runs read-only transactions with execution time limits, for production. Connection is a standard DATABASE_URI environment variable, and it installs via Docker, pipx or uv. Use restricted mode against production, and give the connection string a role that could not do damage even if the mode failed.

Highlights:

• Maintainer: Community, Crystal DBA. The official reference Postgres server is archived
• Exposes: Nine tools covering schema inspection, SQL execution, query plans, index tuning and database health
• Transport: stdio via Docker, pipx or uv
• Auth: Postgres connection string in DATABASE_URI
• Mutates: Yes in unrestricted mode. Restricted mode enforces read-only transactions and time limits
• Cost: Free and open source

9. biz collect

biz collect is on this list as the answer to a job the other ten do not cover: giving an agent live local business data, so it stops inventing dentists in Austin. It ranks ninth for an honest reason. biz collect does not run a hosted MCP endpoint. There is no URL you point an MCP client at to get tools for free. Every other entry above installs in a minute; this one you wrap yourself.

What it ships instead is the material an MCP server is built from: an OpenAPI 3.1 specification at /openapi.json covering every endpoint, parameter and response field, llms.txt and llms-full.txt for agent orientation, a stable JSON response shape, and a synchronous mode that collapses the create-then-poll lifecycle into one call. That comes to one tool definition and one HTTP handler around a single endpoint. The MCP server build guide walks through the wrapper, and the ai agent lead generation pipeline shows the same call inside a find-and-draft agent.

The endpoint that tool wraps is POST /api/v1/search. Only location and keywords are required, and wait: true returns finished results in the same response. Take the API origin from the docs rather than hardcoding one:

# BIZ_COLLECT_API is the API origin shown in the docs, plus /api/v1
curl -X POST "$BIZ_COLLECT_API/search" \
  -H "Authorization: Bearer biz_live_..." \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{
    "location": "Winterthur",
    "keywords": ["bakery", "cafe"],
    "radius_km": 10,
    "scrape_emails": true,
    "wait": true
  }'

A completed call returns the same envelope as GET /api/v1/jobs/{job_id}: job_id, status, results_count, coverage, a businesses array and wait_timed_out: false, with each business carrying name, address, phone, website, emails, social links, coordinates, rating, opening hours and reviews. The OpenAPI 3.1 spec is the field-by-field contract.

Now the part most lists leave out. Emails are scraped from the business's own website, so a business that publishes no address on its site returns none. There is no CRM sync, no email sending, no phone verification, no firmographic, technographic or intent data, no LinkedIn data and no contact database beyond the people a business names on its own pages. Coverage of a city depends on what Google Places returns for your keywords, and coverage: "exhaustive" exists precisely because the standard query is capped by Google at 60 results. If you want a hosted MCP endpoint today rather than a wrapper you own, install something else and come back when you want the data.

Highlights:

• Maintainer: Official, biz collect. Not an MCP server: an OpenAPI 3.1 REST API you wrap
• Exposes: POST /api/v1/search plus jobs, export, account and webhook endpoints
• Transport: HTTPS REST, async by default with a synchronous wait: true mode
• Auth: Authorization: Bearer biz_live_...
• Mutates: Nothing of yours. It creates and reads jobs in your own workspace
• Cost: 200 signup credits with no credit card; Pro $19 per month billed yearly, Business $76 per month billed yearly

10. Notion MCP

Notion maintains an official Notion MCP server, and it is genuinely useful for agents that read and write structured project knowledge. It ranks below the servers above only because of what its own repository says about its future.

There are two things called Notion MCP. The current one is a remote server hosted by Notion, documented at developers.notion.com and authorised over OAuth. The other is the local server at makenotion/notion-mcp-server, whose tools cover querying, retrieving, creating and updating data sources, databases and page markdown.

Read that local repository's own words before you build on it: "We may sunset this local MCP server repository in the future" and "Issues and pull requests here are not actively monitored." It broke compatibility once already, with version 2.0.0 removing post-database-query, update-a-database and create-a-database in favour of data-source equivalents. Use the remote server; if you need local, pin your version and expect to own the maintenance.

Highlights:

• Maintainer: Official, Notion. The local repository is explicitly not actively monitored
• Exposes: Tools for searching, reading, creating and updating pages, databases and data sources
• Transport: Remote hosted server, or stdio via the local package
• Auth: OAuth for the remote server; integration token or headers for the local one
• Mutates: Yes, it creates and updates pages and data sources
• Cost: Included with Notion

11. Slack MCP Server

Slack's reference server is one of the fourteen archived ones, so every current option is community-run. The most capable is korotovsky/slack-mcp-server, and it is last on this list not because it is bad, it is actively maintained and does more than the archived original ever did, but because of its authentication model.

It exposes eighteen tools covering channel history, threads, message search, posting, reactions, user lookup and unread state. Credit where due on safety defaults: the project states that "the conversations_add_message tool is disabled by default for safety" and must be enabled with an environment variable.

The thing to understand is how it authenticates. It supports standard bot tokens (xoxb-) and user OAuth tokens (xoxp-), but its headline feature is a "stealth mode" using browser session tokens (xoxc- and xoxd- cookie) that needs no workspace app install and no scopes. That is exactly why people reach for it, and exactly why it deserves a slower decision than the rest of this list. Session cookies are not scoped, cannot be granularly revoked, and carry your full user identity. If your workspace allows a bot token, use the bot token.

Highlights:

• Maintainer: Community, korotovsky. Slack's official reference server is archived
• Exposes: 18 tools covering channel history, threads, search, reactions, users and unreads
• Transport: stdio, with an HTTP mode available
• Auth: Bot token, user OAuth token, or browser session cookies in stealth mode
• Mutates: Yes. conversations_add_message is disabled by default and enabled by environment variable
• Cost: Free and open source

Installing third-party MCP servers safely

An MCP server is a program you are handing to a model. The specification says so directly: tools "represent arbitrary code execution and must be treated with appropriate caution," and, in a line worth reading twice, "descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server." The protocol also requires hosts to obtain explicit user consent before invoking any tool. None of it is enforced at the protocol level, which means it is your job. Five practical habits, no legal advice and no scaremongering:

Prefer the vendor's own server, and read the repository before the star count. Where GitHub, Linear, Datadog, GitLab or Snowflake ships an official server, install that one: it tracks its own API when it changes. The archived reference servers were the most-copied MCP examples in existence, and their archive notice now states that no security updates or bug fixes will be provided. Popularity is a lagging indicator; recent commits are a leading one.

Use read-only wherever it exists, and read the auth model rather than the tool count. GitHub's --read-only, Linear's /mcp/readonly endpoint and read scope, Postgres MCP Pro's restricted mode and AWS's write-disabled default are one configuration line each, and they switch most of an agent's blast radius off. OAuth with scopes can be revoked and audited, and a personal access token can be scoped. Browser session cookies are neither, and a server whose selling point is that it needs no workspace permissions is telling you exactly what it is doing.

Verify identity through the official registry. The MCP registry at registry.modelcontextprotocol.io is the project's own catalogue, described as "a community driven registry service." Publishers prove namespace ownership through GitHub OAuth, GitHub OIDC from Actions, DNS records or HTTP challenges, so io.github.someuser/thing means that GitHub account really published it. It is still a preview release where, in its own words, "breaking changes or data resets may occur."

What is replacing MCP servers?

Nothing is. The current specification is dated 2026-07-28, and the project has been formally established as "Model Context Protocol a Series of LF Projects, LLC," stewarded under the Linux Foundation with a published governance model rather than owned by a single vendor. Contributions are Apache 2.0. Standards do not usually get donated to a foundation on their way out. The direction of travel is expansion: the specification now defines optional extensions including Tasks for long-running operations, MCP Apps for inline UI, and Skills over MCP.

That last one answers the question people actually mean. Anthropic's engineering write-up frames Agent Skills as complementary, describing how "Skills can complement Model Context Protocol (MCP) servers by teaching agents more complex workflows that involve external tools and software," and MCP runs a Skills Over MCP Working Group with a draft Skills Extension in review. Skills are being delivered through MCP, which is the opposite of a replacement. The neighbouring standard worth knowing is A2A, donated by Google to the Linux Foundation, which its own documentation separates cleanly: MCP "standardizes how an agent connects to its tools, APIs, and resources," while A2A "lets independent agents - including those using MCP - discover each other, delegate tasks, and share results." Use MCP to equip one agent, A2A to make several cooperate.

Which language is best for building an MCP server?

TypeScript or Python, unless your target system pulls you elsewhere. The MCP project classifies its official SDKs into tiers by feature completeness and maintenance commitment: Tier 1 covers TypeScript, Python, C#, Go and Rust, Tier 2 Java and Ruby, Tier 3 Swift, PHP and Kotlin. Pick by where your data already lives. Python is the obvious choice near data tooling, which is why most AWS servers are distributed with uvx; TypeScript wins for anything Node-shaped and the npx pattern every client documents. All SDKs support servers, clients, local and remote transports and the same protocol compliance, so the language matters far less than whether you expose a small number of well-described tools.

How to pick the two or three you install today

Choosing well here is mostly about resisting the urge to install everything. Three factors decide it: whether an official server exists for the system you are connecting, whether the server can be run read-only for what you are actually asking it to do, and whether the auth model can be revoked when something goes wrong. Tool count is not a factor. A server with two well-described tools that cannot damage anything beats one with forty that can, because every tool definition you install costs context on every single turn.

If you are wiring an agent to real-world business data rather than to your own systems, the shape of the problem changes: you are not connecting to a service you already own, you are sourcing data that does not exist in your stack. biz collect is the API for that specific job, and wrapping it is one tool definition and one handler over POST /api/v1/search with wait: true. The OpenAPI 3.1 spec is the contract, llms.txt is the orientation, and nothing in the response shape changes underneath a tool you generated from it.

Hand this to your agent as a tool. Read the API docs.

FAQ: MCP servers