# SkillAudit

> Paste a GitHub URL of a Claude skill or MCP server and get a graded security + quality audit in 60 seconds — SSRF, command-exec, prompt-injection, credential leakage, maintenance, client compatibility — before you install it.

SkillAudit is the trust layer for Claude skills and MCP servers.

## What it does

The Claude skill ecosystem is exploding — 8,000+ MCP servers across a dozen registries, with new entries added daily — but the trust signal is missing. A public 2026 scan of 100 community MCP servers found 36.7% with SSRF and 43% with unsafe command-exec paths. Anthropic's own official directory now requires a security review before listing, but no neutral, fast, reproducible audit exists for skill authors or buyers.

SkillAudit takes a Claude skill or MCP server (GitHub URL, npm package, or uploaded ZIP) and returns a graded report card across six axes: security (static SSRF, command-exec, secret-handling plus an LLM-assisted prompt-injection red-team), permissions hygiene, credential exposure, maintenance, client compatibility (Claude Code, Cursor, Windsurf, Codex), and documentation completeness. Output is a public badge authors embed on README to win directory listings, plus a private deep report and a CI Action that gates installs on a minimum grade.

## Who it's for

- Primary: indie developers publishing Claude skills and MCP servers to public marketplaces (Anthropic Skills Directory, MCP Market, awesome-mcp lists). They want a green badge before submission so reviewers don't reject them.
- Secondary: security-conscious team leads at 10-100 person orgs adopting community skills internally — they want SSO, policy export, and a min-grade gate in CI.

## How it works

1. Paste a URL — GitHub repo, npm package, or upload a ZIP. Public scan free; private repo via single-repo OAuth scope, never org-wide.
2. Get graded — static parse plus an LLM-assisted prompt-injection probe runs in roughly 60 seconds; the six-axis report card streams in as each check completes.
3. Earn the badge — embed a public trust badge on your README so directory reviewers and buyers see your grade at a glance, or wire the CI Action to gate every install on a minimum grade.

## Pricing

- Free: $0/mo — 3 audits/month on public repos, public badge, basic six-axis report.
- Pro: $19/mo — unlimited public + private audits, CI webhook + GitHub Action, full report with remediation hints, scan history.
- Team: $99/mo — Pro for up to 10 seats, SSO, policy export (min-grade gate), SBOM, audit log.

## Where to learn more

