MCP Servers: Which Ones Are Worth Connecting

Thousands of MCP servers exist right now, and a working majority of them were built by one person, in a weekend, for a problem that was theirs and not yours.

Some are genuinely useful.

A few have been caught asking an AI model to read SSH keys and pass them to a stranger, without telling you.

An MCP server is the thing that lets your AI model actually do something, instead of just describing what it would do. Read a file. Send a message. Pull a row out of a database. Click a button on a page nobody ever built an API for. That part of the pitch is real, and it isn't small.

What nobody tells you up front is that "MCP server" describes the shape of the thing, not its quality. A sprawling directory with a thousand random listings and a short, vetted list of five both call themselves MCP servers. The protocol doesn't rank them for you.

So here's the short version: what an MCP server actually does under the hood, the specific way a bad one goes wrong, a five-minute check that catches most of the bad ones before you connect anything, and which servers are actually worth your time, sorted by the job you're trying to get done.

What an MCP server actually does

Strip away the acronym and the mechanism is plain.

Your AI chat app is the client. The MCP server is a small program that exposes a fixed set of tools and data to that client, over a standard interface both sides already agree on. Three roles make up the handshake, not two: a host, the app you're sitting in front of, a client inside that host that speaks the protocol, and a server on the other end exposing tools. People collapse the first two into one word in casual conversation, which is fine until something breaks and you need to know which piece actually failed.

Your model doesn't have to guess how to talk to Slack or Postgres or your file system. It asks the connected server what's available, the server answers with a list of tools it supports, and the model picks the one that fits the task in front of it. Underneath, both sides trade plain JSON messages back and forth, a shared format neither side had to invent for itself.

Here's what that looks like in practice. You ask your AI assistant for a quick read on the last three files added to a specific folder. The model doesn't have folder access on its own. It asks the filesystem server, which does, for a list of recent files, reads their contents through that server, and hands you back a plain description of what's in them. Three separate steps, invisible to you, resolved in a couple of seconds.

Here's what it looks like when that breaks. Point the same model at a server that's stalled, timed out, or simply isn't running, and it rarely fails loudly. It often guesses, describes a file that doesn't exist, or answers from memory of a similar request instead of telling you the connection is down. A quiet failure looks identical to a correct answer until you check the source yourself.

Anthropic open-sourced this protocol on November 25, 2024, alongside a handful of reference servers for Google Drive, Slack, GitHub, Git, Postgres and browser automation through Puppeteer (Anthropic). That date matters more than it sounds like it should. Before MCP, every AI tool that wanted to touch your calendar or your codebase had to build its own custom connector to that specific calendar or that specific codebase. Every new pairing of model and tool was its own integration project.

MCP collapsed that into one shape. Build the connector once, as a server, and any MCP-compatible client can use it without custom code on either end.

One adapter, read by every client that speaks the protocol, instead of a custom cable soldered between every pair of devices. That's the whole pitch.

It also means something less comfortable. A server decides what it's willing to expose. A client decides what it's willing to trust. Neither side automatically verifies that the other is being honest about either one. Hold onto that sentence. It's the source of almost everything that goes wrong next.

The real risk, and how bad it actually gets

Most writing about MCP security stops at "be careful." Here's what careful is actually protecting you from.

In April 2025, the security research team at Invariant Labs demonstrated something they named a tool poisoning attack. A malicious MCP server can bury instructions inside a tool's description, the block of text your AI model reads before deciding how to use that tool. You never see that full text. Your chat app shows you a short, simplified tool name. The model sees everything, hidden instructions included.

In Invariant's published example, an innocent-looking "add two numbers" tool carried a buried instruction telling the model to also read the user's SSH private key and a configuration file full of other servers' credentials, then pass the contents along disguised as an unrelated side note, without ever telling the user. Running it against Cursor, one of the most widely used MCP clients at the time, did exactly that, and the user never saw it happen (Invariant Labs).

The mismatch is what makes it work. Your client's confirmation dialog shows a short, friendly summary: add two numbers? Even in its more detailed view, Cursor's dialog in Invariant's test never surfaced the full tool description, SSH key request included. The model read the entire thing. You read a caption.

It gets worse in two specific, documented ways.

First is what Invariant's team called a rug pull. A server you approved last month can change its tool descriptions today, after your client already trusts it, with no new approval prompt triggered. They draw the direct comparison to malicious packages on the Python Package Index, uploaded clean and modified later. "I checked it once" isn't a security practice. It's a snapshot of a server that's free to look completely different the next time it runs, with no visual cue in your client that anything changed.

Second is shadowing. Connect two servers at once, and a malicious one can inject instructions that change how your model behaves toward a completely different, trusted server. In Invariant's test, a poisoned "add" tool rerouted every email a legitimate, trusted email tool sent to an attacker's address instead, with no mention of the swap anywhere in the visible chat log. The user asked for an email to go to one person. It went to someone else entirely, and the transcript looked clean.

