Mcp security
Detects MCP tool handlers vulnerable to malicious inputs, hardcoded secrets, or unrestricted file/shell access. Use when writing MCP server definitions, tool schemas, or tool handler code. Also invoke when registering tools with Claude or building Claude Code extensions that expose file system, shell, or network access.From its SKILL.md
npx -y skills add thejefflarson/soundcheck --skill mcp-securityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 20 stars20 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.2 KB, as published. Nobody here has run it
MCP Server Security (OWASP LLM07:2025)
What this checks
Prevents MCP tool handlers from being exploited via malicious inputs, hardcoded secrets, unrestricted file access, or shell injection. A compromised MCP server gives attackers direct access to the host environment.
Vulnerable patterns
- MCP tool handler that opens or reads a file path supplied directly by the caller with no allowlist or root confinement
- Tool handler that runs a shell command built from tool input with shell expansion enabled
- Hardcoded API key, token, or credential in the handler body or tool definition
- Tool schema declaring a string parameter with no length cap, pattern, or enum constraint
Fix immediately
Flag the vulnerable code and explain the risk. Then suggest a fix that establishes these properties:
- Tool schemas constrain every string parameter — maximum length, regex pattern, enumerated values, or rejection of additional properties. A bare string type is a blank check. The schema is the first line of defense because the model generated the input.
- Paths are canonicalized and confined to an allowed root. The handler resolves the supplied filename against a fixed base directory and verifies the result stays inside that directory — defeating traversal, symlink escape, and absolute paths.
- Shell execution uses argument lists, never a shell string with interpolated input. If the tool must run a command, the command name comes from a static allowlist and arguments are passed as discrete argv elements.
- Secrets come from the environment or a secrets manager — never hardcoded literals in the handler or tool definition. A leaked MCP server config should not leak credentials.
- Every invocation is audit-logged with the tool name and sanitized inputs
before the side-effect runs. For broader MCP tool design guidance, see the
insecure-plugin-designskill.
Translate each principle to the MCP SDK and language of the audited handler. Use the SDK's documented schema-validation, path-resolution, and process-execution APIs — do not hand-roll equivalents.
Verification
Confirm the response:
- No secrets hardcoded — all credentials loaded from environment variables or a secrets manager
- File paths resolved and confined to an allowed base directory
- Shell calls use argument lists, not a shell string with interpolated input
- Every schema string parameter has a length cap, pattern, or enum constraint
References
- CWE-284 (Improper Access Control)
- CWE-78 (OS Command Injection)
- CWE-200 (Exposure of Sensitive Information)
- OWASP LLM07:2025 Insecure Plugin Design