Skip to main content
Glama
mcp-secret-sentinel

mcp-secret-sentinel

scan_text

Read-onlyIdempotent

Scan code, config, diffs, or logs for exposed API keys, tokens, credentials, private keys, and high-entropy strings, returning redacted findings while skipping placeholders and allowlisted lines.

Instructions

Scan a snippet of text or code for exposed secrets.

64 detectors: GitHub/GitLab/npm/PyPI tokens; OpenAI, Anthropic, xAI, DeepSeek, Perplexity, OpenRouter, Groq, NVIDIA, Hugging Face, Replicate, Together, Cerebras, LangSmith, Langfuse, Pinecone, Firecrawl and Tavily keys; AWS (incl. Bedrock), Azure, Google, DigitalOcean, Cloudflare, Vercel, Supabase, Neon, PlanetScale, Fly.io, Databricks, Vault and Doppler credentials; Stripe, Square, Shopify, SendGrid, Resend, Mailchimp, Twilio, Slack, Discord, Telegram, Linear, Notion, Atlassian, Postman, Sentry, Grafana and PostHog tokens; JWTs, private and age keys, credentialed connection strings and URLs, generic password/secret/token assignments, plus high-entropy strings. Placeholders ($VAR, ${VAR}, {{ templates }}, changeme, masked values...) are skipped, and a line carrying "secret-sentinel: ignore", "pragma: allowlist secret" or "gitleaks:allow" is counted in "suppressed" instead of reported.

Args: text: The raw text to scan (code, config, diff output, logs...). source_name: Label used in each finding's "file" field. max_findings: List at most this many findings, most severe first (default 200, 0 = no limit). When capped, the result adds truncated, total_findings, counts_by_severity, counts_by_pattern and top_files.

Returns: {"clean", "findings": [{"file", "line", "pattern", "severity", "redacted", "advice"}], "files_scanned", "summary"}. Secret values are ALWAYS redacted (at most 4 chars, never more than a quarter of the value, + length); the full value is never included.

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

Input Schema

NameRequiredDescriptionDefault
textYes
source_nameNoinput
max_findingsNo

Output Schema

NameRequiredDescriptionDefault
cleanYes
summaryYes
findingsYes
baselinedNo
top_filesNo
truncatedNo
suppressedNo
files_scannedYes
total_findingsNo
counts_by_patternNo
counts_by_severityNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$defs": {
      +    "FileCount": {
      +      "properties": {
      +        "file": {
      +          "title": "File",
      +          "type": "string"
      +        },
      +        "findings": {
      +          "title": "Findings",
      +          "type": "integer"
      +        }
      +      },
      +      "required": [
      +        "file",
      +        "findings"
      +      ],
      +      "title": "FileCount",
      +      "type": "object"
      +    },
      +    "Finding": {
      +      "properties": {
      +        "advice": {
      +          "title": "Advice",
      +          "type": "string"
      +        },
      +        "commit": {
      +          "anyOf": [
      +            {
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "title": "Commit"
      +        },
      +        "file": {
      +          "title": "File",
      +          "type": "string"
      +        },
      +        "line": {
      +          "title": "Line",
      +          "type": "integer"
      +        },
      +        "pattern": {
      +          "title": "Pattern",
      +          "type": "string"
      +        },
      +        "redacted": {
      +          "title": "Redacted",
      +          "type": "string"
      +        },
      +        "severity": {
      +          "enum": [
      +            "critical",
      +            "high",
      +            "medium"
      +          ],
      +          "title": "Severity",
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "file",
      +        "line",
      +        "pattern",
      +        "severity",
      +        "redacted",
      +        "advice"
      +      ],
      +      "title": "Finding",
      +      "type": "object"
      +    }
      +  },
      +  "properties": {
      +    "baselined": {
      +      "anyOf": [
      +        {
      +          "type": "integer"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "title": "Baselined"
      +    },
      +    "clean": {
      +      "title": "Clean",
      +      "type": "boolean"
      +    },
      +    "counts_by_pattern": {
      +      "anyOf": [
      +        {
      +          "additionalProperties": {
      +            "type": "integer"
      +          },
      +          "type": "object"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "title": "Counts By Pattern"
      +    },
      +    "counts_by_severity": {
      +      "anyOf": [
      +        {
      +          "additionalProperties": {
      +            "type": "integer"
      +          },
      +          "type": "object"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "title": "Counts By Severity"
      +    },
      +    "files_scanned": {
      +      "title": "Files Scanned",
      +      "type": "integer"
      +    },
      +    "findings": {
      +      "items": {
      +        "$ref": "#/$defs/Finding"
      +      },
      +      "title": "Findings",
      +      "type": "array"
      +    },
      +    "summary": {
      +      "title": "Summary",
      +      "type": "string"
      +    },
      +    "suppressed": {
      +      "anyOf": [
      +        {
      +          "type": "integer"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "title": "Suppressed"
      +    },
      +    "top_files": {
      +      "anyOf": [
      +        {
      +          "items": {
      +            "$ref": "#/$defs/FileCount"
      +          },
      +          "type": "array"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "title": "Top Files"
      +    },
      +    "total_findings": {
      +      "anyOf": [
      +        {
      +          "type": "integer"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "title": "Total Findings"
      +    },
      +    "truncated": {
      +      "anyOf": [
      +        {
      +          "type": "boolean"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "title": "Truncated"
      +    }
      +  },
      +  "required": [
      +    "clean",
      +    "findings",
      +    "files_scanned",
      +    "summary"
      +  ],
      +  "title": "ScanReport",
      +  "type": "object"
      +}
  2. First observedv0.2.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important behavior: placeholder handling, suppression-comment semantics, redaction guarantees, and max_findings truncation effects including added result fields. This is substantial operational context that helps an agent invoke and interpret the tool correctly.

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 purpose is front-loaded, but the long enumeration of dozens of provider and service detectors is verbose for a tool description. That list is informative but not essential for correct invocation, and it makes the definition less concise than it could be.

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?

Given the tool's complexity, the description is complete: it covers what is scanned, how findings are suppressed, how redaction works, parameter behavior, and expected return fields. The presence of an output schema reduces the burden, but the added behavioral detail makes the definition self-sufficient.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates by documenting all three parameters: text as raw input, source_name as the finding label, and max_findings with its default, cap behavior, and special 0 value. It also explains the extra result fields produced when truncation occurs.

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?

The description opens with a specific verb and resource: 'Scan a snippet of text or code for exposed secrets.' It clearly distinguishes this tool from file/directory/git scanners by emphasizing raw text snippets, so an agent can tell what it does 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 description gives clear usage context by naming raw text inputs such as code, config, diff output, and logs, and by marking the tool as snippet-oriented. It does not explicitly name sibling alternatives like scan_file or redact_text, so it lacks full when-to-use/when-not-to-use routing guidance.

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