15 Best MCP Servers to Connect in 2026 (Ranked by Maintenance)

Table of Contents

• Read This Before You Install Anything
• The Five Officially Maintained Servers
• First-Party Servers Worth Connecting
• Specialist Servers That Earn Their Place
• The 15 at a Glance
• Three Starter Stacks
• What Changed This Year
• Remote vs Local Servers
• When to Write Your Own
• How to Vet a Server Before Installing
• Five Mistakes People Make
• What It Costs to Run These
• A Sensible Ninety Days
• Frequently Asked Questions
• Final Thoughts

There are now more than twenty-two thousand MCP servers in the wild. Most lists of the best MCP servers respond to that by naming forty of them, which is precisely the opposite of useful.

This one names fifteen, organised by how well maintained they are rather than how impressive they sound. That ordering matters more than it looks, and the reason why is the first thing worth knowing.

Read This Before You Install Anything

The official reference server repository is the place to check maintenance status. Several of the most widely recommended MCP servers – including the original PostgreSQL, Slack and Google Drive reference implementations – have been archived by the MCP steering group. They still function. They are no longer maintained.

This creates a genuine trap. Search for a Postgres server and you will find the reference implementation at the top of every list, still linked from tutorials written a year ago. It works, so nothing appears wrong, and you have quietly added unmaintained code with database credentials to your setup.

The reference servers were always meant as demonstrations of the protocol rather than production software. As vendors shipped their own, the steering group narrowed the officially maintained set to a small core and archived the rest.

So the hierarchy to apply when choosing MCP servers is straightforward:

1. Officially maintained reference servers – small set, actively supported.
2. First-party vendor servers – built by the company whose platform they access. Usually the best option.
3. Well-known community servers – fine, with the usual caution about third-party code.
4. Archived reference servers – working, unmaintained, avoid for anything holding credentials.

The Five Officially Maintained MCP Servers

These are the ones the protocol maintainers still support. If you install nothing else, install from here.

1. Filesystem

Read and write files in directories you nominate. The single most useful server for most people, and the one that turns an assistant from something you paste into to something that works with your actual material.

Scope it deliberately. Point it at one project folder, never your home directory. This is the most common configuration mistake in the entire ecosystem.

2. Git

Read repositories, inspect history, search across commits. Distinct from the GitHub server below – this operates on local repositories and needs no network access or token.

3. Memory

A persistent knowledge graph the assistant can write to and read from across sessions. Genuinely changes daily use, because context stops evaporating between conversations.

4. Fetch

Retrieves web content and converts it to clean text for the model. Deceptively important – without it, answers about anything current come from stale training data.

The caution: this is the clearest path for untrusted content to reach your model. Do not pair it with servers that can send messages or spend money.

5. Sequential Thinking

Gives the model a structured scratchpad for working through multi-step problems. Less immediately visible than the others, and noticeably improves quality on anything requiring several dependent steps.

First-Party MCP Servers Worth Connecting

Built and maintained by the companies whose platforms they reach. Generally the best-supported MCP servers available.

6. GitHub

The official one from GitHub, not the archived reference implementation. Create repositories, open pull requests, manage issues, search code, review diffs. For anyone working in a codebase, this and Filesystem cover most of the value.

7. Supabase

Database queries, schema inspection, auth and storage. A cleaner answer than the archived Postgres reference server if your data already lives there.

8. Sentry

Pull error reports and stack traces into context. Debugging with the actual exception in front of the model rather than a paraphrase of it is a meaningful difference.

9. Notion

Read and write pages and databases. For teams whose knowledge lives in Notion, this is the difference between an assistant that guesses at your context and one that knows it.

10. Linear

Issues, projects, cycles. Particularly good because Linear’s data model is clean, which makes the tools unambiguous – a quality that varies enormously across MCP servers.

11. Figma

Reads design files and hands structured layout data to the model. The design-to-code workflow is the obvious use, and it is one of the clearer wins in the ecosystem.

12. n8n

Exposes your workflows as callable tools, which lets an assistant trigger automations you have already built rather than reinventing them. If you run n8n, this is the highest-leverage server on this list – the patterns in our guide to n8n AI agents apply directly.

Specialist MCP Servers That Earn Their Place

13. Context7

