Reads Windsurf MCP configuration to inventory configured MCP servers and skills with verdicts.
Indexes MCP servers from the Docker MCP Catalog and checks them for verdicts, scores, and sandbox findings before installation.
Indexes skills and MCP servers published to npm and checks package names, versions, and hashes against KillerSkills verdicts before installation.
Indexes skills and MCP servers published to PyPI and checks them against verdicts and sandbox findings before installation.
Check agent skills and MCP servers before they run. Verdicts come from KillerSkills; the policy is yours or your org's.
npm i -g vet-skills # the CLI (Node 20+)
vet-skills hook install claude-code # intercept every install in Claude Code
vet-skills check <skill> # or just ask before you add one
vet-skills publish ./my-skill # org members: detonate + list in the private registryGive any agent the verdicts directly, so it checks a skill or MCP server before
installing it and can pick a verified alternative. Read-only, no account, no API key.
Tools: check_skill (verdict, score, what the sandbox saw, top findings, last safe
version) and search_skills (the index by keyword, with verdicts).
Claude Code
claude mcp add killerskills -- npx -y vet-skills mcpCursor: ~/.cursor/mcp.json (or .cursor/mcp.json in a project)
{
"mcpServers": {
"killerskills": { "command": "npx", "args": ["-y", "vet-skills", "mcp"] }
}
}Claude Desktop: Settings → Developer → Edit Config (claude_desktop_config.json)
{
"mcpServers": {
"killerskills": { "command": "npx", "args": ["-y", "vet-skills", "mcp"] }
}
}VS Code: .vscode/mcp.json
{
"servers": {
"killerskills": { "type": "stdio", "command": "npx", "args": ["-y", "vet-skills", "mcp"] }
}
}Windsurf: ~/.codeium/windsurf/mcp_config.json, same mcpServers block as Cursor.
Codex: ~/.codex/config.toml
[mcp_servers.killerskills]
command = "npx"
args = ["-y", "vet-skills", "mcp"]Then ask your agent: "Before you add that MCP server, check it with KillerSkills." Requires Node 20+. Index: 16,000+ skills and MCP servers from skills.sh, ClawHub, npm, PyPI, the Docker MCP Catalog and Claude Code plugin marketplaces, each run in a honeypot sandbox. Browse them at killerskills.ai.
Related MCP server: airlock
vet-skills discover # every MCP server, skill, plugin and hook on this machine, with verdictsReads Claude Code, Cursor, Windsurf, Claude Desktop, Gemini CLI and Codex configs locally. Only names leave the machine, and only when you are enrolled in an org.
Every skills add, claude plugin install, and claude mcp add is resolved to
an artifact hash, looked up, and evaluated against your policy before it runs:
$ vet-skills check deploy-helper
Resolving deploy-helper …
vet-skills 0.7.1 · policy acme/default-strict
BLOCKED 14/100 deploy-helper@2.3.1 · devtools-cloud · 4,210 installs
Observed in sandbox (3 scenarios, 38s):
✕ network telemetry-cdn.xyz — undeclared
✕ memory wrote agent memory (1)
✕ filesystem reads ~/.ssh/id_ed25519, ~/.aws/credentials, ~/.npmrc
! tools shadows github.create_pr
Policy acme/default-strict:
✕ publisher blocked devtools-cloud is on the block list
✕ Blocked deploy-helper@2.3.1 · publisher devtools-cloud is blocked by policy
Pin instead: deploy-helper@2.2.4 (score 88)Decisions: allow, sandbox (install with restrictions), approval required (the install waits for a reviewer), block (with the last safe version named), defer (unscored: detonate first), observe (org enforcement off; logged only).
If the verdict API is unreachable and nothing is cached, the policy's offline
rule applies. The default is allow with a warning: an outage on our side never
stops your work. Set offline: block in your policy to fail closed.
Solo: a personal policy in ~/.vet-skills/policy.yaml (vet-skills policy show).
Nothing is sent except verdict lookups (skill name, version, hash) and an anonymous
client id.
Org: vet-skills join <org> --token <enroll token> --email you@company.com
switches to the org policy. From then on the hook also reports installed skill
names, versions, hashes, and decisions to your org dashboard. Never code,
prompts, environment variables, or file contents. vet-skills leave reverts.
Command | What it does |
| Dry-run the decision. Exit 2 when blocked. |
| Check, then |
| Force a sandbox run. |
| Last decision and the rule behind it. |
| Org mode on / off. |
| Personal policy. |
| Personal block list. |
| Org, policy version, cache, pending approvals; syncs policy. |
| Inventory agent config on this machine; report names to the org when enrolled. |
| Run as an MCP server over stdio ( |
| Registers the PreToolUse hook in |
| Called by the agent; reads hook JSON on stdin. |
Environment: KILLERSKILLS_API (default https://killerskills.ai),
VET_SKILLS_HOME (default ~/.vet-skills), NO_COLOR.
Look up the KillerSkills security verdict for an agent skill, MCP server or plugin BEFORE installing it. Returns the score (0-100), label (verified / caution / blocked), what the sandbox saw it do (network hosts contacted, credential files read, memory writes), the top findings, and the last safe version when the latest is blocked. Use the package name for npm/PyPI MCP servers (e.g. "@modelcontextprotocol/server-github" with registry "npm").
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Skill or package name: "name", "publisher/name", "@scope/pkg", optionally "@version". | |
| registry | No | Registry, when known. Omit to search all public registries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds substantial value by enumerating the return contents (score, label, sandbox actions, findings, last safe version), which is important behavioral context since no output schema exists. It omits error behavior and any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: purpose and timing first, then return details, then a parameter tip. Every sentence earns its place and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup tool with full schema descriptions and annotations covering safety, the description is complete. It explains what is returned (crucial since no output schema) and provides a concrete name-format example. No essential information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, setting a baseline of 3. The description adds meaningful guidance: it clarifies that package names should be used for npm/PyPI servers with a concrete example ('@modelcontextprotocol/server-github' with registry 'npm'), which goes beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Look up') and resource ('security verdict for an agent skill, MCP server or plugin'), making the tool's function clear. However, it does not explicitly distinguish itself from the sibling tool search_skills, which an agent might confuse for discovery vs. verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use it 'BEFORE installing' — a clear timing condition. It does not name alternatives or provide exclusions, but the context is unambiguous for a pre-install check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the KillerSkills index (every public agent skill and MCP server, each detonated in a sandbox) by keyword. Returns the most-installed matches with their verdicts, so you can pick a verified option instead of an unvetted one.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keywords, e.g. "postgres", "github mcp", "pdf". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and open-world, and the description adds real value beyond them: results are ranked by install count and include sandbox verdicts, which tells the agent what kind of evidence to expect. It omits result-count limits or pagination, keeping it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences with the purpose front-loaded and the payoff second. Minor marketing flavor ('detonated in a sandbox') costs a little, but nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does carry the return-value burden and does so adequately by explaining that matches come with verdicts ranked by installs. Only edge details like result caps or empty-result behavior are unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single query parameter is documented with examples. The description only repeats 'by keyword', adding essentially nothing beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: search the KillerSkills index by keyword, returning most-installed matches with verdicts. It is clearly distinct in spirit from a single-skill check, though it never names the check_skill sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear selection rationale — use this to pick a verified option rather than an unvetted one — which tells the agent when it's appropriate. It stops short of naming alternatives or stating exclusions, so it's a notch below explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_skillsearch_skillsScored across 2 tools
check_skill is an exact-name verdict lookup while search_skills is keyword discovery, so the boundary is clear. There is minor overlap because search results also return verdicts, which could make an agent unsure which to reach for first, but the descriptions disambiguate ('BEFORE installing' vs 'pick a verified option').
Both names follow a clean verb_noun snake_case pattern (check_skill, search_skills). The singular/plural difference reflects the actual semantics (one package vs many results), which is a reasonable and readable variation.
Two tools is thin for a server surface, even one this narrowly scoped to security verdicts. Both tools clearly earn their place, but the minimal surface leaves little room for related operations.
The core lifecycle of 'discover a candidate skill' (search_skills) and 'verify it before install' (check_skill) is covered, including version/sandbox detail in the verdict response. Minor gaps exist around bulk checks or retrieving full findings/history, but agents can work around them.
See which AI models fall for traps in everyday jobs, and check or scan any MCP server, skill or package before your agent installs it. No sign-in; read-only; returns structured data.
Check an A2A agent before you delegate, or an MCP server's measured conduct. Free, no key.
Scan any website or MCP server for agent readiness: 0-100 score, a fix per failing check. Free.
Scans an MCP server for security gaps before your agent connects. Free tier, no signup.
