Scans text strings and code snippets to detect exposed secrets and API keys, helping prevent credential leaks during MCP traffic inspection.
Scan a text string or code snippet for exposed secrets and API keys
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Optional label shown in findings (e.g. filename) | |
| content | Yes | The text content to scan | |
| entropy | No | Also flag random-looking values assigned to secret-like names (default true) |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Scan' implies a read-only, non-destructive operation, but the description does not state that, nor does it describe the return format (findings list?), false-positive behavior, or the notable entropy-detection behavior that the schema exposes. For a no-annotation tool this is a real gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with a clear verb, scope, and detection target. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should do more than state the purpose – it leaves the agent guessing about returned findings, severity, and the entropy default. It is complete for identifying the tool's job but thin on operation-level context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (label, content, entropy) are documented in the schema itself. The description references the content parameter and detection target at a high level but adds no syntax, format, or behavioral detail beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('Scan') and resource ('text string or code snippet') and states the detection target ('exposed secrets and API keys'). The inline-content scope implicitly distinguishes it from secret_scanner__scan_file, scan_directory, and scan_git siblings, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'text string or code snippet' – you call this when the content is inline rather than a path – but there is no explicit when-to-use, when-not, or routing to scan_file/scan_directory/scan_git. An agent must infer the boundary from the parameter name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.