Detects leaked Confluence wiki page links in binary artifacts, which may expose internal documentation, with optional live verification of reachability and anonymous access.
Detects leaked Google Drive document URLs in binary artifacts, which often point to publisher-internal documents.
Detects leaked Logstash or log-ingestion URLs in binary artifacts, which may reveal internal observability infrastructure.
Detects leaked Sentry DSNs in binary artifacts, enabling identification of potential forged crash-report submission endpoints, with optional live verification of the Sentry host.
Detects leaked Slack tokens in binary artifacts, which could provide long-lived API credentials.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@re-leak-scan scan mygame.exe for leaked secrets"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for detecting publisher telemetry pipeline leaks in binary artifacts. Scans the file's string table for:
Sentry DSNs (with embedded public auth) — enables forged crash-report submission
Logstash / log-ingestion URLs — internal observability infrastructure
Confluence wiki page links — often engineering-only docs / secrets
Google Drive document URLs — publisher-internal documents
AWS access key IDs — long-lived credentials
Slack tokens — long-lived API credentials
Generic high-entropy hex strings — possible keys / secrets
The output is vendor-neutral: pattern categories describe observable string content, not specific publishers.
The 2026-06-05 stress test surfaced a new attack-surface class that the existing tools did not cover:
Sample A (GameAssembly.dll): 16,236 Google Drive URL matches — the bulk are publisher-internal design documents.
Sample B (CrimsonDesert.exe): a Sentry DSN with embedded auth, a Logstash ingestion URL, an internal dev server URL, and a Confluence wiki page link — all in plaintext, all unprotected by the encrypted-VM bytecode anti-tamper.
re-leak-scan fills that gap. It is pure-Python (no .NET, no system tools), works on any binary file, and is the .re-leak-scan / .re-telemetry-extract foundation for the re-leak-scan and re-telemetry-extract skills.
Related MCP server: ai-scanner-mcp
Tool | What it does |
| Health check — return pattern catalog + |
| Walk the file, extract ASCII + UTF-16LE printable strings |
| Apply the regex catalog over a binary's string table |
| Full pipeline: extract → apply all detectors → return findings |
| Parse a Sentry DSN + probe |
| Probe a Confluence URL to confirm reachability + anon-access |
Part of the RE-AI plugin; ./install.sh installs the package. To install standalone:
pip install -e ./servers/re-leak-scan
# Optional: live verification (Sentry / Confluence HTTP probes)
pip install -e './servers/re-leak-scan[verify]'re-leak-scan # stdio transport (default for MCP)
python -m re_leak_scan # equivalentThe 7 patterns are defined in src/re_leak_scan/patterns.py. Adding a new one is a 6-line dataclass entry. The patterns are all vendor-neutral — they match the URL schemes of public infrastructure (Sentry.io, Logstash, Atlassian Confluence, Google Docs) without naming any specific publisher.
verify_sentry_dsn and verify_confluence_url make outbound HTTP requests. By default, they are passive — they only check that the endpoint responds. They do not submit forged crash reports, do not authenticate, and do not exfiltrate the leaked data.
If you run these in an air-gapped environment, the verifier returns verified: false, reason: "connection failed: ..." — the leak detection itself is unaffected.
Return pattern-catalog summary + dependency availability.
Always returns status: OK (this server has no external
system-tool dependencies — pure Python).
The optional [verify] extra adds httpx for live
verification of Sentry / Confluence endpoints. When missing,
:func:verify_sentry_dsn and :func:verify_confluence_url
return {"verified": False, "reason": "httpx not installed"}
— the leak detection itself is unaffected.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Extract printable ASCII and UTF-16LE strings from path.
Args: path: file to scan min_length: minimum string length (default 8) max_strings: per-encoding cap (default 50,000)
Returns a dict with ascii and utf16le arrays of
{"string", "offset", "encoding"}. This is the raw
string extraction — pass the result to :func:find_secrets
for the leak-detection pass.
On a 500+ MB GameAssembly.dll, prefer the section-aware
:func:re-lief.categorize_strings instead; this implementation
walks the file linearly and may be slow.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| min_length | No | ||
| max_strings | No |
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.
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.
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.
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.
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.
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.
Run the regex leak catalog over path's string table.
Args:
path: file to scan
detector_set: comma-separated list of pattern names to apply
(default: all categories except the noisy generic-hex-secret).
Use detector_set="all" for the full catalog.
min_length: minimum string length passed to :func:extract_strings
max_per_category: per-category match cap (default 200)
Returns::
{
"path": "...",
"totals": {"strings_seen": N, "matches": N},
"truncated": bool,
"categories_run": ["sentry-dsn", ...],
"by_category": {
"sentry-dsn": {"count": N, "risk": "HIGH", "description": "...",
"matches": [{"string": "...", "offset": N, ...}]},
...
},
}
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| detector_set | No | sentry-dsn,logstash-url,confluence-url,google-drive-url,aws-access-key,slack-token | |
| min_length | No | ||
| max_per_category | No |
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.
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.
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.
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.
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.
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.
Full pipeline: extract strings → apply all detectors → return findings.
Convenience wrapper for the typical workflow. Equivalent to
find_secrets(path, detector_set="all", max_per_category=...).
Returns the same shape as :func:find_secrets.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| max_per_category | No |
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.
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.
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.
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.
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.
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.
Probe a Confluence URL to confirm reachability + anon-access.
Returns::
{"url": "...", "verified": bool, "http_status": N | None,
"anon_accessible": bool, "reason": "..."}A 200 means the page is publicly readable (anon-accessible). A 401/403 means it's behind auth (still reachable). A connection error means unreachable.
Note: this only checks the URL — the actual content of the Confluence page is the analyst's responsibility.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
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.
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.
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.
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.
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.
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.
Parse a Sentry DSN and (if httpx is available) probe the
Sentry host to confirm reachability.
Args:
dsn: a single Sentry DSN string (the full URL, including
the https://key@host/project_id form)
Returns::
{"dsn": "...", "parsed": {"host": "...", "project_id": N,
"public_key": "..."},
"verified": bool, "http_status": N | None, "reason": "..."}The probe hits <host>/api/0/projects/<org>/<project>/ with
the public key. A 200/401/403/404 means the endpoint is
reachable (the specific status tells you whether the key has
project access). A connection error or timeout means the
host is unreachable from the analyst's network.
| Name | Required | Description | Default |
|---|---|---|---|
| dsn | Yes |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Scans remote MCP servers for protocol, security, and TLS issues; exposes scan tools via MCP.
Security research canary remote MCP server for owned-account testing.
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