Multiply that across every server someone connects without reading its tool list first, and the result is a population of agents that follow whatever instruction is hiding in plain sight, then report back that the task went fine.

Invariant's own mitigations boil down to two things an ordinary user can actually act on: read the full tool description a client shows you, not just its friendly summary, and treat a server's version like a lock you keep checked rather than something that updates itself behind your back. None of this means skip MCP entirely. It means the question you're actually answering isn't "is this server useful." It's "who controls this server, and what happens the day they decide to stop being trustworthy."

How to check a server before you connect it

Five minutes, every time, with no exceptions for the one that looks official.

Run through this before you type a single credential into anything:

1. Open the actual tool list, not the marketing copy. A server's landing page will tell you it has "60-plus tools." That number tells you nothing on its own. The individual tool names, and what each one is allowed to touch, tell you everything. A tool called delete_file sitting next to one called read_calendar in the same server is a server with no clear boundary around its own job.
2. Check who maintains it. A named person or company with a visible history of other work is a different risk than an anonymous handle that showed up this month. The official MCP Registry, launched in preview on September 8, 2025, verifies publisher identity for the servers listed inside it, which is a real floor under "who built this" that a random web search doesn't give you (Model Context Protocol).
3. Look at exactly what access it's asking for. Read-only access scoped to one folder is a different animal than write access to your whole drive, or a raw session cookie pasted straight into a config file so the server can act as you. If the permission screen only offers an all-or-nothing toggle, that absence of a narrower option is itself information.
4. Check when it last shipped an update. A server with no commits in a year, running on a protocol that's still actively changing underneath it, is a server nobody is defending anymore.
5. Start it on something that doesn't matter. The first task you ever give a brand new server should never be the one touching your client's financial records.

That list takes less time to run than it took to read it, and it catches the servers that fail on sight: no named maintainer anywhere, a tool list asking for more access than the job needs, nothing shipped since launch week.

Here's what that looks like against a real pick. The official filesystem server Anthropic shipped on day one lists its maintainer plainly, keeps a visible commit history, and its tool list reads exactly like what it does: read file, write file, list directory, nothing hidden behind a vague catch-all name. A server that instead offers one enormous tool called something like process_request is hiding the exact thing this checklist exists to catch.

Which MCP servers are worth connecting, by the job

Skip the directory entirely. Match the server to the job you already have, starting with the one you'll actually use every week.

Each of these jobs maps to a specific, narrow slice of access, which is exactly what the checklist above asks you to look for. A filesystem server scoped to one folder can't see your Downloads directory. A Postgres server running through a read-only database user can't drop a table even if something tricks it into trying. The job defines the blast radius before you ever get to the tool list.

Those six categories cover most of what a solo operator or a small team actually asks AI to do day to day, and five of the six were part of Anthropic's own original reference set the day the protocol shipped in November 2024 (Anthropic). The ecosystem has grown fast since then. A year later, Claude's own connector directory listed more than 75 MCP-powered connections, and the official SDKs were seeing over 97 million downloads a month (Anthropic). If you want the mechanics of the protocol itself rather than just the shortlist, Model Context Protocol, explained plainly walks through how the standard works underneath all of this.

A few of these rows deserve a specific warning. Browser automation servers, Puppeteer and Playwright both, effectively get your logged-in session for whatever site you point them at, which makes that row the single most powerful and most dangerous one in the table. A memory server that persists facts across sessions is only as trustworthy as whatever wrote those facts in the first place, since one poisoned note from an earlier chat can shape every answer that follows it.

Notice what's missing from that table on purpose: a specific pick for "the best CRM server" or "the best marketing automation server." The field under any given job turns over every few months, server quality varies wildly within the same category, and a specific name printed here today is a stale recommendation inside a year. The checklist from the last section stays useful regardless. The brand names in it don't.

Run that five-minute check against whichever row you pick first. A filesystem server failing it is just as disqualifying as a flashy one with sixty tools and no named maintainer. The job doesn't excuse the vetting.

If the job you're actually trying to automate is posting and tracking content across social platforms, that's specific enough to deserve its own walkthrough rather than one row in a table. How to automate social media with MCP covers the setup for that job directly.

Connecting your first one without breaking anything

Here's the real sequence, not the five-second version.

