re-leak-scan

by Heretek-RE

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools are distinct: check_leak_scan for status, extract_strings for raw extraction, find_secrets for catalog detection, scan as a wrapper, and verification tools for URLs/DSNs. However, find_secrets and scan overlap significantly, as scan is essentially a convenience wrapper for find_secrets with all detectors.
Naming Consistency4/5
Tools predominantly use verb_noun snake_case (e.g., extract_strings, verify_confluence_url), but 'scan' is a bare verb, breaking the pattern. This minor inconsistency does not hinder readability.
Tool Count5/5
With 6 tools, the set is well-scoped for a leak scanning server, covering status checking, string extraction, detection, full pipeline, and specific verifications. No unnecessary tools, and the count is appropriate for the domain.
Completeness4/5
The tool surface covers the core workflow: status check, extraction, detection, and verification for two common services. Minor gaps exist, such as pattern catalog management (listing/updating) and support for more service types, but essential operations are present.
Average 4.5/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: always returns status OK, no external dependencies, and behavior of optional [verify] extra. Since no annotations are provided, the description carries the full burden and mostly succeeds, though it could mention any error handling or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only three short sentences that front-load the core purpose. Every sentence adds essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters or output schema, the description covers the tool's behavior adequately. It explains return value, status, and optional dependency behavior. It could slightly improve by mentioning whether the summary includes pattern counts or names, but it remains sufficient.
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?
With 0 parameters, the schema coverage is trivially 100%. The description adds value by explaining the optional [verify] extra and its impact on sibling tool outputs, which is not in the schema. This exceeds the baseline of 4.
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 clearly states the tool returns a 'pattern-catalog summary + dependency availability', using a specific verb and resource. It distinguishes itself from siblings like 'scan' by indicating it is a health/status check rather than a scanning tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It merely explains what it does, without suggesting scenarios or preconditions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It describes the pipeline of extraction and detection but does not explicitly state that it is a read-only operation, nor does it disclose potential side effects like file modifications or permission requirements. The description is adequate but lacks specificity about safety and behavior beyond the pipeline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a code-like reference, all front-loaded. The first sentence captures the entire pipeline, the second explains it's a wrapper, and the third clarifies return format. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a convenience wrapper tool, the description is fairly complete: it explains the pipeline, the equivalent call, and the return shape. It does not mention output schema (which is absent) but that is acceptable as per rules. However, it could offer more context on when to choose this over find_secrets or extract_strings, but the sibling list and description suffice for typical use.
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?
The input schema has 0% description coverage, so the description must compensate. It does so by referencing the equivalent function call find_secrets(path, detector_set='all', max_per_category=...). This clarifies that max_per_category controls limits per category and defaults to 200, adding semantic value beyond the schema.
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 clearly states the tool performs a full pipeline: extract strings, apply all detectors, return findings. It distinguishes itself from siblings by being a convenience wrapper for the typical workflow, with specifics like detector_set='all'.
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 indicates this tool is for the typical workflow and is a convenience wrapper, implying use when a complete scan with all detectors is desired. It references find_secrets as an equivalent but more granular alternative, providing some usage guidance. However, it does not explicitly list when-to-use vs when-not-to-use or compare to other siblings like extract_strings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it parses the DSN, optionally probes the host, explains HTTP status meanings, and notes the httpx dependency. This is comprehensive for a simple tool.
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?
The description is well-structured with clear sections (purpose, Args, Returns, explanation). It is slightly lengthy but every sentence adds value, and the main action is front-loaded.
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?
Despite lacking an output schema, the description details the return format with an example and explains the probe logic. For a single-parameter tool, this is complete and leaves no ambiguity.
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?
The input schema has zero description coverage for the 'dsn' parameter. The description adds critical meaning by specifying the exact format (full URL with https://key@host/project_id) and explaining it is a single DSN string, compensating fully for the schema gap.
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 explicitly states it parses a Sentry DSN and probes the Sentry host for reachability. This specific verb+resource combination clearly distinguishes it from sibling tools, which focus on different tasks like leak scanning or string extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool over alternatives or mention contraindications. It implies usage when a Sentry DSN needs verification, but no comparative context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the behavior of running regex patterns on a file's strings and details the return structure (path, totals, truncated, categories_run, by_category). It does not explicitly state read-only or side effects but implies no modification. The mention of a truncation flag adds transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-liner, Args section, and Returns section. Every part adds value; no redundant information. It is concise despite the length needed to cover parameters and return format.
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 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is highly complete. It explains every parameter, default behaviors, and the full return structure. The truncation flag and categories_run field provide essential runtime context.
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?
Schema coverage is 0%, so description compensates fully. Each parameter is explained beyond schema: path ('file to scan'), detector_set (comma-separated, default, special 'all'), min_length (context of extract_strings), max_per_category (default cap). Return format is also detailed.
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 clearly states 'Run the regex leak catalog over *path*'s string table', specifying verb (run), resource (regex leak catalog), and scope (on path's string table). It effectively distinguishes from sibling tools like extract_strings (just extraction) and verify_* (verifying specific secrets) by focusing on running a catalog of detectors.
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 provides clear context: it explains the default detector_set excludes noisy patterns, how to use 'all', and default values for min_length and max_per_category. However, it does not explicitly state when to use this tool versus alternatives like check_leak_scan or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: the return fields, interpretation of HTTP status codes (200, 401/403, connection error), and the limitation of only checking the URL. This is thorough and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs: one for purpose and return format, another for interpretation and note. Every sentence serves a purpose, and the structure is clear.
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 simplicity (one parameter, no output schema), the description is complete. It provides return format, status code meanings, and usage limitations, covering all necessary aspects for an agent.
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?
The single parameter 'url' is described as a Confluence URL in the description. Since schema coverage is 0%, the description adds meaning beyond the minimal schema, though it does not elaborate on expected format, which is acceptable for a simple string.
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 clearly states the tool probes a Confluence URL to confirm reachability and anonymous access, with a specific verb and resource. It is distinct from siblings like check_leak_scan or find_secrets, which are for content scanning.
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 outlines that the tool only checks URL reachability, not content, and notes the analyst's responsibility for actual content. This provides clear context on when to use, though no explicit alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: return format (dict with ascii and utf16le arrays of objects with string, offset, encoding), linear file walking, per-encoding cap default 50000, and performance characteristics. It adds context beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured with an Args section and a performance note. Every sentence adds value with no redundancy.
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?
For a tool with 3 parameters, no output schema, and a dict return, the description is complete: it explains the return format, the pipeline with find_secrets, and performance caveats. No gaps remain.
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 description coverage is 0%, but the description explains all three parameters ('path: file to scan', 'min_length: minimum string length (default 8)', 'max_strings: per-encoding cap (default 50,000)'), adding meaning and defaults. Could be slightly more detailed (e.g., path format), but compensates well.
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 clearly states 'Extract printable ASCII and UTF-16LE strings from *path*', specifying the verb, resource, and scope. It also distinguishes itself from the sibling 'find_secrets' by indicating the output should be passed to that tool for leak detection.
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?
Explicitly advises against using this tool on large files (>500 MB GameAssembly.dll) and suggests an alternative (re-lief.categorize_strings). It also clarifies that this is raw extraction, not for leaks, guiding proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![re-leak-scan MCP server](https://glama.ai/mcp/servers/Heretek-RE/re-leak-scan/badges/card.svg)](https://glama.ai/mcp/servers/Heretek-RE/re-leak-scan)

Score Badge

Copy to your README.md:

[![re-leak-scan MCP server](https://glama.ai/mcp/servers/Heretek-RE/re-leak-scan/badges/score.svg)](https://glama.ai/mcp/servers/Heretek-RE/re-leak-scan)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Heretek-RE/re-leak-scan'

If you have feedback or need assistance with the MCP directory API, please join our Discord server