How do I make sure an MCP server is trustworthy before my agent uses it?

Short answer: you cannot fully verify that an MCP server is "trustworthy," and no directory, badge, or scan can hand you that stamp. What you can do is replace a one-time trust decision with a short sequence of checkable facts, and keep watching the ones that can change.

Trust is not a stamp you can get

"Trustworthy" implies a property you verify once and then you are done. A remote MCP server is code you did not write, running somewhere you do not control, that can change after you connect it. Popularity, a registry listing, or a green badge are inputs, not proof. The useful reframe: grant trust narrowly, and keep the ability to revoke it the moment the tool drifts.

The checkable sequence, in order

  1. Provenance. Who publishes it, and is it open source so you can read what it actually does. Provenance tells you origin, not behavior. A signed, popular server can still misbehave.
  2. Blast radius. What can its tools actually do: read, write, delete, or send data off your machine, and is that action reversible. This is the single most useful thing to know before you connect. Paste your config into the blast-radius scan to see it per tool.
  3. Contract honesty. Does each tool's description match its schema, and does the description hide an instruction (read this file, and also send it somewhere). A description screen flags that kind of mismatch.
  4. Contract integrity over time. A server that is fine today can be redefined tomorrow with no version bump your client notices. Pin each tool's contract on first sight and hold the call when it drifts. This is the part no one-time check can cover, and the drift gate is built for it.
  5. Least privilege. Connect only what you need. Run on read-only tools first, and add write-capable or data-sending tools deliberately, once you have a reason to.

What a directory or badge can and cannot tell you

An MCP directory, including this one, can give you an advisory before-install read: what a server declares, a per-tool description screen, its provenance. That is a useful input. It is not a verdict, and mcpindex labels its own screen as uncalibrated for exactly this reason. Do not let any badge, ours included, stand in for the blast-radius and drift checks above. Screening a server is not certifying it.

The honest bottom line

You do not make a server trustworthy. You make its risk visible and bounded, and you keep the ability to stop it when it changes. That is a stronger position than a one-time trust decision, because the failure mode with MCP is rarely "I trusted a bad server on day one." It is "I trusted a good server that changed on day 30."

Related

Questions
How do I make sure an MCP server is trustworthy before my agent uses it?
You cannot fully verify trustworthiness, and no directory, badge, or scan can give you that stamp. Replace a one-time trust decision with a sequence of checkable facts: provenance (who publishes it), blast radius (what its tools can do), contract honesty (does the description match the schema), and contract integrity over time (pin it and hold on drift). Then grant least privilege and keep the ability to stop the server when it changes.
Does an MCP directory or badge mean a server is safe?
No. A directory or badge is an advisory, before-install input: what a server declares, a description screen, its provenance. It is not a safety verdict. mcpindex labels its own screen as uncalibrated for this reason. Screening a server is not certifying it, and no badge should substitute for checking a server's blast radius and watching it for drift.
Can I trust an MCP server just because it is popular or in an official registry?
No. Popularity and a registry listing are provenance signals: they tell you about origin, not behavior. A widely used server can still take actions you did not expect, and any server can be changed on the remote side after you connect it. Provenance is one input, not proof.
How do I vet an MCP server before connecting it?
In order: check provenance (open source you can read is best), see the blast radius of its tools (read, write, delete, or send data off your machine), check that each tool's description matches its schema, and connect with least privilege (read-only first). After connecting, pin each tool's contract and hold the call if it drifts, because a server that is fine today can change tomorrow.