Skip to main content
Glama

canary_sanitize

Read-only

Deterministic prompt-injection firewall and honeypot scrubber for AI agents. Sanitizes untrusted text and blocks detected wallet-draining commands before context ingestion. Price: 0.010 USDC on Base or Solana.

Input Schema

NameRequiredDescriptionDefault
contentYesUntrusted text or web content to sanitize
strict_modeNo

Output Schema

NameRequiredDescriptionDefault
statusYesClassification of the input content
risk_scoreYesHeuristic risk severity between 0.0 and 1.0
safety_receiptNoCryptographic safety verification proof
sanitized_contentNoSanitized text safe for model context
injection_detectedNoWhether an exploit or injection payload was identified
threats_neutralizedNoNeutralized prompt injection patterns

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "injection_detected": {
      +      "description": "Whether an exploit or injection payload was identified",
      +      "type": "boolean"
      +    },
      +    "risk_score": {
      +      "description": "Heuristic risk severity between 0.0 and 1.0",
      +      "maximum": 1,
      +      "minimum": 0,
      +      "type": "number"
      +    },
      +    "safety_receipt": {
      +      "description": "Cryptographic safety verification proof",
      +      "type": "string"
      +    },
      +    "sanitized_content": {
      +      "description": "Sanitized text safe for model context",
      +      "type": "string"
      +    },
      +    "status": {
      +      "description": "Classification of the input content",
      +      "enum": [
      +        "clean",
      +        "sanitized",
      +        "blocked"
      +      ],
      +      "type": "string"
      +    },
      +    "threats_neutralized": {
      +      "description": "Neutralized prompt injection patterns",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "status",
      +    "risk_score"
      +  ],
      +  "type": "object"
      +}
  2. Changed5 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / content / description
      Added value: +"Untrusted text or web content to sanitize"
    • removedInput schema / properties / content / maxLength
      Removed value: -50000
    • removedInput schema / properties / content / minLength
      Removed value: -1
  3. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description adds genuinely new context: determinism, that wallet-draining commands are actively blocked, and the payment requirement (0.010 USDC on Base or Solana). What it omits is what happens to blocked or scrubbed content — redaction, removal, or error — which matters for a tool that transforms text before the agent reads it.

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?

Three tight sentences, front-loaded with the capability and ending with the practical cost detail. The pricing sentence is useful for an agent that must decide whether to call a paid tool, though the description could have used that space for strict_mode instead.

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

Completeness3/5

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

An output schema exists, so return values need not be explained, and the payment model is disclosed. Still missing is the semantics of strict_mode and the observable effect of a 'block' on the returned content — gaps an agent needs filled before invoking a sanitizer on untrusted input.

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

Parameters2/5

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

Schema coverage is only 50%: 'content' is documented in the schema, but 'strict_mode' has no description in either the schema or the description text, despite defaulting to true and materially changing blocking behavior. The description's mention of blocking commands gestures at strictness but never explains the flag, leaving a required decision undocumented.

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 ('sanitizes untrusted text', 'blocks detected wallet-draining commands') plus the deployment point ('before context ingestion'). The framing as a prompt-injection firewall distinguishes it from siblings like inspectPhishingUrl, auditMcpToolPoisoning, and guardAgentMemory, which operate on URLs, tool definitions, or memory stores rather than raw untrusted text.

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?

'Before context ingestion' gives a clear trigger condition an agent can act on. However, it never states when not to use it, nor names an alternative for overlapping cases such as guardAgentMemory or auditMcpToolPoisoning, so routing between siblings is left partly to inference.

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.