Spellwarden

All docs

How to vet an MCP server or an agent skill

Last updated 7 November 2026

Before an agent loads an MCP server or a skill, someone should decide whether to let it. This is the checklist to decide with. It works for a team of one or an organisation with a review board, and it needs no Spellwarden account: every step has a manual form and, where one exists, a tool.

A check reduces the chance of a bad surprise. It does not prove that a server or a skill is safe, and nothing on this page says that any particular one is or is not.

The checklist

  1. Find out who publishes it and where the source is. A public repository with a named publisher and a history is easier to judge than an anonymous archive or an address that gives no source. Write down the publisher and the address.
  2. Check that the version is pinned. Ask for an exact version, a full commit or a checksum, so that the version you review is the version that runs. A remote server cannot be pinned, so plan to check it again. See MCP rug pull attacks.
  3. Read the tool descriptions and the instructions. Look for text that talks to the model instead of the reader: orders to hide something, to read a file, to send data, or to treat another tool in a certain way. Look for characters that do not show on screen. See MCP tool poisoning, Prompt injection in agent skills and Hidden Unicode characters in agent skills.
  4. Look at the permissions and credentials it asks for. A skill that reads a credential file, or a server that wants a broad token, needs a reason that you accept.
  5. Check how a remote server signs you in. A server that lists its tools to anyone, uses a static key or runs over plain HTTP is a weaker choice than one with OAuth over HTTPS. Check MCP servers and plan their migration shows what a Spellwarden check reports.
  6. Run the open-source scanner on the skill or on the repository that configures the server, and read each finding. Open-source scanner, CI wrappers and Infra Pack shows how, and Scanner rules explains every rule.
  7. Look the entry up in the Spellwarden catalog. An entry shows when it was checked, with which rules, and what was found. The Spellwarden catalog says what a listing does and does not mean.
  8. Decide, write the decision down with the version or the date, and check again on every update. A decision applies to the version you looked at.

What a check does not prove

  • A scan reads files and answers. It cannot see what a remote server will answer tomorrow.
  • Rules find known shapes. An attack that has a new shape passes until a rule exists for it, and the scanner's own pages say which attacks it does not cover.
  • A clean result is a statement about one version on one day. It is not an endorsement of the publisher and not a guarantee.
  • A finding is not proof of bad intent. Many findings are careless habits, such as an install with no version.

What to do next

To record decisions and enforce them across an organisation, read The private registry. For teams that already use a scanner, two pages compare Spellwarden's open-source scanner with others on what they scan and what they send: Spellwarden and Snyk Agent Scan compared and Spellwarden and Cisco MCP Scanner compared.