BountyProof MCP is a server for managing authorized bug bounty workflows, providing a structured, evidence-driven pipeline for security researchers. Key capabilities:
Session Management (start_session): Create an engagement session by defining program name, in/out-of-scope targets, rules, allowed activities, and authorization confirmation — without sending network traffic.
Scope Validation (scope_check): Verify whether a URL falls within session scope rules before making any requests.
Preflight Checks (preflight_target): Assess a target for WAF/CDN presence, stability, latency, and redirects, classifying it as clear, guarded, or blocked before live testing.
Surface Discovery (discover_surface): Run Katana-based URL discovery on targets that passed preflight, constrained to session rate limits and scope.
High-Signal Scanning (scan_high_signal): Execute Nuclei scans using only high- and critical-severity HTTP templates (no fuzzing, DoS, brute force, or headless templates), rate-limited per session.
Finding Verification (verify_finding): Re-run a specific Nuclei template 2–3 times to confirm whether a finding is consistently reproducible.
Surface Import (import_surface): Import attack surface data from HAR, OpenAPI (JSON/YAML), or Postman Collection files, with automatic scope filtering and credential/value redaction.
Auth Profile Registration (register_auth_profiles): Store authentication profile metadata (roles, auth types, environment variable references) without storing actual credential values.
Authorization Comparison (compare_authorization): Replay imported GET endpoints across different authorization profiles (e.g., owner, anonymous) to detect broken access control issues.
Origin IP Discovery (find_origin_candidates): Identify potential origin IPs behind CDNs using DNS hints and optional SecurityTrails lookups — without sending IP-level traffic.
Origin Verification (verify_origin_candidate): After explicit user confirmation, compare edge vs. direct-IP responses to assess WAF bypass potential.
Report Generation (get_report): Retrieve sanitized JSON or Markdown reports per session and run ID, with sensitive values masked.
Allows importing surface data from Postman Collections into a session for scope-filtered analysis and value redaction.
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., "@BountyProof MCP start a new bug bounty session for example.com"
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.
BountyProof is a small MCP server for authorized bug bounty work. It keeps the workflow explicit and evidence-driven:
session (scope + rules) -> preflight -> surface discovery/import -> targeted checks -> verification -> evidenceWAF detection is not treated as a vulnerability. It is part of the preflight check, where BountyProof decides whether live testing is practical or likely to be wasted on challenges, rate limits, unstable responses, off-host redirects, or other edge protection.
BountyProof is provided for educational purposes and authorized security testing only. Use it only on systems you own or targets for which you have explicit permission to test.
You are responsible for following the applicable law, the bug bounty program's scope, and its testing rules. The built-in scope and authorization checks are safeguards, not a substitute for permission. The authors and contributors are not responsible for misuse, unauthorized testing, damage, or legal consequences resulting from the use of this software.
Related MCP server: recon-mcp
BountyProof has a built-in HTTP client and relies on only two external binaries:
Katana for URL discovery, restricted to hosts that passed preflight.
Nuclei for high- and critical-severity HTTP templates. Fuzzing, DoS, brute force, and headless templates are excluded.
There is no generic shell tool, custom payload runner, mass scanner, subdomain brute force, credential attack, or automatic exploitation.
start_session(...) records the program, scope, exclusions, rules, allowed activities, restrictions, rate limit, and authorization. It does not send network traffic.
scope_check(session_id, url) checks a URL against the session scope without sending a request.
preflight_target(session_id, url) classifies a target as clear, guarded, or blocked.
discover_surface(...) runs Katana after a successful preflight.
scan_high_signal(...) runs a tightly rate-limited Nuclei scan using high- or critical-severity HTTP templates.
verify_finding(...) repeats one matched template two or three times.
find_origin_candidates(...) looks for possible origin IPs through in-scope DNS hints and, when configured, historical A records.
verify_origin_candidate(...) compares one edge response with one direct-IP HTTPS response after fresh user approval.
import_surface(...) imports HAR, OpenAPI, or Postman data with scope filtering and value redaction.
register_auth_profiles(...) stores roles and environment variable names, never credential values.
compare_authorization(...) compares the same GET request as the owner and another identity for two or three rounds.
get_report(...) returns a sanitized JSON or Markdown report.
Every tool except start_session requires a session_id. Exclusions take priority over inclusions, including URL path prefixes. An activity is rejected unless it appears in the session's allowed_activities list:
preflight
discovery
nuclei-scan
verification
origin-discovery
origin-verification
surface-import
authorization-testingLive discovery, scanning, and authorization comparison also require a preflight_run_id. The scheme, host, and port must match the preflight target. A blocked result cannot be overridden. A guarded result requires a manual review and override_guarded=true.
Result | Meaning | Next step |
| The baseline is stable and no obvious friction was found | Continue at the approved rate |
| A WAF/CDN, redirect, high latency, or unstable response was observed | Review the program rules and testing approach |
| Repeated challenges, blocks, rate limits, or connection failures were observed | Stop live automation |
Cloudflare, Akamai, Imperva, CloudFront, F5, Sucuri, Fastly, and Azure edge indicators are recorded only as preflight metadata. They are never reported as vulnerabilities.
BountyProof is developed and documented primarily for Linux. Windows can be used as an optional client environment, but the Linux setup is the reference configuration.
Requirements:
Python 3.11 or newer
Git
Katana available in PATH
Nuclei and nuclei-templates available in PATH
On Debian or Ubuntu, install the base packages first:
sudo apt update
sudo apt install -y git python3 python3-pip python3-venvClone and install BountyProof:
git clone https://github.com/skyxtools/bountyproof-mcp.git
cd bountyproof-mcp
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -e .Set the runtime environment and start the MCP server:
export BOUNTYPROOF_WORKSPACE="$(pwd)"
export BOUNTYPROOF_ALLOWED_PORTS="443"
export BOUNTYPROOF_CONTACT="researcher@example.com"
bountyproof-mcpIf Katana or Nuclei is not in PATH, set the executable paths explicitly:
export BOUNTYPROOF_KATANA_BIN="$HOME/go/bin/katana"
export BOUNTYPROOF_NUCLEI_BIN="$HOME/go/bin/nuclei"Confirm that both tools are available before starting OpenCode:
"$BOUNTYPROOF_KATANA_BIN" -version
"$BOUNTYPROOF_NUCLEI_BIN" -versionWindows is not the primary environment, but the MCP server can still be installed with PowerShell:
git clone https://github.com/skyxtools/bountyproof-mcp.git
cd bountyproof-mcp
py -3.11 -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install -e .
$env:BOUNTYPROOF_WORKSPACE = (Get-Location).Path
$env:BOUNTYPROOF_ALLOWED_PORTS = "443"
$env:BOUNTYPROOF_CONTACT = "researcher@example.com"
bountyproof-mcpIf the external tools are not in PATH:
$env:BOUNTYPROOF_KATANA_BIN = "C:\Tools\katana.exe"
$env:BOUNTYPROOF_NUCLEI_BIN = "C:\Tools\nuclei.exe"Copy opencode.jsonc.example to opencode.jsonc in your OpenCode project and update the Linux executable path to the absolute path of .venv/bin/bountyproof-mcp. Set BOUNTYPROOF_WORKSPACE and any credential environment variables in the shell before starting OpenCode. OpenCode expands {env:VARIABLE} and passes the value to the MCP process through its environment option, so secrets do not need to be written into the config file.
Copy .opencode/commands/bounty-start.md into the project where OpenCode runs, or place it at ~/.config/opencode/commands/bounty-start.md to make it available globally. Start each engagement with:
/bounty-startThe command asks for the program name, in-scope assets, exclusions, rules, allowed activities, restrictions, rate limit, and confirmation that the test is authorized. Once you approve the summary, OpenCode calls bountyproof_start_session and returns a session_id.
An MCP server cannot open a dialog simply because its process has started. The client must initiate the interaction, which is why the custom command is the entry point.
For MCP clients other than OpenCode:
{
"mcpServers": {
"bountyproof": {
"command": "/absolute/path/to/.venv/bin/bountyproof-mcp",
"args": [],
"env": {
"BOUNTYPROOF_ALLOWED_PORTS": "443",
"BOUNTYPROOF_CONTACT": "researcher@example.com"
}
}
}
}For the optional Windows setup, replace the command with the absolute path to .venv\\Scripts\\bountyproof-mcp.exe.
Run /bounty-start in OpenCode. Supported scope formats include:
Exact host: api.example.com
Wildcard subdomain: *.example.com
URL and path prefix: https://app.example.com/api/
Out-of-scope entries always win. For example, an in-scope entry of https://app.example.com/api/ combined with an exclusion of https://app.example.com/api/admin/ blocks the entire admin path.
scope_check(session_id="session-...", url="https://app.example.com/")
preflight_target(session_id="session-...", url="https://app.example.com/", samples=3)Preflight sends between two and five GET requests to the same URL. It does not send attack payloads.
discover_surface(
session_id="session-...",
url="https://app.example.com/",
preflight_run_id="preflight-...",
depth=2
)Katana is restricted to fqdn scope, concurrency 1, and the session rate limit, with a hard maximum of two requests per second.
scan_high_signal(
session_id="session-...",
urls=["https://app.example.com/api"],
preflight_run_id="preflight-...",
profile="high-signal"
)The high-signal profile includes only high and critical findings. The critical-only profile is narrower. A Nuclei match remains a candidate until it has been verified.
verify_finding(
session_id="session-...",
scan_run_id="scan-...",
finding_index=0,
rounds=2
)repeatable-candidate means that the same template matched on every verification round. Business impact and program-policy compliance still require manual review.
find_origin_candidates uses two sources:
DNS resolution for hostnames labeled origin, direct, backend, server, dev, or staging. A hostname is queried only when it matches the wildcard scope and is not excluded.
Historical A records from SecurityTrails when BOUNTYPROOF_SECURITYTRAILS_API_KEY is configured.
Every result starts as an unverified-origin-candidate. Do not send it directly to a scanner.
find_origin_candidates(
session_id="session-...",
target_url="https://app.example.com/",
preflight_run_id="preflight-..."
)If origin-verification is allowed by the program rules, review the candidate IP and confirm a direct request separately. The verification tool then sends exactly two requests: one to the edge and one to the candidate IP, using the target's TLS SNI and HTTP Host header.
verify_origin_candidate(
session_id="session-...",
origin_run_id="origin-...",
candidate_index=0,
direct_request_confirmed=true
)The workflow stops after this comparison. Review the evidence, check the IP owner and hosting provider, and confirm whether the raw IP is covered by the program scope. BountyProof will not pass the IP to scan_high_signal. Any further testing requires a separate decision.
Surfaces can be imported from HAR, OpenAPI JSON/YAML, or a Postman Collection. The file must be inside BOUNTYPROOF_IMPORT_ROOT. Header values and request bodies are not stored; only header names, parameter names, and body field names are retained. Out-of-scope endpoints are discarded.
Full replay URLs remain in the local, gitignored report. MCP output masks query values and path segments that look like object identifiers.
import_surface(
session_id="session-...",
file_path="captures/app.har",
input_format="auto"
)Do not send credentials through chat or MCP parameters. Put tokens or cookies in environment variables available to the MCP process, then register references to those variables:
export BOUNTY_USER_A_TOKEN="<SET_OUTSIDE_CHAT>"
export BOUNTY_USER_B_TOKEN="<SET_OUTSIDE_CHAT>"On optional Windows clients, set the same variables with $env:BOUNTY_USER_A_TOKEN and $env:BOUNTY_USER_B_TOKEN in PowerShell.
register_auth_profiles(
session_id="session-...",
profiles=[
{"name":"user_a", "role":"owner", "auth_type":"bearer", "credential_env":"BOUNTY_USER_A_TOKEN"},
{"name":"user_b", "role":"other-user", "auth_type":"bearer", "credential_env":"BOUNTY_USER_B_TOKEN"},
{"name":"anonymous", "role":"anonymous", "auth_type":"anonymous"}
]
)compare_authorization accepts only replayable GET endpoints. It does not change the object ID, parameters, method, or body. The owner and comparison profiles are requested two or three times. A candidate is created only when the comparison profile consistently receives a 2xx response whose body is identical to the owner's response or whose canonical JSON is stable and equal.
compare_authorization(
session_id="session-...",
surface_run_id="surface-...",
endpoint_index=0,
preflight_run_id="preflight-...",
owner_profile="user_a",
comparison_profiles=["user_b", "anonymous"],
expected_policy="owner-only",
rounds=2
)The workflow stops when a differential candidate is found. BountyProof does not enumerate or replace object IDs automatically. Before any additional impact testing, confirm that the comparison identity should not have access to the object.
Sessions are stored in .bountyproof/sessions/, authentication profile metadata in .bountyproof/auth-profiles/, and reports in .bountyproof/reports/. All three paths are excluded from Git.
Authentication profiles contain environment variable names, not their values. Raw Nuclei request and response data stays local and is not returned through MCP. Nuclei is instructed to redact authorization, cookie, and set-cookie fields.
Variable | Default | Purpose |
|
| Allowed destination ports |
|
| Allow unencrypted HTTP |
|
| Allow non-public IP addresses for lab use |
|
| Verify TLS certificates |
|
| Delay between preflight requests |
|
| Maximum number of discovered URLs |
|
| Maximum Nuclei requests per second |
|
| Local evidence directory |
| empty | Optional historical DNS lookup; never written to reports |
| current directory | Allowed root for HAR, OpenAPI, and Postman files |
|
| Maximum imported surface file size |
python -m unittest discover -s tests -vThe unit tests do not contact external targets.
MIT. The project was inspired by HexStrike AI's MCP orchestration concept, but the implementation is independent and deliberately limited to a small workflow with strict guardrails.
Replay one imported GET as owner and 1-3 other profiles, twice, without changing IDs or request data.
| Name | Required | Description | Default |
|---|---|---|---|
| rounds | No | ||
| session_id | Yes | ||
| owner_profile | Yes | ||
| endpoint_index | Yes | ||
| surface_run_id | Yes | ||
| expected_policy | Yes | ||
| override_guarded | No | ||
| preflight_run_id | Yes | ||
| comparison_profiles | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: it replays requests without changing IDs or data, and does so twice. However, with no annotations, it lacks details on authorization requirements, side effects, or constraints like rate limits. It is adequate but not comprehensive.
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 single-sentence description is concise and front-loads the core action. However, it excludes necessary details for a tool with 9 parameters, making it slightly under-specified rather than optimally concise.
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 complexity (9 params, 7 required, 0% schema coverage), the description is insufficient. It omits parameter explanations, output schema context, and operational details, forcing agents to rely on guessing or external knowledge.
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% schema description coverage, the description only implicitly references 'owner_profile' and 'comparison_profiles', leaving 7 of 9 parameters (including session_id, surface_run_id, endpoint_index) unexplained. Agents cannot infer their purpose or valid values.
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 action (replay a GET request) and its specifics (as owner and 1-3 profiles, twice, without modifying data). It effectively distinguishes the tool from siblings by focusing on authorization comparison through replay.
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?
No guidance is provided on when to use this tool over siblings like 'scan_high_signal' or 'register_auth_profiles'. There is no mention of prerequisites or scenarios to avoid, leaving agents to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use Katana at the session rate limit after scope and preflight gates pass.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| depth | No | ||
| max_urls | No | ||
| session_id | Yes | ||
| override_guarded | No | ||
| preflight_run_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It mentions rate limiting and gate prerequisites but does not disclose whether the tool modifies data, side effects, or output format. This is minimal and insufficient.
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 short (one sentence), which is concise, but it lacks a clear structure. It does not start with the main purpose and relies on the agent knowing what 'Katana' and 'preflight gates' are. Brevity is achieved at the expense of clarity.
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 complexity (6 parameters, no schema descriptions), the description is incomplete. It omits key context: what 'Katana' is, how to set depth/max_urls, and what 'preflight gates' entail. The presence of an output schema does not compensate for these gaps.
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 schema has no parameter descriptions (0% coverage), and the description adds no explanation for parameters like depth, max_urls, or override_guarded. It only alludes to 'session rate limit' without connecting to session_id, leaving the agent with no guidance.
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 does not explicitly state that the tool discovers URLs or attack surface; it only says 'Use Katana...' which is vague. It fails to provide a clear verb+resource purpose, making it difficult for an agent to understand its primary function.
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 implies that this tool should be used after scope and preflight gates pass and at session rate limit, which provides some context. However, it does not differentiate from sibling tools like 'scope_check' or 'preflight_target', nor does it state 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.
Find unverified origin IP candidates using in-scope DNS hints and optional historical DNS; sends no IP traffic.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| target_url | Yes | ||
| preflight_run_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Clearly states that no IP traffic is sent, indicating passive operation. However, with no annotations, the description could disclose more about required permissions or side effects beyond what the schema provides.
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?
Single sentence that is front-loaded with key action and constraints, no wasted words.
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?
Lacks explanation of what 'unverified origin IP candidates' entails and how 'in-scope DNS hints' are determined. Though output schema exists, context for input parameters and overall workflow is incomplete.
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 has 0% description coverage and the description does not elaborate on any of the three parameters, leaving their meaning to be inferred from names only.
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's purpose: finding unverified origin IP candidates using DNS hints and optional historical DNS. It is specific and differentiates from sibling 'verify_origin_candidate'.
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 implies usage context (before verification) but lacks explicit guidance on when to use or alternatives. No 'when not to use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a report only when it belongs to the active engagement session.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | ||
| session_id | Yes | ||
| output_format | No | markdown |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states a condition ('belongs to active engagement session') but omits effects like read-only nature, error behavior, or side effects. The word 'Load' hints at reading, but is insufficient.
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 (one sentence), which is valuable, but it borders on under-specification. It is front-loaded with the main action and condition.
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 complexity of a report-loading tool with 3 parameters (0% schema coverage) and an output schema, the description fails to provide sufficient context about the condition, default behavior, or relation to siblings. It is incomplete.
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%, so the description should clarify parameters. It does not explain 'run_id', 'session_id', or 'output_format'. The names are somewhat clear, but no additional meaning is added 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 verb 'Load' and the resource 'report', and adds a specific condition about belonging to the active engagement session. This differentiates it from siblings like 'discover_surface' or 'verify_finding', though not 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?
No guidance is provided on when to use this tool versus alternatives. The condition 'only when it belongs to the active engagement session' implies a prerequisite, but does not explain contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a local HAR/OpenAPI/Postman file; values are redacted and out-of-scope endpoints are rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| base_url | No | ||
| file_path | Yes | ||
| session_id | Yes | ||
| input_format | No | auto |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions redaction of values and rejection of out-of-scope endpoints, providing some behavioral context. With no annotations, more details (e.g., destructive nature, auth requirements) would improve 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 a single sentence that efficiently conveys purpose and key behaviors. It is front-loaded and free of clutter.
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?
The description covers the import function and key behaviors but omits details like output or prerequisites. Given the presence of an output schema, this is adequate but not rich.
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%, so the description should clarify parameters. It mentions file types (HAR/OpenAPI/Postman) relating to input_format, but does not explain base_url, file_path, or session_id meaning beyond 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 imports local HAR/OpenAPI/Postman files, specifying the resource and action. However, it does not explicitly differentiate from sibling tools, though the import function is distinct.
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?
No guidance on when to use this tool versus alternatives like discover_surface or scope_check. The description implies usage for importing files but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check friction before live testing: stability, latency, redirect, rate limit, and WAF/CDN hints.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| samples | No | ||
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It hints at checks (stability, latency, etc.) but does not state whether the tool is read-only, requires permissions, or has side effects. This is insufficient for full 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 a single sentence, front-loaded with the verb, and contains no extraneous information. It is highly concise.
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?
While the purpose is clear and the aspects checked are listed, the description omits explanation of the required session_id parameter and the optional samples parameter. Given the tool's complexity and the presence of an output schema, more context would be beneficial.
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%, and the description does not mention any parameters. The agent gets no additional meaning about url, samples, or session_id beyond the schema. This is a critical 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 clearly states the tool checks friction before live testing, listing specific aspects (stability, latency, etc.). This distinguishes it from sibling tools like scan_high_signal or verify_finding, which focus on different phases.
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 phrase 'before live testing' gives context on when to use it, but there is no explicit guidance on when not to use it or mention of alternatives among the siblings. The usage guidelines are implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register auth profile metadata and secret environment-variable names; actual credentials are never stored.
| Name | Required | Description | Default |
|---|---|---|---|
| profiles | Yes | ||
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that credentials are never stored, which is important, but it does not explain idempotency, duplicate handling, state changes, or prerequisites like a valid session_id. The session_id parameter remains unexplained.
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 a single, well-structured sentence that is concise and directly conveys the core purpose without any extraneous information.
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 that the tool has an output schema (as indicated by context signals), the description does not mention return values or side effects. It lacks details on workflow integration (e.g., required prior steps like start_session) and does not address the nested structure of profiles, which is essential for correct invocation.
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% for top-level parameters (profiles, session_id). The description adds no meaning beyond the schema's type definitions; it does not explain how profiles are structured or what session_id is used for. For a tool with two parameters, the description should clarify at least the required context.
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 registers auth profile metadata and environment-variable names, and explicitly notes that actual credentials are never stored. This provides a specific verb+resource and a key behavioral distinction.
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?
No explicit guidance on when to use this tool versus alternatives. Sibling tools like compare_authorization, scan_high_signal, etc., have different purposes, but the description does not differentiate or provide context for when registration is appropriate (e.g., before scanning).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run HTTP-only Nuclei high/critical templates under session scope, rules, and rate limit.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | ||
| profile | No | high-signal | |
| session_id | Yes | ||
| override_guarded | No | ||
| preflight_run_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses HTTP-only operation, high/critical templates, and adherence to session scope/rate limits. However, it omits whether the tool is destructive or read-only, and does not explain effects like state changes or output format.
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 a single, front-loaded sentence of 12 words. It efficiently conveys the core purpose without unnecessary details.
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 presence of 5 parameters, 3 required, and sibling tools, the description hints at workflow integration (session scope, preflight run) but does not explain the relationship to session preflight or the role of preflight_run_id. Output schema exists, so return values need no explanation.
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%. The description provides no information about any of the 5 parameters (urls, profile, session_id, override_guarded, preflight_run_id). The agent must rely solely on the schema, which lacks descriptions.
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 runs HTTP-only Nuclei high/critical templates, specifying the verb 'Run', the resource 'Nuclei high/critical templates', and constraints. It distinguishes from sibling tools like compare_authorization or discover_surface by focusing on 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 mentions 'under session scope, rules, and rate limit' but gives no explicit guidance on when to use this tool versus alternatives like preflight_target or verify_finding. There is no mention of exclusion criteria or prerequisites beyond session scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a URL against the active session's in-scope and out-of-scope rules without HTTP traffic.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It notes 'without HTTP traffic' but does not disclose return behavior, side effects, auth requirements, or what 'validate' entails precisely.
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?
Single sentence, 14 words, front-loaded with action and key qualifier. No redundant information.
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 two parameters and no annotations, the description is adequate but minimal. Lacks details on return values (output schema exists but contents unknown) and edge cases. Could be more informative 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?
Schema has 0% description coverage. The description implies the role of session_id and url but does not provide per-parameter details. It adds some value over the schema but does not fully compensate.
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 action (validate), the resource (URL against session's rules), and a key differentiator (without HTTP traffic). It is distinct from sibling tools like 'scan_high_signal' or 'verify_finding'.
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?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FIRST TOOL. Ask the user for every field before creating an engagement session; this sends no traffic.
| Name | Required | Description | Default |
|---|---|---|---|
| rules | Yes | ||
| in_scope | Yes | ||
| out_of_scope | Yes | ||
| program_name | Yes | ||
| forbidden_tests | Yes | ||
| allowed_activities | Yes | ||
| authorization_confirmed | Yes | ||
| max_requests_per_second | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool sends no traffic and creates a session, but it does not explain the session's persistence, idempotency, or any authorization or rate limit implications.
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 a single concise sentence that front-loads the most important information ('FIRST TOOL'). Every word is purposeful, though it could be slightly more structured with bullet points for clarity.
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 8 parameters (7 required) and no schema descriptions, the description is insufficient. It does not explain the session lifecycle, how subsequent tools depend on it, or what the output schema contains.
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%, so the description must compensate but fails to do so. It only instructs to ask for every field without explaining what each parameter means, e.g., 'allowed_activities' enum values, 'rules', or 'forbidden_tests'.
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 it is the 'FIRST TOOL' that creates an engagement session and sends no traffic. The verb 'create' and resource 'engagement session' are specific, and it distinguishes itself from sibling tools like scan_high_signal or preflight_target.
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 explicitly says 'FIRST TOOL' and instructs to ask the user for every field before invoking, providing clear usage context. However, it does not specify when not to use this tool or list alternative tools for similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-run one exact Nuclei template 2-3 times inside the same authorized session.
| Name | Required | Description | Default |
|---|---|---|---|
| rounds | No | ||
| session_id | Yes | ||
| scan_run_id | Yes | ||
| finding_index | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description reveals some behavioral traits: it re-runs a template 2-3 times within the same session. However, it does not disclose potential side effects, destructive actions, or authorization requirements beyond implying session existence. The description is moderately transparent but lacks depth.
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 a single, efficient sentence with no wasted words. It is perfectly concise for the information it conveys.
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 complexity of four parameters, no schema descriptions, and no annotations, the description is insufficient. It does not explain key concepts like finding_index or scan_run_id, and while an output schema exists, the description offers no context on return values or verification outcomes.
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 description does not mention any parameters, despite the schema having four (rounds, session_id, scan_run_id, finding_index) with zero description coverage. It fails to explain what these parameters represent or how they relate to the tool's operation, leaving the agent to infer from names alone.
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's specific action: re-running exactly one Nuclei template multiple times within an authorized session. It uses a specific verb ('re-run') and resource ('Nuclei template'), distinguishing it from sibling tools like discover_surface or scan_high_signal.
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 no guidance on when to use this tool versus its siblings (e.g., preflight_target, verify_origin_candidate). It does not specify prerequisites, such as requiring an existing finding to verify, 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.
After a fresh user decision, compare one HTTPS edge response with one direct-IP response using the target SNI/Host.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| origin_run_id | Yes | ||
| candidate_index | Yes | ||
| direct_request_confirmed | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose side effects, safety, or return behavior. The only behavioral hint is 'compare', implying read-only, but no confirmation or details on what happens.
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 a single sentence, which is concise. However, it lacks structure and essential details, making it minimally effective. A good structure would front-load key information, but here it is too sparse.
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 no annotations, no parameter descriptions, and 4 required parameters, the description is highly incomplete. The presence of an output schema is not leveraged. The tool involves complex comparison logic, yet no behavioral or return value context is provided.
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 has 4 required parameters with 0% description coverage. The description does not explain any parameter roles or values. The tool name hints at 'session_id', 'origin_run_id', 'candidate_index', and 'direct_request_confirmed', but no semantics are provided, leaving the agent guessing.
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 action (compare) and resources (HTTPS edge response vs direct-IP response), with context (after a fresh user decision, using target SNI/Host). It distinguishes from sibling tools like 'verify_finding' by specifying the comparison with direct-IP, but could be more explicit about the 'verify' aspect.
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?
No explicit guidance on when to use this tool versus alternatives like 'verify_finding' or 'compare_authorization'. The description mentions 'after a fresh user decision' but does not explain when not to use or provide comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0compare_authorizationdiscover_surfacefind_origin_candidatesget_reportimport_surfacepreflight_targetregister_auth_profilesscan_high_signalscope_checkstart_sessionverify_findingverify_origin_candidateEach tool targets a distinct phase or aspect of security testing (e.g., session setup, scope validation, scanning, verification). There is no functional overlap that would confuse an agent.
Most tool names follow a clear verb_noun pattern (e.g., start_session, import_surface). Only 'scope_check' deviates slightly (noun_verb), but the convention is otherwise consistent.
With 12 tools, the set covers essential security testing actions without being excessive. Each tool serves a clear purpose, and the count feels well-scoped for the domain.
The workflow from session start to report retrieval is covered. Minor gaps exist (e.g., no explicit session termination or report listing), but core operations are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
ArcAgent MCP server for bounty discovery, workspace execution, and verified coding submissions.
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/skyxtools/bountyproof-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
