Skip to main content
Glama
boy-offi9-inc

HexForge Gateway

by boy-offi9-inc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

scan_secrets

Read-only

Recursively scan a directory (typically decompile_apk or decode_apk output) for likely hardcoded secrets: AWS access keys, Google API keys, private key headers, Slack/GitHub/Stripe tokens, JWTs, and Firebase Cloud Messaging keys.

Instructions

Recursively scan a directory (typically decompile_apk or decode_apk output) for likely hardcoded secrets: AWS access keys, Google API keys, private key headers, Slack/GitHub/Stripe tokens, JWTs, and Firebase Cloud Messaging keys. A curated high-precision starting set, not exhaustive, and not a replacement for a maintained secret scanner. Only reads files; skips files over 2 MB. Returns { dirPath, filesScanned, matchCount, matches: [{ file, line, text, name }], truncated } where name is the secret type, file is relative to dirPath, line is 1-based, and text is the trimmed line (max 300 chars). For your own patterns use search_code. The full result is also saved as a JSON file in the workspace and its path returned as outputPath, so it can be cited as evidence.

Input Schema

NameRequiredDescriptionDefault
dirPathYesAbsolute path of the directory to scan, e.g. the outputDir from decompile_apk. Must exist.
workspaceNoWorkspace name (not id). Created if it doesn't exist, and this call is recorded as a job in its history. Defaults to "default".
extensionsNoOnly scan files with these extensions - lowercase, with the leading dot, e.g. [".java", ".xml"]. Omit to scan every file except known binary types (.apk, .dex, .zip, .jar, .so, images, fonts).
maxResultsNoStop after this many matches. Default and maximum 200.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.3.7
    • changedInput schema / properties / dirPath / description
      Previous value: -"Directory to scan, e.g. a jadx output directory"New value: +"Absolute path of the directory to scan, e.g. the outputDir from decompile_apk. Must exist."
    • changedInput schema / properties / extensions / description
      Previous value: -"File extensions to include, e.g. [\".java\", \".xml\"]. Omit to scan all non-binary-looking files."New value: +"Only scan files with these extensions - lowercase, with the leading dot, e.g. [\".java\", \".xml\"]. Omit to scan every file except known binary types (.apk, .dex, .zip, .jar, .so, images, fonts)."
    • addedInput schema / properties / maxResults / default
      Added value: +200
    • changedInput schema / properties / maxResults / description
      Previous value: -"Cap on results, default/max 200"New value: +"Stop after this many matches. Default and maximum 200."
    • addedInput schema / properties / maxResults / maximum
      Added value: +200
    • addedInput schema / properties / maxResults / minimum
      Added value: +1
    • changedInput schema / properties / workspace / description
      Previous value: -"Workspace name (not id) - created automatically if it doesn't exist yet. Defaults to \"default\"."New value: +"Workspace name (not id). Created if it doesn't exist, and this call is recorded as a job in its history. Defaults to \"default\"."
  2. First observedv1.3.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is largely covered. The description still adds real value beyond them: 'Only reads files; skips files over 2 MB', the 200-match cap, and the fact that results are persisted to a workspace JSON file returned as outputPath. It does not, however, note any auth or workspace-history side effect of the recorded job.

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 caveat, behavior, return shape, alternative, and side effect — a sensible order. The single dense paragraph is longer than strictly necessary, but each sentence carries distinct information.

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 present, the description compensates by spelling out the return object (dirPath, filesScanned, matchCount, matches fields, truncated) and the meaning/units of each field. Combined with the size cap and alternative tool, an agent has everything needed to call and interpret this tool.

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

Parameters3/5

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

Schema description coverage is 100%, so dirPath, workspace, extensions, and maxResults are already documented in-schema, which sets the baseline at 3. The description adds only mild extra context (dirPath typically being decompile output, and the outputPath side-effect), without clarifying formats the schema does not already cover.

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 ('Recursively scan a directory ... for likely hardcoded secrets') and enumerates the concrete pattern classes it looks for. It also distinguishes itself from the sibling search_code by scoping itself to a curated high-precision set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the typical input source (decompile_apk or decode_apk output), sets expectations with 'not exhaustive, and not a replacement for a maintained secret scanner', and explicitly routes custom patterns to the alternative tool: 'For your own patterns use search_code.' That is explicit when/when-not/alternative coverage.

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

Deploy Server

Other Tools