How to Test MCP Servers & AI Agent Tools for Security

When an MCP client queries an MCP server via tools/list, the server returns tool names, descriptions, and input schemas. The host application injects these descriptions verbatim into the LLM's system prompt so the model knows when to invoke each tool. A malicious server can embed adversarial instructions directly inside tool descriptions, commanding the model to prioritize its tool, bypass guardrails, or leak private conversation data.

Enforce static analysis and cryptographic hashing on tool descriptions. Alert on schema mutations where an existing, approved tool updates its description post-authorization.

When an MCP tool executes, its return payload (such as web page HTML, an email body, or database records) is ingested directly back into the LLM's context window. If that external content contains instructions, the LLM may interpret them as user directives, hijacking the rest of the agent's multi-step plan.

Isolate tool return values inside tagged delimiters (e.g. <untrusted_tool_output>) and apply secondary input guardrails to scan tool returns before re-submitting them to the planning LLM.

Because tool arguments originate from an LLM, developers often mistakenly treat them as sanitized, validated inputs. In reality, LLM-generated arguments are untrusted user inputs. If an MCP server interpolates arguments directly into shell commands (exec()), SQL queries, or filesystem paths (fs.readFile()), attackers can achieve command injection, SQL injection, or path traversal.

Implement strict JSON Schema validation on all tool arguments, use parameterized queries, and avoid direct shell execution in favor of explicit argument arrays with non-root sandboxing.

As detailed in the official Model Context Protocol security specification, an MCP proxy or server using a static OAuth client ID to interact with a third-party authorization server can allow a malicious MCP client to acquire valid authorization codes without the end-user's informed consent.

Require explicit, out-of-band user consent screens before forwarding authorization requests to third-party IDPs, and validate state and PKCE parameters on every flow.

An MCP server that accepts OAuth tokens issued for other services and blindly forwards them downstream destroys audience validation (aud claim), audit attribution, and permission scoping. The official MCP specification strictly prohibits token passthrough: servers must accept only tokens explicitly issued for their own audience.

MCP servers must validate JWT audience claims strictly and exchange user tokens for dedicated downstream service tokens via OAuth Token Exchange (RFC 8693).

During remote server connection or OAuth metadata discovery, a malicious server can specify redirect endpoints or resource URLs pointing to cloud metadata addresses (e.g. http://169.254.169.254) or internal private VPC IPs (10.0.0.0/8, 192.168.0.0/16), exfiltrating instance credentials.

Clients and proxies must filter outgoing HTTP requests, blocking link-local addresses, loopback interfaces, and private CIDR blocks on all discovery requests.

When an MCP server tracks multi-step tasks using state handles or context IDs (e.g. pagination cursors, workflow run IDs), these handles must be cryptographically bound to the authenticated user's session. Unbound, predictable, or sequential handles allow attackers to inspect or hijack another tenant's agent execution state.

Generate high-entropy UUIDv4/HMAC tokens for all workflow handles and enforce tenant authorization checks on every state retrieval.

Many popular desktop AI tools (Claude Desktop, Cursor) run local MCP servers as subprocesses via stdio communication. These servers execute with the full privileges of the logged-in user. If an MCP server configuration uses unverified shell command strings or npm packages, installing a server can grant an attacker full local code execution.

Execute local servers inside containerized environments (Docker, Podman) or macOS/Windows sandboxes with restricted filesystem and network access.