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., "@Bug Bounty Assistant MCP recon example.com for subdomains and security headers"
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.
An MCP (Model Context Protocol) server that gives an LLM a toolkit of passive and low-impact active reconnaissance tools for authorized bug bounty and security assessment work. The LLM decides which tools to call based on the target and context, then synthesizes findings into a structured report.
⚠️ Authorized use only. This tool is intended strictly for testing assets you own or have explicit written authorization to test (e.g. a program listed on HackerOne/Bugcrowd/Intigriti with the target in scope). Running these tools against systems without permission may violate laws such as the CFAA (US), Computer Misuse Act (UK), or equivalent legislation elsewhere. Always check the program's scope and rules of engagement before scanning.
The server currently exposes the following tools to the calling LLM:
Tool | Description |
| Resolves A/AAAA/MX/TXT/NS/CNAME/SOA records for a domain |
| Enumerates subdomains via certificate transparency logs (crt.sh), passive DNS sources, and optional wordlist brute force |
| Audits HTTP response headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, etc.) |
| Inspects cookies for |
| Checks TLS/SSL certificate validity, chain, protocol versions, and cipher suites |
| Fetches and parses |
| Fetches and parses |
| Fingerprints frameworks, CMS, JS libraries, and server software (Wappalyzer-style detection) |
| Crawls linked resources and JS files for endpoints, API routes, and parameters worth manual review |
| Captures a visual snapshot of a page for quick triage of many hosts |
| Aggregates all tool outputs into a structured Markdown/JSON recon report |
These extend the recon surface while staying passive/low-impact:
Tool | Description |
| WHOIS/RDAP data — registrar, creation date, org, nameservers |
| Tests for permissive/misconfigured CORS policies (reflected origin, wildcard + credentials) |
| Passive checks for common open-redirect parameter patterns |
| Pulls historical URLs from the Wayback Machine / |
| Searches GitHub for leaked secrets, API keys, or internal references tied to the target domain/org |
| Downloads and greps JS bundles for hardcoded API keys, tokens, internal hostnames |
| Flags dangling CNAMEs pointing to unclaimed cloud resources (S3, Heroku, GitHub Pages, etc.) |
| Uses Shodan/Censys APIs (not direct scanning) to see already-indexed open ports/services |
| Decodes and analyzes JWTs found in requests for weak algorithms ( |
| Sends a small number of requests to see if basic rate limiting exists (low volume, non-disruptive) |
| Validates SPF/DKIM/DMARC records for the domain |
| Computes favicon hash ( |
| Optional, opt-in, rate-limited content discovery against a small curated wordlist |
| Tests if GraphQL introspection is exposed on discovered API endpoints |
| Combines |
| Compares current recon results to a previous run and highlights what changed (new subdomains, new headers, cert renewal, etc.) |
Related MCP server: Bug Bounty MCP Server
┌─────────────┐ MCP (stdio/HTTP) ┌──────────────────────┐
│ LLM Host │ ──────────────────────────────▶│ Bug Bounty MCP │
│ (Claude, etc)│ ◀──────────────────────────────│ Server │
└─────────────┘ tool calls/results └──────────┬───────────┘
│
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
DNS / crt.sh HTTP(S) client Headless browser
resolvers (headers, ssl, (screenshot,
robots, sitemap) JS rendering)Transport: stdio (default) or Streamable HTTP, per the MCP spec
Language: TypeScript (Node.js ≥ 18)
HTTP client: undici / axios
Headless browser: playwright (for take_screenshot, JS-rendered find_interesting_endpoints)
DNS: Node's built-in dns/promises, plus crt.sh queries for subdomain enumeration
Report output: Markdown by default, optional JSON
bug-bounty-mcp/
├── src/
│ ├── index.ts # MCP server entrypoint, tool registration
│ ├── tools/
│ │ ├── dns.ts
│ │ ├── subdomains.ts
│ │ ├── headers.ts
│ │ ├── cookies.ts
│ │ ├── ssl.ts
│ │ ├── robots.ts
│ │ ├── sitemap.ts
│ │ ├── technologies.ts
│ │ ├── endpoints.ts
│ │ ├── screenshot.ts
│ │ └── report.ts
│ ├── lib/
│ │ ├── http-client.ts # shared fetch wrapper, timeouts, retries
│ │ ├── rate-limiter.ts # global politeness/rate-limit control
│ │ ├── scope-guard.ts # validates target is in an allow-listed scope
│ │ └── logger.ts
│ └── types.ts
├── tests/
├── .env.example
├── package.json
├── tsconfig.json
└── README.mdNode.js ≥ 18
npm or pnpm
(Optional) Playwright browsers for screenshots: npx playwright install chromium
git clone https://github.com/<your-username>/bug-bounty-mcp.git
cd bug-bounty-mcp
npm install
cp .env.example .env
npm run buildnpm start
# or in dev mode with hot reload
npm run devAdd to your MCP config (claude_desktop_config.json or equivalent):
{
"mcpServers": {
"bug-bounty-assistant": {
"command": "node",
"args": ["/absolute/path/to/bug-bounty-mcp/dist/index.js"]
}
}
}Set these in .env:
# Comma-separated list of domains this server is allowed to scan.
# scope-guard.ts refuses to run tools against anything not listed here.
ALLOWED_SCOPE=example.com,*.example.com
# Requests per second ceiling applied globally (politeness)
MAX_REQUESTS_PER_SECOND=2
# Timeout (ms) for outbound HTTP requests
HTTP_TIMEOUT_MS=10000
# Optional API keys for enrichment tools
SHODAN_API_KEY=
CENSYS_API_ID=
CENSYS_API_SECRET=
GITHUB_TOKEN=Scope guard: every tool call passes the target through scope-guard.ts, which checks it against ALLOWED_SCOPE and refuses to run if the target isn't explicitly listed. This is the main safety rail — update it per-engagement before you start testing.
User: "Analyze example.com for bug bounty recon."
The LLM will typically:
Call get_dns_records and find_subdomains to map infrastructure
Call check_security_headers, analyze_cookies, and ssl_scan on discovered hosts
Call discover_robots / discover_sitemap for structure hints
Call detect_technologies to fingerprint the stack
Call find_interesting_endpoints to surface API routes worth manual review
Call take_screenshot for visual triage across many hosts
Call generate_report to produce a single Markdown summary with findings, severity notes, and suggested next manual steps
Sample report output:
# Recon Report — example.com
Generated: 2026-07-10
## DNS
- A: 93.184.216.34
- MX: none found
- NS: a.iana-servers.net, b.iana-servers.net
## Subdomains (4 found)
- www.example.com
- dev.example.com ⚠ exposed, no auth wall detected
- api.example.com
- mail.example.com
## Security Headers — www.example.com
- CSP: ❌ missing
- HSTS: ✅ present (max-age=63072000)
- X-Frame-Options: ❌ missing
## Recommendations
- Investigate dev.example.com — appears to be a non-production environment reachable externally
- Add CSP and X-Frame-Options headers on the main siteAdd wayback_urls, github_dork_search, check_cname_takeover
Add per-tool caching to avoid re-hitting the same host repeatedly in one session
Add a diff_scan tool to compare against a prior report
Support authenticated scans (session cookie/header injection) for logged-in recon
Add Slack/Discord webhook output for generate_report
Docker image for one-command deployment
Fork the repo and create a feature branch
Add or update tools under src/tools/
Add tests under tests/
Run npm run lint && npm test before opening a PR
This project performs reconnaissance only — no exploitation, no automated attack payloads, no denial-of-service behavior. It is the user's sole responsibility to:
Confirm the target is in scope for a bug bounty program or that they have explicit authorization to test it
Comply with the program's rules of engagement (rate limits, prohibited techniques, disclosure process)
Comply with local law
The maintainers accept no liability for misuse.
MIT
Inspects cookies for Secure, HttpOnly, SameSite flags
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | The target URL or domain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It omits whether the tool is read-only, what it returns (e.g., list of cookies with flags), and potential side effects. Only the action is stated, not the full behavior.
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 one sentence covering the core action. However, it could be expanded slightly without losing conciseness to include output or behavior 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 no output schema and no annotations, the description is incomplete. It does not explain what the tool returns (e.g., a report of flag statuses) or any prerequisites, making it less useful 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 coverage is 100% for the single parameter 'target', and the schema already describes it as 'The target URL or domain'. The description adds no additional semantics beyond the schema, so baseline score of 3 applies.
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 inspects cookies for Secure, HttpOnly, and SameSite flags, which is a specific verb-resource combination. It distinguishes from sibling tools like check_security_headers which focus on HTTP headers.
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 for checking cookie security flags but does not explicitly state when to use versus alternatives. No when-not-to or comparison with siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audits HTTP response headers (CSP, HSTS, X-Frame-Options, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | The target URL or domain |
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 the tool audits headers but does not mention whether it is read-only, any authentication requirements, rate limits, or what happens on failure.
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 effectively communicates the core purpose without unnecessary words. It is front-loaded and earns its place.
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 provides a basic understanding but omits what the output looks like and any return value details. It is minimally complete for straightforward 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?
Schema coverage is 100% for the single parameter 'target', which is already well-described. The description does not add further meaning or context beyond the schema, meeting the baseline but not exceeding it.
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 audits HTTP response headers and lists specific examples (CSP, HSTS, X-Frame-Options). It differentiates from siblings like 'analyze_cookies' or 'ssl_scan', which focus on different aspects.
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 description lacks any context about prerequisites, when it is appropriate, or when to use sibling tools instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fingerprints frameworks, CMS, JS libraries, and web servers
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | The target URL or domain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without disclosing side effects, permissions, rate limits, or return behavior.
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 is concise but lacks structure; it's front-loaded but omits important details, making it barely adequate.
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 only one parameter and no output schema, the description should clarify expected output or usage context. It does not, leaving agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (single 'target' param with description). Tool description adds no additional meaning beyond 'The target URL or domain', so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fingerprints frameworks, CMS, JS libraries, and web servers' clearly states the tool's action (fingerprinting) and specific resource categories, distinguishing it from sibling tools like analyze_cookies or ssl_scan.
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 or not use this tool, nor any mention of alternatives. Only implied usage from purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches and parses robots.txt for disallowed paths and sitemaps
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | The target domain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only states it 'fetches and parses' without mentioning error handling, caching, redirect behavior, or what happens if robots.txt is missing. Insufficient for a tool with zero annotation support.
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, no unnecessary words. Efficiently conveys the core action and outputs.
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 simple tool with one parameter and no output schema, the description is minimally adequate but could benefit from mentioning output format or edge cases. Falls short of fully preparing the agent for 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 describes the single 'target' parameter as 'The target domain' with 100% coverage. The description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool fetches and parses robots.txt, specifying outputs as disallowed paths and sitemaps. This is a specific verb-resource combination and distinguishes from sibling tools like discover_sitemap.
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 (e.g., discover_sitemap). No context about appropriate scenarios or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches and parses sitemap.xml for site structure and URLs
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | The target domain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as rate limits, authentication needs, error handling, or what happens if the sitemap is missing. It only states the basic action.
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 is front-loaded with the action. Every word is necessary, no waste.
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 output schema and no annotations, the description is somewhat complete for a simple parameter but lacks details on return format, error handling, or prerequisites (e.g., HTTPS). Adequate but with 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 coverage is 100% (one parameter 'target' with description). The description does not add meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetches and parses'), the resource ('sitemap.xml'), and the output ('site structure and URLs'). It distinguishes from siblings like 'discover_robots' and 'find_subdomains'.
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 for obtaining sitemap data, but lacks explicit guidance on when to use or not use this tool compared to alternatives. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scans the main page and linked scripts for links, forms, and API routes
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | The target URL or domain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals the tool is read-only (scans) and specifies the scope (main page and linked scripts), but does not disclose potential rate limits, timeouts, or whether it modifies state. More detail on behavior would be beneficial.
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 of 10 words, front-loaded with the verb 'Scans'. Every word is informative with no redundancy or fluff.
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 tool has no output schema, so the description should explain what the tool returns (e.g., list of endpoints). It only mentions what it scans for but not the format or structure of results, leaving a significant gap in completeness.
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 100% coverage with a description for the only parameter 'target'. The description does not add meaning beyond the schema's 'target URL or domain', so it meets the baseline without adding extra semantic value.
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 'scans' and the resource 'main page and linked scripts', and specifies what it finds: 'links, forms, and API routes'. This distinguishes it from sibling tools like detect_technologies or discover_sitemap.
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 the tool is for discovering endpoints but provides no explicit guidance on when to use it vs alternatives (e.g., discover_sitemap, find_subdomains). No when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerates subdomains via certificate transparency logs (crt.sh)
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | The target domain (e.g. example.com) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals the use of CT logs, indicating passive enumeration, but lacks details on rate limits, completeness guarantees, or whether the operation is read-only. More behavioral context is needed.
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, clear sentence that front-loads the core action. It contains no filler and is appropriately 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 simplicity (1 param, no output schema), the description is minimally adequate. However, it omits details about the output format or what the return data looks like, which leaves some 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?
Schema description coverage is 100%, so the parameter 'target' is already well-documented. The description adds no extra meaning beyond what the schema provides, meeting the baseline.
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 function: enumerating subdomains using certificate transparency logs. The verb 'Enumerates' and resource 'subdomains' are specific, and the mention of crt.sh distinguishes it from sibling tools like get_dns_records or ssl_scan.
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 alternatives. It does not specify prerequisites, limitations, or scenarios where it should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregates all tool outputs into a structured Markdown recon report
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The aggregated ReconReport data structure |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as whether the tool is read-only, destructive, or requires permissions. For a report generation tool, the absence of mutation warnings or safety context leaves the agent uninformed about 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 a single sentence with no wasted words, front-loading the key action and output format. Every word earns its place.
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 tool lacks an output schema and annotations, and the description does not specify what the tool returns (e.g., a Markdown string, a file path). It adequately describes input but leaves output behavior unexplained, limiting completeness for an aggregation tool.
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 100% (parameter 'data' described as 'The aggregated ReconReport data structure'). The description adds no extra meaning beyond the schema; baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool aggregates all tool outputs into a structured Markdown recon report. It uses a specific verb ('aggregates') and resource ('tool outputs', 'Markdown recon report'), and distinguishes itself from sibling tools which are individual reconnaissance tools.
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 after running sibling tools but provides no explicit guidance on when to use or not use this tool, nor alternative tools. Usage context is inferred but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolves A/AAAA/MX/TXT/NS/CNAME/SOA records for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | The target domain/hostname (e.g. example.com) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral info. It says 'resolves' but does not disclose rate limits, authentication requirements, side effects, or output format. This is minimal, leaving the agent without key behavioral context.
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 with no extraneous words. It is front-loaded with the key action and list of record types, making it efficient and scannable.
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 minimally adequate. However, it lacks any information about what the tool returns (e.g., raw DNS responses, parsed JSON), which is important for an agent to fully understand the tool's usage.
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 100% for the single parameter 'target', which already has a description. The tool description adds no additional meaning or constraints beyond the schema, so it meets the baseline but does not enhance understanding.
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 resolves specific DNS record types (A/AAAA/MX/TXT/NS/CNAME/SOA) for a domain, using a specific verb and resource. It distinguishes from sibling tools like find_subdomains or check_security_headers by focusing exclusively on DNS records.
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 explicit guidance on when to use this tool vs. alternatives, such as find_subdomains or ssl_scan. It implies usage for DNS lookups but does not specify contexts, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks TLS/SSL certificate validity, chain, protocol versions, and cipher suites
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | The target domain/hostname |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description carries the full burden. It states what is checked but does not disclose behavioral traits like network requirements, safety (read-only), or potential time consumption.
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-formed sentence with no wasted words, front-loading the action and scope.
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 tool has no output schema, and the description does not explain the return format or error behavior. Given the simplicity, some guidance on output would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'target'. The description adds context about the tool's purpose but does not clarify parameter format (e.g., protocol requirement, IP vs hostname). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Checks' and the resource 'TLS/SSL certificate validity, chain, protocol versions, and cipher suites', clearly distinguishing it from sibling tools like analyze_cookies or check_security_headers.
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 (e.g., for SSL health checks) but provides no explicit guidance on when to use or not use it, nor does it mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Captures a browser snapshot of a page using Playwright
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | The target URL or domain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must bear full burden of behavioral disclosure. It mentions 'using Playwright' but fails to detail key behaviors like page load waiting, viewport settings, full-page vs viewport capture, or output format. This is severely insufficient for a screenshot 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 very short (one sentence, 8 words), but it fails to include necessary information about behavior and output. While concise, it is not appropriately sized for the complexity of the tool, missing details that would aid the AI agent.
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 performs a non-trivial action (Playwright screenshot), the description lacks essential context: no output schema or return value description, no mention of timeouts, page load state, or image format. This is inadequate for an agent to use the tool correctly.
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 one parameter 'target' with a description ('The target URL or domain'). Schema coverage is 100%, so the description adds no additional meaning beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: capturing a browser snapshot using Playwright. The verb 'Captures' and resource 'browser snapshot of a page' are specific, and the tool is distinct from sibling tools (all security scanners, no screenshot tools), so no confusion.
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. The description does not mention prerequisites, common use cases, or when not to use it. Sibling tools are unrelated, so no differentiation needed, but still lacks usage 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.
v1.0.0analyze_cookiescheck_security_headersdetect_technologiesdiscover_robotsdiscover_sitemapfind_interesting_endpointsfind_subdomainsgenerate_reportget_dns_recordsssl_scantake_screenshotEach tool targets a distinct recon area (cookies, headers, technologies, etc.) with no overlap. An agent can clearly differentiate them.
All names follow a consistent verb_noun pattern with underscores, e.g., analyze_cookies, check_security_headers. No mixing of conventions.
11 tools is well-scoped for a bug bounty recon assistant. Each tool serves a clear purpose without being too many or too few.
Covers most common initial recon tasks: subdomain enumeration, DNS, SSL, headers, technologies, endpoints, and report generation. Minor gaps like port scanning or directory brute-forcing are absent but acceptable for this scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rohitprasad-code/recon-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
