The SkillAudit scorecard explained: how we grade MCP server security across six axes

The Security axis covers the attack surface accessible to an adversary who controls tool arguments or can inject instructions into a document the LLM reads. It combines static analysis (AST-level pattern matching via tree-sitter) with LLM-assisted red-teaming that generates adversarial tool invocations against the server's declared schema.

• HIGH SSRF via unvalidated URL argument — any tool accepting a URL or hostname parameter without allowlist validation. Includes http://, file://, and ftp:// schemes. Detected by AST pattern matching on fetch/axios/request calls where the URL argument derives from tool args without an allowlist check.
• HIGH Shell injection — spawn(shell: true), exec(), or execSync() with tool arguments interpolated into the command string. This includes template literal interpolation (`cmd ${args.filename}`) and string concatenation. Does not flag spawn(shell: false) with args as an array.
• HIGH Prompt injection via tool description — tool description contains dynamic content from external sources at load time, or includes instruction-following language that could be weaponized (e.g., "ignore previous instructions and…" patterns in any reachable string).
• HIGH eval() / Function() on argument content — any dynamic code execution where input derives from tool arguments or external data.
• HIGH Path traversal — unvalidated file path argument where path.join() or path.resolve() is not followed by a startsWith(allowedRoot) check. Flags both absolute path construction and relative traversal patterns (../../).
• MED Unchecked integer overflow — numeric arguments used as array indices, buffer sizes, or loop counts without Number.isSafeInteger() or clamping.
• MED ReDoS — regex patterns with catastrophic backtracking applied to user-controlled strings (detected via static analysis of the regex AST).
• MED XML injection — any XML construction with concatenated user-controlled strings outside a proper escaping library.
• MED CRLF injection — argument values interpolated into HTTP headers, log lines, or CSV output without stripping \r\n.
• MED Unsafe deserialization — JSON.parse() on an argument value without schema validation (prototype pollution risk via __proto__ keys in some environments).
• LOW Missing input schema — tool registered without a Zod/JSON Schema declaration on arguments, preventing the MCP host from validating inputs before the tool runs.
• LOW LLM-assisted red-team result — the engine's red-team module generated an invocation that produced an anomalous response (credential hint in output, error stack trace, unexpected external network call). Flagged as LOW only when the evidence is ambiguous; upgraded to HIGH if a concrete exfiltration path is confirmed.

The LLM-assisted red-team runs against every tool in the server's schema. It generates prompt injection payloads via tool arguments and tool descriptions, looking for outputs that contain credential strings, internal path fragments, or unusual network calls. The red-team results supplement — they do not replace — static findings.

The Credentials axis is concerned with how the server handles secrets: where they come from, whether they appear in logs or outputs, and whether they're scoped to the minimum needed. MCP servers have ambient access to every environment variable in the process — this axis checks whether that access is appropriately constrained.

