Waxell

How the security index works

Waxell reviews public Claude skills and plugins from GitHub (24,090 today) and the MCP servers in the official MCP Registry, and publishes what it finds: a verdict, the findings behind it, the version history and where else the same content is published.

Browse skills and pluginsAsk for a rescan or dispute a finding

What a verdict means

  • No issues found

    No high or critical finding in what is published. Lower-severity findings may still be listed.

  • Review findings

    At least one high-severity finding. Read it before you install.

  • High risk

    At least one critical finding.

  • Not checked yet

    We have it, but the check has not finished.

A clean result means nothing alarming in what is published. It is not a statement that something is safe. The checks read files and metadata; they do not run the skill, the plugin or the server, and they cannot see code a package downloads later.

Static analysis and the deep scan

Every entry gets Waxell's static checks, listed below. Where the deep scan has also run, a scanner that reads the instructions themselves for prompt injection and data exfiltration is folded in. Our own findings can raise its verdict, never lower it. Every page says which ran: “Static analysis” or “Static analysis + deep scan”.

For hosted MCP servers we also do what an MCP client does first: an unauthenticated initialize. If the server answers without sign-in we read its tool list, names, descriptions and read-only or destructive hints, so the descriptions can be checked. If it asks for sign-in we read its OAuth discovery documents. We never call a tool.

How often

Skills and plugins are crawled every night, and anything whose content changed is scanned again. MCP servers are synced with the registry every day; new and changed servers are checked, and every server is checked again about once a week. Each page shows when the entry was last checked.

Identical copies of the same content are folded into one entry, and each entry lists where else it is published. When something changes, it gets a new version, and the version history shows what changed and the verdict it got at the time. For MCP servers that includes which tool descriptions changed.

Checks on skills and plugins

What a skill tells Claude to install or run

  • S1criticalTells Claude to download something and pipe it straight into a shell or interpreter.
  • S2highTells Claude to install packages without pinning a version, so whatever is newest that day runs.
  • S3mediumTells Claude to install pinned packages. Pinned is better, but the code still is not in the skill.

How a bundled MCP server is launched

  • M1criticalThe launch command downloads a script and pipes it to a shell.
  • M2highThe server is started through a shell command line (critical if it also fetches remote code).
  • M3highRuns a package without a pinned version.
  • M4mediumRuns a third-party package fetched from a registry at start-up.
  • M5mediumThe package name is one edit away from a well-known package.
  • M6highThe container image is not pinned.
  • M7highThe container drops isolation from the host, or mounts the Docker socket (critical).
  • M8highConnects over plain HTTP.
  • M9mediumConnects to a server we have not catalogued (lower when it is catalogued or verified).
  • M10highA credential is written into the config or passed as an argument.
  • M11highIs pointed at a home directory, the filesystem root, or credential folders.

Binary files, judged by their bytes, not their names

  • B1criticalAn Office file with macros.
  • B2highAn Office file that loads remote content when opened, or embeds another file.
  • B3highAn executable or a library.
  • B4highAn archive inside the package, whose contents go unscanned.
  • B5mediumA file type we cannot inspect.
  • B6infoInspected, nothing found. Said for every clean binary, so you can see it was looked at.

Checks on MCP servers

The launch configuration a user would add is judged by the same launch checks as above. Then:

  • T1highA tool description tries to steer the model behind the user's back: hide things, act without asking, hijack other tools.
  • T2criticalThose instructions also reach for secrets or send data out.
  • T3highInvisible or bidirectional Unicode in a tool description.
  • T4lowA very long tool description, which leaves room to hide instructions.
  • T5mediumA tool description gives the model plain directives.
  • E1highA hosted endpoint over plain HTTP.
  • E2mediumOAuth without PKCE (S256).
  • E3mediumNo sign-in, and tools marked destructive.
  • P1highThe package the registry points to does not exist.
  • P2mediumThe pinned version does not exist.
  • P3mediumThe package is deprecated or yanked.
  • P4mediumInstall-time scripts (high if they download or pipe to a shell).
  • P5highKnown vulnerabilities in that version (critical if rated so).
  • R1lowDeprecated in the registry.
  • R2lowNo source repository linked.
  • R3infoLists the secrets it asks for.

Which entries get their own page

Every entry counts in the totals. Pages are generated for the ones worth reading: official publishers, high-risk entries, entries with findings to review, and popular repositories. A repository that bulk-publishes hundreds of near-identical entries only gets pages for its official, high-risk or widely installed ones.

Disagree with a result?

If you publish one of these and think a finding is wrong, or you have fixed it, here is how to ask for a rescan or dispute it.

See and control which skills and MCP servers your people use

Inside your organization, Waxell scans each skill and plugin before anyone installs it, approves what passes and publishes it to a private marketplace, and puts every MCP tool call behind one governed URL.

30 minutes. No commitment.

SOC 2 Type II attested · ISO/IEC 27001:2022 certified · HIPAA with a BAA · aligned to the EU AI Act and NIST AI RMF