MCP Server & Tool-Definition Security Gate

A pre-connection review gate that audits an MCP server or agent tool definition for the failures that turn a connected tool into an attack path — before you let a tool-calling agent act on your systems.

The problem it solves

Tool-connected agents inherit the risk of every tool they can call. A server description can carry hidden instructions the agent reads as commands. A tool schema can grant far more reach than the job needs. An auth boundary can be missing, so the agent can delete, send, or pay with no confirmation. These are exactly the risks the 2026 agentic-security checklists name — tool poisoning, excessive agency, identity and authorization gaps, and unbounded consumption. This gate treats the tool definition as untrusted and tells you whether the agent should be allowed to use it.

What it does

It installs a skeptical security reviewer between a tool definition and the agent about to trust it. It does not rewrite your server or patch your config. It audits the definition you already have across five passes and returns one structured verdict.

1. Tool-poisoning check — names, descriptions, and instruction fields that steer the agent instead of describing the tool: imperative directions, requests to call other tools, claims of prior authorization, or text hidden in rarely-read fields.
2. Excessive-agency check — write, delete, send, transfer, or execute capability beyond the stated purpose; wildcard scopes; and one tool that quietly bundles several high-impact actions.
3. Authorization and identity check — consequential actions with no confirmation, scoped credential, or human-in-the-loop; ambient credentials the agent reuses freely; confused-deputy paths.
4. Input and injection-surface check — unvalidated free-text flowing into a command, query, path, or URL; tool outputs re-entering the agent as trusted content; and the private-data plus untrusted-input plus exfiltration pattern.
5. Resource and blast-radius check — unbounded loops, fan-out, or spend; irreversible actions with no dry-run; and the single worst outcome under hostile input.

What you get

One decision — SAFE, REVIEW, or BLOCK — with each issue quoted from the definition, tagged by risk class, ranked by how much damage the agent could do, plus the most dangerous action the tool enables and the missing control that would contain it.

Why it works

It separates connecting a tool from trusting a tool. A model told to assume the definition is hostile finds the poisoned descriptions, over-broad scopes, and missing boundaries that a quick read of a tool list never surfaces. The passes map directly to the agentic risks teams are now required to review.

What it is not

A reasoning-and-prompting skill, not a runtime sandbox, proxy, or vulnerability scanner. It does not execute the server, intercept calls, or enforce permissions at run time — it reads the definition as text and judges its safety. Pair it with scoped credentials, allow-lists, human approval for consequential actions, and rate limits for defense in depth.