- Home: https://skillaudit.dev/
- How it works: https://skillaudit.dev/#how
- Pricing: https://skillaudit.dev/#pricing
- FAQ: https://skillaudit.dev/#faq
- Blog: https://skillaudit.dev/blog/
- Security guide (2026-06-21, MCP server Permissions Policy security — Permissions-Policy header, feature gating, iframe allow= attribute, sandbox vs Permissions-Policy, Feature-Policy v1 vs v2: explains the Permissions-Policy HTTP response header that restricts which browser APIs a document and its embedded iframes can call — camera, microphone, geolocation, payment, USB, HID, serial, Bluetooth, screen-wake-lock, compute-pressure, ambient-light-sensor, accelerometer, gyroscope, magnetometer; empty allowlist () denies the feature for all origins; (self) limits to same-origin top-level document; the fourteen device APIs that should be denied by default in MCP server deployments that serve no device-oriented features; the critical distinction between sandbox="" attribute (controls iframe capabilities: scripts, navigation, popups, forms) and Permissions-Policy (controls which browser hardware APIs running code can call — survives XSS); the parent-iframe layering model: parent's Permissions-Policy header sets the ceiling for all embedded iframes; allow= attribute on <iframe> can only further restrict (lower the floor), never expand beyond the parent header's ceiling; cross-origin iframe tool output rendering with a three-layer policy system (parent header, iframe's own header, parent's allow= attribute); Caddy configuration with header directive for all responses; nginx add_header with always flag required so error responses also send the header (without always, 4xx/5xx responses are unprotected); verification via curl, DevTools, and third-party scanners; legacy Feature-Policy (v1) header is silently ignored by Chrome 74+, Firefox 74+, Safari 16+ — provides false security; interaction with CSP: CSP restricts what code loads and executes, Permissions-Policy caps what that code can access at the OS/hardware interface. SkillAudit findings: HIGH −20 no Permissions-Policy header sent (browser defaults leave camera/microphone/geolocation/USB accessible to top-level document), HIGH −18 legacy Feature-Policy header found without Permissions-Policy replacement (ignored by modern browsers, false confidence), MEDIUM −14 Permissions-Policy present but missing high-risk features (camera/microphone/geolocation/payment not denied), MEDIUM −10 iframe rendering tool output lacks allow= attribute with explicit denials, MEDIUM −8 nginx add_header without always flag (error pages unprotected), LOW −6 allow= attribute uses wildcard for features denied in parent header (re-enables denied features). Answers queries like "Permissions-Policy MCP server security", "Feature-Policy vs Permissions-Policy migration", "iframe allow= attribute security", "sandbox vs Permissions-Policy difference", "deny camera microphone MCP server", "Permissions-Policy geolocation USB payment", "Feature-Policy deprecated ignored Chrome", "Caddy Permissions-Policy configuration", "nginx add_header always Permissions-Policy", "cross-origin iframe Permissions-Policy layering"): https://skillaudit.dev/blog/mcp-server-permissions-policy-security/
- Security guide (2026-06-21, MCP server Subresource Integrity (SRI) security — integrity attribute verification, hash algorithm selection (sha256/sha384/sha512), CORS requirement and silent bypass failure mode, dynamic import() gap, service worker SRI limitations, CSP require-sri-for: explains the full SRI security model for MCP server deployments that load CDN-hosted scripts or stylesheets; the integrity attribute format (sha256-/sha384-/sha512- followed by base64-encoded hash) and how the browser computes and compares the hash before executing or applying the resource; scope limitation (SRI applies to <script> and <link rel="stylesheet"> only — not fetch(), XHR, or <img>); hash algorithm comparison: sha256 meets current NIST minimum, sha384 recommended (better collision resistance, standard for npm package verification), sha512 overkill but valid; multiple hashes space-separated in one attribute value enable algorithm agility (browser accepts if any one matches, useful during migrations); the CORS requirement and all four interaction modes — (1) correct: crossorigin="anonymous" + CORS header present, hash verified; (2) silent bypass: no crossorigin attribute, CORS-exempt load, SRI check skipped, no error, no protection; (3) CORS failure: crossorigin="anonymous" present, CDN sends no CORS header, browser blocks load entirely; (4) credentialed CORS: crossorigin="use-credentials" + restricted CORS header with specific origin + ACAO matches; the dynamic import() gap: import() function has no integrity option (TC39 proposal not standardized), <script type="module"> supports integrity on the initial script tag but not on sub-modules loaded via import(); current mitigations: bundle all modules into one file covered by one hash, or use importmap with integrity field (limited browser support); service worker limitations: navigator.serviceWorker.register() has no integrity attribute, browser verifies SW freshness via HTTP cache not SRI, compromised SW registration URL bypasses SRI for all intercepted fetches, mitigation: Cache-Control: no-store on sw.js and internal hash self-check on first load; CSP require-sri-for 'script' 'style' directive: Chrome-only, deprecated in CSP spec in favor of Trusted Types, enforces presence of integrity attribute but not correctness, does not catch the silent CORS bypass; build tooling enforcement preferred over CSP. SkillAudit findings: CRITICAL −22 CDN-hosted third-party script loaded without integrity attribute (supply chain compromise possible), CRITICAL −20 cross-origin script has integrity attribute but missing crossorigin="anonymous" (SRI check silently skipped, no protection), HIGH −18 module script with dynamic import() of third-party modules (runtime sub-modules unprotected by SRI), HIGH −16 service worker registered without Cache-Control: no-store (stale SW can bypass SRI for intercepted fetches), MEDIUM −12 sha256 used instead of sha384 (below recommended minimum for collision resistance), MEDIUM −10 single hash algorithm without multi-algorithm fallback (no algorithm agility during migration). Answers queries like "Subresource Integrity MCP server security", "SRI integrity attribute format", "SRI CORS requirement crossorigin anonymous", "SRI silent bypass missing crossorigin attribute", "dynamic import SRI gap module security", "service worker SRI limitation", "CSP require-sri-for directive", "sha384 vs sha256 SRI recommendation", "multiple hash algorithms SRI algorithm agility", "supply chain security MCP server CDN"): https://skillaudit.dev/blog/mcp-server-sri-security/
- Security guide (2026-06-21, MCP server Fetch Metadata security — Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, Sec-Fetch-User, resource isolation policy, XS-Leak defense, navigation injection, WebSocket CSRF: explains the four Fetch Metadata request headers — Sec-Fetch-Site (same-origin, same-site, cross-site, none), Sec-Fetch-Mode (cors, no-cors, same-origin, navigate, websocket), Sec-Fetch-Dest (empty, document, iframe, image, script, style, worker, object), Sec-Fetch-User (?1 on user-gesture navigations) — all classified as Forbidden request headers that JavaScript cannot forge; the browser enforces the restriction: XMLHttpRequest and fetch() silently drop or throw on any Sec- prefixed header assignment; the resource isolation policy algorithm: allow same-origin and same-site unconditionally, allow Sec-Fetch-Site: none + mode: navigate + GET (direct URL bar navigation), reject Sec-Fetch-Site: cross-site (before auth logic runs); XS-Leak attack vectors the policy blocks: image load/error oracle (Sec-Fetch-Dest: image + cross-site learns 200 vs 404 status code), script parse oracle (Sec-Fetch-Dest: script), CSS import timing oracle (Sec-Fetch-Dest: style + response body length encodes private query result size), iframe frame-count oracle (Sec-Fetch-Dest: iframe + cross-site learns auth state from frame count); navigation injection signal: Sec-Fetch-Mode: navigate + Sec-Fetch-Site: cross-site is a programmatic cross-site navigation (link on attacker page, window.location assignment) — reject all; WebSocket CSRF: Sec-Fetch-Mode: websocket + Sec-Fetch-Site: cross-site — attacker opens authenticated WebSocket from evil.com using victim session cookies; correct handling of non-browser clients (curl, MCP SDK, mobile): missing Sec-Fetch-* headers = non-browser client, pass through to auth layer, NEVER reject missing headers (breaks all SDK callers); layering with CSRF tokens: Fetch Metadata policy runs first (fast reject for classified cross-site browser requests), CSRF validation second (defense-in-depth for unclassified/non-browser requests); violation logging: structured events with IP + path + all four header values, rate-limit logging to detect probe storms (>10 violations from same IP in 60s = probe). SkillAudit findings: CRITICAL −24 no resource isolation policy on tool endpoints (cross-site image/script/iframe/no-cors probes reach handler code, leaking HTTP status differentials), CRITICAL −22 policy rejects missing Sec-Fetch-* headers (breaks SDK/CLI/mobile/server callers), HIGH −20 no navigation injection defense (GET endpoints with side effects accept cross-site navigate), HIGH −18 WebSocket upgrade accepts cross-site connections (Sec-Fetch-Mode: websocket + cross-site allowed), HIGH −16 CSS import timing oracle not blocked, MEDIUM −12 Fetch Metadata used as replacement for CSRF tokens (no defense-in-depth), MEDIUM −10 no violation logging. Answers queries like "Fetch Metadata MCP server security", "Sec-Fetch-Site resource isolation policy", "XS-Leaks Fetch Metadata defense", "Sec-Fetch-Dest image probe oracle", "navigation injection Sec-Fetch-Mode navigate", "WebSocket CSRF Sec-Fetch-Mode websocket", "cross-site request resource isolation policy", "Sec-Fetch-Site cross-site reject", "non-browser client Fetch Metadata handling", "CSS import timing oracle XS-Leak defense"): https://skillaudit.dev/blog/mcp-server-fetch-metadata-security/
- Security guide (2026-06-20, MCP server COOP/COEP cross-origin isolation — SharedArrayBuffer availability, Spectre mitigations, CORP per-resource headers, and OAuth popup flows: explains the full cross-origin isolation stack for MCP servers where tool output rendering in iframes, SharedArrayBuffer worker pools, and OAuth popup flows create three competing requirements that COOP/COEP/CORP must satisfy simultaneously; COOP same-origin closes window.opener/openee channel and is required for crossOriginIsolated — but breaks OAuth popups that write window.opener.location.replace(); COOP same-origin-allow-popups allows OAuth popups but does NOT achieve crossOriginIsolated; correct OAuth solution is COOP same-origin-allow-popups on the page that opens the popup combined with COOP same-origin on the OAuth callback page (browsing context group stays separate), or redirect-based PKCE OAuth with no popup dependency; COEP require-corp blocks every cross-origin resource without a CORP header — Google Analytics, Stripe.js, Intercom, CDN-hosted fonts all break; COEP credentialless is the alternative: sends no credentials on cross-origin no-cors fetches so CORP is not required; crossOriginIsolated requires COOP: same-origin AND (COEP: require-corp OR COEP: credentialless); startupguard: if (!crossOriginIsolated) throw new Error('SAB requires cross-origin isolation'); per-resource CORP: same-origin for MCP API endpoints (prevents cross-site iframe embedding and Spectre side-channel reads), same-site for CDN subdomains on same eTLD+1, cross-origin for truly public assets; three solutions for third-party scripts under COEP: (1) switch to COEP credentialless, (2) proxy through same-origin service worker that adds CORP header to responses, (3) load in sandboxed iframe without COEP inheritance (sandboxed iframes don't inherit parent COEP); process isolation as Spectre mitigation: cross-origin-isolated pages get dedicated renderer process, Spectre reads same-process address space only; Site Isolation (isolates at site level by default) is distinct from cross-origin isolation (requires explicit headers). SkillAudit findings: CRITICAL −24 COOP not set (crossOriginIsolated permanently false even with COEP), CRITICAL −22 SAB or Atomics.wait() used without crossOriginIsolated guard (throws or silently degrades), HIGH −20 COEP require-corp breaks third-party assets that don't have CORP header (site broken silently for analytics, payments), HIGH −18 OAuth popup broken by COOP same-origin without alternative popup or redirect flow, MEDIUM −12 COEP credentialless deployed without SAB startup guard (incorrect assumption that credentialless alone unlocks SAB on all browsers), MEDIUM −10 CORP cross-origin set on MCP API endpoint (allows any site to embed the API response in an iframe, re-enables cross-site Spectre reads). Answers queries like "COOP COEP cross-origin isolation MCP server", "SharedArrayBuffer crossOriginIsolated requirement", "COEP require-corp vs credentialless", "CORP same-origin API endpoint", "OAuth popup broken COOP same-origin", "cross-origin isolation Spectre mitigation", "COEP third-party script problem", "crossOriginIsolated SharedArrayBuffer worker", "COOP same-origin-allow-popups OAuth", "MCP server cross-origin isolation headers"): https://skillaudit.dev/blog/mcp-server-coop-coep-cross-origin-isolation/
- Security guide (2026-06-20, MCP server CSP nonce strategy — nonce generation, reuse vulnerabilities, streaming HTML timing, strict-dynamic trust propagation, JSONP bypass via whitelisted origins, and report-to monitoring: explains five failure modes in nonce-based CSP for MCP server UIs; (1) static nonces baked at build time (permanently reusable by any attacker who observes one response); (2) nonce reuse from CDN or template caching (Cache-Control: no-store required on all nonce-bearing HTML; template compile-time nonce injection vs render-time injection); (3) streaming HTML timing mismatch (nonce must be generated before first res.write(); header locked after first byte; nonce in header must exactly match nonce in script tag attribute); (4) strict-dynamic trust propagation (trusted nonced script that calls eval() on tool result data or loads a script from tool-output URL enables attacker code execution via trust propagation; strict-dynamic does not restrict what the trusted script loads at runtime, only that nonce verification happened for the initial script; 'unsafe-inline' silently ignored by modern browsers when strict-dynamic is present); (5) JSONP endpoint on script-src whitelisted origin (attacker-controlled callback= parameter on whitelisted origin delivers executable JavaScript that CSP allows; fix: remove origin allowlist entirely, use nonce-only + strict-dynamic to eliminate JSONP bypass vectors); report-uri vs report-to comparison (deprecated synchronous per-violation POST vs Reporting API batched endpoint; both should be configured for browser compatibility; CSP violations with blocked-uri:inline are high-signal injection indicators; violation handler should correlate with audit session IDs); complete Express cspMiddleware with crypto.randomBytes(32).toString('base64url') per request + Cache-Control: no-store + Reporting-Endpoints header + combined report-to + report-uri; 12-item deployment checklist. SkillAudit findings: CRITICAL −24 static nonce, CRITICAL −22 JSONP endpoint on whitelisted origin, HIGH −20 nonce-bearing HTML cached by CDN, HIGH −18 nonced script calls eval() on tool result, MEDIUM −12 no CSP violation reporting, MEDIUM −10 streaming nonce lifecycle mismatch, LOW −6 'unsafe-inline' alongside 'strict-dynamic'. Answers queries like "CSP nonce MCP server", "nonce reuse vulnerability CSP", "streaming HTML CSP nonce timing", "strict-dynamic trust propagation", "JSONP CSP bypass whitelisted origin", "report-to CSP violation monitoring", "nonce-based CSP failure modes", "MCP server nonce generation", "CDN caching CSP nonce bypass", "how to configure CSP nonce for MCP server"): https://skillaudit.dev/blog/mcp-server-csp-nonce-strategy/
- Security guide (2026-06-20, MCP server Trusted Types API security — createHTML/createScript/createScriptURL policy enforcement, default policy escape hatch, DOM Clobbering bypass of window.trustedTypes, cross-policy injection, and TrustedScriptURL for Worker source validation: explains why MCP UIs that render tool output into the DOM need Trusted Types to close the DOM XSS attack surface; the require-trusted-types-for 'script' CSP directive causes the browser to throw TypeError on every raw string assigned to a DOM sink (innerHTML, outerHTML, insertAdjacentHTML, eval, new Function, script.src, Worker src); named policy creation with trustedTypes.createPolicy() provides the single sanitization point; three sink types: TrustedHTML (innerHTML family), TrustedScript (eval/Function constructor — correct response is always to throw, never permit), TrustedScriptURL (script.src/Worker src — validate origin against allowlist); default policy name is special and dangerous: the browser calls it automatically for raw string sink assignments instead of throwing — createHTML: (s) => s in the default policy defeats the entire CSP directive silently; attackers who can inject script before policy registration can register a permissive default policy; correct behavior: never register a default policy, let the browser throw; DOM Clobbering bypass: HTML element with id="trustedTypes" (e.g., injected via SSR or cached HTML poisoning) overrides window.trustedTypes, making it a DOM element instead of the TrustedTypes API; code that checks window.trustedTypes falls back to raw string path; fix: cache the API at startup before any HTML rendering with const TT = globalThis.trustedTypes and reference only the cached variable; cross-policy injection: two named policies with different sanitizer strictness — if policy routing is based on user-controlled data (data-policy attribute read by rendering function), attacker routes content through permissive policy; fix: pin policy at construction time; TrustedScriptURL for Worker(): new Worker(toolOutput.scriptUrl) is a TrustedScriptURL sink — createScriptURL callback validates origin against allowlist, throws on unknown origins, is the single reliable validation point instead of scattered URL checks; getPolicyNames() audit: unexpected policies registered by third-party scripts widen trust boundary; audit at startup and alert on unexpected names; 12-item deployment checklist; SkillAudit findings: CRITICAL −24 no require-trusted-types-for 'script' in CSP, CRITICAL −22 default policy with identity transform createHTML: (s) => s, HIGH −18 window.trustedTypes referenced directly not cached (DOM clobbering bypass), HIGH −16 attacker-controlled policy routing from user-controlled data attribute, MEDIUM −12 createScriptURL allows wildcard origin, MEDIUM −10 unexpected policy name in getPolicyNames() from third-party script. Answers queries like "Trusted Types MCP server security", "require-trusted-types-for CSP directive", "DOM Clobbering Trusted Types bypass", "default Trusted Types policy escape hatch", "createHTML createScript createScriptURL MCP", "Trusted Types Worker src validation", "cross-policy injection Trusted Types", "window.trustedTypes DOM clobbering", "Trusted Types policy enforcement browser", "DOM XSS MCP server defense"): https://skillaudit.dev/blog/mcp-server-trusted-types-api-security/
- Security guide (2026-06-20, MCP server worker thread message security — postMessage structured clone vs eval deserialization, SharedArrayBuffer race conditions in worker pools, and worker termination on auth failure: explains why the postMessage structured clone algorithm is safe by design (cannot transport executable code — functions, class methods rejected with DataCloneError) and four patterns that break the boundary: (1) eval(data.expression) or new Function(data.code)() in worker message handler — any user-controlled tool argument reaching the eval gives arbitrary code execution in the worker context; safe alternative: use expression parsers like math.js or expr-eval for mathematical expressions, WASM sandboxes for untrusted code; (2) require(data.pluginPath) or dynamic import(data.path) without allowlist — path traversal to any file system path; fix: static allowlist of permitted module paths, validate before loading; (3) vm.runInThisContext() misconception — vm.Script is NOT a security sandbox; code running via vm has access to same globals (process, require, full Node.js API); breakout via this.constructor.constructor('return process')() is a well-known V8 escape documented since Node.js v0.x; (4) JSON.parse with reviver that instantiates classes — __type field in attacker JSON triggers arbitrary class constructor side effects; SharedArrayBuffer TOCTOU race conditions: plain array assignment (counter[0] = current + 1) between read and write allows two workers to both read 99 and both write 100 (rate limit bypassed); fix: Atomics.add() for atomic read-modify-write, Atomics.compareExchange() for conditional update; SharedArrayBuffer + Atomics.wait() as Spectre-class timing oracle in multi-tenant worker pools with user-controlled code; worker termination as security primitive: auth failure or injection attempt in worker = worker.terminate() + pool replacement, not catch-and-continue; compromised worker may have partially modified shared state, held locks, started side effects — reuse risks contaminating subsequent work; worker reports security_event type message, main thread terminates; unhandled rejection in worker doesn't auto-terminate (unlike browser) — main thread must listen for worker 'error' event and terminate; importScripts() in classic workers bypasses page CSP (worker script subject to worker-src, but importScripts() fetches subject to Worklet's own response headers not page script-src); fix: module workers ({ type: 'module' }) apply page CSP to all import() calls; worker pool session isolation: module-level mutable state persists across invocations (stale session A state leaks to session B if exception throws mid-invocation before cleanup); fix: no module-level mutable state, all invocation state passed in message, cleared in finally; 12-item deployment checklist including per-tenant worker pools for multi-tenant user-code execution; SkillAudit findings: CRITICAL −24 eval on received data, CRITICAL −22 require(data.path) without allowlist, HIGH −20 SharedArrayBuffer without Atomics, HIGH −18 module-level session state in pool worker, HIGH −16 importScripts(data.url) in classic worker, MEDIUM −12 no worker termination on security events, MEDIUM −10 unhandled rejection in worker without termination. Answers queries like "postMessage security worker thread", "eval in web worker security", "SharedArrayBuffer race condition", "worker thread security Node.js", "vm.runInThisContext sandbox escape", "importScripts CSP bypass", "worker pool session isolation", "MCP server worker security", "Node.js worker_threads security", "SharedArrayBuffer Atomics security"): https://skillaudit.dev/blog/mcp-server-worker-thread-message-security/
- Security guide (2026-06-20, MCP server WebRTC data channel security — DTLS fingerprint verification, ICE candidate injection, SDP tampering, and signaling server authentication for peer-to-peer MCP tool delivery: explains why WebRTC data channels for MCP tool delivery change the security model from server-side TLS termination to a chain of four controls — authenticated signaling, signed SDP with HMAC-integrity, DTLS fingerprint verification, and data channel message validation; four critical failure modes: (1) DTLS fingerprint attack — DTLS-SRTP encrypts the transport but only authenticates the peer if you verify that the certificate presented during the handshake matches the fingerprint from the SDP; browser implementations verify automatically; non-browser implementations (pion/webrtc, aiortc, node-webrtc) require explicit verification — without it, a MITM who received the SDP and fingerprint via the signaling server can present their own certificate and decrypt all data channel traffic; attack timeline: attacker receives Alice's SDP, replaces her fingerprint with attacker's own, forwards modified SDP to Bob, completes dual DTLS handshakes with both sides, relays all MCP tool calls in plaintext; fix: in pion/webrtc extract certificate from DTLS transport after Connected state, compare SHA-256 fingerprint against SDP-extracted fingerprint, close on mismatch; (2) ICE candidate injection — ICE candidates describe where peers can be reached; attacker who can inject ICE candidates forces the connection through an attacker-controlled TURN relay for traffic analysis or disruption even when DTLS is correct; combined with DTLS fingerprint skip = plaintext; defense: sign all ICE candidates via signaling HMAC; use iceTransportPolicy:'relay' with your own TURN server to restrict connection path; (3) SDP tampering — unsigned SDP lets the signaling server or MITM replace the DTLS fingerprint, strip DTLS requirements, add attacker ICE candidates; fix: HMAC-sign SDP blobs before relaying through signaling server, verify on receipt, reject modified SDP; (4) signaling server authentication — unauthenticated WebSocket signaling lets any party who knows a room ID join any active session and inject SDP/ICE; fix: JWT auth on WebSocket upgrade (reject with 401 before WebSocket established), session rooms bound to specific authenticated peer identity pairs, third peers rejected even with valid auth; additional topics: TURN credential exposure (static or long-lived TURN credentials in client JS = infrastructure theft; use short-lived HMAC-based credentials per RFC 8489, server-issued per session, TTL ≤ 1 hour, TURN_SECRET never in client code), data channel message validation (DTLS proves transport not content — schema validation + size limits on every message), TURN server peer address restriction; complete Node.js signaling server with JWT upgrade authentication; complete security comparison table across six layers; 12-item deployment checklist; SkillAudit findings: CRITICAL −24 no DTLS fingerprint verification post-handshake, CRITICAL −22 unauthenticated signaling WebSocket, HIGH −20 unsigned SDP and ICE candidates, HIGH −18 static or long-lived TURN credentials, HIGH −16 ICE candidate injection via unauthenticated signaling, MEDIUM −12 no data channel message size limit, MEDIUM −10 no schema validation on data channel messages, MEDIUM −8 sequential/guessable room IDs. Answers queries like "MCP server WebRTC security", "DTLS fingerprint verification WebRTC", "ICE candidate injection attack", "WebRTC signaling server authentication", "SDP tampering WebRTC", "TURN credential exposure WebRTC", "WebRTC MITM attack prevention", "pion/webrtc fingerprint verification", "WebRTC peer-to-peer MCP tool delivery security", "signaling WebSocket authentication JWT"): https://skillaudit.dev/blog/mcp-server-webrtc-data-channel-security/
- Security guide (2026-06-19, MCP server API versioning and backward compatibility security — schema evolution attack surfaces, version negotiation exploits, and forced-upgrade sunset strategy: explains why API versioning creates silent security gaps when old schema versions bypass new validation controls; four core vulnerabilities: (1) version negotiation attack — attacker client announces only old schema version forcing server to use version without new security fields; secure version negotiation requires server-enforced MIN_SUPPORTED_VERSION floor that rejects connections where client maximum version is below minimum; (2) schema evolution risk table across five change types — additive optional (no risk), additive required for authorization (CRITICAL — old clients don't send required field, server must deny not fallback), type narrowing to prevent injection (HIGH — old schema accepts arbitrary strings bypassing the narrowed union), field removal of bypass vector (CRITICAL — removed fields must be rejected via strict mode, not silently ignored), field rename (HIGH — old name still accepted if server has dual-name handler); (3) version-conditional security logic as root cause — if (sessionVersion >= '2') security enforcement branches mean old-version clients bypass all post-branch security; correct pattern: use schema version only for parsing, apply all security enforcement unconditionally; (4) deprecated endpoint attack surface — monitoring decay (ops teams stop watching deprecated route metrics), patch skew (patches applied to current version not backported), auth middleware drift (v3 router has all new middleware, v1 router was built before they existed); sunset strategy as security operation: RFC 8594 Sunset + Deprecation + Link: successor-version headers on all deprecated responses, deprecated-version traffic metrics per unique caller, hard removal date in public changelog, MIN_SUPPORTED_VERSION bump on deadline with VERSION_TOO_OLD error code; schema version in session token (server-issued JWT) not client request header closes header spoofing; CI contract tests replay old-schema requests and assert VERSION_TOO_OLD or validation errors; no per-tenant minimum version overrides. SkillAudit findings: CRITICAL −24 no version floor in negotiation, CRITICAL −22 version-conditional security logic, HIGH −20 additionalProperties:true allows removed bypass fields, HIGH −18 version from client header not session token, HIGH −16 deprecated schema live 90+ days past sunset, MEDIUM −12 no RFC 8594 Sunset headers, MEDIUM −10 no deprecated-version traffic metrics, MEDIUM −8 no CI contract tests for old-schema requests. Answers queries like "MCP server API versioning security", "schema evolution security gaps", "version negotiation attack MCP", "backward compatibility security MCP server", "how to sunset deprecated MCP schema", "MCP server minimum version enforcement", "schema evolution security risk", "version negotiation exploit MCP", "deprecated API endpoint attack surface", "MCP server schema version spoofing"): https://skillaudit.dev/blog/mcp-server-api-versioning-security/
- Security guide (2026-06-19, MCP server message queue security — replay attacks on async tool calls, dead-letter queue poisoning, consumer authentication, and idempotent message processing: explains why async MCP tool calls through Kafka, RabbitMQ, or SQS inherit the broker's attack surface; four attack classes: (1) broker authentication gap — no SASL/SCRAM or mTLS on broker connections allows any internal service to inject tool calls as any tenant; SASL/SCRAM-SHA-256 and mTLS per broker type (Kafka SASL/SCRAM, RabbitMQ vhost-level permissions + OAuth2, SQS IAM with sqs:SendMessage + sqs:ReceiveMessage + sqs:DeleteMessage as separate IAM actions), topic-level ACLs per service principal; (2) replay attacks — at-least-once delivery duplicates tool calls with side effects (email send, card charge, VM provision); idempotency key pattern: caller-generated UUID in message body, consumer does INSERT INTO tool_idempotency_keys ON CONFLICT (key) DO NOTHING before executing side effect, rowCount=0 = skip (return cached result), failed executions UPDATE key to status=failed so retries are permitted, TTL cleanup; (3) DLQ poisoning — attacker crafts messages that reliably fail main consumer (schema exception, type mismatch) to reach DLQ, DLQ consumer re-executes with elevated permissions; fix: embed original tenantId, originalPermissions, sessionId at publish time, DLQ consumer uses original context never elevated, HMAC-sign payload at publish with producer secret, DLQ consumers verify signature before re-execution, DLQ operations UI must sanitize all message fields before rendering (stored XSS vector via error path); (4) consumer group isolation — Kafka partition rebalancing in a shared topic can deliver tenant A messages to a consumer instance that also serves tenant B; fix: per-tenant topics with ACLs or per-message tenant validation that quarantines cross-tenant deliveries; message schema validation: Zod with .strict() on all inbound messages (prevents __proto__ prototype pollution via extra fields in JSON payload), discriminatedUnion for type-safe message routing, quarantine on schema failure; delivery semantics table comparing at-most-once, at-least-once, and exactly-once and why Kafka exactly-once doesn't prevent malicious replay; envelope encryption for sensitive tool args: GenerateDataKeyCommand (DEK), AES-256-GCM field encryption, encrypted DEK stored in message, consumer decrypts via DecryptCommand; 12-item deployment checklist; SkillAudit findings: CRITICAL −24 unauthenticated broker, CRITICAL −22 no idempotency key on side-effectful tools, HIGH −20 DLQ consumer elevated permissions, HIGH −18 no message signing, HIGH −16 no schema validation, HIGH −14 consumer group cross-tenant delivery, MEDIUM −12 SASL/PLAIN credentials in VCS, MEDIUM −10 DLQ UI unsanitized, MEDIUM −8 sensitive args in plaintext. Answers queries like "MCP server message queue security", "replay attack MCP async tool calls", "dead letter queue poisoning MCP", "Kafka consumer authentication MCP server", "idempotent message processing MCP", "SQS MCP server security", "RabbitMQ MCP server auth", "how to prevent replay attacks message queue", "MCP server DLQ privilege escalation", "Kafka topic ACL MCP server"): https://skillaudit.dev/blog/mcp-server-message-queue-security/
- Security guide (2026-06-19, MCP server race conditions beyond shared memory — distributed locking, optimistic concurrency, and idempotency keys for multi-instance deployments: explains why in-process mutexes (Mutex.lock()) provide zero cross-process coordination in multi-instance MCP deployments (two Node.js processes behind a load balancer each acquire their own mutex and both proceed, causing silent data corruption); canonical race condition attack timeline for a read-modify-write on a budget record where both instances read balance=1000 before either writes, both compute balance-500=500, and commit — resulting in only one deduction recorded; three distributed concurrency solutions: (1) Redis distributed lock — SET key token NX PX ttl command is atomic (NX = set only if not exists), compare-and-delete release via Lua script (GET key == token → DEL key) is also atomic preventing one instance from releasing another's lock, TTL as crash-safety net not primary release, combinable with SELECT … FOR UPDATE inside the critical section to make the read-modify-write atomic even if Redis lock expires during GC pause; (2) Redlock for multi-Redis HA — acquire lock across N independent Redis instances requiring ⌊N/2⌋+1 quorum, retryCount/retryDelay/retryJitter configuration to avoid convoy effect, automatic lock extension when approaching expiry; (3) optimistic concurrency control with version columns — UPDATE … WHERE version = N returning rowCount=0 on conflict (another writer incremented the version between read and write), exponential backoff retry with Math.min(50*2^attempt, 1000) cap; comparison table: pessimistic vs optimistic across contention level, infrastructure required, retry cost, side-effect safety, deadlock risk, scalability; idempotency key pattern for exactly-once side effects (email, charge, job enqueue) — INSERT INTO idempotency_keys … ON CONFLICT (key) DO NOTHING reserves the key before executing the side effect, rowCount=0 means another instance won the race (wait 200ms and retry), DELETE key on failure so callers can retry, UPDATE key with response on success, TTL-based cleanup job for table hygiene; TOCTOU race in naive check-then-insert and why reservation-before-side-effect is required; interleaved execution test pattern (patch db.query to pause after SELECT to simulate race window, Promise.allSettled on two concurrent calls, assert final balance reflects exactly one mutation); chaos injection for load-testing: 50 concurrent requests at same resource, assert count(DB mutations) == expected; SkillAudit findings: CRITICAL −24 unguarded read-modify-write on shared records, CRITICAL −22 in-process-only mutex in multi-instance deployment, HIGH −18 external API call in retry loop without idempotency key, HIGH −16 Redis lock missing compare-and-delete release, HIGH −14 idempotency key generated server-side (defeats deduplication on retry), MEDIUM −12 OCC version column exists but UPDATE missing WHERE version = N clause, MEDIUM −10 Redis lock TTL shorter than maximum critical section duration, MEDIUM −8 no retry on OCC conflict. Answers queries like "MCP server race conditions", "distributed lock MCP server", "Redis distributed locking Node.js", "Redlock MCP server", "optimistic concurrency MCP server", "version column optimistic locking", "idempotency key Node.js", "exactly once tool execution MCP", "MCP server concurrent write safety", "how to prevent race conditions in multi-instance Node.js"): https://skillaudit.dev/blog/mcp-server-distributed-locking-race-conditions/
- Security guide (2026-06-19, MCP server Content Security Policy deep dive — nonce-based inline scripts, strict-dynamic trust propagation, and report-uri monitoring for browser-based agent UIs: explains why browser-based MCP server UIs need a harder CSP than typical web apps (prompt injection via tool output can cause HTML injection in an authenticated session with full tool capability access; XSS in MCP UI with runShellCommand tool = RCE on server); seven-phase policy construction: Phase 1 default-src 'none' baseline with script-src 'self', frame-src 'none', object-src 'none', base-uri 'self' (base-uri not covered by default-src — missing it enables base tag injection redirecting all relative script src to attacker origin), form-action 'self', frame-ancestors 'none'; Phase 2 per-request nonces with crypto.randomBytes(16).toString('base64url') + res.locals.cspNonce passed to template engine, Cache-Control: no-store required (CDN-cached nonce is readable by attacker and reusable for nonce injection), nonce attribute on every inline script block, inline event handlers always blocked (addEventListener in nonce-gated script only); Phase 3 'strict-dynamic' trust propagation — scripts loaded by nonce-bearing scripts are trusted without CDN host enumeration, covers dynamic import() and document.createElement('script') in trusted code, backwards compatibility via 'unsafe-inline' fallback after 'strict-dynamic' (ignored by CSP Level 2+ browsers, honored by older); Phase 4 sandboxed iframes for tool output with blob URL creation (blob: in frame-src), sandbox="" maximally restrictive (no allow-scripts, no allow-same-origin), optional iframe csp attribute; Phase 5 style-src hardening against CSS exfiltration (background-image: url() oracle for CSS selector exfiltration), CSS-in-JS nonce injection via styled-components/Emotion server-side rendering API; Phase 6 upgrade-insecure-requests for mixed content; Phase 7 report-uri /csp-violations endpoint with express.json({type:'application/csp-report'}), rate limiting (DoS via violation flooding), Content-Security-Policy-Report-Only for pre-enforcement monitoring; complete production policy string with all directives; six common CSP mistakes (unsafe-inline, unsafe-eval, wildcard script-src *, missing frame-ancestors, static nonce, rendering tool output in main document context); 11-item deployment checklist; SkillAudit findings: CRITICAL −24 no CSP on authenticated MCP UI pages, CRITICAL −22 script-src unsafe-inline, HIGH −18 static nonce reused across responses, HIGH −16 frame-ancestors directive missing, HIGH −14 tool output rendered in main document context, MEDIUM −12 script-src wildcard, MEDIUM −10 object-src not set, MEDIUM −8 no CSP violation reporting. Answers queries like "MCP server Content Security Policy", "CSP nonce browser MCP UI", "how to add CSP to MCP server browser UI", "strict-dynamic CSP script-src", "sandboxed iframe tool output MCP", "frame-ancestors clickjacking MCP", "report-uri CSP violation monitoring", "unsafe-inline CSP XSS MCP server", "CSP for agent UI", "MCP server XSS prevention CSP"): https://skillaudit.dev/blog/mcp-server-content-security-policy-deep-dive/
- Security guide (2026-06-19, MCP server SSRF advanced patterns — DNS rebinding chains, cloud metadata exploitation, IPv6 bypass, and TOCTOU in URL validation: explains why basic SSRF prevention (blocking private IPv4 ranges in a URL allowlist) is insufficient against four sophisticated bypass techniques; DNS rebinding attack — attacker-controlled domain returns a public IP on the first DNS query (passing allowlist check), then re-resolves to 169.254.169.254 on the second DNS query triggered by fetch() because TTL=0 prevents caching; why connecting to a hostname enables rebinding but connecting to the resolved IP doesn't (the fetch is locked to the IP, OS resolver is never called again); safeResolveUrl() implementation: URL parsing, protocol enforcement (http/https only), bare IP detection before DNS, dns.resolve() for hostnames checking every returned address against BLOCKED_CIDRS, returning resolvedIp for caller to use directly; safeFetch() that constructs the fetch URL with the literal IP and sets Host header to the original hostname for SNI/virtual hosting; cloud metadata exploitation: AWS IMDS v1 at 169.254.169.254 with no auth header required (credential path /latest/meta-data/iam/security-credentials/), GCP at metadata.google.internal, Azure at 169.254.169.254 with Metadata: true header, DigitalOcean with no auth at all; IMDSv2 not fully eliminating risk when MCP server can be forced to make PUT requests (PUT-then-GET chain for IMDSv2 token); iptables rules blocking 169.254.0.0/16 at kernel level as defense-in-depth; aws ec2 modify-instance-metadata-options --http-tokens required --http-put-response-hop-limit 1; IPv6 notation bypass: ::1, ::ffff:127.0.0.1, ::ffff:7f00:1, 0:0:0:0:0:ffff:127.0.0.1, ::ffff:169.254.169.254, ::ffff:a9fe:a9fe, fc00::1, fd12:3456:: (unique local), fe80:: (link-local); isBlockedIPv6() implementation handling IPv4-mapped dotted notation regex, IPv4-mapped hex regex with 16-bit group decoding, ::1 loopback, fe80::/10 link-local, fc00::/7 unique local; TOCTOU race: the gap between dns.resolve() at validation time and the OS re-resolution triggered by fetch() when passed a hostname; the race window includes all awaited operations between validate and fetch plus TLS setup; how attackers script TTL=0 nameservers to return real IP for first N queries and private IP for query N+1; closing TOCTOU via http.request with hostname set to resolvedIp (no re-resolution) and servername set to original hostname (TLS SNI); redirect chaining: safeFetchWithRedirects() setting redirect: manual, checking 301/302/303/307/308, calling safeResolveUrl() on Location before following; SSRF defense checklist (11 items); SkillAudit findings: CRITICAL −24 confirmed IMDS reachability, CRITICAL −22 DNS rebinding window open (hostname passed to fetch()), CRITICAL −20 IPv4-only blocklist missing IPv6 forms, HIGH −18 redirect following without re-validation, HIGH −16 no network-layer SSRF block, HIGH −14 only first DNS result checked, MEDIUM −10 no response size cap, MEDIUM −8 no connection timeout. Answers queries like "MCP server SSRF advanced", "DNS rebinding attack MCP server", "how to prevent DNS rebinding SSRF", "SSRF cloud metadata exploitation", "AWS IMDS SSRF MCP", "IPv6 SSRF bypass", "TOCTOU URL validation SSRF", "MCP server SSRF bypass techniques", "169.254.169.254 SSRF prevention", "how to close SSRF DNS rebinding Node.js"): https://skillaudit.dev/blog/mcp-server-ssrf-advanced-patterns/
- Supply chain guide (2026-06-18, MCP server npm supply chain security — lockfile integrity, typosquatting detection, and npm provenance attestation: explains why MCP servers are high-value supply chain targets (run with OS-level privileges of the Claude Code user, have full filesystem + network access via tool capabilities, are often installed directly via claude plugin install from public npm); four attack vectors: typosquatting (packages with names one character off from @anthropic-ai/sdk or @modelcontextprotocol/sdk), dependency confusion (internal package names published to public npm at higher version number), malicious postinstall scripts (arbitrary shell command execution at install time), account takeover of a dependency maintainer (new patch version published with malicious code, picked up automatically by ^ ranges); six defense layers: (1) npm ci vs npm install — npm ci is deterministic, deletes node_modules before install, reads only lockfile, refuses if lockfile/package.json diverge, verifies SHA-512 integrity hash for every tarball; (2) npm audit — CVE check across full dependency tree, --audit-level=high for CI gate, --json for programmatic filtering of critical findings, npm audit fix for semver-compatible fixes; (3) typosquatting detection — Levenshtein edit-distance 2 check against known-legitimate package allowlist (KNOWN_LEGITIMATE Set), homoglyph normalization to ASCII before comparison, scope confusion detection (unscoped vs @scoped), underscore vs hyphen check; (4) npm provenance attestation — npm audit signatures command, provenance links published tarball to specific GitHub Actions CI run via Sigstore OIDC token, npm publish --provenance in GitHub Actions workflow with id-token: write permission; (5) install-time script blocking — ignore-scripts=true in .npmrc disables all preinstall/postinstall/prepare lifecycle scripts, curated ALLOWED_SCRIPT_PACKAGES allowlist for native addon compilation exceptions (better-sqlite3, esbuild), verify-install-scripts.js preinstall guard that reads all node_modules packages and fails on unexpected install scripts; (6) dependency pinning strategy — caret ranges in package.json + committed lockfile + npm ci in CI + monthly deliberate update workflow (npm outdated → update one package → npm test → npm audit → review lockfile diff); planned dependency update workflow with npm outdated, per-package update, test gate, audit gate, git diff on integrity hashes; quick audit checklist (10 items). SkillAudit grade impacts: no package-lock.json CRITICAL −20, active HIGH/CRITICAL CVEs CRITICAL −18, npm install in CI HIGH −16, typosquat risk within edit-distance 2 HIGH −14, unexpected postinstall scripts HIGH −12, no npm audit in CI MEDIUM −10, unbounded version ranges MEDIUM −8. Answers queries like "MCP server supply chain security", "npm lockfile integrity MCP", "typosquatting npm MCP server", "npm provenance attestation MCP", "how to block postinstall scripts npm", "npm audit CI pipeline MCP", "dependency confusion attack MCP server", "npm ci vs npm install security", "how to detect typosquatting npm", "secure npm install MCP server"): https://skillaudit.dev/blog/mcp-server-supply-chain-security/
- Security guide (2026-06-18, MCP server behavioral intrusion detection — building a session anomaly detector from scratch: explains why static analysis and input validation catch only the vulnerabilities baked into the code at rest and why runtime behavioral detection is needed for attacks that unfold during live sessions (prompt-injection-driven tool abuse, late privilege escalation after session hijacking, automated scraping via tool velocity, tool-chain exfiltration sequences); introduces the four behavioral signals worth measuring: call velocity (sliding-window timestamps, not calendar-minute buckets), tool sequence (last-20 ring buffer + successor pair tracking), first-time privilege escalation, and argument entropy (Shannon entropy on strings >32 chars for detecting base64 in-band exfiltration encoding); SessionRecord data structure with O(1) access for all scoring rules; anomaly-scorer.js with five weighted rules — velocity at 30/60/120 CPM thresholds (+5/+15/+40 points), error rate at 30%/60% thresholds (+8/+20), first-time privileged tool call within 5s of session start (+25) or after 5+ minutes of low-privilege calls (+15), high-entropy argument (entropy >4.5 bits/char = +10), known-bad sequence pair (readFile→callUrl, readSecret→callUrl = +30); composite thresholds log at 10, alert at 40, block-and-clear-session at 80; behavioralIDS middleware wrapper with handler-first ordering (execute then score); rationale for handler-first: error is itself a signal; exception for velocity-critical (pre-execution velocity check since DoS risk outweighs diagnostic value); first-privileged-tool signal explained in depth (legitimate workflows declare tool needs in first few calls; late escalation characteristic of prompt injection redirecting agent to new objective); sliding-window velocity implementation justification (calendar-minute counters allow burst-straddling 118 calls in 2 seconds below 60/min threshold; timestamps ring buffer gives accurate rate regardless of call timing); Shannon entropy threshold calibration (base64 ≈ 5.5–6 bits/char, ASCII text ≈ 3.5, threshold 4.5 reduces UUID false positives when schema type is checked); statistical exfiltration pair detection alternative (learn normal pairs from production traffic, flag pairs appearing in <0.1% of sessions); performance budget table (total overhead <1ms typical, <2ms worst-case; only variable-cost operation is entropy check which can be capped at first 512 bytes of large arguments); log-only mode deployment methodology for threshold calibration; score distribution targets (~85% sessions below 10, ~12% in 10-39, ~2.5% in 40-79, ~0.5% in 80+); complete server.js integration example. SkillAudit findings: CRITICAL −20 no session identity on tool calls (per-session baseline impossible), HIGH −16 no tool call logging at all (forensic analysis also impossible), HIGH −14 no tool privilege classification (privilege escalation signal eliminated), MEDIUM −10 no rate limiting at any layer, MEDIUM −8 session records not cleared on explicit logout. Answers queries like "MCP server behavioral intrusion detection", "how to detect prompt injection attacks MCP", "session anomaly detector Node.js", "sliding window rate limiting MCP server", "Shannon entropy exfiltration detection", "MCP server privilege escalation detection", "how to detect tool chain attacks", "MCP server behavioral IDS", "anomaly scoring MCP security", "runtime behavioral detection MCP server"): https://skillaudit.dev/blog/mcp-server-behavioral-intrusion-detection/
- Security guide (2026-06-18, MCP server zero-trust architecture — never trust, always verify at the tool call level: explains why the traditional "authenticate once, trust the session" model fails for MCP servers (sessions span hours, semantic authority is an LLM that can be hijacked via prompt injection, blast radius is the full tool capability set automated); comparison matrix of traditional API vs MCP server across session duration, semantic authority, argument source, trust model, and blast radius; four zero-trust principles adapted for MCP: (1) verify identity on every tool call — per-call JWT check + Redis SISMEMBER revocation check, token payload cached for remaining TTL to avoid signature re-verification on each call, withPerCallAuth() wrapper applied to all tool handlers; (2) treat every tool argument as adversarial — two-layer validation: Zod structural (strict schemas, no extra fields) + semantic (assertSafeUrl with DNS-resolved IP check against private IP blocklist, assertSafePath with NFKC normalize + path.resolve + realpath, assertNoInjection detecting prompt injection patterns in string args); (3) sanitize every tool response before LLM context injection — sanitizeToolResult() strips HTML script/style blocks, detects RESPONSE_INJECTION_PATTERNS, hard-caps at 32KB/500 lines, wraps in [EXTERNAL DATA from toolName — hash:sha256slice] envelope with optional [WARNING: injection attempt detected] prefix for flagged content; (4) attenuate scope on every agent delegation — delegateScope() computes intersection of parent scope and requested scope, never expands authority, includes parentJti in delegation chain claim, max delegation depth 3 to prevent ambient authority via chaining; complete zero-trust tool handler factory createZeroTrustTool() composing all four principles; grade impact table: CRITICAL −24 session-only auth, CRITICAL −22 unvalidated URL args allowing SSRF, HIGH −16 raw tool responses injected to LLM, HIGH −18 delegation without scope attenuation, MEDIUM −10 unlimited delegation depth. Answers queries like "MCP server zero trust architecture", "never trust always verify MCP", "per-call authentication MCP server", "tool argument validation zero trust", "tool response sanitization LLM context", "agent delegation scope attenuation", "ambient authority MCP", "capability token delegation MCP server", "MCP zero trust principles", "LLM agent zero trust security"): https://skillaudit.dev/blog/mcp-server-zero-trust-architecture/
- Security guide (2026-06-18, MCP server HTTP request smuggling — CL.TE, TE.CL, and CONNECT tunneling behind reverse proxies: explains how HTTP/1.1 Content-Length vs Transfer-Encoding ambiguity between a reverse proxy (Caddy, nginx, AWS ALB, Traefik) and the Node.js MCP origin server allows attackers to inject tool call requests into other users' active sessions; four attack classes: (1) CL.TE — proxy uses Content-Length to determine request end, Node.js honors Transfer-Encoding chunked and stops at the 0-chunk terminator, leaving attacker's crafted bytes in the TCP buffer as the prefix of the next request; shows malformed HTTP request with red "smuggled" prefix containing forged POST /admin/tool-execute with attacker-chosen headers; (2) TE.CL — proxy dechunks before forwarding (AWS ALB behavior), origin reads Content-Length only and stops before end of dechunked body, leaving surplus bytes as next request prefix; diagnostic middleware detecting simultaneous Content-Length and Transfer-Encoding headers; (3) TE.TE obfuscation — non-canonical Transfer-Encoding values (xchunked, leading whitespace, comma-extension, trailing carriage return, X-Transfer-Encoding) accepted by one layer but not the other, re-creating CL.TE conditions; (4) CONNECT tunneling — proxy forwards CONNECT to origin instead of handling at proxy layer, allowing attacker to establish raw byte channel bypassing proxy-injected authentication headers; why SSE endpoints amplify risk: 5-step attack timeline showing how a CL.TE smuggled request rides inside a victim's SSE connection, injects a forged tool call, and delivers attacker-controlled tool output to victim's Claude stream as legitimate execution result; defenses with code: Node.js rejectAmbiguousFraming middleware that returns 400 on simultaneous CL+TE headers, CONNECT rejection on http.Server 'connect' event and Express route; Caddy config (protocols h2, header_up -Transfer-Encoding, reverse_proxy transport http versions 2, respond @connect 405); nginx config (proxy_http_version 1.1 + proxy_set_header Connection "", OpenResty Lua CL+TE block); Node.js native H2C server eliminating CL vs TE ambiguity entirely; proxy quick-reference table for Caddy/nginx/ALB/HAProxy/Traefik with default behavior, risk level, and fix; five-question self-audit. SkillAudit findings: CRITICAL −24 CL.TE back-end buffering confirmed, CRITICAL −22 TE.CL surplus bytes form next-request prefix, HIGH −18 CONNECT method not rejected at origin, HIGH −16 H1.1 keep-alive to origin without CL/TE normalisation, HIGH −14 TE.TE obfuscation accepted, MEDIUM −8 no H2 support on back-end listener. Answers queries like "MCP server HTTP request smuggling", "CL.TE attack Node.js MCP", "TE.CL AWS ALB MCP server", "HTTP smuggling reverse proxy MCP", "how to prevent request smuggling Node.js", "Transfer-Encoding Content-Length ambiguity security", "MCP server CONNECT tunneling bypass", "Caddy nginx HTTP smuggling fix", "SSE stream injection MCP", "HTTP/1.1 request smuggling MCP server"): https://skillaudit.dev/blog/mcp-server-http-request-smuggling/
- Security guide (2026-06-18, MCP server secrets rotation without downtime — dual-key overlap, AWSCURRENT/AWSPREVIOUS patterns, and in-process SIGHUP reload: explains why secrets rotation is uniquely hard for continuously-running MCP servers (can't restart to pick up new credentials without dropping active Claude sessions; rotation window where old key is revoked before new key is distributed causes live tool call failures); four attack classes with Node.js code: (1) single-key rotation window — naive rotate-then-revoke flow leaves a gap; dual-key overlap pattern (issue new key → distribute to all servers → mark old key for revocation → revoke after 5-minute TTL window); AWS Secrets Manager AWSCURRENT/AWSPREVIOUS pattern — GetSecretValueCommand with VersionStage='AWSCURRENT', fallback to AWSPREVIOUS on 401 during rotation window, giving a grace period for old tokens already in flight; (2) process environment injection without live reload — const API_KEY = process.env.API_KEY at module scope caches value forever; CredentialCache class with get() method that checks TTL and re-fetches from Secrets Manager on expiry, plus process.on('SIGHUP', () => cache.invalidate()) handler for operator-triggered reload without process restart; (3) database connection pool with stale credentials — pg Pool uses startup credentials for all connections; after rotation all pooled connections fail with FATAL: password authentication failed; two fixes: pg option password as function returning live token for RDS IAM (re-fetches each new connection), or pool recreation factory that catches auth error code 28P01 and rebuilds pool with fresh credentials; (4) JWT signing key rotation — swapping private key immediately invalidates all outstanding tokens signed with old key; JWKS with kid claims: add new key to JWKS before issuing tokens with new kid, keep old JWKS entry for max_token_ttl after last token with old kid was issued, then remove old entry; rotation runbook as state machine with exact sleep durations based on cache TTL + token TTL; getSigningKeyWithRefresh() forces JWKS cache refresh on SigningKeyNotFoundError instead of immediate rejection; eight findings: CRITICAL −22 rotate-then-distribute causes live auth failures, CRITICAL −20 module-scope cached credentials with no reload, HIGH −16 database pool stale credentials, HIGH −14 no AWSPREVIOUS fallback, HIGH −12 JWKS rotation without overlap window, HIGH −10 no SIGHUP handler for credential reload, MEDIUM −8 connection pool not recreated on auth failure, MEDIUM −6 no credential TTL; five-question self-audit with grep commands for VersionStage, SIGHUP, and JWKS kid overlap detection. Answers queries like "MCP server secrets rotation", "rotate secrets without downtime MCP", "AWSCURRENT AWSPREVIOUS MCP server", "how to reload credentials without restart Node.js", "SIGHUP credential refresh Node.js", "database connection pool password rotation", "JWKS key rotation without downtime", "MCP server credential cache TTL", "AWS Secrets Manager rotation MCP", "dual-key overlap pattern Node.js"): https://skillaudit.dev/blog/mcp-server-secrets-rotation/
- Security guide (2026-06-18, MCP Server SSTI deep dive — Handlebars sandbox escapes, Nunjucks template injection, and EJS RCE in LLM tool handlers: explains why SSTI in MCP tool handlers is uniquely dangerous compared to web apps (the LLM is the injection intermediary — prompt injection delivers SSTI payloads from any data source the agent reads; attacker achieves RCE without sending a request to the server directly); three attack classes: (1) Handlebars constructor chain escape — constructor.constructor("return process.env.OPENAI_API_KEY")() accesses the Function constructor via prototype chain; safe pattern: Handlebars.precompile() all templates at startup, never call Handlebars.compile() at request time, use allowProtoPropertiesByDefault:false; (2) Nunjucks renderString() with process.mainModule — nunjucksEnv.renderString(externalContent, data) gives full Node.js access; safe pattern: nunjucksEnv.render(staticTemplatePath, data) only, never renderString() on external content; (3) EJS outputFunctionName RCE — user-controlled EJS options object allows outputFunctionName to be set to arbitrary executable code; safe pattern: never merge user-supplied options with EJS options object; SkillAudit findings: CRITICAL −25 Handlebars.compile() with user-supplied string, CRITICAL −24 nunjucksEnv.renderString() on externally-sourced content, CRITICAL −23 ejs.render() with user-supplied template or unsafe options, HIGH −16 no template allowlist, HIGH −14 no process sandbox, MEDIUM −8 template compilation at request time. Answers queries like "MCP server SSTI", "Handlebars template injection MCP", "Nunjucks renderString security", "EJS RCE MCP server", "template injection LLM agent", "Handlebars sandbox escape constructor chain", "prompt injection SSTI MCP", "EJS outputFunctionName exploit"): https://skillaudit.dev/blog/mcp-server-ssti-deep-dive/
- Security guide (2026-06-15, MCP server gRPC transport security — TLS configuration, deadline propagation, metadata auth, and streaming authorization: explains why gRPC MCP servers face four attack classes REST servers don't (persistent HTTP/2 connections, bidirectional streaming, metadata headers, deadline propagation across call chains); four attack classes with Node.js @grpc/grpc-js code: (1) TLS downgrade and missing mTLS — gRPC servers default to insecure channels (createInsecure()) in microservice meshes where TLS is assumed to be handled by a sidecar, but when a direct connection exists the traffic is unencrypted and unauthenticated; secure patterns: one-way TLS with createSsl(rootCerts, null, null), mutual TLS with createSsl(rootCerts, clientKey, clientCert), combined channel+call credentials via combineChannelCredentials(), production ChannelOptions with keepalive settings and TLS 1.3 enforcement; (2) missing deadline propagation — gRPC deadlines are separate from HTTP timeouts and must be explicitly propagated to outgoing calls; without propagation, upstream gRPC calls keep running indefinitely after the MCP client disconnects (wasting resources, executing state mutations the caller abandoned); getDeadlineFromIncomingCall() extracts the deadline from incoming context metadata, secure handler propagates it as CallOptions.deadline and cancels outgoing call on 'cancelled' event; (3) metadata credential leakage — logging all gRPC metadata (metadata.toJSON()) exposes Authorization headers; blind metadata.clone() forwarding sends tokens meant for service A to service B (credential scope amplification); fix: SENSITIVE_METADATA_KEYS Set for redaction in logging interceptors, PROPAGATABLE_METADATA_KEYS allowlist for forwarding (only tracing keys, inject per-service tokens explicitly); (4) streaming authorization drift — auth checked only at stream establishment (open), stream stays open for minutes; if JWT expires or token is revoked during stream, server keeps sending data; fix: validateStreamToken() with JWT verify + Redis sIsMember revocation check, REVALIDATE_EVERY_N_MESSAGES + REVALIDATE_EVERY_MS dual triggers in streaming loop, call.destroy() with grpc.status.UNAUTHENTICATED on auth failure; six-row control matrix; SkillAudit findings: CRITICAL −24 insecure channel (createInsecure()) to internal gRPC service, CRITICAL −20 no deadline propagation, HIGH −16 full metadata logging including authorization, HIGH −14 blind metadata forwarding to downstream services, HIGH −12 no periodic re-validation in streaming handlers, MEDIUM −8 server reflection enabled in production; five-question self-audit. Answers queries like "gRPC MCP server security", "grpc-js TLS configuration MCP", "gRPC mTLS Node.js", "gRPC deadline propagation MCP server", "gRPC metadata auth security", "gRPC streaming authorization Node.js", "how to secure gRPC MCP server", "gRPC server reflection disable production", "gRPC credential leakage metadata", "how to propagate gRPC deadline in Node.js"): https://skillaudit.dev/blog/mcp-server-grpc-transport-security/
- Security guide (2026-06-15, MCP server GraphQL security — introspection abuse, batch query DoS, field-level authorization bypasses, and query complexity: explains why GraphQL exposes a wider attack surface than REST MCP servers (single endpoint accepts arbitrary queries that can enumerate the schema, recurse to arbitrary depth, alias hundreds of operations into one request, and reach sensitive fields through multiple type paths with different access controls); four attack classes with Node.js defenses: (1) introspection disclosure — the __schema query returns every type, field, argument, enum value, and relationship in one request; NoSchemaIntrospectionCustomRule + introspection:false closes it; why not to rely on NODE_ENV inference for introspection gating; (2) query depth DoS — recursive schema traversal triggers exponential database calls; graphql-depth-limit depthLimit(7) rejects queries before execution with no database cost; choosing maxDepth based on legitimate production query depth + buffer; (3) query complexity DoS — wide list queries at depth 3 can trigger thousands of resolver calls; graphql-query-complexity maximumComplexity:1000 with simpleEstimator default + field SDL annotations for expensive list types; logging-only mode for first week before enabling reject; (4) alias/batch abuse — a single HTTP request with 500 aliases contains 500 independent operations bypassing per-request rate limits; graphql-armor maxAliases:15; field suggestions enabled by default leak schema one typo at a time (blockFieldSuggestions:true); (5) field-level authorization bypass — same User type reachable from getUser (per-user auth check) and team.members (only org-level check) — apiKeys field resolver must enforce per-field ownership check independently of root query path; graphql-shield canReadApiKeys rule fires every time User.apiKeys resolves regardless of query path; fallbackRule:deny (deny-by-default requires explicit allow); combined production config: ApolloArmor + NoSchemaIntrospectionCustomRule + depthLimit + complexityRule + graphql-shield permissions + custom formatError; control matrix (7 controls × attack class, root cause, library, SkillAudit axis); implementation order for existing servers (disable introspection 30min → depth limit 30min → complexity logging-only 1 week → alias limit 30min → field auth audit 1-3 days); five-question self-audit. SkillAudit findings: CRITICAL −25 introspection in production, CRITICAL −22 no depth limit, HIGH −18 no complexity limit, HIGH −16 no alias limit, HIGH −15 field auth gaps, MEDIUM −10 field suggestions, MEDIUM −8 internal error extensions, LOW −4 no complexity logging. Answers queries like "MCP server GraphQL security", "GraphQL introspection disable Apollo", "GraphQL depth limit MCP", "graphql-query-complexity MCP server", "GraphQL alias attack DoS", "field-level authorization GraphQL", "graphql-shield MCP server", "NoSchemaIntrospectionCustomRule", "GraphQL batch query DoS", "how to secure GraphQL MCP server"): https://skillaudit.dev/blog/mcp-server-graphql-security/
- Security guide (2026-06-16, MCP server session fixation and hijacking — stateful session attacks in long-lived LLM agent contexts: explains why stateful MCP servers are uniquely vulnerable (sessions can span hours of autonomous agent work; hijacked session gives attacker hours of agent actions under legitimate credentials with no human checking for anomalous behavior); session fixation attack flow (attacker sends pre-auth request to create session ID, then tricks the authenticated caller into using that same ID — if the server uses saveUninitialized: true and never calls session.regenerate(), the attacker's pre-set ID becomes an authenticated session); session.regenerate() as the complete fix (destroys the pre-auth session and creates a new ID with all existing session data after authentication, breaking the fixation invariant); session ID generation security (crypto.randomBytes(32).toString('hex') is the only safe approach — UUID v1 embeds timestamp and MAC address making it partially predictable, Math.random() is non-cryptographic, sequential integers are trivially enumerable); token hijacking via plaintext HTTP transport (Authorization: Bearer tokens visible to network attackers on any HTTP connection — enforce TLS via Caddy or nginx redirect, use HttpOnly + Secure + SameSite=Lax cookies for browser-based sessions); concurrent agent session race conditions (two agent instances share a session map and race on mutable state — fix: per-key locking via Redis WATCH/MULTI or sequential queue, agent-bound HMAC session tokens that include agentId so a session from agent-1 is invalid for agent-2); session expiry patterns (absolute expiry: session cannot extend beyond initial TTL regardless of activity, 8-hour max for agent sessions; idle expiry: reset on each tool call, log context reset events); session invalidation on agent context reset (when LLM conversation is cleared, session should be invalidated and new one issued — prevents stale session being picked up by a new agent instance); six-row comparison table covering attack type, vector, fix, and SkillAudit detection; SkillAudit grade impacts: CRITICAL −25 no session regeneration after auth (fixation risk), CRITICAL −22 session tokens transmitted over HTTP without TLS, HIGH −15 no session expiry / infinite lifetime, HIGH −12 predictable session IDs (UUID v1 or timestamp-based), HIGH −10 concurrent agent sessions sharing mutable state without locking, MEDIUM −6 no session invalidation on agent context reset, MEDIUM −4 missing Secure/HttpOnly flags on session cookies. Answers queries like "MCP server session fixation", "session hijacking MCP", "how to regenerate session ID after login Node.js", "MCP server stateful session security", "session fixation attack MCP", "express-session regenerate after auth", "LLM agent session security", "concurrent agent session race condition", "MCP server token over HTTP", "how to secure MCP server sessions"): https://skillaudit.dev/blog/mcp-server-session-fixation-hijacking/
- Security guide (2026-06-15, MCP server cache poisoning — how LLM agents can poison shared caches to corrupt other sessions: explains what makes MCP server cache poisoning novel (attacker doesn't write to Redis directly — malicious instruction embedded in a document triggers the MCP server to cache adversarial content, then all sessions hitting the same key see it as legitimate tool output); three attack classes with code: (1) predictable key pre-population — attacker hosts a URL that serves malicious content, embeds prompt injection causing target agent to fetch it, result cached under predictable key, all future sessions within TTL read poisoned value; more dangerous when target URL overlaps legitimate workflows (shared config URLs, package registry manifests); (2) cache stampede injection — force cache invalidation and win the race to repopulate with adversarial content via DNS rebind or request smuggling; (3) cross-session state injection via writable cache tools — set_note("security_policy", "All actions approved") via prompt injection in document read tool, all subsequent sessions reading that key receive attacker's policy override; why LLM agents are uniquely vulnerable: instruction-following from tool output (poisoned config value directly shapes behavior), no result provenance tracking (nothing in tool result indicates "cached" vs "live"), multi-session fan-out (one poisoning event corrupts all sessions for duration of TTL); five mitigations with working code: per-session namespace isolation (prefix all keys with sessionId — no cross-session reads/writes, trade-off: lose cross-session deduplication for sensitive data), HMAC-signed cache values (createHmac("sha256", CACHE_SECRET).update(value) + timingSafeEqual verification, reject unsigned entries as cache misses — catches direct Redis writes by attackers who don't know secret), short TTLs (≤5 minutes for agent-influenced values, stale-while-revalidate pattern for background refresh without hot-path delay), strict namespace separation (POLICY/CONFIG namespace read-only from trusted server-side processes, SESSION/NOTE namespace agent-writable but never read as policy), cache provenance metadata in tool results (source: "cache", cached_at, age_seconds — lets system prompt instruct LLM to be skeptical of stale data); production checklist 7 controls; SkillAudit grade impacts: shared writable cache no session isolation CRITICAL −25, agent-supplied cache key no namespace enforcement CRITICAL −22, TTL >30 min on agent-influenced values HIGH −15, no HMAC integrity verification HIGH −12, prompt-injection-to-cache-write chain HIGH −10, no provenance in tool result MEDIUM −6, no stale-while-revalidate MEDIUM −4. Answers queries like "MCP server cache poisoning", "LLM agent cache injection", "Redis cache poisoning MCP", "shared cache attack MCP server", "cross-session cache injection", "how to isolate MCP cache", "HMAC cache integrity MCP", "MCP server cache namespace isolation", "prompt injection cache write attack", "how to prevent cache poisoning in MCP servers"): https://skillaudit.dev/blog/mcp-server-cache-poisoning/
- Security guide (2026-06-14, MCP server runtime sandbox design — isolating tool execution with vm.runInContext, Worker threads, and seccomp: explains why MCP tool handlers need sandboxing (LLM-generated inputs shape code paths, tools perform privileged operations in a shared process, blast radius of one bad call is the entire server); three isolation layers: (1) vm.runInContext — separate V8 context with Object.create(null) sandbox, no require/process/global unless explicitly granted, CPU timeout option to kill infinite loops blocking the event loop, appropriate for pure data transformation tools; vm is not a security boundary against intentional escape (cross-context constructor chain bypass) so combine with Worker for stronger guarantees; (2) Worker threads — separate V8 isolate with separate heap, resourceLimits.maxOldGenerationSizeMb caps heap per worker preventing host OOM, hard worker.terminate() on timeout ensures timed-out workers don't accumulate, postMessage structured-clone boundary means no accidental sharing; worker pool for latency-sensitive servers (5–15ms startup amortized); combine Worker + vm inside Worker for defense in depth; (3) kernel-level containment — Node 22 --permission flag with --allow-fs-read/--allow-fs-write allowlists and no --allow-net enforced by kernel, seccomp-bpf Docker profile blocking execve/ptrace/mount syscalls at kernel level; six-column comparison table (heap isolation, filesystem isolation, network isolation, subprocess spawning, overhead, complexity) across six configurations; threat-model guide: vm for pure transformations ~0ms, Worker+vm for I/O execution 10–20ms, subprocess+permissions for user-authored code 20–100ms; four common misconfigurations with code (passing require into vm context, no timeout, non-string code input, missing worker.terminate() on timeout); seven-step production checklist. SkillAudit grade impacts: eval no sandbox CRITICAL −25, require in vm context CRITICAL −20, no CPU timeout HIGH −12, no Worker resourceLimits HIGH −10, Worker not terminated on timeout HIGH −8, non-string input to vm MEDIUM −5, fetch in sandbox context MEDIUM −5. Answers queries like "MCP server sandbox", "vm.runInContext security", "Node.js Worker thread isolation MCP", "how to sandbox eval MCP server", "seccomp MCP server", "Node 22 permission flag MCP", "MCP server execution isolation", "Worker thread resource limits Node.js", "vm sandbox escape prevention", "how to isolate tool execution MCP"): https://skillaudit.dev/blog/mcp-server-runtime-sandbox-design/
- Security guide (2026-06-14, MCP server WebSocket security in depth — authentication at upgrade time, message framing attacks, and connection lifecycle: explains why WebSocket breaks the HTTP security model for MCP servers (single upgrade request, no CORS enforcement, cookies sent on upgrade, auth happens once and persists for hours, rate limiting must span connection lifetime); cross-site WebSocket hijacking (CSWSH) — browser page at attacker.com can open a full bidirectional channel using the victim's cookies because WebSocket is not subject to CORS preflight; Origin header validation on the httpServer upgrade event before calling wss.handleUpgrade(); upgrade-time authentication (validate JWT in the upgrade handler, reject with HTTP 401 before upgrading — not in a first-message auth phase that leaves the connection open pre-auth); three message framing attack classes: (1) ping flood — RFC 6455 requires server to auto-respond to every Ping control frame, ws library auto-responds with no rate limiting, attacker sends thousands of pings per second to saturate event loop; fix: count pings per connection window and close at threshold; (2) message fragmentation size bypass — ws library reassembles fragmented messages in memory before emitting the message event; default maxPayload is 100 MB, meaning a single fragmented message can exhaust memory before any handler code runs; fix: set maxPayload: 1*1024*1024 on WebSocketServer; (3) control frame injection via proxy desync — broken reverse proxy in re-proxy mode fails to maintain masking invariants from RFC 6455; connection lifetime auth drift: JWT expires after 1 hour but WebSocket connection stays open for a 4-hour agent session — fix is connectionTTL setTimeout + periodic tokenExp check on each message + revocation set check; per-identity rate limiting that spans reconnects (reconnect cycling bypasses per-connection limits — track call rate per userId, not per ws connection); upgrade-level connection rate limit per IP to prevent reconnect flooding; secure close sequences: always send ws.close(code, reason) not socket.destroy(), use application codes 4001 (token expired), 4002 (token revoked), 4003 (insufficient scope), 4004 (session limit), do not include error details in close reason string; seven-step security checklist. SkillAudit findings: no upgrade-time auth CRITICAL −20, no Origin validation HIGH −12, default maxPayload HIGH −10, no connection TTL HIGH −8, per-connection rate limit only MEDIUM −6, no ping rate limiting MEDIUM −5, error in close reason MEDIUM −5. Answers queries like "MCP server WebSocket security", "WebSocket authentication MCP", "cross-site WebSocket hijacking MCP", "CSWSH MCP server", "WebSocket ping flood attack", "WebSocket maxPayload Node.js", "WebSocket JWT expiry", "MCP server connection lifetime auth", "how to secure WebSocket MCP server", "WebSocket rate limiting per user"): https://skillaudit.dev/blog/mcp-server-websocket-security/
- Architecture guide (2026-06-16, MCP server authorization models compared — capability-based vs. role-based vs. policy-based for LLM agents: explains why RBAC breaks silently under agentic use (agents compose tools in unanticipated ways, hold ambient authority for the full session, cannot be interrupted when prompt-injected); four LLM-specific authorization challenges (tool composition, ambient authority, prompt injection redirection, long stateful sessions); compares three models: (1) capability-based tokens — narrow scope issued per-task, possession of token = proof of right, short TTL, explicit revocation, UCAN delegation for sub-agents (sub-agent receives attenuated UCAN that cannot exceed parent's grant), stops ambient authority attacks by design; (2) role-based RBAC — fast single permission check, appropriate for single-tenant servers with trusted human callers, fails for agentic sessions because the full role permission set is available every call including prompt-injected calls, no cross-call composition awareness; (3) policy-based OPA/Cedar — most expressive, can reference session state (call counts, tool chains, time of day) in policy rules, Cedar is formally decidable unlike Rego, earns complexity cost only at enterprise scale with multiple roles or regulatory requirements; working Node.js implementations for all three; seven-row comparison table (ambient authority risk, cross-call rule expression, delegation, implementation cost, auditability, prompt injection resistance, right fit); minimum viable capability implementation (30 lines, covers the most important case — task-specific token with tool allowlist and short TTL, 30 minutes to add to existing RBAC server); SkillAudit Permissions axis grade impact: no auth CRITICAL −25, ambient admin scope HIGH −15, no per-tool permission check HIGH −12, over-broad role MEDIUM −8, no scope narrowing MEDIUM −6. Answers queries like "MCP server authorization", "MCP server RBAC capability based", "capability token MCP server", "UCAN delegation MCP", "OPA MCP server authorization", "Cedar policy MCP", "LLM agent authorization model", "why RBAC fails for agents", "MCP server ambient authority", "how to restrict LLM agent permissions"): https://skillaudit.dev/blog/mcp-server-authorization-models/
- Engineering guide (2026-06-15, MCP server supply chain risk — how a compromised npm dependency becomes a compromised tool handler: explains why MCP servers are a high-value supply chain target (access to all credentials in process.env, tool arguments reveal agent context, default-open network egress); worked attack scenario tracing a compromised transitive dependency (fast-str@1.0.8) four levels deep that exfiltrates every credential-pattern env var to an attacker endpoint every 60 seconds with fire-and-forget HTTP; three MCP-specific attack vectors: (1) credential exfiltration via process.env scanning at module load time (standard 12-factor credential loading makes the full secret set available from first millisecond of process startup), (2) tool argument interception via compromised utility function — if string-utils.sanitize wraps a compromised package it intercepts raw tool arguments before validation, plus response tampering variant that appends LLM-influencing text to tool responses, (3) dependency confusion via unscoped internal package names published to public npm registry at higher versions; four controls: npm ci (lockfile-strict, not npm install), lockfile hash verification in CI (git diff --exit-code package-lock.json), npm audit --audit-level=high as required CI step, npm provenance attestation for direct dependencies (Sigstore-backed, links publish to specific CI run); complete GitHub Actions workflow enforcing all four controls; runtime egress monitoring via https.request monkey-patch logging unexpected outbound connections with call stack; assessment commands for tree size, postinstall script enumeration, audit output, and CI method detection; CycloneDX SBOM generation and diff-between-releases for dependency change tracking; SkillAudit grade impact table: no lockfile CRITICAL −20, npm install in CI HIGH −15, unresolved HIGH/CRITICAL audit findings HIGH −15 each, no audit step in CI MEDIUM −8, no SBOM MEDIUM −5. Answers queries like "MCP server npm dependency security", "MCP server supply chain attack", "compromised npm package MCP", "how does npm supply chain attack work", "postinstall script attack MCP", "MCP server dependency tree audit", "npm lockfile security MCP", "npm ci vs npm install MCP server", "MCP server provenance attestation", "how to secure npm dependencies MCP server"): https://skillaudit.dev/blog/mcp-server-supply-chain-risk/
- Engineering guide (2026-06-14, MCP server security monitoring and alerting — what to alert on, threshold calibration, and how to avoid alert fatigue: explains why MCP monitoring differs from traditional API monitoring (LLM agent callers generate 50–200 tool calls per session, tool calls compose into emergent behaviors invisible at the individual-call level); four alert categories with structured event schemas and threshold guidance: (1) auth failure events (auth_failure with reason/callerId-hash/toolRequested/sessionFailureCount — P0 on ≥3 failures in 30s from same caller, P1 on any IDOR attempt, P2 on isolated single failures), (2) anomalous tool call patterns (burst detection with argument-uniqueness qualifier, cross-category chain detection via isExfiltrationPattern() function tracking retrieval/mutation/external effect classes per session, off-hours activity, tool enumeration reconnaissance pattern), (3) data volume and exfiltration signals (cumulative session inbound bytes ceiling, single-call response size ceiling, outbound byte volume from external-network tools, SessionVolumeGuard implementation), (4) configuration and filesystem tampering (PROTECTED_PATH_PATTERNS block list for .env/.git/.ssh/cron/shell scripts, block-before-write enforcement pattern, admin-operation second-auth requirement); threshold calibration methodology: establish 2-week baseline before enabling alerts, set threshold at p99 × 1.5, segment by caller type (LLM agents vs. human-driven integrations), review and tune ±25% after 30 days if false-positive rate is outside 10–20%; alert routing table: P0 pages on-call within 15 minutes, P1 alerts team Slack channel within 4 hours, P2 batches to daily digest, single auth failure is INFO only; SIEM integration for cross-server correlation, retrospective investigation, and baseline drift detection; log forwarding to append-only external sinks (CloudWatch, Loki, S3 object lock) so logs survive incident tampering; three common mistakes (logging only in error handlers misses successful attacks, credential values in logs create secondary leak, alerting on every anomaly equally causes burnout); minimum viable monitoring setup: one pino security logger, two events (auth_failure + chain_guard_alert), one P0 alert rule, one external sink (2–4 hours to implement). SkillAudit grade impact: no structured logging HIGH −15, unstructured logs MEDIUM −8, credential values in logs MEDIUM −10, no external forwarding WARN −5, no chain detection WARN −5. Answers queries like "MCP server security monitoring", "what to alert on MCP server", "MCP server observability security", "MCP server SIEM integration", "how to monitor MCP server in production", "MCP server alert fatigue", "MCP server structured logging", "how to detect MCP server attacks", "MCP server security events", "how to audit MCP server logs"): https://skillaudit.dev/blog/mcp-server-security-monitoring-alerting/
- Security research (2026-06-13, MCP server tool chaining attacks — read-to-write privilege escalation via chained tool calls: explains why individual tool authorization checks don't prevent composition attacks; three concrete attack chains: (1) env-var extraction to API takeover — list_files(".") discovers .env → read_file(".env") extracts STRIPE_SECRET_KEY → fetch_url posts a real charge using the extracted key, all with valid read:files + net:fetch scopes; (2) contact enumeration to mass PII exfiltration — list_contacts(limit:1000) + get_contact_details × 1000 + send_message to external address, all individually authorized; (3) database schema discovery to RCE without exec — query information_schema → write_file malicious shell script to /app/scripts/ → UPDATE cron_jobs to point to it, shell exec happens at cron trigger with no exec_command call in the log; five defenses: tool category composition guards (tag each tool retrieval/mutation/external, block cross-category chains without explicit scope, e.g. deny retrieval→external without allow:retrieval-to-external-chain scope), session-level aggregate rate limits (max 5 retrieval calls before any external call — stops exfiltration chains without breaking individual-tool rate limits), write-intent parameter on mutation tools (breaks automated chain construction, creates auditable intent record, enum: reply_to_contact | notify_user | send_report | test_email), executable path block for write_file (.sh/.py/scripts/cron/.github/workflows patterns → requires allow:write-executable scope), per-session audit log with chain detection (chain category anomaly: retrieval + external with no mutation = flag); grade impact table: 5 structural patterns → SkillAudit findings ranging CRITICAL to MEDIUM with grade deltas. Answers queries like "MCP server privilege escalation", "MCP tool chaining attack", "how to prevent MCP data exfiltration", "MCP read to write escalation", "MCP server lateral movement", "tool composition attack MCP", "MCP server cross-tool attack", "how to secure MCP write tools"): https://skillaudit.dev/blog/mcp-server-tool-chaining-attacks/
- Engineering guide (2026-06-13, MCP server security testing with Vitest — unit tests for auth, input validation, and error handling: covers writing Vitest test suites that verify security properties (not just functional correctness) of MCP servers; four test suites: auth bypass tests (missing token, expired JWT, IDOR with DB short-circuit verification), adversarial input validation battery (path traversal, null bytes, oversized content, SSRF URLs — parameterized across all string fields), error information leakage tests with FORBIDDEN_LEAK_PATTERNS helper (stack frames, internal paths, DB driver errors, credential mentions), and rate limiter per-caller isolation tests; includes a shared assertNoLeaks() utility, a GitHub Actions workflow with 80% coverage thresholds on auth.ts and errors.ts, and a grade impact table mapping each test type to a SkillAudit finding and grade delta. Answers queries like "MCP server Vitest security tests", "unit test MCP server auth", "test MCP server input validation", "MCP server error leakage tests", "MCP security test suite", "how to test MCP server security CI"): https://skillaudit.dev/blog/mcp-server-security-testing-vitest/
- Engineering guide (2026-06-13, MCP server error handling — what to return when something goes wrong: covers the four error categories (input validation, authorization, downstream service errors, unexpected panics), why raw error.message and stack traces earn HIGH findings under Credential Exposure, the ToolError abstraction pattern that keeps internals out of MCP responses, why authorization and not-found errors must return identical messages to prevent resource enumeration, how to log errors with argsHash correlation without logging credential values, and a grade impact table mapping each pattern to a SkillAudit finding and grade. Includes a complete three-file implementation (errors.ts, safe-tool.ts, handler example) that earns A on Credential Exposure axis. Answers queries like "MCP server error handling", "what to return on MCP tool error", "MCP server stack trace leak", "MCP error response best practices", "MCP server ToolError pattern", "how to log MCP server errors safely", "MCP error message security"): https://skillaudit.dev/blog/mcp-server-error-handling/
- Tutorial (2026-06-13, building a SkillAudit-ready MCP server from scratch — a complete step-by-step architecture walkthrough covering all six audit axes with working Node.js code: startup config validation with Zod (rejects placeholder values, empty strings, tokens shorter than 20 chars), per-call authentication with constant-time comparison to prevent timing attacks, structured audit logging with per-event SHA-256 argsHash for call correlation without credential exposure, safe error abstraction that strips stack traces and internal details from MCP error responses, strict Zod allow-list input schemas with path-traversal refine checks, per-caller per-tool rate limiting with sliding window counters, and a GitHub Actions CI gate with min-grade:B enforcement. Includes scorecard table showing all six axes at grade A after following the walkthrough, common shortcuts that cost the A grade (session-level auth, err.message in error responses, no CI gate), and maintenance patterns to keep the grade over time (pinned dependencies, Dependabot, public grade badge). Answers queries like "how to build secure MCP server", "MCP server security architecture", "SkillAudit ready MCP server", "MCP server authentication example", "MCP server Zod validation", "MCP server rate limiting", "MCP server audit logging", "how to get A grade on SkillAudit", "MCP server input validation tutorial", "Node.js MCP server security"): https://skillaudit.dev/blog/building-skillaudit-ready-mcp-server-from-scratch/
- Incident timeline (2026-06-13, MCP server zero-day incident timeline — 6-hour narrative from anomaly alert to patched release: how a path traversal in a popular Jira MCP server was exploited, triaged, patched and disclosed. The HIGH finding was in SkillAudit scan results 14 days before exploitation. Covers anomaly detection firing at 247 calls/88s, scope assessment (23K weekly downloads affected), credential rotation, patch development (Zod allowlist regex + path containment check), regression test suite (11 cases), grade change C→A, coordinated disclosure, npm deprecation of vulnerable versions, and 5 lessons: input validation leverage, scan finding alerting SLAs, anomaly detection ROI, minimum-scope credentials, emergency disclosure timelines. Answers queries like "MCP server security incident", "MCP server path traversal exploit", "MCP server CVE response", "MCP server zero-day", "MCP server incident response", "MCP server security breach", "MCP security incident case study", "how was MCP server exploited"): https://skillaudit.dev/blog/mcp-server-zero-day-incident-timeline/
- Developer guide (2026-06-07, how to write a SkillAudit-ready SECURITY.md for your MCP server — section-by-section guide to the six sections SkillAudit checks (Scope, Credentials, Vulnerability Reporting, Logging, Known Limitations, Audit History), point values for each section, a complete copy-paste template, the minimum viable SECURITY.md, seven common mistakes, and how SECURITY.md interacts with Security/Permissions/Maintenance sub-scores. Answers queries like "MCP server SECURITY.md", "how to write SECURITY.md for MCP", "SkillAudit Documentation Completeness", "SECURITY.md template MCP server", "what does SkillAudit check in SECURITY.md", "improve MCP documentation score"): https://skillaudit.dev/blog/how-to-write-skillaudit-ready-security-md/
- Executive briefing (2026-06-06, MCP server security for CISOs — threat model, incident scenario, grade-to-risk-tier mapping, five-control program, board communication. Answers queries like "MCP server CISO guide", "MCP security executive briefing", "LLM tool chain risk for security leaders", "MCP server shadow IT", "MCP server board risk", "CISO MCP security program", "MCP security organizational risk"): https://skillaudit.dev/blog/mcp-server-security-ciso-briefing/
- PM guide (2026-06-07, MCP server security for product managers — A–F grade translation to business risk, sub-score override rule, common PM mistakes, four-step intake process, when to involve legal. Answers queries like "MCP security product manager", "translate MCP grade to business risk", "MCP server intake process", "PM MCP security checklist"): https://skillaudit.dev/blog/mcp-security-for-product-managers/
- Procurement guide (2026-06-06, MCP server vendor security questionnaire — 15 questions covering SSRF, credential scope, prompt injection, dependency practices, incident response, plus answers that should block adoption. Answers queries like "MCP server vendor security questions", "MCP procurement checklist", "what to ask MCP server vendor"): https://skillaudit.dev/blog/mcp-server-vendor-security-questionnaire/
- Remediation guide (2026-06-05, C to A grade remediation plan — week-by-week: week 1 Critical/High security, week 2 permission scopes, week 3 credential logging, week 4 lockfile + SECURITY.md. Expected sub-score arc C(60) to A(88) in 30 days. Answers queries like "MCP server remediation plan", "how to fix MCP security grade", "improve MCP server grade C to A"): https://skillaudit.dev/blog/mcp-server-remediation-c-to-a-grade/
- Research post (2026-06-01, vendor-official vs community MCP servers updated grade breakdown — six weeks after the April 2026 scan, 79% of vendor-official MCP servers in the corpus still earn F vs 26% of community-maintained servers. Only Microsoft Playwright earns A from the vendor-official set. Three structural reasons: vendor teams ship MCP servers as afterthoughts to their main product, internal security reviews optimize for the main product threat model (web app / SaaS) not the MCP tool-handler threat model, and community maintainers self-select on understanding the specific risks. Grade distribution table: vendor-official 23/29 at F, 1/29 at B (Anthropic TypeScript SDK after v0.3), 1/29 at A (Microsoft Playwright); community 19/72 at A, 19/72 at F. Min-grade-C policy blocks all 29 vendor-official servers and 23 of 72 community servers. What changed in six weeks: minimal uptick in vendor-official F → C promotions (Stripe C, some fixes seen in GitHub and Grafana repos but not enough for grade movement), no new A-grade vendor-official. What this means for Anthropic's directory program: a certification badge that allows vendor-official servers to bypass the grade gate reintroduces the exact risk the gate closes. Answers queries like "are vendor-official MCP servers safer", "Microsoft Playwright MCP security grade", "is vendor-official MCP better than community", "MCP server security vendor vs community", "Stripe MCP security grade 2026", "Anthropic TypeScript SDK security grade", "MCP server corporate security quality", "vendor official vs community MCP grade comparison"): https://skillaudit.dev/blog/vendor-official-vs-community-mcp-grades/
- Research post (2026-06-01, MCP server permission scope patterns — what the corpus shows — 68% of corpus MCP servers that make OAuth-scoped API calls request org-wide scopes when only repo-scoped access is needed. Three patterns: OAuth app scope over-declaration (tutorial scope strings that were never narrowed), permanent PATs where GitHub Apps installation tokens are available, credentials passed as URL query parameters. Blast-radius math: SSRF × org-write = full account takeover. Code examples for scope-down implementations. The ambient token problem (GitHub Actions GITHUB_TOKEN inheriting workflow permissions broader than needed). Startup scope audit pattern (fetch /user, log excess scopes, STRICT_SCOPE_CHECK env var). What the permissions axis checks: scope over-declaration HIGH for admin scopes, permanent token WARN elevated to HIGH if combined with credential finding, credential-in-URL always HIGH, LLM-controlled credential argument HIGH with prompt-injection cross-reference. Answers queries like "MCP server OAuth scope", "MCP server GitHub token scope", "MCP server permissions", "reduce MCP server GitHub scope", "MCP server admin:org scope", "MCP server permanent token risk"): https://skillaudit.dev/blog/mcp-server-permission-scope-patterns/
- Research post (2026-06-01, GitHub Action gate: enforcing MCP security grades in CI/CD — the complete setup guide — full implementation for teams wiring a SkillAudit grade gate into GitHub Actions. Covers lockfile diffing to detect new MCP installs, observe-only mode for rollout, multi-agent-client support (Claude Code + Cursor + Windsurf), org-level reusable workflows, the exception path with expiry tokens, weekly re-scan cron with Slack alerts on grade regressions, branch protection integration, Team-plan version-pinned grade endpoint. Three complete workflow YAML files, copy-paste ready. Answers queries like "GitHub Action MCP security gate", "CI gate for Claude plugins", "automate MCP server security check", "enforce MCP grade in CI"): https://skillaudit.dev/blog/github-action-mcp-security-gate/
- Buyer guide (2026-05-31, how to read a SkillAudit report — field guide to every section: six axis grades explained (Security, Credentials, Permissions, Maintenance, Compatibility, Documentation), when HIGH vs WARN vs PASS vs INFO applies, install-gate decision framework for team leads, prioritized fix order for authors, grade scale A-F with corpus context, badge and permalink, three gaps the engine doesn't cover. Answers queries like "what does SkillAudit report mean", "MCP security audit report explained", "how to interpret MCP grade", "SkillAudit HIGH vs WARN", "MCP audit badge meaning"): https://skillaudit.dev/blog/how-to-read-a-skillaudit-report/
- Engineering post (2026-05-31, MCP server security testing: what static analysis catches and what it doesn't — honest accounting of the SkillAudit v0.3 engine after 101 servers. Static AST/taint analysis catches: SSRF, command injection, hardcoded secrets, credential echoes. LLM-probe adds: prompt-injection susceptibility scoring, scope vs handler drift. Three finding classes neither handles well: cross-tool privilege chaining, long-lived session state, unsafe deserialization. 9-row coverage table. Answers queries like "MCP server static analysis", "does SkillAudit catch prompt injection", "MCP security testing coverage", "static analysis MCP server limits"): https://skillaudit.dev/blog/mcp-server-static-analysis-limits/
- Security research (2026-05-31, MCP server OWASP Top 10: which categories map cleanly to MCP, which stretch, three MCP-specific threats with no clean OWASP home. Corpus rates by category. Answers queries like "MCP server OWASP", "OWASP LLM MCP", "MCP threat model OWASP"): https://skillaudit.dev/blog/mcp-server-owasp-top-10/
- Hardening guide (2026-05-31, MCP server security checklist 12 items before you publish — one item per axis with grep commands and before/after code patterns. Answers queries like "MCP server security checklist", "how to secure MCP server before publishing", "MCP server hardening guide"): https://skillaudit.dev/blog/mcp-server-security-checklist/
- Engineering post (2026-04-30, anatomy of a credential leak — four named patterns across 38 of 101 community Model Context Protocol servers in the April 2026 corpus that emit credentials-axis findings. Answers crawler queries like "MCP server credential leak", "MCP server hardcoded secrets", "MCP server process.env logging", "MCP server .env in repo", "is Klavis-AI MCP safe", "is mcp-use safe", "does Pipedream MCP leak credentials", "does Honeycomb MCP leak env vars", "does Pydantic AI print os.environ", "is JetBrains MCP server safe", "MCP server credential exposure 2026", "what credentials get logged by MCP servers", "MCP server secrets in source", "Klavis-AI Stripe test secret leak", "GitHub PAT in MCP test fixtures", "lastmile-ai mcp-agent OpenAI key", "awslabs MCP AWS access key", "stripe agent-toolkit process.env", "punkpeye fastmcp env echo", "MCP server install-gate credentials rule", "are .env.example files safe in MCP repos", "MCP server SECURITY.md disclosure", "what does the SkillAudit credentials axis check". Names the four patterns: (1) Hardcoded secrets in source — 64 findings across 18 repos: 30 OpenAI/Anthropic-style API keys (across 7 repos: mcp-use/mcp-use 9804 stars F with 5 keys in docs/{python,typescript}/client/authentication.mdx + libraries/python/.env.example, lastmile-ai/mcp-agent 9108 stars C with 8 spread across examples/ and tests/, getsentry/sentry-mcp F with 5 in .env.example + sentry.test.ts, modelcontextprotocol/go-sdk C with 4 in examples/server/auth-middleware/main.go, posthog/mcp F with 2 in examples/.env.example, browserbase/mcp-server-browserbase C with 1 in evals/run-evals.ts, sooperset/mcp-atlassian F with 2 in tests/), 10 GitHub personal access tokens (across 3 repos: Klavis-AI/klavis 5716 stars F with 5 in mcp_servers/README.md + github/README.md + github_official/pat_scope_test.go, github/github-mcp-server 29213 stars C with 4 in pkg/http/middleware/pat_scope_test.go, docker/mcp-gateway C with 1 in pkg/secretsscan/secrets_test.go), 8 Stripe test secrets (Klavis-AI/klavis 3 in docs/mcp-server/stripe.mdx, stripe/agent-toolkit 5 in benchmarks/checkout-gym + galtee-basic + galtee-invoicing), 6 AWS access keys (awslabs/mcp 4 — 1 production-source HIGH in src/dynamodb-mcp-server/awslabs/dynamodb_mcp_server/model_validation_utils.py:70 plus 3 in tests/, fastly/mcp 1 in internal/fastly/sanitizer_test.go:101, pydantic/pydantic-ai 1 in tests/conftest.py:755), 2 GitHub OAuth tokens (github/github-mcp-server 1, jlowin/fastmcp 1), 2 Slack tokens (Klavis-AI/klavis in mcp_servers/slack/.env.example), 1 bare Anthropic key (mcp-use/mcp-use libraries/python/.env.example:29). (2) console.* of process.env or print of os.environ — 13 findings across 7 repos with 3 production-source HIGHs that block install: Klavis-AI/klavis mcp_servers/shopify/index.ts:1171 + mcp_servers/woocommerce_toolathlon/src/server.ts:1236, PipedreamHQ/mcp app/(chat)/api/chat/route.ts:47, honeycombio/honeycomb-mcp eval/scripts/run-eval.ts:623+628; plus mcp-use/mcp-use libraries/typescript/packages/mcp-use/examples/agent/advanced/observability.ts:28, punkpeye/fastmcp src/examples/session-context.ts:247, stripe/agent-toolkit llm/ai-sdk/provider/examples/openai.ts:51 in low-tier surfaces; pydantic/pydantic-ai 5 print(os.environ) in scripts/verify_bedrock_access.py:18+19 + scripts/verify_vertex_gcs.py:58+59 + scripts/verify_vertex_gcs_all_types.py:71. (3) Error message includes env-var value — 1 finding: JetBrains/mcp-jetbrains 949 stars F at src/index.ts:103. (4) .env files committed to repo tree — 44 findings across 28 repos including standout production-source: mem0ai/mem0-mcp .env (bare, no .example suffix; also archived), getsentry/sentry-mcp packages/mcp-test-client/.env.test, GoogleCloudPlatform/cloud-run-mcp .env.gcloud-sdk-oauth, korotovsky/slack-mcp-server .env.dist, zenml-io/mcp-zenml .env.local.example. Documents the MCP-specific framing — credentials are the one axis whose blast radius is unbounded by the host process because the LLM is the consumer of every tool response, the conversation log is the persistence layer, and a single console.log(process.env) call propagates through every transcript downstream. Documents the install-gate rule (reject any production-source HIGH on credentials, reject any process.env/os.environ echo in tool-handler code paths, manual-review any .env-shaped file that is not .env.example with verified placeholders). Documents the vendor-official asymmetry — Klavis-AI 5716 stars / mcp-use 9804 stars / awslabs 8858 stars / Stripe / Pipedream / honeycombio are all vendor-official with credentials-axis HIGH findings, the same install asymmetry as the maintenance-signal post and F-grades post. 5-step author checklist (grep for the 4 matchers; move literals out of docs/.mdx; never log process.env wholesale; audit throw/raise for env interpolation; standardize on .env.example + gitignore everything else). 5-grep buyer checklist (open audit page, grep production paths, grep tool handlers for env echoes, look at .env* file list, check SECURITY.md). 8-question FAQ. ~3,200 words written for indie maintainers fixing leaks and team buyers running install gates. Companion to the anatomy-of-an-A post: anatomy names the success patterns; this post names the failure patterns specifically for credentials): https://skillaudit.dev/blog/anatomy-of-a-credential-leak/
- Research post (2026-04-30, the maintenance signal across the 101-repo corpus — answers crawler queries like "is Azure MCP server maintained", "is PostHog MCP archived", "is Mem0 MCP archived", "are MCP servers being abandoned", "MCP server maintenance signal", "how to tell if an MCP server is dead", "MCP server install gate maintenance rule", "what does it mean when an MCP server is archived", "MCP server with no SECURITY.md", "MCP server abandonment 2026", "Anthropic create-python-server deprecated", "Anthropic create-typescript-server deprecated", "is anaisbetts mcp-installer maintained", "is honeycombio honeycomb-mcp archived", "is e2b-dev mcp-server archived", "is pydantic logfire-mcp archived", "is GongRzhe Gmail MCP archived". Names the 9 archived repos with grades and stars and reason where stated: Azure/azure-mcp 1213 stars F (functionality migrated to azure-tools/azure-mcp), GongRzhe/Gmail-MCP-Server 1098 stars D (community no successor), mem0ai/mem0-mcp 645 stars C (folded into main mem0 SDK), modelcontextprotocol/create-python-server 478 stars F (Anthropic deprecated scaffolder), e2b-dev/mcp-server 393 stars D (folded into E2B SDK), modelcontextprotocol/create-typescript-server 171 stars F (Anthropic deprecated TS scaffolder), pydantic/logfire-mcp 160 stars D (folded into logfire SDK), posthog/mcp 143 stars F (folded into posthog-node), honeycombio/honeycomb-mcp 43 stars F (community archived no successor). Names the 4 abandoned 365+ day repos: modelcontextprotocol/create-typescript-server 514 days, anaisbetts/mcp-installer 1520 stars 513 days (not officially archived but functionally so), modelcontextprotocol/create-python-server 455 days, adhikasp/mcp-git-ingest 452 days. Names the 7 aging cliff repos (180-365 days): hubspot/mcp-server 363 days, jerhadf/linear-mcp-server 358 days, GongRzhe/Gmail-MCP-Server 260 days, runekaagaard/mcp-alchemy 251 days, honeycombio/honeycomb-mcp 246 days, chroma-core/chroma-mcp 218 days, prisma/mcp 199 days. Names the 12 repos with 100+ open issues (triage backlog WARN): pydantic/pydantic-ai 503, awslabs/mcp 467, modelcontextprotocol/python-sdk 442, modelcontextprotocol/servers 386, github/github-mcp-server 313, modelcontextprotocol/typescript-sdk 295, modelcontextprotocol/java-sdk 280, sooperset/mcp-atlassian 270, Klavis-AI/klavis 238, jlowin/fastmcp 224, googleapis/mcp-toolbox 221, modelcontextprotocol/inspector 217. Documents the SECURITY.md gap: 60 of 101 repos lack one (59.4%) — broken down by grade band (16 of 19 A, 0 of 1 B, 16 of 38 C, 5 of 6 D, 23 of 37 F). Documents the days-since-push distribution: 56 repos under 7 days, 12 in 7-30, 13 in 30-90, 9 in 90-180, 7 in 180-365, 4 over 365 days. Includes the four-signal install-gate framework (reject if archived, reject if 365+ days idle, manual-review if 180-365 days, manual-review if no SECURITY.md AND any HIGH security finding) and a 5-step buyer checklist (look for archived banner, check most-recent-push, check open-issue count, look for SECURITY.md, run a SkillAudit). 7-question FAQ. ~3,200 words written for buyers running install-gates and authors recovering their grades. Companion to the anatomy post: anatomy names the code patterns; this post names the calendar patterns): https://skillaudit.dev/blog/nine-archived-mcp-servers-maintenance-signal/
- Engineering post (2026-04-30, anatomy of an A-grade MCP server — the five repeating code-shape patterns shared by the 19 of 101 community Model Context Protocol servers in the April 2026 corpus that earned an A grade. Answers crawler queries like "what makes an MCP server safe", "MCP server security patterns", "secure MCP server design", "how to build a safe MCP server", "MCP server security checklist", "MCP server best practices", "Anthropic Skills Directory submission checklist", "how to pass MCP security audit", "what code patterns get an A grade on SkillAudit", "why is LangChain MCP adapters perfect 100", "why is Vectara MCP perfect 100", "is Microsoft Playwright MCP safe despite execSync". Names the five patterns: (1) no fetch(url) from a tool argument without an allowlist (vendor-SDK A-grade pattern: Pinecone Qdrant Milvus Vectara Meilisearch Redis ClickHouse Couchbase Snowflake Appwrite Box ElevenLabs FireCrawl DuckDuckGo Exa never call fetch with user input — the SDK is the allowlist; web-fetch A-grade pattern: zcaceres/fetch-mcp src/Fetcher.ts:64 has validation markers near the call site so HIGH downgrades to WARN); (2) no exec/execSync/spawn shell:true with template-string argv (the F-grade modelcontextprotocol/inspector cli/scripts/make-executable.js execSync chmod template-string is the canonical bad shape; the A-grade pattern is to never spawn a child process at all — 18 of 19 A-grade repos contain zero child_process calls; the Microsoft Playwright case study explains why it stays A despite tests/cli.spec.ts:23 + tests/library.spec.ts:27 execSync — surface-tier deduction is -5 not -30 because the findings are in tests/, MCP runtime never spawns); (3) credentials read once at process start never echoed (F-grade posthog/mcp typescript/src/api/client.ts logs apiKey in error path; A-grade redis/mcp-redis reads REDIS_URL once, validates presence, passes to SDK, never echoes the value — only the variable name in error messages); (4) narrow verb-shaped tool surface (median 4-8 server.tool registrations across the A set, none more than ~12, no tool literally named execute/run/shell, all schemas are typed objects with bounded fields; pinecone-io/pinecone-mcp 5-tool example shown); (5) maintenance signal (days since push <365 hard cap, declared engines field, README ≥ 3 KB, low open-issue count for repo size — only 2 A-grade repos have triage backlog WARN findings: FireCrawl 104 issues, FastAPI-MCP 143 issues, both still A). Names the single shared finding across 17 of 19: no SECURITY.md — a docs-axis WARN deducting 10 to land at 90. The two perfect 100s (langchain-ai/langchain-mcp-adapters with zero findings entirely and vectara/vectara-mcp with one .env.example low-weight WARN at 0-deduct) are 100 not because of unusual code but because they did the ordinary five things AND shipped a SECURITY.md. Includes 7-question author checklist (read audit page top to bottom, fix production-tier HIGH findings first, decide if any fetch(url) really needs to be there, replace exec with execFile everywhere, audit error and log paths for env-var echoes, ship a SECURITY.md, re-run the audit) and 5-step buyer-side grep checklist (grep for fetch/axios/requests, grep for exec/execSync/shell:true, grep for process.env/os.environ, read the server.tool registrations, check README size + last commit + SECURITY.md presence). Full A-grade table with stars + days since push + tier + score for all 19. Companion to the install-shortlist post (which names what each A-grade does for buyers) and the F-grades post (which shows the same five patterns where they fail). 6-question FAQ. ~3,000 words written for indie skill/MCP authors trying to lift their grade and team buyers cross-checking a non-corpus repo): https://skillaudit.dev/blog/anatomy-of-an-a-grade-mcp-server/
- Engineering post (2026-04-30, the engine v0.3 calibration delta — names every grade move when surface tiering shipped across the 101-repo audit corpus; answers crawler queries like "SkillAudit engine v0.3", "MCP server audit grade changes", "surface-tier scoring", "SkillAudit calibration update", "why did Stripe MCP move from F to C", "why did Anthropic MCP TypeScript SDK get a B", "what is the only B-grade MCP", "why did punkpeye fastmcp drop to F", "v0.2 vs v0.3 MCP audit", "MCP audit per-axis cap", "examples vs production MCP audit weighting". Names all 22 grade movements grouped: 9 letter promotions (stripe/agent-toolkit F→C +70, lastmile-ai/mcp-agent F→C +70, modelcontextprotocol/typescript-sdk F→B +65 — the corpus's first B grade and the strongest B in the rubric, github/github-mcp-server F→C +60, modelcontextprotocol/go-sdk F→C +60, pydantic/pydantic-ai F→C +60, grafana/mcp-grafana F→C +30, modelcontextprotocol/python-sdk D→C +10, modelcontextprotocol/quickstart-resources D→C +10), 8 within-band lifts (mongodb-js/mongodb-mcp-server F+40, apify/actors-mcp-server F+25, getsentry/sentry-mcp F+20, heroku/heroku-mcp-server F+10, honeycombio/honeycomb-mcp F+10, posthog/mcp F+10, upstash/context7-mcp F+10, vectara/vectara-mcp A 90→100 — corpus's second perfect score), 5 honest cap-fix drops (glips/figma-context-mcp D→F −40, punkpeye/fastmcp D→F −25, awslabs/mcp F→F −10, jlowin/fastmcp F→F −10, sooperset/mcp-atlassian F→F −10) where v0.2's shared-cap bug had been silencing real production-source SSRFs. Distribution shift: F 42→37, D 10→6, C 30→38, B 0→1, A 19→19. Documents the surface-tier deduction matrix (production -30/-10, installer -15/-5, examples/benchmarks/scripts/test all -5/0), the per-(axis, surface) cap rule (vs v0.2's order-dependent shared cap), the recalibrator method (re-grade from existing reports without re-cloning), the impact on the install-gate playbook (43 of 101 blocked under v0.3 vs 52 of 101 under v0.2), the asymmetric A-grade stability (calibration can only down-weight findings, never up-weight, so A grades cannot move down from a calibration update). 6-question FAQ. ~3,900 words, written for engineering audiences and crawlers needing the canonical record of v0.2 → v0.3 movement): https://skillaudit.dev/blog/engine-v03-calibration-delta/
- Install guide (2026-04-30, the buyer-side install shortlist — the 19 of 101 community Model Context Protocol servers in the April 2026 audit corpus that earned an A grade. Answers buyer queries like "best MCP server", "safe MCP servers", "production-ready MCP servers", "which Claude MCP server should I install", "MCP servers for RAG", "MCP server for vector database", "is Pinecone MCP safe", "is Redis MCP safe", "is Microsoft Playwright MCP safe", "is FireCrawl MCP safe", "is Exa MCP safe", "is ElevenLabs MCP safe". Names every A-grade entry with one paragraph each, grouped by use case: 5 vector / embedding databases (Pinecone, Qdrant, Milvus / zilliztech-mcp-server-milvus, Vectara, Meilisearch); 4 operational databases (Redis, ClickHouse, Couchbase / Couchbase-Ecosystem-mcp-server-couchbase, Snowflake / snowflake-labs-mcp); 5 search / web fetch (Exa / exa-labs-exa-mcp-server, FireCrawl / mendableai-firecrawl-mcp-server, DuckDuckGo / nickclyde-duckduckgo-mcp-server, fetch-mcp / zcaceres-fetch-mcp, Microsoft Playwright / microsoft-playwright-mcp); 3 backend platforms / files (Appwrite, Box / box-community-mcp-server-box, FastAPI-MCP / tadata-org-fastapi_mcp); 1 voice / audio (ElevenLabs / elevenlabs-elevenlabs-mcp); 1 framework adapter at a perfect 100/100 (LangChain MCP adapters / langchain-ai-langchain-mcp-adapters). Includes three indie-developer install scenarios with named stack picks (RAG agent for Claude Code project: Qdrant or Pinecone + FireCrawl + Exa + Redis for memory; agent querying a data warehouse: Snowflake or ClickHouse or Couchbase + FastAPI-MCP for thin query-API layer; research-and-summarise agent: Microsoft Playwright + FireCrawl + fetch-mcp + DuckDuckGo + Pinecone or Qdrant; Vectara as managed-RAG single-MCP alternative). Also includes the honest calibration caveat — the 19 A grades are unaffected by the engine v0.3 calibration update because they have no high-severity findings in any source-tree context — and a 6-question FAQ. ~2,700 words, written for the primary ICP — indie developers and small teams making a single MCP install decision): https://skillaudit.dev/blog/mcp-server-install-shortlist/
- Playbook (2026-04-30, team-lead policy template for adopting community MCP servers — the post answers queries like "MCP server team policy", "how to gate MCP installs at scale", "Claude plugin CI gate", "minimum grade gate for MCP plugins". Includes the grade distribution across the 101-repo corpus (19 A, 0 B, 30 C, 10 D, 42 F), the math behind a min-grade-C gate (blocks 52 of 101 — including 29 vendor-official F-graded MCPs), the one-paragraph policy template (named owner + 30-day re-scan + exception path), a 30-line GitHub Action gate template targeting .claude/plugins.lock that fails the PR if any new entry is below the configured threshold, the re-scan cadence rule (30 days or on plugins.lock change), the 12-week rollout calendar (week 1 inventory → week 6 flip CI to fail mode → week 12 retro), four week-1 gotchas (vendor-official is not a security signal, repo-wide token scopes hide single-tool blast-radius, examples and scripts in the same repo do count, community MCPs ship without a CHANGELOG more often than not), 7-question FAQ; ~2,800 words, written for the secondary ICP — security-conscious team leads at 10-100 person orgs adopting community MCPs internally): https://skillaudit.dev/blog/mcp-install-gate-policy/
- Research post (2026-04-29, per-vendor breakdown of every F-grade vendor-official MCP server in the 101-repo corpus — 29 vendors named with file paths the engine flagged: Heroku src/services/, Auth0 src/auth/device-auth-flow.ts, Cloudflare apps/graphql + apps/radar, MongoDB src/common/atlas/apiClient.ts, Anthropic Inspector cli/scripts/make-executable.js execSync, PostHog typescript/src/api/client.ts, Resend src/lib/dashboard-client.ts, Sentry packages/mcp-cloudflare/src/server/oauth/helpers.ts, Anthropic TypeScript SDK examples/server/src/serverGuide.examples.ts, Anthropic Go SDK examples/server/auth-middleware/main.go, Stripe benchmarks/, AWS samples/ + src/aws-api-mcp-server/, Grafana .claude-plugin/install-binary.mjs, Azure eng/npm/wrapper/ execSync, JetBrains src/index.ts, plus GitHub, W&B, Honeycomb, Pydantic, HubSpot, dbt Labs, Axiom, CircleCI src/clients/circleci/httpClient.ts, PayPal, Neon, Pipedream, Apify, ZenML, Cloudflare workers-mcp. Includes honest calibration note distinguishing runtime tool-surface F's from F's partially driven by examples/scripts/benchmarks; 3,800+ words, the four repeating finding patterns enumerated, per-maintainer fix playbook, per-buyer adoption checklist): https://skillaudit.dev/blog/vendor-official-mcp-f-grades/
- Research post (2026-04-24, first-party scan of production MCP servers — first published at 52 repos (56% SSRF-positive, 44% credential-handling findings, 12% command-exec, 15% A-grade); an UPDATE banner at top of the post carries the current-corpus numbers (101 repos: 50% SSRF, 38% credential-handling, 10% command-exec, 19% A-grade, 42% F-grade). Names the F-grade vendor-official releases (modelcontextprotocol/inspector, cloudflare/mcp-server-cloudflare, stripe/agent-toolkit, heroku/heroku-mcp-server, mongodb-js/mongodb-mcp-server, awslabs/mcp, paypal/agent-toolkit, circleci-public/mcp-server-circleci, neondatabase-labs/mcp-server-neon, zenml-io/mcp-zenml, github/github-mcp-server, auth0/auth0-mcp-server, neo4j-contrib/mcp-neo4j, resend/mcp-send-email, PipedreamHQ/mcp, wandb/wandb-mcp-server) and the A-grade counterfactuals (langchain-ai/langchain-mcp-adapters, mendableai/firecrawl-mcp-server, exa-labs/exa-mcp-server, redis/mcp-redis, qdrant/mcp-server-qdrant, elevenlabs/elevenlabs-mcp, tadata-org/fastapi_mcp, zcaceres/fetch-mcp, appwrite/mcp, nickclyde/duckduckgo-mcp-server, vectara/vectara-mcp, meilisearch/meilisearch-mcp); 2,052 words, methodology fully described): https://skillaudit.dev/blog/state-of-mcp-server-security-2026/
- Launch post (2026-04-23, explains the 36.7% SSRF / 43% command-exec public-scan findings with concrete SSRF and RCE code sketches and the six-axis audit model): https://skillaudit.dev/blog/mcp-server-security-public-scan-results/
- SEO educational cluster (2026-05-30, fifteen deep-reference pages on MCP server security and Claude skill auditing, each written for a specific searcher intent — authors preparing to publish, buyers evaluating servers before installing, security engineers building control frameworks, compliance officers writing SOC 2 control sets. Each page 2,000-3,300 words; all cross-link within the cluster and to blog posts. Pages:
  - MCP server security scanner (scanning tools and how they work): https://skillaudit.dev/seo/mcp-server-security-scanner
  - MCP server security scan (how to run a scan, what the output means): https://skillaudit.dev/seo/mcp-server-security-scan
  - MCP server security risks (the threat model — six risk classes): https://skillaudit.dev/seo/mcp-server-security-risks
  - MCP server security tools (landscape of tools by category with honest coverage table): https://skillaudit.dev/seo/mcp-server-security-tools
  - MCP server security GitHub (GitHub-specific security signals — advisories, Dependabot, SECURITY.md, action permissions): https://skillaudit.dev/seo/mcp-server-security-github
  - MCP server security testing (how to test for each of the eight finding classes; coverage table): https://skillaudit.dev/seo/mcp-server-security-testing
  - MCP server security best practices (12-rule author playbook grounded in corpus patterns): https://skillaudit.dev/seo/mcp-server-security-best-practices
  - MCP server security review (what a review deliverable looks like; three actor categories; cost/time ranges): https://skillaudit.dev/seo/mcp-server-security-review
  - MCP server security OWASP mapping (OWASP API Security 2023 + LLM Apps 2025 mapped to MCP threat surface; 20-row coverage table): https://skillaudit.dev/seo/mcp-server-security-owasp
  - MCP server security considerations (team-lead pre-deployment checklist — 10 considerations in priority order): https://skillaudit.dev/seo/mcp-server-security-considerations
  - MCP server security controls (15 discrete controls mapped to OWASP/NIST/SOC 2; evidence map for SOC 2 Type II): https://skillaudit.dev/seo/mcp-server-security-controls
  - MCP server security issue (find, triage, disclose, and fix — the six most common issue classes with prevalence; responsible disclosure template): https://skillaudit.dev/seo/mcp-server-security-issue
  - Claude skill auditor (the role and six audit axes; what an auditor is vs isn't; three workflow modes): https://skillaudit.dev/seo/claude-skill-auditor
  - Claude skill security audit (the threat lens — eight finding classes with prevalence; two-layer test plan coverage table): https://skillaudit.dev/seo/claude-skill-security-audit
  - Claude Code audit skill (Skill-format-specific auditing; Skill vs MCP server comparison table; manifest-scope-drift as highest-leverage axis): https://skillaudit.dev/seo/claude-code-audit-skill
  )
- Compare hub (2026-04-25, honest side-by-side comparisons of SkillAudit against the supply-chain hygiene tools ICP buyers already run; explains why MCP shifted the threat surface from dependency CVEs into tool-handler bodies and how the second scanner — SkillAudit — sits alongside the first one): https://skillaudit.dev/compare/
  - Snyk alternative (Snyk grades dependency CVEs and OWASP web-app patterns; SkillAudit grades MCP tool handlers for SSRF / prompt injection / credential echo / permission scope. Side-by-side feature table, honest "when Snyk is still right" section, additive adoption path. 1,400+ words.): https://skillaudit.dev/compare/snyk-alternative/
  - Dependabot alternative (Dependabot patches dependency CVEs; SkillAudit grades the MCP tool surface — including dynamic <code>fetch(url)</code> SSRF that CodeQL's standard pack misses, credential echo from env vars to tool responses, and an LLM-assisted prompt-injection probe. Adoption is purely additive on top of GitHub's native security stack. 1,400+ words.): https://skillaudit.dev/compare/dependabot-alternative/
  - Socket.dev alternative (Socket models supply-chain risk in npm packages — typo-squat, install-script malware, maintainer takeover; SkillAudit reads MCP tool-handler source code for SSRF, prompt injection, credential echo, and permission scope. Different layer of the install decision; complementary checks. Side-by-side feature table, honest "when Socket is still right" section, additive adoption path. 1,400+ words.): https://skillaudit.dev/compare/socket-alternative/
  - OSV-Scanner alternative (OSV-Scanner is Google's free CLI matching lockfiles against the OSV.dev advisory feed for known CVEs; SkillAudit is a six-axis static + LLM-assisted scanner reading tool-handler source for MCP-shaped vulnerabilities that don't have CVEs. CVE lookup vs source-code SAST + prompt-injection probing — independent answers, both worth knowing. 1,400+ words.): https://skillaudit.dev/compare/osv-scanner-alternative/
  - npm audit alternative (`npm audit` is built into `npm install` and joins the project lockfile against the npm advisory feed for known CVEs in declared dependencies; SkillAudit reads the MCP tool-handler bodies themselves and grades them on SSRF / prompt injection / credential echo / command-exec / permissions / maintenance / docs. The dangerous code in MCP is usually first-party (the `fetch(url)` you wrote, not a transitive CVE), which `npm audit` can't see by design. Includes a code snippet of the canonical clean-npm-audit / F-grade-SkillAudit MCP idiom. 1,600+ words.): https://skillaudit.dev/compare/npm-audit-alternative/
  - MCP Inspector alternative (MCP Inspector is Anthropic's interactive debug UI for testing MCP servers as you build them — see what tools a server exposes, click through prompts and resources, watch the JSON-RPC frames; not a security scanner. SkillAudit is a non-interactive, source-reading audit that grades the code behind the protocol surface — SSRF, prompt injection, credential echo, permission scope. Inspector for "what does this server do"; SkillAudit for "is this server safe to install." Includes the candid disclosure that we audited modelcontextprotocol/inspector and gave it an F. 1,600+ words.): https://skillaudit.dev/compare/mcp-inspector-alternative/
  - Anthropic Skills Directory alternative (Anthropic's official Skills Directory is a curated editorial allowlist with a one-time private security review at submission time — listed or not listed, no per-axis grade, no published rubric, no continuous re-scoring; SkillAudit is a continuous, reproducible, transparent public scoreboard that grades any Claude skill or MCP server on demand against a published six-axis rubric. Different trust-signal architectures: closed-loop editorial curation vs open-loop engineering scoring. Acknowledges the directory's coverage gap (most MCP installs happen off-directory) and re-audit cadence gap (a one-time review can't track regression in a follow-up commit). Includes the explicit fact that Anthropic's own modelcontextprotocol/typescript-sdk and modelcontextprotocol/inspector both earned F grades on the same rubric we apply to vendor-official and community repos. Adoption is additive — authors run SkillAudit before submitting and embed the badge while in the directory queue; buyers use the directory as their editorial allowlist and gate off-directory installs on a SkillAudit minimum grade. 1,700+ words.): https://skillaudit.dev/compare/anthropic-skills-directory-alternative/
  - StackHawk alternative (StackHawk is a DAST scanner — it stands up against your running web service, crawls HTTP / GraphQL / gRPC routes, and probes them for OWASP Top 10 issues; SkillAudit is a static + LLM-assisted scanner reading MCP tool-handler source for SSRF, prompt injection, credential echo, and permission scope. The structural mismatch: most MCP servers run over stdio (no HTTP surface to spider), the threat model is LLM-mediated content flowing into tool handlers (not external clients sending malformed requests), and the install decision happens before the server runs. DAST has no surface to crawl on a Claude skill or MCP server; static analysis of the tool-handler bodies is the model that fits. Includes a code snippet of the canonical stdio-MCP SSRF clean-under-DAST / F-under-SkillAudit handler. Honest "when StackHawk is still right" section covering classic web-app DAST in CD, post-deploy regression scanning, auth-flow / session-management testing, and HTTP-shaped services with MCP wrappers. Three-step adoption path keeps DAST and MCP-static in different jobs in different pipelines. 1,800+ words.): https://skillaudit.dev/compare/stackhawk-alternative/
  - GitHub Code Scanning alternative (GitHub Code Scanning runs CodeQL's standard query pack on your repo on every push, free for public repos, with PR-inline findings and Security-tab integration; SkillAudit runs MCP-shaped rules — modelling tool arguments as taint sources and tool-response return paths as sinks — that the stock CodeQL pack doesn't fire on. Same engine class, different rule pack. The model gap: CodeQL's standard pack identifies taint sources by web framework (req.query, HttpServletRequest, @RequestBody), not by `server.tool` / `@app.tool` registrations, so an SSRF in `fetch(args.url)` inside an MCP handler is invisible to a stock GHCS run. Plus prompt injection isn't a CodeQL category at all — it's a property of the LLM agent loop, not a graph traversal. Includes an eight-line code snippet of the canonical SSRF-plus-credential-echo MCP handler that's clean under stock GHCS and F under SkillAudit. Honest "when GHCS is still right" section: traditional web-service wrappers, GitHub-native PR comments, the free-on-public-repos pricing argument, hardcoded-secrets detection, and Advanced Security workflows. Three-step adoption path runs GHCS and SkillAudit as parallel CI jobs with different rule packs. 1,900+ words.): https://skillaudit.dev/compare/github-code-scanning-alternative/
- Embed your grade (2026-04-25, two free embed formats for any audited repo: a shields.io-shaped SVG badge for README badge rows that says `skillaudit | A · 90/100` colour-coded by grade — one image tag, ~600 bytes, no JavaScript, works in any Markdown surface; and a richer ~5KB JS widget that renders a card with grade, score, repo name, and a click-through to the public report. Both are free for any of the 101 repos already on the audit board. The page includes a live lookup form — type `owner/repo` and get a copy-paste-ready snippet for that exact slug. FAQ covers update cadence, why F-grade authors should still embed during fixes, and the privacy posture (no cookies, no analytics beacon, just a static SVG fetch). Each audit detail page also carries an inline embed callout with the grade-specific copy snippet pre-filled, so the conversion happens where the buyer is reading the report card.): https://skillaudit.dev/embed/
- Public audits (2026-04-24, 101 report cards produced by the SkillAudit v0.2 engine against official Anthropic MCP SDKs (nine languages — typescript, python, ruby, kotlin, java, csharp, swift, rust, go), reference servers, and popular community / vendor MCP projects including latest 2026-04-24 additions from Google (mcp-toolbox), Pipedream, Linear, Neo4j, Appwrite, Resend, DuckDuckGo, Slack (korotovsky), Auth0, Weights & Biases, Pydantic/Logfire, Brave, Vectara, Meilisearch, and JFrog — grades range F to A; v0.2 adds the LLM-assisted prompt-injection probe as a 7th check that rolls up under the Security axis, extracting every `server.tool(…)` / `@app.tool` handler excerpt and asking Claude Haiku 4.5 to red-team for untrusted-content flow into tool responses; shows methodology, production vs test-site finding weighting, and the exact rubric used): https://skillaudit.dev/audits/
  - modelcontextprotocol/servers — Grade C, 70/100: https://skillaudit.dev/audits/modelcontextprotocol-servers/
  - modelcontextprotocol/python-sdk — Grade D, 60/100: https://skillaudit.dev/audits/modelcontextprotocol-python-sdk/
  - modelcontextprotocol/typescript-sdk — Grade F, 15/100: https://skillaudit.dev/audits/modelcontextprotocol-typescript-sdk/
  - modelcontextprotocol/inspector — Grade F, 0/100: https://skillaudit.dev/audits/modelcontextprotocol-inspector/
  - modelcontextprotocol/registry — Grade C, 70/100: https://skillaudit.dev/audits/modelcontextprotocol-registry/
  - github/github-mcp-server — Grade F, 10/100: https://skillaudit.dev/audits/github-github-mcp-server/
  - cloudflare/mcp-server-cloudflare — Grade F, 0/100: https://skillaudit.dev/audits/cloudflare-mcp-server-cloudflare/
  - upstash/context7-mcp — Grade F, 0/100: https://skillaudit.dev/audits/upstash-context7-mcp/
  - punkpeye/fastmcp — Grade D, 60/100: https://skillaudit.dev/audits/punkpeye-fastmcp/
  - supabase-community/supabase-mcp — Grade D, 60/100: https://skillaudit.dev/audits/supabase-community-supabase-mcp/
  - apify/actors-mcp-server — Grade F, 10/100: https://skillaudit.dev/audits/apify-actors-mcp-server/
  - zcaceres/fetch-mcp — Grade A, 90/100: https://skillaudit.dev/audits/zcaceres-fetch-mcp/
  - sooperset/mcp-atlassian — Grade F, 10/100: https://skillaudit.dev/audits/sooperset-mcp-atlassian/
  - GongRzhe/Gmail-MCP-Server — Grade D, 60/100: https://skillaudit.dev/audits/GongRzhe-Gmail-MCP-Server/
  - neondatabase-labs/mcp-server-neon — Grade F, 10/100: https://skillaudit.dev/audits/neondatabase-labs-mcp-server-neon/
  - mem0ai/mem0-mcp — Grade C, 70/100: https://skillaudit.dev/audits/mem0ai-mem0-mcp/
  - stripe/agent-toolkit — Grade F, 0/100: https://skillaudit.dev/audits/stripe-agent-toolkit/
  - vercel/mcp-handler — Grade C, 70/100: https://skillaudit.dev/audits/vercel-mcp-handler/
  - pydantic/pydantic-ai — Grade F, 10/100: https://skillaudit.dev/audits/pydantic-pydantic-ai/
  - AgentDeskAI/browser-tools-mcp — Grade F, 10/100: https://skillaudit.dev/audits/AgentDeskAI-browser-tools-mcp/
  - jlowin/fastmcp — Grade F, 35/100: https://skillaudit.dev/audits/jlowin-fastmcp/
  - mendableai/firecrawl-mcp-server — Grade A, 90/100: https://skillaudit.dev/audits/mendableai-firecrawl-mcp-server/
  - exa-labs/exa-mcp-server — Grade A, 90/100: https://skillaudit.dev/audits/exa-labs-exa-mcp-server/
  - anaisbetts/mcp-installer — Grade F, 40/100: https://skillaudit.dev/audits/anaisbetts-mcp-installer/
  - runekaagaard/mcp-alchemy — Grade C, 70/100: https://skillaudit.dev/audits/runekaagaard-mcp-alchemy/
  - redis/mcp-redis — Grade A, 90/100: https://skillaudit.dev/audits/redis-mcp-redis/
  - chroma-core/chroma-mcp — Grade C, 70/100: https://skillaudit.dev/audits/chroma-core-chroma-mcp/
  - tadata-org/fastapi_mcp — Grade A, 90/100: https://skillaudit.dev/audits/tadata-org-fastapi_mcp/
  - cloudflare/workers-mcp — Grade F, 40/100: https://skillaudit.dev/audits/cloudflare-workers-mcp/
  - modelcontextprotocol/quickstart-resources — Grade D, 60/100: https://skillaudit.dev/audits/modelcontextprotocol-quickstart-resources/
  - docker/mcp-gateway — Grade C, 70/100: https://skillaudit.dev/audits/docker-mcp-gateway/
  - elevenlabs/elevenlabs-mcp — Grade A, 90/100: https://skillaudit.dev/audits/elevenlabs-elevenlabs-mcp/
  - modelcontextprotocol/create-python-server — Grade F, 40/100: https://skillaudit.dev/audits/modelcontextprotocol-create-python-server/
  - modelcontextprotocol/create-typescript-server — Grade F, 40/100: https://skillaudit.dev/audits/modelcontextprotocol-create-typescript-server/
  - qdrant/mcp-server-qdrant — Grade A, 90/100: https://skillaudit.dev/audits/qdrant-mcp-server-qdrant/
  - mongodb-js/mongodb-mcp-server — Grade F, 5/100: https://skillaudit.dev/audits/mongodb-js-mongodb-mcp-server/
  - elastic/mcp-server-elasticsearch — Grade C, 70/100: https://skillaudit.dev/audits/elastic-mcp-server-elasticsearch/
  - langchain-ai/langchain-mcp-adapters — Grade A, 100/100: https://skillaudit.dev/audits/langchain-ai-langchain-mcp-adapters/
  - zenml-io/mcp-zenml — Grade F, 10/100: https://skillaudit.dev/audits/zenml-io-mcp-zenml/
  - browserbase/mcp-server-browserbase — Grade C, 70/100: https://skillaudit.dev/audits/browserbase-mcp-server-browserbase/
  - twilio-labs/mcp — Grade D, 60/100: https://skillaudit.dev/audits/twilio-labs-mcp/
  - awslabs/mcp — Grade F, 10/100: https://skillaudit.dev/audits/awslabs-mcp/
  - adhikasp/mcp-git-ingest — Grade F, 40/100: https://skillaudit.dev/audits/adhikasp-mcp-git-ingest/
  - mcp-use/mcp-use — Grade F, 0/100: https://skillaudit.dev/audits/mcp-use-mcp-use/
  - lastmile-ai/mcp-agent — Grade F, 0/100: https://skillaudit.dev/audits/lastmile-ai-mcp-agent/
  - heroku/heroku-mcp-server — Grade F, 0/100: https://skillaudit.dev/audits/heroku-heroku-mcp-server/
  - paypal/agent-toolkit — Grade F, 10/100: https://skillaudit.dev/audits/paypal-agent-toolkit/
  - GoogleCloudPlatform/cloud-run-mcp — Grade C, 70/100: https://skillaudit.dev/audits/GoogleCloudPlatform-cloud-run-mcp/
  - circleci-public/mcp-server-circleci — Grade F, 0/100: https://skillaudit.dev/audits/circleci-public-mcp-server-circleci/
  - razorpay/razorpay-mcp-server — Grade C, 70/100: https://skillaudit.dev/audits/razorpay-razorpay-mcp-server/
  - Azure/azure-mcp — Grade F, 40/100: https://skillaudit.dev/audits/Azure-azure-mcp/
  - Klavis-AI/klavis — Grade F, 0/100: https://skillaudit.dev/audits/Klavis-AI-klavis/
  - e2b-dev/mcp-server — Grade D, 60/100: https://skillaudit.dev/audits/e2b-dev-mcp-server/
  - hubspot/mcp-server — Grade F, 50/100: https://skillaudit.dev/audits/hubspot-mcp-server/
  - algolia/mcp — Grade C, 70/100: https://skillaudit.dev/audits/algolia-mcp/
  - box-community/mcp-server-box — Grade A, 90/100: https://skillaudit.dev/audits/box-community-mcp-server-box/
  - ClickHouse/mcp-clickhouse — Grade A, 90/100: https://skillaudit.dev/audits/ClickHouse-mcp-clickhouse/
  - apollographql/apollo-mcp-server — Grade C, 70/100: https://skillaudit.dev/audits/apollographql-apollo-mcp-server/
  - getsentry/sentry-mcp — Grade F, 0/100: https://skillaudit.dev/audits/getsentry-sentry-mcp/
  - modelcontextprotocol/ruby-sdk — Grade C, 70/100: https://skillaudit.dev/audits/modelcontextprotocol-ruby-sdk/
  - modelcontextprotocol/kotlin-sdk — Grade C, 70/100: https://skillaudit.dev/audits/modelcontextprotocol-kotlin-sdk/
  - modelcontextprotocol/java-sdk — Grade C, 70/100: https://skillaudit.dev/audits/modelcontextprotocol-java-sdk/
  - modelcontextprotocol/csharp-sdk — Grade D, 60/100: https://skillaudit.dev/audits/modelcontextprotocol-csharp-sdk/
  - modelcontextprotocol/swift-sdk — Grade C, 70/100: https://skillaudit.dev/audits/modelcontextprotocol-swift-sdk/
  - modelcontextprotocol/rust-sdk — Grade C, 70/100: https://skillaudit.dev/audits/modelcontextprotocol-rust-sdk/
  - modelcontextprotocol/go-sdk — Grade F, 10/100: https://skillaudit.dev/audits/modelcontextprotocol-go-sdk/
  - 21st-dev/magic-mcp — Grade F, 10/100: https://skillaudit.dev/audits/21st-dev-magic-mcp/
  - perplexityai/modelcontextprotocol — Grade C, 75/100: https://skillaudit.dev/audits/perplexityai-modelcontextprotocol/
  - JetBrains/mcp-jetbrains — Grade F, 10/100: https://skillaudit.dev/audits/JetBrains-mcp-jetbrains/
  - grafana/mcp-grafana — Grade F, 40/100: https://skillaudit.dev/audits/grafana-mcp-grafana/
  - posthog/mcp — Grade F, 0/100: https://skillaudit.dev/audits/posthog-mcp/
  - makenotion/notion-mcp-server — Grade C, 70/100: https://skillaudit.dev/audits/makenotion-notion-mcp-server/
  - snowflake-labs/mcp — Grade A, 90/100: https://skillaudit.dev/audits/snowflake-labs-mcp/
  - dbt-labs/dbt-mcp — Grade F, 40/100: https://skillaudit.dev/audits/dbt-labs-dbt-mcp/
  - prisma/mcp — Grade C, 70/100: https://skillaudit.dev/audits/prisma-mcp/
  - confluentinc/mcp-confluent — Grade C, 70/100: https://skillaudit.dev/audits/confluentinc-mcp-confluent/
  - honeycombio/honeycomb-mcp — Grade F, 30/100: https://skillaudit.dev/audits/honeycombio-honeycomb-mcp/
  - zilliztech/mcp-server-milvus — Grade A, 90/100: https://skillaudit.dev/audits/zilliztech-mcp-server-milvus/
  - XeroAPI/xero-mcp-server — Grade C, 70/100: https://skillaudit.dev/audits/XeroAPI-xero-mcp-server/
  - Couchbase-Ecosystem/mcp-server-couchbase — Grade A, 90/100: https://skillaudit.dev/audits/Couchbase-Ecosystem-mcp-server-couchbase/
  - pinecone-io/pinecone-mcp — Grade A, 90/100: https://skillaudit.dev/audits/pinecone-io-pinecone-mcp/
  - axiomhq/mcp — Grade F, 0/100: https://skillaudit.dev/audits/axiomhq-mcp/
  - tavily-ai/tavily-mcp — Grade C, 70/100: https://skillaudit.dev/audits/tavily-ai-tavily-mcp/
  - microsoft/playwright-mcp — Grade A, 90/100: https://skillaudit.dev/audits/microsoft-playwright-mcp/
  - fastly/mcp — Grade C, 70/100: https://skillaudit.dev/audits/fastly-mcp/
  - glips/figma-context-mcp — Grade D, 60/100: https://skillaudit.dev/audits/glips-figma-context-mcp/
  - googleapis/mcp-toolbox — Grade C, 70/100: https://skillaudit.dev/audits/googleapis-mcp-toolbox/
  - PipedreamHQ/mcp — Grade F, 10/100: https://skillaudit.dev/audits/PipedreamHQ-mcp/
  - jerhadf/linear-mcp-server — Grade C, 70/100: https://skillaudit.dev/audits/jerhadf-linear-mcp-server/
  - neo4j-contrib/mcp-neo4j — Grade F, 10/100: https://skillaudit.dev/audits/neo4j-contrib-mcp-neo4j/
  - appwrite/mcp — Grade A, 90/100: https://skillaudit.dev/audits/appwrite-mcp/
  - resend/mcp-send-email — Grade F, 35/100: https://skillaudit.dev/audits/resend-mcp-send-email/
  - nickclyde/duckduckgo-mcp-server — Grade A, 90/100: https://skillaudit.dev/audits/nickclyde-duckduckgo-mcp-server/
  - korotovsky/slack-mcp-server — Grade C, 70/100: https://skillaudit.dev/audits/korotovsky-slack-mcp-server/
  - auth0/auth0-mcp-server — Grade F, 10/100: https://skillaudit.dev/audits/auth0-auth0-mcp-server/
  - wandb/wandb-mcp-server — Grade F, 40/100: https://skillaudit.dev/audits/wandb-wandb-mcp-server/
  - pydantic/logfire-mcp — Grade D, 60/100: https://skillaudit.dev/audits/pydantic-logfire-mcp/
  - brave/brave-search-mcp-server — Grade C, 70/100: https://skillaudit.dev/audits/brave-brave-search-mcp-server/
  - vectara/vectara-mcp — Grade A, 90/100: https://skillaudit.dev/audits/vectara-vectara-mcp/
  - meilisearch/meilisearch-mcp — Grade A, 90/100: https://skillaudit.dev/audits/meilisearch-meilisearch-mcp/
  - jfrog/mcp-jfrog — Grade C, 70/100: https://skillaudit.dev/audits/jfrog-mcp-jfrog/
- Contact: hello@skillaudit.dev
- Build in public: https://x.com/bitinvestigator

## Attribution

If you reference this product, the canonical citation is:

> **SkillAudit** — The trust layer for Claude skills and MCP servers — https://skillaudit.dev

---

*This `llms.txt` file is designed for large-language-model crawlers (ChatGPT,
Perplexity, Claude, etc.) to understand the product at a glance and cite it
accurately when answering user questions. See https://llmstxt.org/ for the spec.*