Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Treat every MCP server-provided tool definition as untrusted input. Audit the description, parameter schema, return schema, and related metadata; compare them with an approved baseline whenever definitions change; and hold changed definitions for review before an agent can use them. A hash can flag changed metadata, but it cannot establish that the server’s code or behavior is safe. Enforce permissions on the server, not by relying on the model to make access decisions.
What a manifest audit is meant to catch
Tool poisoning is a form of indirect prompt injection in which malicious instructions are embedded in MCP tool descriptions. Because an agent reads descriptions to understand and select tools, altered text can steer it toward unintended actions. Microsoft for Developers describes the threat in its April 28, 2025 article on the Azure MCP Server.
Do not limit inspection to prose. OWASP advises reviewing the whole tool definition, including its name, description, parameter names and types, and return schema. Review definitions both individually and alongside tools from other connected servers: the agent may consider them together when deciding what to call. The goal is to find suspicious instructions, unexpected schema changes, and discrepancies between a tool’s declared purpose and its inputs or outputs—not to award a universal pass score. The OWASP MCP Top 10 does not establish an official scoring rubric for this audit.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesHow to audit an MCP manifest
-
Capture the definitions the client actually receives
Connect with the intended MCP client and record every advertised tool’s name, description, input schema, output schema, and any annotations or metadata exposed alongside the definition. Preserve the server identity and version information with the capture. This observed inventory is the object to review; a server’s marketing description or a separate documentation page is not a substitute for the definitions delivered to the client.
-
Inspect descriptions for instruction-like content
Flag language that attempts to override system or user instructions, asks the model to reveal credentials or hidden context, directs data to an unrelated destination, demands unrelated tool calls, or claims authority beyond the tool’s stated function. Record the exact text and the field where it appears, then assess it in context. These are practical review heuristics derived from the documented tool-poisoning threat, not a standardized official detection rubric. A scanner or clean-looking description cannot prove that every malicious instruction has been found.
-
Check whether schema semantics fit the stated purpose
Compare parameter names, types, required fields, and output structure with what the tool claims to do. Unexpected broad inputs, unrelated fields, or changed return formats are reasons to pause and investigate. A plausible description does not make an unexpectedly permissive schema safe, and a schema that looks ordinary does not make suspicious prose acceptable.
-
Compare every definition with a reviewed baseline
Store the approved definitions and cryptographic hashes alongside the server identity and version. On reconnection or update, compare the newly fetched definitions with the approved baseline. Route differences through human review before making the changed metadata available to agents. Microsoft Learn’s Azure MCP Server security guidance recommends auditing tool descriptions for every configured server, not just Azure tools.
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Review implementation integrity separately
A matching hash shows that the measured metadata matches the stored version; it does not show that server code, dependencies, or behavior behind that definition are unchanged. Assess package provenance, version changes, runtime permissions, and actual behavior as separate audit surfaces. OWASP explicitly cautions that pinning tool definitions does not detect changes to server implementation.
-
Limit the consequences of a bad definition
Give each server only the permissions it needs, and require user approval for sensitive actions where appropriate to the host. Validate authorization for every request in the server. OpenAI’s MCP server guidance says not to rely on the model to decide whether a user has access.
-
Log changes and reassess
Keep records of definition changes and tool invocations so unexpected behavior can be investigated. Re-review definitions and server provenance periodically, as well as when a server version or deployment changes. These steps reduce risk; they are not, by themselves, a complete security audit.
What to do when a definition changes
Do not treat every difference as proof of an attack, but do not silently accept it either. Hold the changed definition from agent use while a reviewer checks the affected field, the tool’s stated purpose, the schema, and the reason for the change. Approve it only through the same change-control process used to establish the baseline; otherwise retain the previously approved definition or disable the tool until the discrepancy is resolved.
Recommended Free Tools
For audit records, preserve the old and new definitions, the server identity and version, the fields that changed, the reviewer’s decision, and the time the change was observed. This makes it possible to distinguish an expected update from an unexplained change and to investigate later tool calls against the definition the agent actually saw.
Which controls cover which risks?
| Control | What it can help address | What it does not establish |
|---|---|---|
| Description and schema review | Suspicious instructions, mismatched purpose, and unexpected parameter or return structures. | That the server implementation behaves as declared or that every malicious instruction will be detected. |
| Approved baseline and metadata hash | Whether the measured tool definition differs from the reviewed version. | Whether code or runtime behavior changed behind unchanged metadata. |
| Context inspection or prompt shields | Potentially, risky content entering agent context, including tool descriptions and outputs. | Server-side access enforcement or guaranteed detection. Microsoft identifies Azure AI Content Safety Prompt Shields as a possible option; suitability depends on the deployment architecture. |
| Server-side authorization and least privilege | Whether each request is permitted and how much a compromised or misused tool can do. | Whether tool descriptions are free of prompt injection. |
These measures belong at different points in a defense-in-depth approach: review and pinning govern metadata changes, context inspection may help scrutinize content presented to an agent, and server-side authorization governs what requests can actually do.
Keep protocol authorization checks in scope
MCP authorization guidance includes audience-bound token validation and PKCE safeguards for clients. These controls address authorization threats; they do not inspect or neutralize malicious prose in a tool description. A manifest audit therefore complements, rather than replaces, protocol and server authorization checks. See the MCP authorization specification.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
