Skip to main content
Glama

Check text for leaked secrets before sending it

scan_for_leaks
Read-onlyIdempotent

Check text BEFORE your agent sends it to an LLM, tool, log or webhook: finds crypto wallet keys (BIP39 seed phrases with checksum, EVM/Solana private keys, WIF, xprv), API secrets (GitHub, AWS, Stripe, OpenAI, Anthropic, Slack, Telegram, npm, JWT, PEM) and PII (cards, IBAN, SSN, email, phone). Free preview tier: verdict, safe_to_send and counts by type (text up to 8192 bytes). Redacted text: paid x402 endpoint /v1/lite ($0.005); JSON payloads and live balances of wallets whose keys leaked: /v1/scan ($0.02).

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": "scan_for_leaks"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesText to check before it is sent (prompt, tool arguments, log, message, file content). POST /v1/scan also accepts {"json": <any JSON payload>}.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations by disclosing the free tier's exact return shape (verdict, safe_to_send, counts by type), the 8192-byte input limit, and what each paid endpoint adds at what price. Cost and payload-size constraints are precisely the behavior an agent needs and cannot get from annotations.

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?

Purpose and the 'before sending' trigger are front-loaded, and the detector list and pricing are compressed into dense clauses with no filler. It is somewhat over-packed — detector taxonomy and endpoint pricing compete for attention — but nothing is redundant.

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?

With no output schema, the description carries return-value disclosure itself and does so fully: free tier yields verdict, safe_to_send and per-type counts; paid tiers add redacted text and injected JSON/live-balance data. Combined with the input limit, an agent has everything needed to call it and interpret the result.

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% and there is only one parameter, so the schema already carries the burden. The description still adds the 8192-byte ceiling and mentions the alternate JSON payload form that the schema only parenthetically notes, which is genuine added meaning.

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 ('check text ... finds crypto wallet keys ... API secrets ... PII') and enumerates the exact secret categories detected, so the scope is unambiguous without opening the schema. The 'BEFORE your agent sends it' framing pins down the point of application.

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?

Explicitly names the moments to use it ('before your agent sends it to an LLM, tool, log or webhook') and explains the free-preview vs. paid-endpoint split with prices, which effectively tells the agent which tier applies to which need. No sibling tools exist, so there is no alternative-tool routing to state, but it also does not state what to do if the text exceeds 8192 bytes.

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