Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

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

An MCP security linter can make risky tool definitions and configuration changes easier to spot before an agent uses them. It cannot prove a server is safe or replace least-privilege access, runtime authorization, and deployment safeguards. I built a linter to inspect this overlooked layer: the names, descriptions, and parameter schemas that MCP servers present to agents.

Why MCP tool definitions need security review

An MCP client discovers tools by receiving definitions from a server. Those definitions include tool names, descriptions, and parameter schemas; the model can use them to decide which tool to call and how to construct its arguments. That makes tool metadata part of the agent’s decision context, not just documentation.

Microsoft’s MCP security guidance describes a missing checkpoint in many integrations: deciding whether a particular agent should be allowed to invoke a particular tool with particular arguments at a particular time. A linter can inspect the advertised interface before use, but it cannot make that authorization decision for every live call.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

What a linter should look for

Instructions hidden in descriptions

OWASP and Microsoft describe tool poisoning: malicious instructions embedded in tool descriptions, where they may influence the agent’s reasoning. A linter can flag instruction-like or unexpectedly broad language for human review. A finding is an indicator, not proof that the text is exploitable; a scan that finds nothing is not proof that the tool is safe.

Changes after approval

A server’s advertised definitions can change after a user approves them. OWASP calls this kind of change a rug pull. Recording and comparing tool names, descriptions, and schemas across versions can surface a changed interface for review rather than silently treating it as the one the user previously approved.

Ambiguous or overbroad interfaces

Unclear descriptions and broad parameter schemas make it harder for people to understand what an agent may do. A useful review can flag vague purpose statements, parameters that appear to grant wide scope, or metadata that does not clearly communicate the action. These are prompts for a maintainer to investigate, not automatic verdicts about intent.

Local startup configuration

MCP’s security guidance notes that local servers are downloaded and executed on a user’s machine. Review their startup commands and configuration as well as their tool metadata: the guidance discusses malicious startup commands and payloads, and local servers exposed through DNS rebinding. A clean-looking tool description cannot establish that the program launched behind it is trustworthy.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

How MCP security approaches differ

Approach What it inspects When it runs and what it returns What it cannot establish alone
Static linting Source code or configuration, and advertised tool names, descriptions, and schemas During development or CI; returns rule hits, review prompts, or definition diffs That runtime behavior matches the inspected material, or that the server is safe
Active audit or probing Observed server behavior under the probes used During an audit; returns observations and a report That untested inputs or behaviors are free of vulnerabilities
Runtime governance Live tool calls and arguments against authorization policy Before execution; returns a policy decision and, where implemented, an audit trail That a sequence of individually permitted calls is harmless

These approaches complement one another rather than compete. A 2025 paper on McpSafetyScanner reported that a scan and report took less than one minute on an M2 Max MacBook Pro in that paper’s experimental setup. That is a result for the described setup, not a general performance guarantee or evidence of the tool’s current maintenance or compatibility.

What to do with a finding

  1. Inspect the exact definition. Review the tool name, description, and schema the client receives. Decide whether the stated purpose and permitted arguments match the task the agent is meant to perform.
  2. Investigate changes before accepting them. Compare current definitions with the version that was reviewed. Ask why a description or schema changed, and require an appropriate human review rather than treating approval of an earlier version as approval of every later one.
  3. Check the program and configuration behind the tools. For a local server, review its startup command, configuration, and downloaded code through your deployment process. Metadata review alone cannot validate those components.
  4. Test the issue in context. Determine whether the flagged text or behavior can affect the agent, the connected systems, or the data available to it. Record the evidence and the decision; do not equate a lint rule firing with confirmed exploitation.
  5. Constrain the consequences. Give the agent an identity with only the roles and permissions its task requires, and put consequential calls behind authorization controls where possible.

Why approval and prompt instructions are not enough

Human approval can reduce risk, but it is not a substitute for verification: Google Cloud’s guidance notes that users may approve malicious or destructive actions without adequately checking them. Approval works best when the reviewer can see what the call will do and the identity making it has limited authority.

Prompt-only safety instructions also have limits. Microsoft reported a 26.67% policy-violation rate in an internal red-team evaluation using 60 prompts—45 adversarial and 15 valid—mapped to the OWASP Agentic Top 10. This is a result from that evaluation, not a rate for MCP deployments generally. Microsoft recommends prompt shields and supply-chain security as defenses against tool poisoning; neither should be treated as a guarantee that prompt injection is eliminated.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Runtime controls still matter

Where possible, check each consequential call before execution: which agent is calling, which tool it is invoking, what arguments it supplies, and whether the action is permitted at that moment. Per-call governance has its own boundary. Microsoft notes that its described approach governs individual calls and does not yet correlate sequences of allowed calls, so a harmful workflow may be assembled from calls that each pass separately.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The MCP security guidance also says authorized servers must verify inbound requests and must not treat possession of a state handle as authentication. A linter cannot enforce those server-side requirements merely by inspecting advertised tools; they need to be handled in the server’s authorization and deployment design.

A linter is an inspection aid, not a safety certificate

OWASP identifies risks that span connected servers, including tool shadowing, confused-deputy behavior, and data exfiltration through apparently legitimate channels. Because descriptions from connected servers can enter the model’s context, reviewing one server’s metadata in isolation may miss interactions with other tools.

Static checks can reveal suspicious patterns and definition changes, while active probes can reveal behavior under specific test conditions. Neither proves the absence of vulnerabilities. Runtime policies can block calls, but may not recognize a dangerous multi-call sequence. The defensible claim for a linter is therefore modest: it helps people notice and review part of the risk surface.

The NSA Artificial Intelligence Security Center’s May 20, 2026 announcement put the implementation concern plainly: “While MCP simplifies the integration of diverse capabilities into powerful agent workflows, the current protocol specification requires careful and cautious implementation for security.”

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

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.