Scan an MCP server before connecting your AI agent

In short

• An MCP server supplies tool names, descriptions, and parameter schemas. Agents read this information to decide which tools to use and how to use them.
• Scanning that metadata before connecting can reveal suspicious instructions without granting the server access to files or credentials.
• The result is a snapshot. Later changes and tool responses need their own controls.

MCP makes it easy to give an agent a new capability. Add a server address or configuration, restart the client, and another service becomes available. A security decision happens before the first tool call: when the client connects, it receives a catalog of tools with descriptions and schemas. The model uses that text as context for its decisions.

Our earlier article on the MCP attack surface covers the wider risks around agents and tools. This article focuses on the earlier question: how do you inspect a server before adding it to an agent's tool catalog?

Tool descriptions are security-relevant input

Ordinary API documentation informs a human about an endpoint. An MCP tool description is also read by a language model. Alongside legitimate documentation, it can contain instructions that steer the model beyond the user's task. This is tool poisoning.

The OWASP MCP Security Cheat Sheet identifies tool descriptions, parameter schemas, and return values as possible carriers of manipulation. A reasonable tool name does not tell you what the complete entry says. Inspect the text the server actually publishes, including whether it tries to direct the agent toward unrelated files, other tools, or unexpected destinations.

The infrastructure behind a registry entry can change too. In research announced on September 24, 2026, OX Security examined 15,465 published MCP servers and 5,095 unique hostnames. At the time of its analysis, 2.3 percent of those hostnames no longer resolved, and six domains were available to register again. A server's geographic location is not a security verdict by itself. The figures do show why an old registry entry cannot establish who operates an endpoint today or what code it now serves.

Scan before connecting

For public remote MCP servers, the Patronus Scan API can assess published MCP metadata. The MCP integration documentation explicitly describes this as scanning without executing the server's tools. Scan only servers you operate or are authorized to assess.

A practical review has five steps:

1. Verify the address and operator. Check that the URL belongs to the expected provider and that you are allowed to assess the server.
2. Capture the metadata. Review tool names, descriptions, and input schemas before the agent can use the server.
3. Assess suspicious content. Look for instructions outside the stated tool purpose and parameters broader than the task requires.
4. Limit permissions. Give the server and agent only the access needed for the specific workflow.
5. Watch for changes. Record the approved tool definition and review it again after updates or a change of operator.

The API returns an assessment. Your application or security process decides whether to connect, review, or reject the server. A clean result does not prove the server will remain trustworthy.

Keep checking after connection

A server can change its tool descriptions after approval. It can also publish harmless metadata and later return manipulated content in a tool response. A pre-connection scan does not cover that later channel. OWASP therefore recommends least privilege, monitoring changes to tool definitions, and treating external tool output as untrusted data.

The practical benefit is a control point before trust is granted. You do not have to give an unknown MCP server file access or credentials just to learn what tools and instructions it wants to present to an agent.

To assess a server you operate or are authorized to test, start with the Patronus API documentation. Metadata scanning is one part of securing the agent's subsequent tool calls.