Context7 pulls current, version-specific library documentation into context. Solves a real and constant problem: models confidently using APIs that changed two releases ago. If you write code with AI assistance, this measurably reduces wrong answers.

14. Playwright

Browser automation – navigate pages, fill forms, take screenshots, read rendered content. Powerful, and worth treating carefully since it combines web access with the ability to act.

15. Kubernetes

Inspect clusters, read logs, check deployments. Start read-only. An assistant that can describe why a pod is failing is useful; one that can delete it is a decision to make deliberately.

The 15 at a Glance

Server	Category	Maintenance	Risk level
Filesystem	Files	Official	Medium – scope it
Git	Code	Official	Low
Memory	Context	Official	Low
Fetch	Web	Official	Medium – untrusted input
Sequential Thinking	Reasoning	Official	Low
GitHub	Code	First-party	Medium – scope the token
Supabase	Database	First-party	Medium
Sentry	Monitoring	First-party	Low
Notion	Knowledge	First-party	Medium
Linear	Project	First-party	Low
Figma	Design	First-party	Low
n8n	Automation	First-party	High – it can act
Context7	Docs	Community	Low
Playwright	Browser	Community	High
Kubernetes	Infrastructure	Community	High – read-only first

Three Starter Stacks

Developer. Filesystem, Git, GitHub, Context7, Sentry. Covers reading your code, understanding your dependencies and seeing what is breaking.

Knowledge worker. Filesystem, Memory, Fetch, Notion. Your documents, your notes, current information and context that persists.

Automation builder. Filesystem, n8n, GitHub, a database server. The assistant can inspect, then trigger workflows you already trust.

Five MCP servers is a sensible ceiling to start. Tool selection accuracy drops noticeably as the catalogue grows, and an assistant choosing between sixty tools is measurably worse than one choosing between fifteen.

What Changed in the Ecosystem This Year

Three shifts explain why advice about MCP servers written a year ago is now actively misleading.

The reference set shrank deliberately. Early on, the protocol maintainers shipped demonstration servers for everything – Postgres, Slack, Drive, Puppeteer, and more. As real vendors published their own, keeping demonstration code alive stopped making sense. The archive was a sign of maturity, but it left a long tail of tutorials pointing at unmaintained repositories.

Vendors took over. The best MCP servers today are almost all first-party. A company maintaining a server for its own platform has better API knowledge, better incentives and a support channel. Where a first-party option exists, it is nearly always the right choice.

The protocol itself moved. The mid-2026 specification made MCP stateless and deprecated several older capabilities, with a twelve-month window before removal. Servers that have not been updated will start failing against newer clients as that window closes. Checking commit recency is not fussiness – it is the difference between a server that works next quarter and one that does not.

The practical takeaway: recency of maintenance now matters more than popularity when choosing MCP servers, and that inverts how most lists rank them.

Remote Servers vs Local Servers

A choice that catches people out, because both are called MCP servers and they behave very differently.

Local servers run as a process on your machine and talk to the client over standard input and output. Your credentials sit in your own configuration and never travel. This is the right default for filesystem access, local databases and anything sensitive.

Remote servers are hosted, reached over HTTP, and authenticated with OAuth. You do not run anything, updates happen without you, and the vendor sees the requests. Increasingly this is how large platforms offer access.

The trade is control against convenience, and it is worth deciding deliberately rather than by whichever the install instructions happened to describe. A useful rule: local for anything where the data would be a problem if it left, remote for platform services you already trust with that data anyway.

One practical note – remote MCP servers benefit most from the stateless protocol change, because requests can now land on any instance behind a load balancer. If a hosted server feels unreliable, an older protocol version is a reasonable first suspicion.

When to Write Your Own Instead

Sometimes the right answer is not on any list of MCP servers.

Our step-by-step build guide covers this. Write your own when the thing you want to reach is internal – your own API, your own database schema, a legacy system nobody else has. Wrapping an existing internal endpoint is genuinely an afternoon with the official SDKs, and the result fits your situation exactly rather than approximately.

It is also worth it when an existing server does too much. A community server exposing forty tools where you need three is adding noise to every tool-selection decision your assistant makes. A small custom server with three well-described tools frequently outperforms it.

The part that decides quality is not the code. It is how you describe each tool, because that description is what the model reads when deciding whether to call it. Write them like documentation for a new colleague – what it does, when to use it, what comes back, what it will not do.