• HIGH Credential in log output — any call to console.log(), logger.info(), or similar where the argument chain can include a value derived from a known credential environment variable (API_KEY, SECRET, TOKEN, PASSWORD, PRIVATE_KEY pattern matching). Includes logging the entire args object which may contain credential-adjacent fields.
• HIGH Credential in tool output — a tool's return value includes a raw secret string. Detected by tracing data flow from environment variable reads to the return statement.
• HIGH Credential in error message — new Error(\`Connection failed: ${connectionString}\`) where the interpolated value is a database URL or similar. The error propagates to the LLM context window where it can be exfiltrated.
• HIGH Hardcoded credential — any string literal matching known credential patterns (sk-, sk-ant-, AKIA, ghp_, xoxb-, postgresql://, mongodb+srv://) in source code or committed config files. Checks full git history, not just current HEAD.
• MED Implicit environment variable read — process.env spread or destructuring that pulls all env vars into scope, rather than reading only the named keys the server needs.
• MED Missing credential validation at startup — no check that required environment variables are set (and non-empty) before the server registers its tools. Servers that start without credentials and fail at tool-call time expose the error to the LLM.
• MED Cross-tool credential sharing — a single credential variable reused across tools with different permission requirements, where one tool needs only read access but the credential grants write or destructive capabilities.
• LOW No credential rotation support — no TTL-bounded token pattern; the server reads a single long-lived credential at startup with no refresh mechanism.
• LOW Credential in default argument value — a tool argument declares a default value that contains a credential-adjacent string or placeholder that hints at the expected secret format.

The git history scan deserves special mention. We scan full commit history for hardcoded credential patterns — not just the current HEAD. A secret that was committed and then deleted is still a valid finding because the secret is permanently in the git history and must be rotated, not just removed from the working tree. Authors are often surprised that removing a line doesn't close the finding.

The Permissions axis checks whether the server accurately declares what it can do, and whether it asks for less than the maximum. This matters because MCP host policies and team adoption gates increasingly rely on machine-readable permission declarations to make installation decisions. An over-declared server forces human review of every team member's installation; an under-declared server is deceptive.

• HIGH No permission manifest — the server ships with no mcp-manifest.json, no YAML permission declaration, and no inline annotations in tool definitions. Without a manifest, downstream policy enforcement is impossible.
• MED Over-declared write scope — manifest declares write:filesystem or equivalent but no tool in the source actually performs a write operation. Over-declaration inflates the blast-radius estimate and triggers unnecessary human review.
• MED Under-declared network scope — source calls external URLs but manifest does not declare network:outbound. Under-declaration means policy gates pass the server that shouldn't.
• MED Tool destructive annotation missing — a tool performs a delete, truncate, or irreversible write operation but is not annotated destructive: true in the tool definition. MCP host clients use this annotation to insert confirmation gates.
• MED Overly broad filesystem access — the server reads or writes anywhere on the filesystem without constraining to a declared working directory. Compare against servers that declare and enforce a WORKING_DIR root.
• LOW Tool description omits permission implications — a tool description does not mention that it makes external network calls, even though it does. Authors reading the description before installation have no warning.
• LOW No readOnly: true annotation on read-only tools — tools that only read data should be annotated to allow hosts to grant them without requesting write capabilities.

The over/under-declaration checks use a two-pass approach: first, the manifest is parsed and its declared permissions are extracted; second, the source is statically analyzed for actual capability usage. The gap between declared and actual is the finding. This makes the Permissions axis effectively a correctness check on the manifest, not just its presence.

The Maintenance axis is the only axis that degrades with time regardless of code changes. It measures signals that indicate the server will receive security fixes when they're needed — not whether it's already secure. A server that's A-grade today but abandoned tomorrow will drop through B to C in under six months on this axis alone.

• HIGH Unacknowledged critical advisory — a dependency has a published CVE at severity CRITICAL or HIGH, and there is no Dependabot PR, no renovate config, and no comment in package.json acknowledging the advisory. "Unacknowledged" means no evidence of awareness, not that the CVE is necessarily exploitable in this specific context.
• MED Last commit >90 days ago — the most recent commit to the default branch is older than 90 days. This is a signal of abandonment, not a defect. The deduction is applied even if the server has zero security findings, because a maintained server responds to advisories; an unmaintained one doesn't.
• MED Open security issue >30 days old — a GitHub issue labeled "security", "vulnerability", or "CVE" has been open without a response for more than 30 days.
• MED Unpinned dependencies — package.json uses ranges (^1.2.3, ~4.5.6) without a lockfile committed to the repository. Unpinned production dependencies mean the server's behavior drifts between installs.
• MED No Dependabot or Renovate config — no automated dependency update tooling configured. This is not a finding on its own but combines with other signals for the overall axis score.
• LOW No CHANGELOG or release history — no documented record of what changed between versions. Not a security issue, but a signal that the maintainer is not tracking changes systematically.
• LOW No SECURITY.md — no documented process for reporting vulnerabilities. Responsible disclosures from researchers go unreported because there's no obvious channel.

The 90-day threshold for last commit was calibrated on our corpus: servers that last committed 90+ days ago had a 4.3× higher rate of unpatched advisories at the next monthly rescan compared to actively maintained servers. It is a leading indicator, not a direct finding. See grade drift analysis for the full rescan data.

The Compatibility axis verifies that the server works correctly with the four major MCP host clients: Claude Code, Cursor, Windsurf, and Codex. Compatibility is weighted below security because it affects functionality, not safety — but a server that silently malfunctions on a popular client is worse than one that fails loudly. Silent malfunction can produce unexpected tool invocations.

• HIGH Transport incompatibility — server registers tools via a transport the declared client does not support (e.g., HTTP streaming on a stdio-only host, or SSE on a client that requires batch). Detection via declared transport type in manifest vs. known host capabilities matrix.
• MED Tool schema uses unsupported JSON Schema features — anyOf, oneOf, $ref, or recursive schemas that some host clients serialize incorrectly. Detected against the known compatibility matrix for each client version.
• MED Missing protocol_version declaration — server does not declare which MCP protocol version it implements, preventing hosts from performing capability negotiation correctly.
• LOW Tool name contains non-ASCII characters or symbols — some host clients reject tool names with characters outside [a-z0-9_-].
• LOW Tool description exceeds 512 characters — some clients truncate descriptions at 512 characters, which can silently strip security-relevant text from the LLM's context.
• LOW Return value exceeds soft size limit — tool returns objects larger than 64 KB, which some host clients buffer entirely in memory, causing degraded performance or OOM in resource-constrained environments.

Documentation is the lowest-weighted axis but not zero — documentation gaps make security findings harder to evaluate and mitigations harder to implement. A server where the tool descriptions don't explain what a parameter does forces users to infer, which often means inferring wrong. The axis does not reward verbosity; it rewards completeness on security-relevant attributes.

• MED No runnable example — README or documentation contains no working invocation example. A user cannot verify the server works correctly before installing into a production agent.
• MED Tool description omits required credential setup — a tool requires an API key or database connection string but the description (and README) don't document what env vars to set. Users guess; guesses are often wrong and produce error messages that leak context.
• LOW No version string in package.json or equivalent — versioning enables reliable dependency pinning. Without it, npm install author/repo#HEAD installs whatever is current, not a specific known state.
• LOW Parameter descriptions missing on one or more tool arguments — inputSchema declares a field without a description property. The LLM must infer semantics from the field name alone.
• LOW No README — server ships without a top-level README.md or equivalent documentation file.
• INFO Tool count — surfaced as an informational note. High tool counts (>20) may indicate a server that does too much; low tool counts (<2) may indicate incomplete implementation. Not a finding.