Xuanmu-BugBounty-mcp is a self-contained, zero-dependency MCP toolkit for bug bounty hunting and SRC vulnerability testing, covering the full lifecycle from reconnaissance to report generation with built-in anti-blocking and WAF protection strategies.
Reconnaissance
bb_ping — TCP + HTTP dual-mode target liveness detection
bb_port_scan — TCP port scanning with Top100 or custom ranges
bb_subdomain — DNS-based subdomain enumeration with custom wordlists
bb_fingerprint — Web technology stack, CMS, and WAF fingerprinting
bb_dir_scan — Directory/file brute-forcing with 150+ built-in sensitive paths
Vulnerability Detection
bb_sqli — SQL injection (error-based, boolean, time-blind)
bb_nosqli — NoSQL injection detection
bb_xss — Reflected XSS across multiple contexts
bb_ssti — SSTI for Jinja2, Twig, FreeMarker, Velocity, ERB, Smarty
bb_cmdi — Command injection via time-blind and output-echo
bb_ssrf — SSRF with internal network probing and OOB hints
bb_cors — CORS misconfiguration testing
bb_open_redirect — Open redirect detection with parameter scanning
bb_file_upload — File upload bypass (extension, MIME, double extension, .htaccess, SVG)
bb_csrf — CSRF detection via token analysis, SameSite, Referer/Origin checks
bb_xxe — XXE detection (classic, blind OOB, XInclude, SVG)
bb_lfi — LFI/path traversal with PHP filter tests
bb_host_inject — Host header injection with 9 attack scenarios
bb_takeover — Subdomain takeover via CNAME + 50+ cloud service matching
bb_race — Race condition testing with concurrent requests and response diff analysis
Authentication & JWT Security
bb_jwt_decode — Decode JWT header/payload without signature verification
bb_jwt_analyze — Full JWT security analysis with vulnerability detection and attack suggestions
bb_jwt_crack — HMAC key brute-force with built-in or custom wordlists
bb_jwt_attack — JWT attacks: None algorithm, KID injection, RS256→HS256 confusion
bb_graphql — GraphQL scanning: introspection, batch queries, deep recursion, schema extraction
Information Extraction
bb_extract — Extract URLs and API endpoints from HTML and JS
bb_secrets — Sensitive data detection with 20+ regex patterns (keys, tokens, passwords, internal IPs)
bb_headers — Security header audit with scoring and remediation advice
bb_param_discover — Auto parameter discovery from forms, queries, JSON fields, and JS variables
bb_js_analyze — JavaScript file analysis
Utilities
bb_send — Custom HTTP request sender with custom methods, headers, and body
bb_payload — Payload factory for XSS/SQLi/SSTI/SSRF and more, with encoding variants
bb_oob — OOB callback payload generator for blind SSRF/XXE/RCE verification
bb_idor — IDOR testing
bb_cloud_check — Cloud service security checking
bb_waf_check — WAF identification
bb_session — Multi-step session handling
bb_report — Generate structured SRC-format Markdown vulnerability reports
All network tools support Bearer Token and Cookie authentication, proxy configuration, request timeouts, User-Agent rotation, and WAF protection modes (safe/aggressive) with retry logic and circuit breakers.
Provides tools for scanning GraphQL endpoints, including introspection, batch queries, and recursive queries to detect vulnerabilities.
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., "@Xuanmu-BugBounty-mcp check if example.com is vulnerable to SQL injection"
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.
玄幕安全团队 · guaidao2 开发
独立自包含的 SRC 挖洞专用 MCP 工具包 — 零外部扫描器依赖，即装即用
git clone https://github.com/guaidao2/Xuanmu-Bugbounty-mcp.git
cd Xuanmu-BugBounty-mcp
pip install -e . -i https://pypi.tuna.tsinghua.edu.cn/simple
# 启动
xuanmu-bb
# 或: python "绝对路径/src/xuanmu_bb/server.py"Related MCP server: mcp-security-toolkit
{
"mcpServers": {
"Xuanmu-BugBounty-mcp": {
"command": "xuanmu-bb"
}
}
}所有漏洞检测工具返回统一的 JSON 格式，LLM 可直接解析：
{
"tool": "bb_sqli",
"target": "https://example.com",
"status": "confirmed",
"summary": "发现 3 个可疑点（2个CRITICAL, 1个HIGH），其中 2 个已确认",
"findings": [{
"param": "id", "payload": "' AND SLEEP(3) --",
"type": "time_based", "severity": "CRITICAL",
"evidence": "时间盲注: 响应延迟 3.2s",
"verified": true,
"verified_by": "二次确认: sleep(5) 延迟 5.1s"
}],
"waf": {"detected": true, "name": "Cloudflare"},
"metadata": {"duration_ms": 8234, "requests_sent": 45}
}漏洞类型 | 首次检测 | 二次确认方式 |
SQLi 时间盲注 | SLEEP(3) 延迟 | 重试 SLEEP(5) 验证 |
SQLi 布尔盲注 | 1=1 vs 1=2 差异 | 换 2=2 vs 2=1 验证 |
XSS | payload 未编码反射 | 不同向量 ( -> ) 交叉验证 |
SSTI | 7*7 -> 49 | 验证 8*8 -> 64 |
CMDI | ping -c 3 延迟 | 重试 ping -c 5 |
SSRF/LFI | 响应含系统文件 | 自动确认；大小变化则换地址重试 |
确认后的 finding 标记 verified: true，severity 升为 CRITICAL。
所有漏洞检测工具支持 custom_payloads 参数，与内置 Payload 合并执行：
bb_sqli url="..." custom_payloads="' OR 1=1 -- ,1' AND SLEEP(10) -- "
bb_xss url="..." custom_payloads="<script>alert(document.cookie)</script>,<img src=x onerror=alert(1)>"融合 Wappalyzer + EHole + FingerprintHub 三大项目的检测思路：
检测源 | 数量 | 方法 |
FingerprintHub 全量 | 2,224 条 | 关键词AND + 33 favicon哈希 + 评分 |
增强指纹库 | 79 条 | 多信号评分 + 关键词AND + 隐含推导 |
Wappalyzer | 运行时 | 库检测 |
Favicon 哈希 | 运行时 | MMH3 32-bit 计算 (Shodan/EHole 兼容) |
Meta Generator | 运行时 | HTML meta 标签提取 CMS+版本 |
覆盖 27 个技术分类：CMS、OA/办公、ERP/财务、框架/语言、Web服务器、CDN/代理、WAF/安全、数据库、网络设备、监控/日志、邮件系统、VPN/远程、堡垒机、DevOps、视频监控、NAS/IoT、云服务等。
隐含技术推导：WordPress -> PHP + MySQL、Django -> Python、Spring Boot -> Java、Element UI -> Vue.js ...
输出按技术分类分组，附带 WAF 检测和后续测试建议。
bb_fingerprint url="https://example.com"以下工具凡涉及 HTTP 请求的，均支持通用认证参数：
auth_token（Bearer Token）、cookie、proxy、timeout。 漏洞检测类工具额外支持：waf_mode、method（GET/POST）、body、custom_payloads。
工具 | 功能 | 特有参数 |
| 存活探测 — TCP + HTTP 双重检测 | target |
| 端口扫描 — Top100/自定义范围 | target, ports, concurrent |
| 子域名枚举 — DNS 批量解析 | domain, wordlist, concurrent |
| 增强指纹识别 — 2300+指纹/27分类/favicon哈希 | url |
| 目录爆破 — 内置 150+ 敏感路径 | url, wordlist, status_filter, concurrent |
工具 | 功能 | 特有参数 |
| SQL 注入 — 报错/布尔/时间盲注 + 二次确认 | url, params, custom_payloads |
| NoSQL 注入 — MongoDB $ne/$gt/$regex | url, params |
| XSS 检测 — 反射型/多上下文 + 交叉验证 | url, params, custom_payloads |
| SSTI 模板注入 — 多引擎 + 数值确认 | url, params, custom_payloads |
| 命令注入 — 时间盲注+输出回显 + 确认 | url, params, custom_payloads |
| SSRF 检测 — 内网/云元数据/OOB + 确认 | url, params, custom_payloads |
| CORS 跨域 — 12 种 Origin 测试 | url |
| 开放重定向 — 参数扫描+跳转测试 | url, params |
| 文件上传绕过 — 多扩展名/MIME/截断 | url |
| CSRF 检测 — Token/SameSite/Referer 分析 | url |
| XXE 检测 — 经典/Blind/SVG/XInclude | url, body, content_type |
| 路径遍历 — ../遍历/PHP filter + 确认 | url, params, custom_payloads |
| Host 头注入 — 9 种攻击场景 | url |
| 子域名接管 — CNAME+50+云服务匹配 | domain |
| 条件竞争 — 并发请求+响应差异分析 | url, method, data, concurrent |
工具 | 功能 | 特有参数 |
| JWT 解码 — 解析 Header/Payload | token |
| JWT 安全分析 — 漏洞检测+攻击建议 | token |
| JWT 密钥爆破 — HMAC 字典攻击 | token, wordlist |
| JWT 攻击 — None/KID注入/算法混淆 | token, mode, payload_override, public_key |
| GraphQL 扫描 — Introspection/批量/递归 | url |
工具 | 功能 | 特有参数 |
| URL/Endpoint 提取 — HTML+JS分析 | url, depth |
| 敏感信息检测 — 20 种正则模式 | url, check_js |
| 安全头审计 — 8 项评分+修复建议 | url |
| 参数自动发现 — 表单/查询/JSON/JS | url, depth |
| JS 深度分析 — API路由/Sourcemap/硬编码/WebSocket | url |
工具 | 功能 | 特有参数 |
| 手工 HTTP 发包 — JSON/form/multipart/文件上传 | url, method, headers, body, content_type, files, follow_redirects |
| Payload 工厂 — 9 类漏洞 x 6 种编码 | vuln_type, encode, count |
| OOB 外带辅助 — 回调标识/Payload 建议 | mode, callback_url |
| IDOR 越权检测 — 双 Token 对比 + 序号枚举 | url, token_owner, token_attacker, param, method |
| 云服务安全 — S3/元数据/云配置泄露 | url |
| WAF 指纹识别 — 14 种 WAF + 绕过建议 | url |
| 多步骤流程 — Session保持 + 请求链 | steps (JSON) |
| 漏洞报告生成 — SRC 格式 Markdown | vuln_type, target, param, payload, impact, detail, poc |
参数 | 适用工具 | 说明 |
| 所有 HTTP 工具 | Bearer Token，自动添加 |
| 所有 HTTP 工具 | Cookie 字符串，自动添加 |
| 所有 HTTP 工具 | 代理地址，如 |
| 所有 HTTP 工具 | 请求超时秒数（默认 15） |
| 漏洞检测 |
|
| 漏洞检测 |
|
| 漏洞检测 | POST 请求体，如 |
| sqli/xss/ssti/cmdi/ssrf/lfi | 逗号分隔的自定义 Payload，与内置 Payload 合并执行 |
| 漏洞检测+dir_scan | 请求间隔秒数，检测到 WAF 后自动升为 3s |
# 1. 指纹识别（识别技术栈 + WAF + 分类）
bb_fingerprint url="https://target.com"
# 2. 目录扫描
bb_dir_scan url="https://target.com"
# 3. 参数发现
bb_param_discover url="https://target.com/api"
# 4. 漏洞检测（使用发现的参数 + 自定义 payload）
bb_sqli url="https://target.com/page?id=1" params="id" \
custom_payloads="' OR 1=1 -- ,' AND SLEEP(5) -- "
bb_xss url="https://target.com/search?q=test" params="q" \
custom_payloads="<script>alert(1)</script>,<img src=x onerror=alert(1)>"
bb_ssti url="https://target.com/welcome?name=test" params="name"
bb_cmdi url="https://target.com/ping?host=127.0.0.1" params="host"
bb_ssrf url="https://target.com/fetch?url=http://example.com" params="url"
bb_lfi url="https://target.com/file?name=test.txt" params="name"
bb_cors url="https://api.target.com/data"
bb_open_redirect url="https://target.com/redirect?url=https://example.com"
bb_xxe url="https://target.com/xml/parse"
# 5. 认证测试
bb_jwt_analyze token="eyJhbGciOiJIUzI1NiIs..."
bb_jwt_attack token="..." mode="none"
bb_graphql url="https://target.com/graphql"
# 6. 多步骤业务流
bb_session steps='[
{"method":"POST","url":"https://target.com/login","body":"user=admin&pass=test"},
{"method":"GET","url":"https://target.com/api/profile"}
]'
# 7. 生成报告 + bb_send 全格式示例
bb_report vuln_type="sqli" target="https://target.com/page?id=1" \
payload="' OR 1=1 -- " impact="可获取数据库所有数据"
# bb_send: JSON 自动识别
bb_send url="https://api.example.com/login" method="POST" \
body='{"user":"admin","pass":"test"}'
# bb_send: Form 自动识别
bb_send url="https://example.com/search" method="POST" \
body="q=test&page=1"
# bb_send: 文件上传 (multipart/form-data)
bb_send url="https://example.com/upload" method="POST" \
files="file=/path/to/shell.php" body="action=upload"
# bb_send: XML 手动指定 Content-Type
bb_send url="https://example.com/api" method="POST" \
headers="Content-Type: application/xml" \
body='<?xml version="1.0"?><root>data</root>'# Bearer Token
bb_sqli url="https://target.com/api/search" params="q" auth_token="eyJ..."
# Session Cookie
bb_xss url="https://target.com/search" params="q" cookie="JSESSIONID=ABCD1234"# 先检测 WAF
bb_waf_check url="https://target.com"
# 带 WAF 防护扫描（自动降速 + UA轮换）
bb_sqli url="https://target.com/page?id=1" waf_mode="safe" request_delay="3"src/xuanmu_bb/
├── server.py # MCP 入口（39 工具，注册表模式）
├── client.py # HTTP 客户端（代理/Cookie/UA轮换/反封策略）
├── utils.py # 公共工具 + ResultBuilder 结构化输出
├── data/
│ ├── payloads.py # SQLi/XSS/SSTI/CMDI/SSRF/LFI Payload
│ ├── dicts.py # 子域/目录字典 + 端口映射 + 弱口令
│ ├── fingerprints.py # Web 指纹库 + WAF 签名
│ ├── fingerprints_enhanced.py # 增强指纹库（79条，27分类）
│ ├── fingerprints_hub.py # FingerprintHub 全量（2,224条，365KB）
│ ├── patterns.py # 敏感信息正则 + 安全头列表
│ └── waf.py # WAF 检测引擎
├── recon/ # 侦察模块（5 工具）
├── vuln/ # 漏洞检测模块（15 工具，均支持二次确认）
├── auth/ # 认证安全模块（5 工具）
├── extract/ # 信息提取模块（5 工具）
└── tools/ # 工具模块（9 工具 + fingerprint_importer）完全自包含 — 不依赖 nmap/nuclei/burp 等外部工具，纯 Python 实现
结构化 JSON 输出 — 所有漏洞检测返回统一格式，LLM 可直接解析联动
检测二次确认 — SQLi/XSS/SSTI/CMDI/SSRF/LFI 自动验证减少误报
2300+ 指纹库 — 融合 FingerprintHub + Wappalyzer + EHole，覆盖 27 个技术分类
Favicon 哈希 — MMH3 32-bit 计算，兼容 Shodan/EHole 指纹匹配
自定义 Payload — 所有漏洞工具支持用户注入自定义 Payload
反封策略 — User-Agent 轮换 / 请求间隔控制 / 代理支持 / WAF 熔断
注册表模式 — server.py 新增工具仅需一行元组，无需重复样板代码
16 个单元测试 — 覆盖 utils、payloads、dicts 核心模块
本项目仅供合法的安全测试与漏洞挖掘使用。使用者需遵守相关法律法规。
Xuanmu-BugBounty-mcp (c) 2026 玄幕安全团队 · guaidao2
命令注入检测 — 时间盲注 + 输出回显
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| proxy | No | ||
| cookie | No | ||
| params | No | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions specific techniques (time blind + output echo) giving some behavioral insight, but fails to disclose that the tool sends HTTP requests, potential destructive actions, or authentication needs. No annotations exist to compensate.
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 line, concise but lacking structure. It communicates the purpose efficiently but is too brief for proper context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema presence, the description fails to explain the tool's behavior with 6 undocumented parameters, leaving an agent unable to correctly invoke it. No annotations or parameter details are 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?
With 0% schema description coverage, the description must explain parameters, but it does not mention any of the 6 parameters or their roles in the detection process.
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 is for command injection detection, specifying two techniques (time blind and output echo). This is a specific verb-resource combination that distinguishes it from siblings like bb_sqli or bb_lfi.
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, no prerequisites, and no context about required inputs or expected outcomes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CORS 跨域检测 — 12 种 Origin 反射测试 + 预检请求 + 凭据配置分析
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| proxy | No | ||
| cookie | No | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool performs 12 types of Origin reflection tests and analyzes preflight requests and credentials, but it does not mention whether the tool is destructive, requires authentication, or any 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 very concise (one line) and front-loads the core purpose. However, it sacrifices necessary detail, especially about parameters. Still, it is efficient for the purpose it serves.
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 5 parameters and an output schema, the description is incomplete. It lacks explanation of input parameters, expected output, and usage scenarios. The 12 tests mentioned are not elaborated.
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 explain any of the 5 parameters (url, proxy, cookie, timeout, auth_token). The agent must rely solely on parameter titles and types, which is insufficient for correct usage.
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 is for CORS detection, specifying '12 Origin reflection tests + preflight requests + credential configuration analysis'. This is specific and distinguishes it from sibling tools like bb_headers. However, the verb '检测' (detection) is implicit rather than explicit about the action taken.
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 vs alternatives (e.g., bb_headers). The description only states what the tool does but does not provide context for selection or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CSRF 检测 — 表单 Token 分析 + Cookie SameSite + Referer/Origin 校验
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| proxy | No | ||
| cookie | No | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses three types of checks performed, but lacks details on side effects, request behavior, or return format. No annotations exist to compensate.
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 concise line covers the main purpose, though it could include more detail without being verbose.
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 5 parameters, no parameter descriptions, and an output schema not shown, the description is insufficient to fully guide 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 coverage is 0% and description does not explain any of the 5 parameters (url, proxy, cookie, etc.), leaving their semantics unclear.
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's for CSRF detection and specifies three distinct analysis components (form token, SameSite, Referer/Origin), differentiating it from siblings like bb_cors or bb_xss.
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 vs alternatives, nor any prerequisites or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
目录/文件爆破 — 内置 150+ 敏感路径字典
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| proxy | No | ||
| cookie | No | ||
| timeout | No | ||
| wordlist | No | ||
| auth_token | No | ||
| concurrent | No | ||
| status_filter | No | 200,301,302,307,308,401,403,405,500 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral traits. It only mentions brute-force and built-in dictionary, but does not disclose potential noise, rate limiting, authentication requirements, or how the tool behaves with concurrent requests or status filters. This is insufficient for a security scanning 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 a single short sentence, which is concise but overly so given the lack of other documentation. It front-loads the main action, but omits crucial details, making it minimal rather than efficiently informative.
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 (8 parameters, no annotations, but has an output schema not described), the description is far from complete. It does not explain expected output, result interpretation, or any operational nuances. The output schema exists but is not leveraged in the description.
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 provides no information about any of the 8 parameters. The parameter names (url, proxy, cookie, etc.) are self-explanatory to some extent but the description fails to clarify formats, defaults, or how they affect behavior. For a tool with 8 params, this is critically lacking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs directory/file brute-force with a built-in 150+ sensitive path dictionary. It uses a specific verb (爆破/brute-force) and resource (目录/文件 directories/files), and distinguishes from sibling tools like bb_subdomain or bb_port_scan which focus on different attack vectors.
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 use for discovering hidden paths, but provides no explicit guidance on when to use or not use this tool, nor compares it to alternatives. The sibling tools list suggests many other attack types, but no differentiation is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
URL/Endpoint 提取 — 从 HTML 和 JS 中提取链接、API 端点
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| depth | No | ||
| proxy | No | ||
| cookie | No | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 basic extraction function, omitting details like authentication needs, handling of JS execution, redirect following, rate limits, or safety 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, front-loaded with the core purpose. However, it lacks structure and additional detail, but is efficient for its minimalism.
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 6 parameters, no parameter descriptions, no annotation, and an existing output schema not described, the description is grossly incomplete. It fails to explain usage, behavior, or output, making it insufficient for correct tool 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 0% (no parameter descriptions in schema) and the description adds no meaning. Parameters like depth, proxy, cookie, timeout, auth_token are not explained, leaving their purpose ambiguous.
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: extracting URLs and API endpoints from HTML and JS. The verb 'extract' and resource 'links, API endpoints' are specific. Among siblings, this tool is distinct as a reconnaissance extraction tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus siblings. The description lacks context on prerequisites, alternatives, or scenarios, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
文件上传绕过检测 — 扩展名/MIME/双扩展名/截断/.htaccess/SVG
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| proxy | No | ||
| cookie | No | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only lists techniques without describing the tool's behavior (e.g., whether it sends requests, what it checks, potential destructive actions, 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?
While the description is very short, it is under-specified to the point of being unhelpful; it reads as a title rather than a functional description, sacrificing information for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters lacking any documentation, no annotations, and only a one-line description, the description fails to provide essential context about inputs, outputs, or behavior, making it nearly unusable for an AI agent without 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?
Schema coverage is 0% (no parameter descriptions), and the tool description does not explain any of the five parameters (url, proxy, cookie, timeout, auth_token), leaving their purpose and format completely unclear.
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 states 'File upload bypass detection' and lists specific techniques (extension, MIME, double extension, truncation, .htaccess, SVG), clearly identifying the tool's purpose and differentiating it from sibling tools that target other vulnerabilities.
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 other sibling tools, no exclusions, and no context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Web 指纹识别 — 技术栈/CMS/WAF 识别 + 绕过建议
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| proxy | No | ||
| cookie | No | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description states the tool 'identifies' and gives 'bypass suggestions', but does not disclose whether it sends network requests, modifies anything, or if it is safe. The behavioral impact (e.g., potential WAF triggers) is not mentioned, leaving the agent uninformed.
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 line) and conveys core purpose without redundancy. It is front-loaded with the main action. However, it could be slightly more structured (e.g., separate output info), but overall it is 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 complexity (5 parameters, has output schema) and no annotations, the description is incomplete. It lacks details on parameter usage, output format, and expected behavior. The output schema exists but is not described, so the agent cannot anticipate result structure.
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%, meaning the schema does not explain parameters. The description fails to add meaning to the 5 parameters. It only implies 'url' is the target, but does not explain 'proxy', 'cookie', 'timeout', or 'auth_token'. The agent has no semantic help for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs web fingerprinting to identify tech stack, CMS, WAF, and provides bypass suggestions. The verb'指纹识别' (fingerprint recognition) combined with the listed targets makes the purpose specific. However, it does not explicitly differentiate from sibling tools like bb_dir_scan, but the unique function is clear.
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. It does not mention prerequisites, scenarios, or that it should be used for initial reconnaissance. The sibling tools cover different attack types, but no comparison or usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GraphQL 安全扫描 — Introspection/批量查询/深度递归/Schema 提取
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| proxy | No | ||
| cookie | No | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It lists scan types but does not state side effects, required permissions, whether data is modified, or what happens if the endpoint is not GraphQL.
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 line, directly conveying the tool's purpose and key features with no redundant 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?
For a security scanner with 5 parameters and a potential complex output, the description lacks details on output format, behavior when scanning, and how parameters interact. It does not compensate for the missing schema descriptions.
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 explain any of the 5 parameters (url, proxy, cookie, timeout, auth_token). The user gets no help understanding what each parameter does.
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 a GraphQL security scanner and lists specific attack types (introspection, batch query, deep recursion, schema extraction). This differentiates it from sibling tools focusing on other vulnerabilities like SQL injection or XSS.
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. While the purpose implies usage for GraphQL endpoint testing, there is no mention of alternatives or conditions where it is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
安全头审计 — 检查 8 项安全响应头 + 评分 + 修复建议
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| proxy | No | ||
| cookie | No | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the core behavior (checking headers, scoring, suggestions) but lacks details on how the tool behaves under error conditions, authentication requirements (auth_token parameter), or potential side effects. The behavior is adequately described for a simple audit 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 a single sentence, which is concise but lacks detail about parameters and usage. It front-loads the purpose, but for a tool with 5 parameters, it is too brief to be fully useful.
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 (5 parameters, no schema descriptions, no annotations), the description is incomplete. It omits parameter explanations and usage context, forcing the agent to rely on the schema alone, which lacks descriptions. The existence of an output schema does not compensate for input 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?
Schema description coverage is 0%, and the description does not explain any of the 5 parameters. It only implies 'url' as the target but gives no information about 'proxy', 'cookie', 'timeout', or 'auth_token'. This severely hampers correct invocation.
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 function: checking 8 security response headers, providing a score, and offering fix suggestions. It uses a specific verb ('check') and resource ('security response headers'), distinguishing it from sibling tools like bb_cors or bb_csrf.
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 security header auditing but does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or prerequisites. The intended context is inferred from the name and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Host 头注入检测 — Host 覆盖/XFH/Forwarded/重复 Host 等 9 种测试
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| proxy | No | ||
| cookie | No | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions 9 types of tests but does not disclose how it executes them, what side effects occur (e.g., sending requests), or any authentication requirements (though an auth_token parameter exists). The output schema is present but not referenced.
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 redundant information. It front-loads the purpose and scope. However, it is entirely in Chinese, which may affect readability for some agents.
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 5 parameters, no annotations, and no schema descriptions, the description is too minimal. It does not cover usage prerequisites, parameter details, or output expectations, despite the existence of an output schema.
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. However, it provides no explanation of the parameters (url, proxy, cookie, timeout, auth_token), leaving the agent with no guidance beyond their names and types.
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: Host header injection detection. It lists specific attack types (Host override, XFH, Forwarded, duplicate Host, etc., 9 types), making it distinct from sibling tools like bb_headers or bb_sqli.
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 host header injection testing, but does not provide explicit guidance on when to use vs. alternatives, nor does it mention when not to use it. Sibling tool names provide context, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JWT 安全分析 — 完整分析报告（解码 + 漏洞检测 + 攻击建议）
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool produces a report with decoding, vulnerability detection, and attack recommendations, but does not disclose whether it is read-only, requires permissions, or has side effects. The high-level behavior is clear but lacks detail on constraints or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the main purpose. It contains no unnecessary words and effectively communicates the tool's function.
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 output schema exists (though not provided), the description covers the output's nature (complete analysis report). However, it lacks details on error handling or input constraints. The sibling tools provide context, making it fairly complete for a report-producing 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?
The input schema has one required parameter 'token' with 0% description coverage. The description does not explain what the token should be (e.g., full JWT string) or any formatting constraints. It adds no value beyond the schema's title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs JWT security analysis, providing a complete report with decoding, vulnerability detection, and attack recommendations. It effectively distinguishes itself from sibling tools like bb_jwt_decode, bb_jwt_crack, and bb_jwt_attack, which cover only specific 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?
The description implies usage for comprehensive JWT analysis but does not explicitly state when to use this tool versus siblings or provide exclusions. No guidance on prerequisites or alternatives is given, though context implies it is for analysis after decoding or cracking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JWT 攻击 — None 签名/KID 注入/算法混淆 (RS256→HS256)
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | none | |
| token | Yes | ||
| public_key | No | ||
| verify_url | No | ||
| payload_override | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It names attack types but does not disclose behavioral traits such as whether the tool modifies the token, requires network access, or affects the system. The agent cannot infer safety or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line) and front-loaded with the purpose, which is good. However, it is too terse for a tool with 5 parameters and no schema descriptions, sacrificing necessary detail.
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 (5 params, multiple attack modes) and lack of descriptions, the description is incomplete. It does not cover return values (output schema exists but not referenced), error conditions, or prerequisites. The agent would struggle to use this 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?
Schema description coverage is 0%, so the description must clarify parameters. It mentions attack types but does not link them to the 'mode' parameter or explain the role of 'public_key', 'verify_url', or 'payload_override'. Almost no added parameter meaning.
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 performs JWT attacks, listing specific techniques (none signature, KID injection, algorithm confusion). This helps distinguish from sibling tools like bb_jwt_analyze, bb_jwt_crack, and bb_jwt_decode, though it does not explain the exact relationship.
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 given on when to use this tool versus alternatives (e.g., bb_jwt_crack or bb_jwt_analyze). The description lacks context for the agent to decide among the JWT siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JWT 暴力破解 — 尝试破解 HMAC 密钥，不传 wordlist 则自动使用内置 Top 100+ 弱密钥字典
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| wordlist | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the core behavior (cracking with optional wordlist and default dictionary) but does not mention potential side effects (e.g., time consumption, network activity) or authentication requirements. The transparency is adequate but not exhaustive.
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 that front-loads the purpose and includes a critical condition (auto-use dictionary). No extraneous words; every part 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 that the tool has no annotations and an output schema (though not detailed in description), the description lacks information about return values, failure modes, or potential side effects. For a cracking tool, details like timeout or network usage would be helpful. It is adequate but not fully complete.
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. It explains the wordlist parameter's default behavior (auto-use built-in dictionary) and implicitly clarifies the token parameter via tool name. However, it does not add explicit details for the token parameter. This provides moderate added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: cracking JWT HMAC keys via brute-force. It uses a specific verb (破解/crack) and resource (HMAC key of JWT), and is clearly distinguishable from sibling JWT tools like bb_jwt_analyze or bb_jwt_decode.
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 includes key usage information: attempting to crack HMAC keys and automatically using a built-in weak key dictionary if no wordlist is provided. It does not explicitly state when not to use it or mention alternatives, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JWT 解码 — 解析 Header/Payload（不验证签名）
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the tool does not verify the signature, a critical behavioral trait. With no annotations provided, this disclosure is valuable. It does not elaborate on error handling or output format, but the output schema covers that.
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, front-loading the tool's purpose and key behavior (no signature verification). 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?
Given the tool's simplicity (one parameter), the presence of an output schema, and the description covering the main purpose and critical non-verification behavior, it is fairly complete. It could add a note about what the output contains, but the schema likely handles that.
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 adds minimal meaning beyond the schema: it explains that the token is a JWT and that the tool decodes it. It does not describe token format, constraints, or the output structure.
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 decodes a JWT and parses the header and payload without signature verification. This distinguishes it from sibling tools like bb_jwt_verify or bb_jwt_attack, though explicit sibling differentiation is absent.
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 when a JWT's contents need to be inspected without verifying the signature, but does not explicitly state when not to use it or provide alternatives. The non-verification trait provides some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LFI 路径遍历检测 — 多种遍历/PHP filter 测试
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| proxy | No | ||
| cookie | No | ||
| params | No | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions performing multiple traversal/PHP filter tests but does not disclose potential destructive behavior (e.g., reading sensitive files) or error handling. Minimal 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 very concise (two short sentences) but lacks structure. It front-loads the main purpose but does not provide additional context. Could be more informative without adding length.
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 6 parameters and an output schema, the description is incomplete. It does not explain what the tool returns, how parameters affect behavior, or what 'params' and 'auth_token' are for. The output schema may help, but the description itself offers insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. Only the required 'url' is implied, but no details on proxy, cookie, params, timeout, or auth_token.
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 for LFI (Local File Inclusion) path traversal detection, using multiple traversal and PHP filter tests. The verb is implied (detect/test), and the resource is LFI. It distinguishes from sibling tools like bb_sqli and bb_xss.
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 when or when-not instructions, but the name and description imply use for LFI testing. Alternatives are not mentioned, but the context of sibling tools provides implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OOB 外带检测辅助 — 生成回调标识/Payload 建议，用于 Blind SSRF/XXE/RCE 验证
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | generate | |
| callback_url | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only states the tool generates suggestions but does not explain side effects (e.g., making outbound requests), authentication needs, rate limits, or safety profile. The brief description fails to compensate for missing annotations.
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 and front-loaded with the tool's purpose ('OOB 外带检测辅助'). However, it is too brief to cover necessary details; could be slightly expanded without losing conciseness.
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 (for security testing, has output schema, multiple parameters), the description is incomplete. It does not explain output format, supported modes, or how to interpret the generated payload. An AI agent lacks sufficient information to use the tool effectively.
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 2 parameters (mode, callback_url) with 0% description coverage. The description does not explain parameter roles, valid values for 'mode', or how to use 'callback_url'. Without schema descriptions, the tool description should provide this context but does not.
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 tool assists OOB detection for Blind SSRF/XXE/RCE by generating callback identifiers/payload suggestions. The verb '生成' (generate) and resource '回调标识/Payload 建议' are specific. However, it does not explicitly differentiate from sibling tools like bb_ssrf or bb_xxe, which might have overlapping purposes.
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?
Description implies usage context ('用于 Blind SSRF/XXE/RCE 验证') but lacks explicit guidance on when to use this tool vs alternatives like bb_ssrf or bb_xxe. No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
开放重定向检测 — 多种跳转测试 + 常见参数名扫描
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| proxy | No | ||
| cookie | No | ||
| params | No | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions 'multiple redirect tests' and 'parameter scanning' without disclosing side effects, rate limits, or safety profile.
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; it is concise but lacks necessary detail for proper tool usage.
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 6 parameters and is a security scanner, the description is extremely sparse and fails to explain testing behavior, parameter usage, or output characteristics (though output schema exists).
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 adds no meaning to the 6 parameters (e.g., url, proxy, params). The 'params' field could be related to scanning but is not clarified.
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 is for open redirect detection with multiple redirect tests and common parameter scanning, distinguishing it from sibling tools like bb_xss or bb_ssrf.
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 vs alternatives, no prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
参数自动发现 — 从页面/API/JS 中提取表单参数/查询参数/JSON 字段/JS 变量
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| depth | No | ||
| proxy | No | ||
| cookie | No | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It only states what is extracted but does not disclose whether the tool is read-only, requires authentication, or any side effects. This is insufficient for a discovery 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 a single concise line, front-loading the primary purpose. However, it could be slightly more structured with key 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 complexity (6 parameters, no annotations, but has output schema), the description is too sparse. It does not explain behavior, return values, or how parameters influence output. The agent lacks sufficient information to use the tool effectively.
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 explain any parameters beyond the schema's titles. With 6 parameters and no additional context, the agent cannot infer semantics like meaning of 'depth', 'proxy', or 'auth_token'.
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: automatic parameter discovery from various sources (page, API, JS) for form parameters, query parameters, JSON fields, and JS variables. It is specific and distinct from sibling attack 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 provides no guidance on when to use this tool versus alternatives (e.g., when to perform parameter discovery vs. other operations). There are no usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Payload 工厂 — 生成 XSS/SQLi/SSTI/SSRF 等 9 类 Payload，支持 6 种编码变体
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| encode | No | raw | |
| vuln_type | No | xss |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral transparency. It only lists capabilities (9 types, 6 encodings) but discloses no side effects, limits, or outputs. For instance, it does not state whether payloads are random, if count affects generation, or if network access 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 concise sentence in Chinese, front-loading key information (9 types, 6 encodings). No wasted words, but it could still add value without becoming verbose.
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 (multiple payload types and encodings) and absence of annotations, the description is incomplete. It omits parameter details and return value format (output schema exists but unaddressed). Users would lack info 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 description does not explain what the parameters (count, encode, vuln_type) mean or what values they accept. While it hints at types and encodings, it fails to map 'vuln_type' to payload categories or 'encode' to encoding names. With 0% schema description coverage, the description should compensate but does not.
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 generates payloads for 9 specific types (XSS, SQLi, SSTI, SSRF, etc.) and supports 6 encoding variants. This distinguishes it from sibling tools like bb_xss or bb_sqli, which are more specific attack 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 provides no guidance on when to use this tool versus alternatives (e.g., bb_xss, bb_sqli). It does not mention prerequisites, context, or conditions where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
存活探测 — TCP + HTTP 双重检测目标是否存活
| Name | Required | Description | Default |
|---|---|---|---|
| proxy | No | ||
| target | Yes | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses TCP+HTTP dual detection, which is behavioral. However, it does not discuss whether the tool modifies any state, requires permissions, or has rate limits. Some transparency but incomplete.
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), which is concise but under-specified given 4 undocumented parameters. It could be restructured to include parameter details without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no annotations, and an output schema not shown, the description is incomplete. It fails to describe what the output looks like or how to interpret results, leaving agents 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 0% (no parameter descriptions in schema). The tool description does not explain any of the 4 parameters (target, proxy, timeout, auth_token). Agents must infer from parameter names alone, which is insufficient.
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 function: '存活探测 — TCP + HTTP 双重检测目标是否存活' (survival detection using TCP and HTTP). It differentiates from siblings like 'bb_port_scan' by specifying dual detection, but does not explicitly contrast with all alternatives.
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 bb_port_scan or other probing tools. The description only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
端口扫描 — TCP Connect 方式，支持 Top100/自定义端口范围
| Name | Required | Description | Default |
|---|---|---|---|
| ports | No | top100 | |
| target | Yes | ||
| timeout | No | ||
| auth_token | No | ||
| concurrent | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only mentions TCP Connect, omitting behavioral details like network impact, permissions, or output nature.
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 necessary detail for a 5-parameter tool.
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?
Inadequate for a tool with 5 parameters, no parameter docs, no annotations, and an output schema not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. Description provides no explanation for parameters (target, ports, timeout, auth_token, concurrent). Only vague reference to ports.
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?
Clearly states it performs a port scan using TCP Connect method, supporting Top100 or custom port ranges, distinguishing it from other security 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?
No guidance on when to use or avoid this tool versus alternatives like other bb_ tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
条件竞争检测 — 并发请求分析 + 响应差异检测
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| data | No | ||
| proxy | No | ||
| cookie | No | ||
| method | No | POST | |
| timeout | No | ||
| auth_token | No | ||
| concurrent | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only mentions high-level analysis without specifics. It fails to state whether the tool sends destructive requests, requires authentication, or has rate limits.
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 short sentence, which is concise but omits necessary details. It earns its place but fails to provide sufficient information for an 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's complexity (8 parameters, race condition testing), the description is incomplete. It does not explain the output schema or how the response difference detection works, leaving critical 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?
Schema description coverage is 0%, so the description should explain parameters like 'concurrent', 'timeout', and 'auth_token'. The description provides no explanations, leaving the agent to infer meaning 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 it is for race condition detection using concurrent request analysis and response difference detection. It uniquely identifies the tool's function among sibling security testing 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?
No guidance is given on when to use this tool versus alternatives like bb_sqli or bb_xss. The description does not specify prerequisites or contexts where race condition detection is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
漏洞报告生成 — 生成结构化 SRC 格式 Markdown 报告
| Name | Required | Description | Default |
|---|---|---|---|
| poc | No | ||
| param | No | ||
| detail | No | ||
| impact | No | ||
| target | No | ||
| payload | No | ||
| vuln_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fails to disclose any behavioral traits such as side effects, required permissions, or output format details beyond stating it generates a report.
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, but it lacks structure such as separating purpose from details. It is minimally adequate but not well-organized.
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 7 parameters and no output schema shown, the description provides insufficient context. It does not cover return values, parameter usage, or how to integrate with sibling tools.
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 explain any of the 7 parameters. Agents have no information about what each parameter controls, making correct invocation difficult.
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 generates a structured SRC format Markdown report, which is a distinct purpose from sibling tools focused on specific vulnerability testing. However, it does not explicitly differentiate itself from siblings.
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 provides no context about prerequisites or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
敏感信息泄露检测 — 检测 Key/Token/密码/内网地址/注释泄露等 20 种模式
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| proxy | No | ||
| cookie | No | ||
| timeout | No | ||
| check_js | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only mentions 'detection' but does not disclose how the tool operates (e.g., network requests, page scanning, side effects). It lacks critical behavioral details for a security scanner.
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 one concise sentence, but it is too brief and omits important details. It could be structured to include more context without being lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters and no schema descriptions, the description fails to provide sufficient context for usage. Output schema exists but is not referenced. The tool's complexity demands more comprehensive 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 coverage is 0% (no parameter descriptions). The description does not explain any of the 6 parameters (url, proxy, cookie, timeout, check_js, auth_token). It adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it detects sensitive information leaks (Key/Token/Password/Internal address/Comment) and specifies 20 patterns. This distinguishes it from sibling tools which focus on other vulnerabilities like SQLi, XSS, etc.
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 use when scanning for secrets, but does not explicitly state when to prefer this over siblings or when not to use it. No exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
手工 HTTP 发包 — 自定义方法/头/Body 发送请求，支持完整请求响应查看
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| body | No | ||
| proxy | No | ||
| cookie | No | ||
| method | No | GET | |
| headers | No | ||
| timeout | No | ||
| auth_token | No | ||
| content_type | No | ||
| follow_redirects | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions request/response viewing but fails to disclose side effects, auth needs, or safety profile for a tool that sends network requests.
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 line front-loads purpose efficiently; no wasted words, but could add more without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite output schema existing, the description is too brief for a tool with 10 parameters; lacks usage scenarios, error handling, or parameter interplay details.
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 mentions method/headers/body but lacks format, accepted values, or detailed parameter help for the 10 parameters.
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 manual HTTP request sending with custom method/headers/body and full response viewing, distinguishing it from specialized sibling 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?
Implied usage for custom HTTP requests but no explicit when-to-use or alternatives among siblings like bb_sqli or bb_xss.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SQL 注入检测 — 报错/布尔/时间盲注三种模式
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| delay | No | ||
| proxy | No | ||
| cookie | No | ||
| method | No | GET | |
| params | No | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as whether the tool sends potentially harmful payloads, causes delays, or requires specific network conditions.
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 line that front-loads the purpose and modes, but it sacrifices necessary detail for brevity.
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 8 parameters and no schema descriptions, the description is critically incomplete. It does not explain parameters, return values (despite output schema existing), or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation for any of the 8 parameters, leaving their semantics entirely unclear to the agent.
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 'SQL injection detection' (verb and resource) and lists three detection modes (error, boolean, time blind), which distinguishes it from sibling tools like bb_cmdi or bb_xss.
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 SQL injection testing but provides no explicit guidance on when to use this tool versus alternatives, nor any conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SSRF 检测 — 内网地址探测 + 协议转换 + OOB 提示
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| proxy | No | ||
| cookie | No | ||
| params | No | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It mentions OOB hints and intranet scanning, which imply network requests, but does not disclose potential risks like making requests to internal resources or side effects. Critical behavioral context is missing.
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 short phrase), but it lacks substance for the number of parameters. It front-loads the purpose but omits necessary details, making it insufficiently structured for a 6-parameter tool.
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 6 parameters, 0% schema coverage, and an output schema, the description should explain parameters and output. It does neither. The tool's complexity is not matched by the description.
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 provides no explanation of any parameter (e.g., url, proxy, cookie). The agent receives no assistance in understanding parameter purpose or format beyond the schema structure.
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 is for SSRF detection and lists specific capabilities: intranet address detection, protocol conversion, and OOB hints. This distinguishes it from sibling tools like bb_sqli or bb_xss, which target different vulnerabilities.
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 SSRF testing but provides no explicit guidance on when to use or avoid this tool. No alternatives or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SSTI 模板注入检测 — Jinja2/Twig/FreeMarker/Velocity/ERB/Smarty
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| proxy | No | ||
| cookie | No | ||
| params | No | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only states the purpose and supported engines but does not explain detection behavior, potential side effects (e.g., payload injection), authentication needs, or rate limits. Minimal disclosure.
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 line, very concise, and front-loaded with purpose and engines. However, it sacrifices completeness; it is too brief to be useful for a complex tool.
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 is complex (6 params, security scanner) with no output schema shown in description. The description lacks any context about return values, scanning process, or configuration. Highly 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%. The description does not explain any of the 6 parameters (url, proxy, cookie, params, timeout, auth_token). The agent has no help understanding what these parameters do or how to use them.
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?
Clearly states it detects SSTI (Server-Side Template Injection) and lists specific template engines (Jinja2, Twig, FreeMarker, Velocity, ERB, Smarty). This verb+resource combination is specific and distinguishes it from sibling vulnerability scanning tools like bb_sqli or bb_xss.
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, when not to, or alternatives. The description does not mention any prerequisites, context, or comparison with siblings, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
子域名枚举 — DNS 批量解析 + 自定义字典
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| wordlist | No | ||
| auth_token | No | ||
| concurrent | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals it uses DNS batch resolution and custom dictionary, giving some behavioral insight. It implies concurrent requests via the parameter. However, it does not disclose potential impacts (e.g., DNS query rate limiting, wildcard handling, or authentication requirements). With no annotations, more detail 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 extremely short (one phrase), which is concise but lacks structure. It front-loads the core purpose but omits any sentences about usage, behavior, or output. It could be more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 0% schema descriptions, and an existing output schema, the description is incomplete. It does not explain return values, prerequisites, or how to interpret results. The context of sibling security tools demands more detail for correct 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 description coverage is 0%, so the description should explain parameters. It mentions 'DNS batch resolution' and 'custom dictionary' which partially cover domain and wordlist, but ignores auth_token and concurrent. Parameter semantics are weak and rely heavily on naming.
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 performs subdomain enumeration using DNS batch resolution and custom dictionary. It specifies the resource (subdomains) and method (DNS), distinguishing it from sibling tools like bb_dir_scan or bb_port_scan. However, it lacks detail on the output format or scope.
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 bb_takeover or bb_secrets. It does not mention prerequisites, limitations, or scenarios where it is appropriate. The sibling list shows many similar tools but no comparative information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
子域名接管检测 — DNS CNAME 分析 + 50+ 云服务模式匹配 + HTTP 验证
| Name | Required | Description | Default |
|---|---|---|---|
| proxy | No | ||
| domain | Yes | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions methods but does not clarify if the tool is read-only (non-destructive) or if it performs any actual takeover actions. It also omits any mention of authentication needs, rate limits, or potential 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 very concise, stating the purpose and methods in a single line. However, it lacks structure and does not include parameter explanations or usage notes, which reduces its helpfulness despite its brevity.
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 4 parameters, no annotations, and an output schema (unseen), the description is severely incomplete. It does not cover return values, behavior specifics, or how to effectively use the tool, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters (domain, proxy, timeout, auth_token) with 0% documentation coverage. The description does not explain any of these parameters, leaving the agent to guess their meaning and usage.
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: subdomain takeover detection. It specifies the methods used (DNS CNAME analysis, cloud service pattern matching for 50+ services, HTTP verification), which distinguishes it from sibling tools like bb_subdomain (likely just enumeration) and other vulnerability scanners.
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 bb_subdomain. The context implies it's for after subdomain enumeration, but there is no mention of prerequisites, when not to use, or how it fits into a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
XSS 检测 — 反射型 XSS，多种上下文/事件/属性 Payload
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| proxy | No | ||
| cookie | No | ||
| method | No | GET | |
| params | No | ||
| timeout | No | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'multiple context/event/attribute payloads', hinting at a testing methodology, but fails to disclose important behavioral traits such as whether it sends requests, modifies data, or has any side effects. With no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line that front-loads the tool's purpose ('XSS detection'). However, it lacks any structural elements like bullet points or separate sections, and the brevity sacrifices depth for conciseness.
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 (7 parameters, an output schema, and a security testing context), the description is too sparse. It does not explain return values, authentication needs, or how to interpret results. Sibling tools have more detailed descriptions, making this one feel 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 explain parameters. It only implies 'url' as the target but does not clarify 'proxy', 'cookie', 'method', 'params', 'timeout', or 'auth_token'. No added value beyond the parameter names.
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 'XSS detection — reflected XSS', specifying both the vulnerability type and the testing scope. This distinguishes it from sibling tools like bb_sqli or bb_ssti, which target different vulnerability classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. No context about prerequisites, when not to use it, or how it compares to other XSS detection methods is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
XXE 检测 — 经典/Blind OOB/XInclude/SVG 多 Payload 测试
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| proxy | No | ||
| cookie | No | ||
| timeout | No | ||
| auth_token | No | ||
| content_type | No | application/xml |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is destructive, safe, or requires specific permissions for a security testing 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 brief (one line). While concise, it lacks structure and front-loads no critical details beyond the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and 6 parameters, the description provides minimal context. It fails to describe expected behavior, parameter effects, or return values, making it inadequate for a complex security 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 description coverage is 0%. The description does not explain any of the 6 parameters (url, proxy, cookie, timeout, auth_token, content_type). The agent must infer their meanings 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 is for XXE detection and lists specific attack types (classic, blind OOB, XInclude, SVG). It differentiates from sibling tools like bb_sqli and bb_ssrf.
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 vs alternatives. The description does not mention prerequisites, recommended scenarios, 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0bb_cmdibb_corsbb_csrfbb_dir_scanbb_extractbb_file_uploadbb_fingerprintbb_graphqlbb_headersbb_host_injectbb_jwt_analyzebb_jwt_attackbb_jwt_crackbb_jwt_decodebb_lfibb_oobbb_open_redirectbb_param_discoverbb_payloadbb_pingbb_port_scanbb_racebb_reportbb_secretsbb_sendbb_sqlibb_ssrfbb_sstibb_subdomainbb_takeoverbb_xssbb_xxeEach tool has a clearly distinct purpose, with specific attack types or operations (e.g., bb_cmdi vs bb_sqli). Even the JWT sub-tools are split into analyze, attack, crack, and decode, each with different outputs. No two tools overlap in functionality.
All tools follow the uniform pattern 'bb_' followed by a lowercase underscore-separated name (e.g., bb_file_upload, bb_open_redirect). This naming convention is consistent and self-explanatory.
While 32 tools is a large number, each tool covers a distinct security check or utility (e.g., ping, port scan, report generation). The count is justified by the scope of bug bounty testing, though it may be slightly heavy for general use.
The tool set covers an exhaustive range of web security vulnerabilities: injections (SQLi, CMDI, SSTI, LFI, XSS, XXE, SSRF), logic issues (CSRF, CORS, race condition, open redirect), infrastructure (subdomain, takeover, port scan), and utilities (payload generation, report formatting). No obvious gaps remain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
238+ dev tools via MCP: JSON, QR, PDF, DNS, hash, UUID, code review, JWT, SSL, WHOIS, and more
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Production-grade cryptography toolkit with 31 MCP tools for classical, PQC, and KMS workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/guaidao2/Xuanmu-Bugbounty-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server