Lordevo Shop (x402 website checks)

Prompt-injection scan for untrusted text ($0.002/call)

prompt_injection_scan

Read-onlyIdempotent

$0.002 per call (x402, USDC on Base; free trial: add "trial": true or use try_free). [Data utilities] Screens text an agent is about to read (web page, email, tool output, document) for prompt injection: instruction overrides ("ignore previous instructions"), role hijacks and jailbreak modes, fake chat delimiters (<|im_start|>, [INST], "system:" lines), requests to reveal the system prompt or send secrets, Markdown-image exfiltration URLs, hiding things from the user, coerced tool calls, payments or shell one-liners, and text hidden from humans (zero-width, bidi and Unicode tag characters, HTML comments, display:none blocks, base64), which is decoded and scanned too. Returns verdict likely_injection / suspicious / no_injection_found, a 0-100 score, findings with excerpt and line, and hidden-content counts. Rule-based and offline: not a model and not a guarantee. Input: text (POST for long text), optional format, max_findings, clean. Limit: 200,000 characters.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "text": "<text>"
    },
    "name": "prompt_injection_scan"
  }
}

Input Schema

Name	Required	Description	Default
`text`	Yes	Untrusted text, HTML or Markdown to scan, 1-200,000 characters (POST JSON {"text": "..."} for long text)
`clean`	No	yes: also return cleaned_text with invisible characters (zero-width, bidi, Unicode tags) removed	no
`trial`	No	Optional. true = free if a trial call is left (3 per IP per UTC day), else the payment terms.
`format`	No	auto (default, detected), text, html or markdown; html and markdown also read HTML comments and hidden elements	auto
`max_findings`	No	Findings returned, 1-200 (default 50)	50

Output Schema

Name	Required	Description
`tool`	No
`cache`	No
`lines`	No
`notes`	No
`score`	No
`_trial`	No	Present when the call was a free trial call.
`format`	No
`verdict`	No
`findings`	No
`provider`	No
`price_usd`	No
`categories`	No
`confidence`	No
`text_length`	No
`cleaned_note`	No
`cleaned_text`	No
`finding_count`	No
`hidden_content`	No
`recommendation`	No
`findings_truncated`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

changedInput schema / properties / trial / description

Previous value: -"Optional. true = answer free if a trial call is left (3 per IP per UTC day); otherwise you get the payment terms."New value: +"Optional. true = free if a trial call is left (3 per IP per UTC day), else the payment terms."

AddedNov 3, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: declares the method is rule-based and offline (consistent with openWorldHint=false), explicitly disclaims it is not a model and not a guarantee, states the 200,000-character limit, the cost model, and that base64 payloads are decoded and scanned. It also previews the verdict taxonomy and finding structure, so an agent knows both the safety profile and the failure modes.

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 content is dense and largely earns its place, but it is delivered as one long run-on sentence after a pricing lead. Leading with '$0.002 per call' rather than the purpose pushes the most decision-relevant information to the second position, and the attack-class list could be tightened without losing coverage.

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 an output schema already available, the description is more than sufficient: it covers input limits, transport for long text, detection scope, disclosed limitations, and cost. Nothing an agent needs in order to call it correctly or interpret its reliability 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 3 is the baseline; the description adds real meaning on top by explaining that long text should be POSTed, that format selection changes whether HTML comments and hidden elements are read, and that clean removes invisible characters from a returned cleaned_text. It does not, however, add anything for max_findings beyond the schema's own 1-200 default-50 documentation.

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 ('Screens text an agent is about to read ... for prompt injection') and enumerates the exact attack classes detected, so the agent knows precisely what capability this is. It is distinguishable from every sibling (none of which is a content-safety scanner) and even flags try_free as the payment-side alternative.

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 clear triggering context: use it on 'text an agent is about to read (web page, email, tool output, document)', and notes the free-trial path via 'trial': true or try_free. It never states when not to rely on it beyond 'not a model and not a guarantee', and gives no guidance on how to react to each verdict.

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

All Lordevo Shop (x402 website checks) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?