Skip to main content
Glama

prompt_injection_check

Detect prompt injection and jailbreak attempts in untrusted text such as scraped web pages, emails and tool output. JSON body {text} (max 50,000 chars). Rule-based detection of instruction override phrasing, role spoofing tags, data leak links and hidden Unicode in 6 languages. Returns verdict safe, suspicious or malicious, a 0-100 score and matched spans. Text is not stored. Free tier: 25 calls/day per IP with header X-Free-Call: 1 (or ?free=1). Price $0.005 USDC per call via x402. Example output: {"verdict":"safe","score":0,"chars":56,"categories":{},"matches":[]}

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_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
freeNoUse the shared free allowance (25 successful calls per IP per UTC day across eligible tools). Defaults to false.
textYesText to screen, max 50,000 characters

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / free
      Added value: +{
      +  "description": "Use the shared free allowance (25 successful calls per IP per UTC day across eligible tools). Defaults to false.",
      +  "type": "boolean"
      +}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the rule-based method and its six-language scope, the exact verdict vocabulary (safe/suspicious/malicious) plus 0-100 score and matched spans, the 50,000-character limit, non-retention of text, and both the free-tier quota and paid x402 pricing. Rate limits, privacy behavior and cost are exactly the traits annotations would otherwise have to supply.

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

Conciseness4/5

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

Front-loaded with purpose, then constraints, pricing and an inline example — dense but nearly every clause carries decision-relevant information. The example output is slightly bulky but compensates for the absent output schema, so waste is minimal.

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?

There is no output schema, yet the definition supplies the verdict enum, score range, matched-span concept and a literal example payload, so an agent knows what comes back. Input limits, cost and quota are all covered, leaving no gap an agent needs before calling it.

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 is 3, but the description adds meaning beyond the schema by explaining how the free allowance is invoked in practice (X-Free-Call header or ?free=1) and bounding the text length. The 25-calls-per-IP-per-day context makes the boolean `free` flag actionable.

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 ('Detect prompt injection and jailbreak attempts in untrusted text') and immediately scopes the input domain to scraped web pages, emails and tool output. An agent can tell this is a security screening tool distinct from content tools like safe_web_read without opening the schema.

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?

The 'such as scraped web pages, emails and tool output' clause gives clear situational triggers for when to call it. It stops short of explicit when-not-to-use guidance or naming a sibling alternative, so it is strong but not complete routing guidance.

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