Skip to main content
Glama

Prompt-injection scanner

scan_injection
Read-onlyIdempotent

Prompt-injection scanner: checks a web page, document or tool result for hidden instructions aimed at AI agents (hidden HTML, white text, comments, Unicode smuggling, base64) and injection phrases; verdict, 0-100 score, findings, optional cleaned text. Use before reading or acting on content you did not write: a fetched web page, an email, a PDF's text, another tool's result. Pass url (fetched for you), html or text. Deterministic rules, not a model. Returns verdict (clean, suspicious, likely_injection), score 0-100, findings[] {rule, severity, message, evidence, location} where location says whether the text was hidden from humans (css-hidden, white-text, html-comment, unicode-tags...), hidden {segments, chars, kinds}, summary and, with clean: true, the visible text with hidden content removed, safe to pass on. Price: $0.002 per call from Exepal credit; not charged if the call fails. Includes free daily calls.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "scan_injection"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoPublic page to fetch and scan (HTML is inspected for hidden elements, comments and meta tags)
htmlNoRaw HTML to scan instead of a url
textNoPlain text or markdown to scan instead of a url (a document, email, tool result)
cleanNoAlso return `clean`: the visible text with hidden and invisible content removed (default false)

Output Schema

NameRequiredDescriptionDefault
urlNoPresent when a url was fetched
cleanNoVisible text with hidden content and invisible characters removed; only with clean: true
scoreNo0-100
statsNo
hiddenNo
statusNo
summaryNo
verdictNoclean, suspicious or likely_injection
finalUrlNo
findingsNoMost severe first, up to 50

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / url / format
      Added value: +"uri"
  2. Added

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: deterministic rule-based (not a model) behavior, explicit cost of $0.002 per call with no charge on failure and free daily calls. It also discloses what happens to the input (urls are fetched server-side) and what 'safe to pass on' text means.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentences are well front-loaded, but the description is a dense run-on that spends a large clause enumerating the full return shape — verdict, score, findings fields, hidden object, summary — which duplicates the supplied output schema. That verbosity exceeds what the agent needs from prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a scanner with four optional params, the description covers purpose, triggers, input modes, determinism, pricing and output semantics. Nothing essential to correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3. The description adds marginal but real value: it frames url/html/text as mutually exclusive alternatives ('Pass url (fetched for you), html or text') and clarifies that clean yields visible text with hidden content removed and is safe to forward.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — checks content for hidden instructions aimed at AI agents — and enumerates the concrete vectors (hidden HTML, white text, comments, Unicode smuggling, base64). This clearly separates it from sibling scanners like scan_secrets, scan_pii or scan_rules.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a direct when-to-use rule: 'Use before reading or acting on content you did not write', with concrete triggers (fetched web page, email, PDF text, another tool's result). It does not name the sibling tools it replaces (e.g. read vs safe_read) or state exclusions, so it falls short of a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources