Agent skill · security · github
mcp-implementation-security-review
Review the implementation source code of MCP (Model Context Protocol) servers, clients, and tool handlers against a security baseline — authentication, sessions, rate limiting, input-schema validation, official-SDK usage, RCE vectors, and the OWASP MCP Top 10 — producing a report with file/line evidence. Use this skill when: - Reviewing an MCP server implementation for security before release - Checking a server against the baseline controls (MCP-01 to MCP-05) and the OWASP MCP Top 10 - Auditing tools for RCE vectors (command/code injection, unsafe deserialization, path traversal, SSTI, dependency hijacking, SSRF) - Verifying auth, session, rate-limiting, and input-validation controls on a network-exposed server - Reviewing MCP client code that handles untrusted server responses and session IDs - Requests like "review this MCP server for security" or "is my MCP server implementation secure?
Why this skill is useful
Adds a comprehensive security review process for MCP implementations, including specific checks for RCE vectors and OWASP risks that are not commonly documented.
What it needs
About 11k tokens when loaded. Last updated 2026-08-07. 37,534 stars on the source repository.
What this skill does
MCP Implementation Security Review Process Step 1 — Classify the target Check MCP protocol version 2025-03-26 or later (current: 2025-11-25). Flag older versions as a finding but continue the review. Determine whether the target is a server or client. Classify transport as network-exposed or local-only using the transport reference below. Record transport, protocol version, and whether sessions exist. Completion criterion: Target type, protocol status, and transport are identified. Step 2 — Filter false positives Apply the False Positive Filters before opening findings. Keep docs only when they describe the repo's own server behavior, deployment, transport, or auth posture. For framework/SDK repositories, scope findings to the default configuration and public API surface. Completion criterion: Remaining evidence is in-scope code, repo-owned docs, or public API behavior. Step 3 — Check baseline controls For network-exposed servers, check MCP-01 through MCP-05. For local/STDIO servers, do not mark baseline controls PASS/FAIL; give best-practice notes and continue to RCE review. For clients, only review token/session handling explicitly visible in client code; do not apply the server baseline unless the user asks for client-side risk review. Completion criterion: Each applicable control has a supported status. Step 4 — Check RCE vectors Review all 7 RCE vectors. Mark each vector SAFE, AT RISK, or N/A. Prefer direct evidence over inference; the RCE Vectors table below enumerates the patterns to look for. Completion criterion: Every relevant tool has an RCE result or explicit N/A. Step 5 — Check OWASP MCP Top 10 Evaluate all 10 OWASP risks below. If a control from Step 3 already fully covers an OWASP risk, reference that result rather than re-checking. For local/STDIO servers, mark network-dependent OWASP risks (MCP07, MCP09) as N/A. Mark each risk PASS, FAIL, or NEEDS INVESTIGATION. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills github/mcp-implementation-security-review