/auditing-mcp-servers

name: auditing-mcp-servers
description: Audit Model Context Protocol servers for injection surfaces, excessive tool scope, authorization gaps, resource over-exposure, and transport weaknesses across stdio, SSE, and Streamable HTTP deployments. Use when reviewing an MCP server implementation, assessing tool definitions for injection or description manipulation risk, auditing the trust boundary between an AI agent and MCP tools, or reviewing MCP server deployment for authentication and authorization controls.
verified: 2026-07-27

Auditing MCP Servers

An MCP server is a privilege boundary — it translates model-generated requests into real actions (database queries, file operations, API calls, shell commands). The model's output is shaped by user input, which makes every tool parameter an indirect injection surface. The security question is not whether the MCP server is well-coded, but whether an adversarial input to the model can cause the server to do something the user did not intend.

When to Use

• Reviewing an MCP server implementation for security issues
• Assessing tool definitions for injection risk or description manipulation
• Auditing the trust boundary between an AI agent and MCP tools
• Reviewing MCP server deployment for authentication and authorization
• Evaluating resource definitions for data over-exposure
• Checking transport configuration (stdio, SSE, Streamable HTTP) for security

When NOT to Use

• **Broader AI/LLM security including prompt injection without MCP** — use

`securing-ai-systems`. That skill covers the full agent threat model; this one focuses on the MCP server boundary specifically.

• **General source code audit of the server's codebase** — use

`auditing-code-for-vulnerabilities`. Conventional bugs (SQL injection in a query builder, path traversal in file handling) are found the same way regardless of whether the code is an MCP server.

• **Testing the HTTP transport as a REST API** — use `testing-apis`. MCP over

HTTP is not a REST API; the protocol, framing, and threat model differ.

MCP Architecture

User input --> AI model --> MCP client --> MCP server --> Actions
                                |              |
                           (tool calls)   (executes with
                                           server's credentials)

The server exposes three primitive types:

| Primitive | What it does | Security relevance | | --- | --- | --- | | **Tools** | Callable functions the model invokes with parameters | Every parameter is model-generated, influenced by user input | | **Resources** | Data endpoints the client reads into context | Content enters the model's context window and shapes its behavior | | **Prompts** | Reusable prompt templates with arguments | Template arguments are injection surfaces; prompt text is trusted instruction |

The server runs with its own credentials and executes actions the model requests. The client (the AI agent) trusts tool descriptions to decide when and how to call tools. This creates two distinct attack surfaces: the tool definitions that influence the model, and the tool implementations that execute actions.

Tool Definition Review

Tool descriptions are part of the model's prompt. They shape which tool the model calls, when, and with what arguments. A malicious or compromised description can steer model behavior across the entire session.

Check each tool definition for:

• **Accuracy**: does the description honestly describe what the tool does? A

tool described as "search files" that also deletes matches is a misdescription with security impact.

• **Description injection**: instructions embedded in a tool description that

cause the model to behave differently — exfiltrate data through that tool, avoid calling competing tools, or ignore user instructions. Review descriptions for imperative language directed at the model.

• **Parameter schema completeness**: are all parameters typed and constrained?

Missing `enum` values, absent `maxLength`, or `string` where `integer` is meant are all relaxations an attacker can exploit.

• **Required vs. optional**: optional parameters with dangerous defaults (e.g.,

`recursive: true`, `force: true`) that the model might omit.

• **Hidden parameters**: parameters not mentioned in the description that the

implementation accepts and acts on.

# Extract tool definitions from a running server for review
# stdio transport
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | node server.js 2>/dev/null | jq '.result.tools[] | {name, description, inputSchema}'

# Review descriptions for imperative instructions aimed at the model
# Look for: "always", "never", "you must", "do not", "ignore", "instead"

Input Validation

Every tool parameter originates from model output. Model output is influenced by user input. Therefore every tool parameter is an indirect injection surface — the same classes of injection that apply to web form fields apply here, but the input is harder to predict because it passes through the model.

Injection classes to test

| Class | Example tool parameter | Payload | | --- | --- | --- | | SQL injection | `query`, `filter`, `where` | `'; DROP TABLE users; --` | | Command injection | `filename`, `path`, `command` | `file.txt; rm -rf /` | | Path traversal | `filepath`, `resource` | `../../../etc/passwd` | | LDAP injection | `username`, `search` | `*)(uid=*))(|(uid=*` | | Template injection | `template`, `format` | `{{constructor.constructor('return process')()}}` | | NoSQL injection | `filter`, `query` | `{"$gt": ""}` |

For each tool, trace the parameter from the JSON-RPC request to the sink:

Parameter received --> deserialized --> validated? --> used in:
  - SQL query (parameterized or string-concatenated?)
  - shell command (exec or execFile? quoted?)
  - file path (resolved against a root? symlink-aware?)
  - HTTP request (SSRF?)
  - eval / template engine

The question is not wh