Auditing MCP Servers

An MCP server hands an agent a set of tools, and the descriptions of those tools are loaded straight into the model's context — which makes them instructions the model may follow, not inert documentation. That is the crux: a malicious or compromised server can hide directives in a tool description ("tool poisoning"), shadow a trusted tool, or change a description after you approved it ("rug pull"), and a capable model will quietly comply. This skill audits the server implementation itself — what its tools can do to the agent and the data the agent can reach — rather than deciding whether to install it.

Confirm the server (and any remote endpoint) is in scope per AGENTS.md. Active checks like SSRF probing run only against a server you own or are authorized to assess, and callbacks stay on operator-controlled infrastructure.

When to Use

• Auditing an MCP server's implementation for how it can steer or exfiltrate from an agent
• Inspecting tool descriptions and input schemas for hidden instructions or unbounded inputs
• Testing a URL-fetching tool for SSRF into metadata/loopback services
• Reviewing transport, authentication, and network exposure of a remote MCP server
• Checking for rug-pull risk (description drift after approval) and toxic tool combinations

When NOT to Use

• Deciding whether a skill/plugin/MCP server is safe to install at all — use vetting-agent-extensions; this skill is the deeper implementation audit once you are assessing the server itself
• Securing the LLM/agent application around it (prompt injection, excessive agency in your own app) — use securing-ai-systems
• Dependency, provenance, and release-signature risk of the server package — use auditing-supply-chain
• Web/API flaws in a remote server's HTTP surface beyond MCP — use testing-web-applications / testing-apis
• Writing up findings — use reporting-security-findings

Read the Tool Descriptions as Attacker Input

Enumerate the tools and read every description and schema as untrusted, model-visible text.

# Static scan for poisoned descriptions, shadowing, and toxic flows
uvx mcp-scan@latest ~/.cursor/mcp.json --json > mcp_report.json
uvx mcp-scan@latest inspect ~/.cursor/mcp.json      # dump raw descriptions

In the raw descriptions look for what a scanner can miss:

• Agent-directed imperatives — "do not tell the user", "first read ~/.ssh/id_rsa", <important> blocks, fake nested documentation.
• Zero-width or Unicode-obfuscated characters hiding instructions.
• URLs or exfiltration endpoints referenced in a description or default example.
• Descriptions that mismatch the tool's actual function (shadowing a trusted name).

Enumerate programmatically to verify tool count, names, and schemas against the documentation, and flag input fields that accept unbounded data (raw URLs, command strings, file paths):

from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
# initialize a session, then session.list_tools(); inspect each name/description/inputSchema

Active Checks (owned/authorized servers only)

• SSRF via URL-fetching tools. Point a fetch tool at metadata and loopback targets (http://169.254.169.254/latest/meta-data/, http://127.0.0.1:*, file:///etc/passwd). Returned IMDS credentials or loopback banners are a finding. Callbacks must be in-scope operator infrastructure.
• Transport and auth exposure. For HTTP/SSE servers, confirm authentication is required, the server binds to localhost or a restricted network rather than 0.0.0.0, and TLS is enforced. curl -si http://host:port/sse | head and ss -tlnp reveal unauthenticated listeners.
• Secrets handling. Descriptions/schemas must not request API keys or SSH keys in plaintext parameters or reference env-var secrets to use; responses must not leak secrets back into the agent context.

Rug Pulls and Toxic Flows

• Rug pull. Pin tool-description hashes and re-audit on change (mcp-scan tracks hashes; run it in CI on config changes). A description that mutates after approval is re-audited before re-trusting.
• Toxic flow. A read-files tool plus an HTTP-send tool is an exfiltration pipeline; a secrets-reading tool plus an external-logging tool is a credential leak. Assess tool combinations, not just each tool alone, and constrain them by policy.

Rationalizations to Reject

• "The tool descriptions are just docs." They are loaded into the model as instructions. Read them as attacker-controlled input.
• "mcp-scan came back clean, so it's safe." Scanners miss novel obfuscation and semantic poisoning. Read the raw descriptions and assess toxic flows by hand.
• "It passed audit once." Descriptions can change post-approval (rug pull). Pin hashes and re-audit on drift.
• "SSRF is a web thing, not an MCP thing." A URL-fetching MCP tool is a first-class SSRF sink straight into cloud metadata. Test it.
• "It only runs locally over stdio." Local still reads your files and secrets and can exfiltrate through its own network tools. Local is not safe by default.

Deliverable

# MCP Server Audit <MCP-###>     Date: <UTC>   Auditor: <name>
Server / scope:   <name, transport (stdio/SSE/HTTP), endpoint, in-scope confirmation>
Tool inventory:   <names, description hashes — pinned for rug-pull tracking>
Poisoning:        <hidden instructions / shadowing / obfuscation found>
SSRF / inputs:    <URL-fetch and unbounded-input results>
Transport / auth: <auth required? binding? TLS?>
Secrets:          <handling issues in descriptions/schemas/responses>
Toxic flows:      <tool combinations enabling exfil/leak>
Supply chain:     <source open? releases signed? deps pinned/scanned?>
Findings:         <each with severity + remediation>   Map: ATLAS AML.T0010, OWASP MCP03:2025

Log findings via maintaining-engagement-state. Map to MITRE ATLAS (AML.T0010, ML supply-chain compromise) and OWASP for LLM/Agentic apps — cite real control IDs and re-verify before reporting.

References

• vetting-agent-extensions — the install/no-install decision this audit informs
• securing-ai-systems — the agent/LLM application that consumes these tools
• auditing-supply-chain — provenance, releases, and dependencies of the server package
• testing-web-applications — SSRF and HTTP-surface testing for remote servers
• mcp-scan (Invariant Labs), MCP SDK; MITRE ATLAS, OWASP Top 10 for LLM/Agentic Applications