1. Pick the lowest-stakes job on your list, not the most exciting one. Reading a Google Doc beats writing to a production database on day one.
2. Find the server through the official registry or a named maintainer, never the first unverified result that turns up. A registry listing shows you the publisher and the last update in one view, which saves the separate lookup the checklist otherwise asks for.
3. Run the five-minute check from the section above in full. Specifically, open its tool list and read every tool name before you approve a single one.
4. If the server offers a scoped or read-only credential instead of full access, use the scoped one. Almost every server that actually matters offers this option. The ones that don't are a warning sign on their own.
5. Give it one small, verifiable task. Ask it to walk you through a document you already know the contents of, then check what it says against the real thing. A model that gets the easy, checkable task wrong is not a model you want anywhere near the one you can't check.
6. Watch the confirmation dialog your client shows you, not just the final result. If your client hides the full tool arguments behind an oversimplified summary the way Cursor did in Invariant's testing, that's worth knowing before you connect something with real write access.

A worked version of this: connecting a Google Drive server, read-only, to one folder of client proposals. The first task is a plain description of the three most recent files in that folder. It answers three questions at once: whether the server actually works, whether it respected the read-only scope you set, and whether its answers are accurate enough to trust with something bigger next week.

A second version worth trying once you've cleared the first: connecting a Postgres server through a dedicated read-only database user, not your admin login, and asking it a question you already know the answer to, a row count on a table you can check yourself in a few seconds. A matching number means the connection is doing its job. A mismatch means you've found a problem before it touched anything real, and the read-only user means the worst it could have done is give you a wrong answer, not a changed database.

Keep a short log of what you connect and why, even if it's three lines in a note. A month from now you won't remember which server you gave write access to for a one-off task, and the checklist only keeps working if you actually revisit it.

If step six surprises you the first time, that's the entire reason to run it on a folder you don't mind being wrong about.

What changes once you're running more than one

The first MCP server you connect is manageable. The fifth one is a different problem entirely.

Every new client app you try, Claude Desktop, Cursor, ChatGPT, whatever you're testing this week, wants its own separate copy of the same connection. Reconnect the GitHub server here. Reconnect it again over there. Re-approve the same tool list a third time in an app that has no memory of the first two approvals you already made. Multiply that by however many servers you've actually connected, and the setup tax alone starts to rival the time the servers were supposed to save you.

Every added server also widens the shadowing risk from earlier in this post. More connected servers means more opportunities for one poisoned tool description to rewrite how a trusted tool behaves without any visible sign in the chat log, and more surface area you'd actually have to watch to catch it before it does damage.

Say you're testing whether Claude or GPT writes a better first draft of a client email, so you ask both, in two different apps, each with its own copy of your email-sending server connected. That isn't redundancy. That's two separate trust boundaries running the same tool with no way for either app to tell you the other one exists.

Magai's agents can connect to the same kind of external MCP servers, and the part that solves the multiplication problem is that the connection and the conversation around it stay inside one workspace instead of resetting every time you switch models mid-task. You're not re-approving the same Slack server three separate times across three separate apps just because you wanted a second model's opinion halfway through a project. The tool stays connected. The thread stays intact, even while you're switching models to find the right one for the job. That's the specific thing an AI aggregator is supposed to solve, and an MCP connection is as real a test of it as the model switch itself.

A server you vetted once, using the checklist from earlier, only has to be vetted once this way, not once per app you happen to be using that day. This is one small piece of a much bigger shift in how artificial intelligence gets used day to day: tools that used to live inside one app now move with you, and the connections are worth treating like it, regardless of which model you end up switching to for the actual work.

The maintenance nobody budgets for

A connected MCP server isn't a thing you set up once and forget about.

Rug pulls mean the server you vetted in March can look different by June, with nothing telling you it changed. The fix isn't constant paranoia. It's a standing habit: once a month, open the tool list again on whatever you've got connected and read it the way you did the very first time. Most clients list your active MCP connections in one settings screen. That screen is the monthly habit. It isn't a separate tool to learn, just a page you're already one click away from.

Revoke what you aren't using. A server sitting connected with broad access, doing nothing for you, is pure downside with zero upside. It adds to the shadowing risk from earlier without ever paying you back for the exposure. Most providers put this control under a connected apps or integrations page in account settings, not inside the AI client itself, which is exactly why it gets forgotten.

Pin the version where the server offers that option. Locking a connection to a specific release you've already checked, instead of always pulling whatever shipped most recently, closes the exact gap Invariant's team flagged: a server changing underneath you without your client ever asking you to approve it again. In practice this often means specifying a version number in the server's configuration instead of leaving it on "latest," the same habit careful developers already use for any other dependency.

None of these three habits needs a calendar reminder forever. Run them for two months straight and they turn into the same unconscious check you already run before clicking a link in an email you didn't expect.

Pick one task you still do by hand every week. Find the one server built for exactly that job. Run the five-minute check before you connect anything, give it something small to prove itself on first, and only then let it near the thing that actually matters.

The protocol isn't the hard part anymore. Anthropic solved that piece back in November 2024. Deciding which of the thousands of things built on top of it have earned your trust is the job that's actually yours, and it starts with the one server you were about to connect without checking.