How to Vet a Server Before Installing

MCP servers run with your permissions and holds your credentials. Treat installation the way you would adding a dependency to a production project.

Check who publishes it. First-party or official beats popular. A server with many stars written by someone anonymous is still anonymous code.

Read the tool descriptions. This is the specific thing worth doing, because tool descriptions are where hidden instructions live in a tool-poisoning attack. The model reads them; you normally do not. Five minutes here is the highest-value security review available.

Check recent commits. A server untouched for a year against a fast-moving protocol is a liability regardless of how good it was.

Scope the credential. Read-only where the job allows. Separate token per server. Revocable without breaking anything else.

Prefer local over remote for anything sensitive, so credentials stay on your machine.

Our guide to how MCP works covers the tool poisoning problem in more depth – it is the one ecosystem risk worth genuinely understanding before you start installing.

Five Mistakes People Make With MCP Servers

1. Installing a dozen at once. Tool selection degrades, and you cannot attribute a behaviour change to any one server.

2. Using archived reference servers. They work, which is exactly why nobody notices. Check maintenance status before trusting one with credentials.

3. Pointing Filesystem at everything. One project directory. Not your home folder, and certainly not the root of a drive.

4. Combining web access with write access. A server that reads arbitrary pages alongside one that can send email or spend money is the classic injection path. Keep them apart.

5. Admin tokens because it was quicker. Almost every credential given to an MCP server needs a fraction of the permissions it usually receives.

What It Costs to Run These

Almost nothing in money, which is worth saying plainly because people assume otherwise.

The MCP servers themselves are open source and free. What you pay for is whatever they connect to – a Supabase plan, a Sentry subscription, a Notion workspace – and you were paying for those already. There is no protocol tax.

Two real costs do exist though. The first is tokens: every connected server adds its tool definitions to the context of every request, so a catalogue of sixty tools is quietly costing you on each call even when none are used. That is a second argument, beyond accuracy, for keeping the set small.

The second is attention. Each server is a dependency to keep current. Five well-chosen MCP servers is maintainable indefinitely. Twenty is a small side project you did not intend to take on, and the ones you forget about are the ones running unmaintained code with live credentials.

A Sensible Ninety Days

If you are starting from nothing, this sequence avoids most of the mistakes above.

Week one. Filesystem only, scoped to one project directory. Work with it daily and notice what you reach for that it cannot do.

Week two. Add whichever of GitHub or Notion matches where your work actually lives. Two MCP servers is enough to feel the difference.

Month two. Add Memory, and separately add Fetch if you need current information. Keep Fetch away from anything with write access.

Month three. Add one specialist server for a problem you can name – Context7 if you write code, n8n if you automate, Sentry if you debug.

That is four or five MCP servers after a quarter, each of which you understand and use. It is a considerably better position than thirty installed in an afternoon, none of which you have read.

Frequently Asked Questions

How many MCP servers should I run?

Three to five to start. Add one at a time and only when you can name what it unblocks.

Are MCP servers free?

Almost all are open source and free. Some connect to paid services, but the servers themselves are not the cost.

How do I know if a server is archived?

Check the repository – archived projects are clearly marked and read-only. If a tutorial links you somewhere without mentioning maintenance status, verify it yourself.

Local or remote servers?

Local for anything touching sensitive data, since credentials never leave your machine. Remote when a vendor hosts it and you would rather not run infrastructure.

Can I write my own?

Yes, and it is a good afternoon with the official SDKs‘s work with the official SDKs. Wrapping an internal API you already have teaches you more than reading the specification.

Do these work with any AI tool?

With any MCP-compatible client, which now includes most major AI applications and coding tools. That portability is the point of the protocol.

What if a server stops working after an update?

Usually a protocol version mismatch. The specification changed significantly in mid-2026, and servers on older versions can break against updated clients.

Final Thoughts

The temptation with twenty-two thousand options is to treat MCP servers as a collection to build. Resist it. The people getting real value run four or five, know exactly what each one does, and have read the tool descriptions on all of them.

Start with Filesystem pointed at one project folder. Add GitHub or Notion depending on where your work lives. Add Memory when you get tired of re-explaining context.

Then stop, and only add a sixth when something specific is annoying you. A small, well-understood set beats a large one every time – and it is considerably easier to secure.