┌──────────────────────────────────────────────────────────┐
│ $ pentest ask --query "scan for SQLi and XSS" \ │
│ --target http://localhost:3000 --consent │
└──────────────────┬───────────────────────────────────────┘
│ Direct Python execution
▼
┌──────────────────────────────────────────────────────────┐
│ GEMINI-POWERED AGENT (Python) │
│ │
│ Phase 1: PLAN → LLM selects tools from query │
│ Phase 2: EXECUTE → Runs tools, collects findings │
│ Phase 3: REPORT → LLM generates professional report │
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌────────────────┐ │
│ │ Session │ │ Scan Mode │ │ Tool │ │
│ │ Manager │ │ Orchestrator│ │ Registry │ │
│ └─────────────┘ └──────┬───────┘ └────────────────┘ │
│ │ │
│ ┌────────────────┼────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌────────────┐ ┌────────────┐ ┌────────────────┐ │
│ │ nmap │ │ sqlmap │ │ ffuf │ │
│ │ nuclei │ │ dalfox │ │ nikto │ │
│ │ sslyze │ │ commix │ │ gobuster │ │
│ │ wafw00f │ │ arjun │ │ subfinder │ │
│ │ ... 30+ │ │ ... │ │ ... │ │
│ └────────────┘ └────────────┘ └────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────┐ │
│ │ GEMINI API │ │
│ │ (Flash Lite) │ │
│ │ Triage · Analysis │ │
│ │ CVSS · Reporting │ │
│ └──────────────────────┘ │
└──────────────────────────────────────────────────────────┘Related MCP server: Pentest-mcp
Funktion | Beschreibung |
Natürliche Sprachschnittstelle | Stellen Sie Sicherheitsfragen in einfachem Englisch — die KI wählt die passenden Tools aus und führt sie aus |
3 Scan-Modi | Schnell (5-10 Min.), Mittel (15-30 Min.), Umfangreich (45+ Min.) — jeder mit unterschiedlicher Tiefe und KI-Analyse |
30+ Sicherheitstools | nmap, sqlmap, nuclei, ffuf, dalfox, nikto, wafw00f, subfinder, sslyze und mehr |
KI-gestützte Analyse | Gemini KI (Flash Lite) führt Schwachstellen-Triage und CVSS-Bewertung durch und erstellt Management-Berichte |
Automatisierte Tool-Auswahl |
|
Sitzungsverwaltung | Verfolgen, pausieren und fortsetzen Sie Sicherheitsbewertungen über mehrere Ziele hinweg |
OWASP Top 10 Abdeckung | Systematische Scans, die den OWASP 2021 Kategorien zugeordnet sind |
Intelligente Fallbacks | Wenn ein professionelles Tool nicht installiert ist, schließen Python-native Implementierungen die Lücke |
Python 3.11+
uv (Python Paketmanager)
Gemini API Key (kostenlose Stufe verfügbar)
git clone https://github.com/yourusername/pentest-ai-cli
cd pentest-ai-cli
# Install dependencies
uv synccp .env.example .envBearbeiten Sie .env und fügen Sie Ihren Gemini API-Schlüssel hinzu:
GEMINI_API_KEY=your_gemini_api_key_hereDer Server funktioniert mit Python-nativen Fallbacks, aber für Scans auf professionellem Niveau installieren Sie die externen Tools:
# macOS (Homebrew)
brew install nmap sqlmap
# Install ffuf (Go-based fuzzer)
go install github.com/ffuf/ffuf/v2@latest
# Install nuclei (vulnerability scanner)
go install github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest
# Install subfinder (subdomain discovery)
go install github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latestTipp: Führen Sie
session_initaus, um zu sehen, welche Tools auf Ihrem System erkannt werden.
pentest ask \
--query "run a quick security scan" \
--target https://example.com \
--consentSchnelle Triage für eine sofortige Risikobewertung.
Test | Tool |
WAF-Erkennung | wafw00f / custom |
DNS-Enumeration | dnsrecon / custom |
Port-Scan (Top 20) | nmap / custom |
Header-Analyse | custom |
TLS/SSL-Audit | sslyze / custom |
Tech-Fingerprinting | whatweb / custom |
Suche nach sensiblen Dateien | ffuf / custom |
Standard-Penetrationstest, der die OWASP Top 10 abdeckt.
Test | Tool |
Alles aus Schnell | — |
Port-Scan (Top 100) | nmap |
XSS-Scan | dalfox / custom |
SQL-Injection | sqlmap |
Verzeichnissuche | ffuf / gobuster |
CORS-Fehlkonfiguration | corscanner / custom |
Pfad-Traversal | custom |
Open Redirect | custom |
CSRF-Prüfungen | custom |
Umfassende Sicherheitsbewertung auf Management-Ebene.
Test | Tool |
Alles aus Mittel | — |
Port-Scan (Top 1000) | nmap / masscan |
Subdomain-Enumeration | subfinder / amass |
Erweitertes Fuzzing | wfuzz / ffuf |
SSRF-Probing | custom |
Secret-Scanning | trufflehog |
Git-Exposition | git-dumper |
JWT-Analyse | jwt_tool |
GraphQL-Sicherheit | graphql-cop |
Command-Injection | commix |
Der Server integriert 30+ Sicherheitstools mit automatischer Erkennung. Wenn ein Tool nicht installiert ist, stellen Python-native Fallbacks sicher, dass der Scan dennoch ausgeführt wird.
Tool | Kategorie | Erforderlich |
nmap | Port-Scanning | Optional (hat Fallback) |
sqlmap | SQL-Injection | Optional |
ffuf | Fuzzing / Dateisuche | Optional (hat Fallback) |
nuclei | Schwachstellen-Scan | Optional |
dalfox | XSS-Scan | Optional |
subfinder | Subdomain-Suche | Optional |
wafw00f | WAF-Erkennung | Optional (hat Fallback) |
sslyze | TLS/SSL-Audit | Optional (hat Fallback) |
nikto | Webserver-Scan | Optional |
gobuster | Verzeichnis-Brute-Force | Optional |
whatweb | Tech-Fingerprinting | Optional (hat Fallback) |
wfuzz | Erweitertes Fuzzing | Optional |
arjun | Suche nach versteckten Parametern | Optional |
testssl | SSL/TLS-Test | Optional |
masscan | Schnelles Port-Scanning | Optional |
amass | OSINT / Subdomain-Enum | Optional |
dnsrecon | DNS-Enumeration | Optional (hat Fallback) |
theHarvester | E-Mail/Domain OSINT | Optional |
retire.js | JS-Bibliothek CVE-Scan | Optional |
trufflehog | Secret-Erkennung | Optional |
git-dumper | Git-Repo-Exposition | Optional |
commix | Command-Injection | Optional |
corscanner | CORS-Fehlkonfiguration | Optional (hat Fallback) |
jwt_tool | JWT-Analyse | Optional |
graphql-cop | GraphQL-Sicherheit | Optional |
xsstrike | Erweitertes XSS | Optional |
hydra | Brute-Force | Optional |
shodan | Internet-Intelligenz | Optional |
enum4linux-ng | SMB-Enumeration | Optional |
Der pentest ask Befehl verwendet Gemini KI, um Sicherheits-Scans basierend auf Anfragen in natürlicher Sprache automatisch zu planen und auszuführen.
Schneller Schwachstellen-Scan
pentest ask \
--query "scan for SQL injection and XSS vulnerabilities" \
--target http://localhost:3000 \
--consentVollständiges OWASP Top 10 Audit
pentest ask \
--query "perform a comprehensive OWASP Top 10 security audit" \
--target https://example.com \
--consentNur Aufklärung (Reconnaissance)
pentest ask \
--query "enumerate subdomains and check for exposed sensitive files" \
--target example.com \
--consentBenutzerdefinierter Berichtspfad
pentest ask \
--query "check security headers and TLS configuration" \
--target https://example.com \
--consent \
--output security-audit-2024.md📖 Vollständige Dokumentation: Siehe CLI_USAGE_GUIDE.md für detaillierte Anleitungen, Beispiele und Fehlerbehebung.
pentest-ai/
├── pentest_mcp/
│ ├── scan_modes.py # Quick/Medium/Extensive scan orchestration
│ ├── agent.py # Standalone CLI orchestrator
│ ├── session.py # Session state management
│ ├── models.py # Pydantic data models
│ ├── config.py # Environment & settings
│ ├── cli.py # CLI interface (includes "ask" command)
│ ├── cli_ui.py # Beautiful CLI UI components
│ ├── tools/
│ │ ├── __init__.py # Python-native security tools
│ │ ├── professional.py # External tool wrappers (nmap, sqlmap, etc.)
│ │ └── tool_registry.py # Tool execution and result processing
│ └── utils/
│ └── sanitizer.py # Input validation & sanitization
├── tests/
│ └── test_system.py # System tests
├── wordlists/ # Fuzzing wordlists for ffuf/gobuster
├── reports/ # Generated scan reports (Markdown)
├── CLI_USAGE_GUIDE.md # Example prompts and detailed usage guide
├── pyproject.toml # Project dependencies & metadata
├── Makefile # Development shortcuts
├── install_tools.sh # Security tool installer script
└── .env.example # Environment variable templateVariable | Beschreibung | Standard |
| Ihr Gemini API-Schlüssel | Erforderlich |
| LLM-Modell für die Analyse |
|
| Maximale Antwort-Token |
|
| LLM-Temperatur |
|
| Pfad zur Sitzungsspeicherung |
|
| Protokollierungs-Ausführlichkeit |
|
| Maximale Tools pro |
|
Jeder Scan-Modus verwendet eigene Gemini KI-Prompts, die auf die Scan-Tiefe kalibriert sind:
Schnell: Prägnante Triage — konzentriert sich nur auf kritische/hochgradige Funde
Mittel: OWASP Top 10 Analyse mit ausgewogener Risikobewertung und Behebungsvorschlägen
Umfangreich: Zusammenfassung auf Management-Ebene mit erschöpfenden CVSS-bewerteten Funden, Compliance-Zuordnung und strategischen Empfehlungen
Read-only file system FehlerBerichte werden unter <project_root>/reports/ gespeichert. Stellen Sie sicher, dass das Projektverzeichnis beschreibbar ist.
Überprüfen Sie Ihren API-Schlüssel: echo $GEMINI_API_KEY
Überprüfen Sie die Ratenbegrenzungen unter aistudio.google.com
Der Server setzt den Scan auch dann fort, wenn Gemini nicht verfügbar ist — die rohe Tool-Ausgabe wird weiterhin zurückgegeben
Installieren Sie fehlende Tools über Homebrew oder Ihren Paketmanager. Python-Fallbacks decken die Kernfunktionalität auch ohne externe Tools ab.
Dieses Tool ist nur für autorisierte Sicherheitstests bestimmt.
Holen Sie immer eine ausdrückliche schriftliche Genehmigung ein, bevor Sie ein Ziel scannen
Nicht autorisierte Tests verstoßen gegen den Computer Fraud and Abuse Act (CFAA), das IT Act 2000/2008 und ähnliche Gesetze weltweit
Der Parameter
consent_confirmeddient als ethische Sicherheitsmaßnahme — umgehen Sie ihn niemalsCommitten Sie niemals API-Schlüssel in die Versionskontrolle
Siehe LICENSE für Details.
Advanced subdomain enumeration
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| session_id | 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 only states 'Advanced subdomain enumeration' with no details on how it behaves—e.g., scanning depth, concurrency, output format, or potential risks. This is insufficient for an agent to predict side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words), but it sacrifices informativeness for brevity. It is under-specified and does not justify its conciseness by being complete. A single sentence could have been more helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of subdomain enumeration tools (sibling: subfinder, dnsrecon) and the absence of output schema, annotations, or parameter descriptions, this description is woefully incomplete. An agent would lack critical operational details needed to invoke 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?
Schema description coverage is 0% and the description adds no meaning to the parameters. The 'session_id' parameter is unclear without context, and 'domain' is obvious from the tool name. The description fails to compensate for the lack of schema documentation.
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 it performs subdomain enumeration, which is a specific verb and resource. However, it does not differentiate from the sibling tool 'subfinder' which also performs subdomain enumeration. The word 'advanced' hints at more capability but lacks explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives like subfinder or other enumeration tools. There is no mention of prerequisites, contexts, or exclusions, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HTTP parameter discovery
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and the description lacks any behavioral detail such as network requests, authentication, rate limits, or side effects. The agent has no insight into what happens when the tool is invoked.
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?
At 4 words, the description is under-specified rather than concise. It fails to be informative and does not earn its place due to lack of substance.
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 no output schema, no annotations, and a minimal description, the tool is critically incomplete. An agent cannot understand what the tool returns, how to interpret results, or how it fits into a larger workflow.
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?
Input schema has 2 parameters (url, session_id) with 0% schema description coverage. The description adds no meaning beyond the schema field names, leaving the agent unable to understand parameter roles or formats.
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 'HTTP parameter discovery' states a verb-noun pair but is vague. It doesn't specify what kind of parameters (GET, POST) or how it works, making it hard to distinguish from sibling tools like ffuf or wfuzz.
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 ffuf, wfuzz, or dalfox. An agent cannot determine the appropriate context from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Command injection vulnerability scanner
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits. It does not state whether the tool is read-only or destructive, what authentication is required (beyond requiring a session_id), rate limits, or potential side effects like actually exploiting vulnerabilities. The agent is left blind to important safety and operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), which is generally good for conciseness but insufficient for completeness. Every word is used, but critical information is missing, making the brevity a trade-off rather than an optimal structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a vulnerability scanner with two required parameters and no output schema, the description should explain the role of 'session_id', how results are returned, and how it differs from other vulnerability scanners. It fails to provide a complete picture for correct agent 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?
The input schema has 0% description coverage, and the tool description does not explain the meaning of 'url' and 'session_id'. For example, 'session_id' is likely tied to an active session from a sibling tool like init_session, but no explanation is given. The description adds no value beyond the schema's 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 'Command injection vulnerability scanner' clearly specifies the tool's purpose: it scans for command injection vulnerabilities. This verb-resource combination is distinct from sibling tools like sqlmap (SQL injection) and dalfox (XSS), making its purpose unambiguous.
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. With 27 sibling tools all scanning for different vulnerabilities, an agent needs explicit context for when command injection scanning is appropriate versus other scanners. No prerequisites, when-not-to-use, or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CORS misconfiguration scanner
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose any behavioral traits such as read-only vs destructive nature, authentication requirements, or rate limits. The minimal description leaves the agent uninformed about tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only 3 words, which is concise but not efficient—it sacrifices valuable context for brevity. Every word should earn its place, but here the description is too minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and two undocumented required parameters, the description is severely incomplete. It fails to provide essential context for proper 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 description coverage is 0%, and the description does not explain the purpose of 'url' and 'session_id' parameters. The agent lacks semantic guidance on how to use these required inputs.
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 specifies it's a scanner for CORS misconfigurations, which clearly identifies the tool's function and distinguishes it from other security scanners like nmap or sqlmap.
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 other scanners. Siblings like 'nuclei', 'nikto', and 'dalfox' overlap in scanning capabilities, but no differentiation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
XSS vulnerability scanner
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | Yes | ||
| params | No | ||
| consent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic purpose. It fails to mention whether the tool makes network requests, modifies data, requires authentication, or has any side effects. The description carries the full burden for transparency but provides none.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it sacrifices all substance for brevity. Every sentence should earn its place; this sentence only repeats the tool name's implication.
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 (4 parameters, no output schema, no annotations), the description is grossly incomplete. It provides no context about the scan process, expected output, or how to handle results.
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 contains no information about the parameters (url, session_id, params, consent). With 0% schema description coverage, the tool's description fails to compensate by explaining parameter meanings, defaults, or constraints.
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 'XSS vulnerability scanner' clearly states the tool's purpose (scan for XSS vulnerabilities) but does not differentiate it from sibling tools that might also target XSS. However, among the listed siblings, none are explicitly XSS-focused, so it is sufficiently distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to choose Dalfox over other scanners like sqlmap or nuclei). The description gives no context for usage, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DNS enumeration and reconnaissance
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only says 'DNS enumeration and reconnaissance'. It does not explain what actions are performed, whether it's safe, or what the output looks like.
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 brief, but brevity comes at the cost of clarity. It is not a full sentence and omits critical information that an agent needs.
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 lack of output schema and multiple sibling tools, the description is insufficient. It does not explain the tool's scope, output, or how it differs from similar 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 adds no meaning to the parameters. It does not clarify what 'domain' or 'session_id' represent 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?
The description clearly states it performs DNS enumeration and reconnaissance, specifying the domain reconnaissance area. However, it does not differentiate from sibling tools like subfinder or amass which also do DNS enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context for selection criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comprehensive scan (20-45 min): WAF detection, full recon, top-1000 port scan, tech fingerprinting, TLS audit, directory discovery, XSS, SQLi, CSRF, sensitive file discovery
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target URL | |
| consent | Yes | Explicit consent for active scanning |
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 time duration and scan types, but lacks info on side effects, destructive potential (though consent is required), rate limiting, or what happens during/after the scan. The consent parameter is already in schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence front-loaded with the key purpose and duration. It efficiently lists scan types without unnecessary words, though it could benefit from brief separators for readability.
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 moderate complexity of a comprehensive scan and no output schema, the description covers the scope and duration but omits expected output format, error handling, or post-scan behavior. It is adequate but lacks completeness for an agent to fully anticipate results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with two parameters (target and consent) already documented. The description does not add any parameter-specific information beyond the schema, so it meets the baseline but does not exceed.
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 comprehensive scan with a list of specific activities (WAF detection, full recon, port scan, tech fingerprinting, etc.), which distinguishes it from sibling tools like quick_scan, nmap, and whatweb. The verb 'scan' and resource context are explicit.
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 thorough scanning and mentions time range (20-45 min), but does not explicitly state when to use vs alternatives like quick_scan or other specialized tools. No guidance on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast web fuzzer for directory/file discovery
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | Yes | ||
| mode | No | dirs | |
| consent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only mentions speed ('fast') but does not disclose network behavior, ethical implications (though 'consent' parameter hints), authorization needs, or the fact that it can perform vhost fuzzing beyond directory/file discovery.
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 and adequately concise. However, it lacks structure and does not provide a clear breakdown of features. It is not verbose, but the conciseness comes at the cost of missing critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters including an enum with three modes (dirs, files, vhosts) and a consent boolean, the description is incomplete. It does not cover the vhost mode, explain the session_id parameter, or describe what the tool does in detail. With no output schema, the agent has no understanding of return values.
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 provides no property descriptions. The tool description does not explain any parameter: 'url', 'session_id', 'mode', or 'consent'. It adds no semantic value beyond the schema types and enum.
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 'Fast web fuzzer for directory/file discovery' clearly identifies the tool's purpose as discovering directories and files through fuzzing. It distinguishes it from general scanners like nmap or sqlmap, but does not explicitly differentiate it from sibling tools like gobuster or wfuzz that serve similar roles.
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 ffuf versus alternative tools, no prerequisites, and no usage context. With siblings like gobuster and wfuzz available, the lack of usage guidelines makes it harder for an agent to select the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate final security assessment report
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description should disclose behavioral traits. It only states 'generate', implying a side effect, but lacks details on whether it overwrites existing reports, requires specific permissions, or returns immediately.
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 very concise, front-loading the action and object. Could benefit from more context, but no unnecessary 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?
Given no output schema and many sibling scanning tools, the description should explain what the report contains and any side effects. It is too sparse for a tool that presumably consolidates results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'session_id' described as 'Session identifier'. The description adds no additional meaning beyond the schema, earning the baseline score.
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 'Generate final security assessment report' clearly states it produces a report, using a specific verb and resource. It is distinct from the many scanning tools in the sibling list, but doesn't specify report 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 or prerequisites. The only hint is the required 'session_id', but the description does not explain how to obtain it or when the report is ready.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exposed .git directory dumper
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as destructiveness, network activity, or side effects. A dumper tool may be read-only, but this is not stated.
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, which is concise, but it omits essential front-loaded information. It earns its place but could be expanded to improve utility.
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 no output schema, no annotations, and 2 required parameters lacking descriptions, the description is incomplete. It fails to clarify expected behavior, output format, or safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0% with no parameter descriptions. The description adds no meaning beyond the parameter names 'url' and 'session_id'.
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 the resource (exposed .git directory) and action (dump), but the verb 'dump' is ambiguous—it doesn't specify whether it downloads files, lists contents, or something else. It does not clearly distinguish from sibling scanning/navigation 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 this tool versus alternatives like extensive_scan or commix. Context for optimal use cases is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Directory/file brute forcing
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | Yes | ||
| mode | No | dir |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description bears full responsibility for disclosing behavioral traits. It fails to convey that gobuster is a brute-forcing tool that may generate significant network traffic, require specific permissions, or have rate-limiting considerations. The brief phrase does not indicate whether the tool is read-only or destructive.
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 (three words), but conciseness is not helpful when it sacrifices essential information. It front-loads nothing of value and leaves the agent guessing about critical details. A more balanced description would include at least the modes and parameter roles.
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 complexity (3 parameters, one enum, no output schema), the description is woefully incomplete. It does not explain how to use the tool, what the returned output looks like, or any constraints on the URL or session_id. This leaves an agent unable to invoke the tool correctly 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?
The input schema has 0% description coverage, meaning no parameter descriptions exist. The tool description does not compensate by explaining the purpose of url, session_id, or mode (e.g., how mode = 'dns' changes behavior). For a tool requiring session_id and offering multiple modes, this omission severely impairs 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 'Directory/file brute forcing' gives a general idea but fails to mention that the tool also supports DNS and vhost modes, as indicated by the mode enum. This omission could mislead an agent into thinking it only does directory/file brute forcing, while it actually has broader capabilities. Sibling tools like ffuf and wfuzz also perform similar tasks, so more specificity is needed.
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 gobuster versus its siblings like ffuf, wfuzz, or nmap. An agent would have no context to decide which tool is appropriate for a given task. The description does not mention any prerequisites, such as the need for a valid session_id or URL format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GraphQL security scanner
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description bears full responsibility for disclosing behavior. 'Security scanner' is vague; it does not specify whether the tool performs introspection, injection testing, or other actions, nor does it mention any side effects, rate limits, or authentication requirements.
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 only three words, which is concise but at the cost of completeness. It is not well-structured; it front-loads minimal information but omits crucial details, making it underspecified rather than 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 low schema coverage and lack of annotations, the description fails to provide adequate context. It does not explain the output, typical use cases, or how it differs from other security scanners, leaving the agent with insufficient information to select or invoke 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?
Schema description coverage is 0%, and the description adds no meaning to the parameters beyond their names. 'url' and 'session_id' are self-explanatory, but without additional context on format or constraints, the agent lacks guidance for 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 'GraphQL security scanner' clearly identifies the target (GraphQL) and general purpose (security scanning), distinguishing it from sibling tools focused on other technologies like SQL (sqlmap) or DNS (dnsrecon). However, it lacks a specific verb like 'scan' or 'detect vulnerabilities', which would make it clearer.
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, such as other scanners in the same server. The description does not mention prerequisites, context, or scenarios 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.
Initialize new security assessment session
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target URL or domain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior, but it only states the initialization action. It does not explain what a 'session' entails, whether it is safe, what side effects occur, or if authentication is needed. This lack of detail leaves the agent uncertain about the tool's impact.
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, but it under-specifies the tool's role. While brevity is valued, the content does not fully earn its place due to missing critical 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?
Given the simplicity of the tool (one parameter, no output schema), the description should provide more context about what initializing a session accomplishes, such as whether it creates a persistent state or requires prior steps. The lack of this information makes the definition incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with 'target' described as 'Target URL or domain', which is sufficient. The description adds no extra parameter insight, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('initialize') and the resource ('new security assessment session'), making the tool's primary function understandable. However, it does not differentiate from sibling tools like 'quick_scan' or 'extensive_scan', which may also be session-related.
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. There is no mention of prerequisites, context, or conditions that would help an agent decide to invoke init_session over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JWT security testing
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| session_id | Yes | ||
| url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is too vague to disclose behavioral traits such as whether the tool makes network requests, modifies data, or requires authentication. It does not indicate if testing is passive or active, nor the nature of the output. With no annotations, the description should have provided these details.
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 (three words), which might be considered concise, but it sacrifices essential detail. It is not front-loaded with key information; rather, it provides insufficient guidance. Every sentence should earn its place, and this one fails to justify 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 lack of output schema, annotations, and parameter descriptions, the tool description is severely incomplete. It does not explain what the tool returns, potential side effects, or error conditions. The agent cannot effectively decide when or how to invoke this 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 description does not explain the meaning or usage of any of the three parameters (token, session_id, url). With 0% schema description coverage, the agent has no information about what values these parameters expect or how they affect execution. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'JWT security testing' indicates the tool deals with JWTs and security testing, which is moderately clear but lacks specificity. It does not distinguish from other security testing tools like nmap or sqlmap, making it generic. A more precise verb such as 'crack', 'decode', or 'validate' would improve clarity.
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 its many siblings (e.g., nmap, ffuf, nuclei). The description does not mention prerequisites, expected inputs, or scenarios where jwt_tool is preferred. This leaves the agent to guess the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast port scanner
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| session_id | Yes | ||
| ports | No | 0-65535 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only mentions speed, but omits details like rate limiting, permissions required (e.g., root), or potential for disruption. 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 short (3 words) but not necessarily concise in a useful way. It lacks crucial details that could be added without significant length. Front-loading is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description is severely incomplete. An agent cannot determine correct usage, required permissions, or how to interpret results among 25+ 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 adds no parameter information. It does not explain the format of 'target' (IP vs domain), the purpose of 'session_id', or how to specify 'ports' (e.g., range syntax).
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 'Fast port scanner' clearly indicates the tool performs port scanning, which is a specific verb and resource. However, it does not differentiate from sibling tools like nmap or quick_scan, which also scan ports.
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 masscan vs alternatives. The description lacks context about scenarios where masscan's speed is beneficial or trade-offs compared to nmap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Web server vulnerability scanner
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | Yes | ||
| consent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description offers no behavioral details. It does not disclose that Nikto can be intrusive, requires consent (implied by the consent parameter), or any side effects. The description adds no value beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 4 words, which is excessively brief. While concise, it lacks necessary detail and structure to be useful. It is under-specified 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 no output schema, no annotations, and three parameters with zero description, the description is completely inadequate for an agent to invoke the tool correctly. It fails to explain return values, parameter usage, or behavior.
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 3 parameters (url, session_id, consent) with 0% description coverage. The tool description does not explain any of these parameters, leaving the agent without guidance on required formats or purpose, e.g., what session_id is for or how consent is used.
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 'Web server vulnerability scanner' clearly states the tool's purpose: scanning web servers for vulnerabilities. It uses a specific verb and resource, and while not extremely detailed, it distinguishes from siblings like nmap (network scanner) or whatweb (web technology detection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not explain when to use Nikto over other sibling tools like nuclei, nmap, or extensive_scan. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Port scanning and service detection
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | ||
| session_id | Yes | ||
| ports | No | ||
| consent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the basic function and does not disclose behavioral traits such as potential network impact, authorization requirements, rate limiting, or destructive nature. This is insufficient for a tool that may perform intrusive scanning.
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 (two words and 'service detection'), which is concise but lacks structure. It does not waste words but also does not provide a complete sentence or organized information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters including consent and session) and lack of output schema, the description is severely incomplete. It omits essential information about parameters, behavior, and typical use cases, making it inadequate for an agent to invoke 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%, and the description adds no parameter details. It fails to explain that 'host' is the target, 'session_id' ties to a session, 'ports' limits scanning to specific ports, and 'consent' likely authorizes scanning. Without parameter semantics, the agent cannot correctly fill 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 'Port scanning and service detection' clearly states the core function with a specific verb and resource. However, it does not differentiate from sibling tools like masscan which also performs port scanning, slightly reducing clarity.
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 nmap versus alternatives like masscan or nikko. There is no mention of the need for consent (despite the consent parameter) or context about session management, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast vulnerability scanner with templates
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | 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 only mentions speed ('fast'), but fails to disclose potential destructiveness, permissions, or other behavioral traits for a vulnerability 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 extremely short (4 words), which is underspecification rather than conciseness. It does not earn its brevity as it omits critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 required parameters, no output schema, and no annotations, the description is woefully incomplete. It fails to convey essential details for a security scanning 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%, and the description provides no explanation for the 'url' and 'session_id' parameters, leaving the agent without guidance on how to populate 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?
The description clearly states it is a vulnerability scanner using templates, which is a specific verb+resource. It distinguishes from siblings by mentioning templates, though it lacks explicit web context from the URL parameter.
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 nikto, nmap, or sqlmap. No context about prerequisites 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.
Fast triage scan (10-15 min): WAF detection, subdomain enum, top-port scan, header analysis, TLS audit, tech fingerprinting, sensitive file discovery, SSRF probe, CSRF check
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target URL | |
| consent | Yes | Explicit consent for active scanning |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose potential impacts of active scanning beyond requiring consent. It omits details on rate limiting, 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 a single, front-loaded sentence with a colon-separated list. It is efficient but slightly dense; could be broken into bullet points for readability.
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?
No output schema exists, but the description does not explain how results are returned. Given the tool's complexity (multiple checks), more detail on output would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions for 'target' and 'consent'.
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 a 'Fast triage scan' and lists specific checks (WAF detection, subdomain enum, etc.). This distinguishes it from more specialized sibling tools like nmap, sqlmap, and nikto.
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 term 'triage' implies initial quick assessment, but the description lacks explicit when-to-use or alternatives. It does not guide the agent to choose other tools for deeper analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JavaScript library vulnerability scanner
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'scanner', omitting details on side effects, permissions, rate limits, or output format. Essential behavioral traits are 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 only four words, which is overly terse and under-specifies the tool. Conciseness at the expense of completeness is not effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no schema descriptions, no annotations, no output schema, and two required parameters, the description is severely incomplete. It fails to explain prerequisites, return values, or operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning to the two required parameters (`url`, `session_id`). The context of 'JavaScript library vulnerability scanner' hints at their roles but does not explain them explicitly.
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 identifies the tool as a vulnerability scanner for JavaScript libraries, which is specific and differentiates it from sibling tools that scan networks or web applications. However, it lacks further specificity.
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 like `nuclei` or `jstool`. No contextual cues are given for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SQL injection detection and exploitation
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | Yes | ||
| params | No | ||
| consent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions exploitation but does not disclose potential disruptiveness, authorization requirements, or the role of the consent parameter, leaving significant behavioral ambiguity.
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?
Extremely concise to the point of under-specification; a single sentence does not provide enough structure or useful detail for an 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 and the absence of annotations and output schema, the description is far too minimal to enable correct selection and 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?
With 0% schema description coverage, the description adds no meaning to the four input parameters; it does not explain what url, session_id, params, or consent are for.
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 as SQL injection detection and exploitation, which is specific and distinguishes it from sibling networking and scanning 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 provided on when to use this tool versus alternatives, nor any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TLS/SSL configuration analyzer
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | ||
| port | No | ||
| session_id | Yes | ||
| consent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose that this tool performs network scans, potential impact on targets, or that it may require permission. 'Analyzer' implies read-only, but not explicit.
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?
Extremely short but at the cost of missing all essential information. A tool with 4 parameters and no schema descriptions needs far more detail for agent usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 4 parameters with 0% documentation, the description is completely inadequate. Sibling tools like testssl have likely more comprehensive 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 provides no information about parameters (host, port, session_id, consent). The agent cannot infer parameter meanings or constraints from the description 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 'TLS/SSL configuration analyzer' states the tool's domain but is vague; it does not specify what aspects are analyzed (e.g., certificates, protocols, vulnerabilities). Among siblings, 'testssl' is a similar tool, so lack of differentiation reduces clarity.
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 testssl or nmap. No context about prerequisites (e.g., consent parameter) or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Passive subdomain enumeration
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| session_id | Yes | ||
| consent | No |
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 only says 'Passive subdomain enumeration', omitting critical behavioral traits such as rate limits, permissions, output format, or potential side effects. This is insufficient for safe invocation.
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 (3 words), but this is under-specification rather than conciseness. Important information is missing, making it less helpful than a slightly longer but informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of subdomain enumeration and the absence of an output schema and annotations, the description is highly incomplete. It fails to explain what the tool returns, how to interpret results, or any prerequisites for use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters (domain, session_id, consent) with 0% description coverage. The tool description adds no explanation of these parameters, their purpose, or constraints. The agent must infer everything from names alone, which is inadequate.
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 'Passive subdomain enumeration' clearly states the tool's action and target, distinguishing it from active enumeration tools like amass or dnsrecon. However, it lacks detail on what exactly is enumerated (e.g., all subdomains?) which would make it a 5.
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 its siblings. There are many subdomain tools (amass, dnsrecon) and the description does not explain when passive enumeration is preferable, nor does it provide any exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TLS/SSL security testing
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | ||
| port | No | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'TLS/SSL security testing', offering no information about behavior (e.g., whether it is destructive, requires permissions, or what actions it performs).
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 phrase, which is too terse and does not convey necessary details. It fails to earn its place by omitting critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no output schema, no annotations) and the presence of many sibling tools, the description is completely inadequate, providing no context 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?
Input schema has 3 parameters (host, port, session_id) with 0% description coverage, and the description provides no explanation of their meaning or usage, leaving the agent with only 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?
Description states the domain ('TLS/SSL security testing'), which is clear but not specific. It does not distinguish from sibling tools like sslyze, which also perform SSL/TLS testing.
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 gives no context for selection among many related security tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OSINT gathering from public sources
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits such as whether it makes network requests, requires API keys, or has safe/destructive operations. The one-line description provides none of this information.
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 but fails to provide necessary details. It is under-specified rather than concise, wasting the opportunity to inform the 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 two required parameters, no output schema, and no annotations, the description is critically incomplete. It does not address what the tool returns, how to use parameters, or any constraints.
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 the purpose of the 'domain' and 'session_id' parameters. No meaning is added beyond the schema definition.
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 'OSINT gathering from public sources' indicates the general function but is vague. It does not specify what type of data is gathered (e.g., emails, subdomains) or differentiate from sibling tools like subfinder or dnsrecon that also perform OSINT.
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 amass or subfinder. The description lacks context on prerequisites or scenarios where theharvester is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Secret and credential scanner
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| session_id | Yes | ||
| scan_type | No | filesystem |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is too brief to disclose behavioral traits. It does not mention what the tool does beyond scanning, such as whether it scans filesystems or git repos, or how it handles outputs.
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 (3 words), but it under-specifies the tool. It lacks necessary details, making it insufficient for an agent to use correctly.
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 three parameters with no schema descriptions, no annotations, and no output schema, the description is completely inadequate. It does not cover what the parameters represent or how the tool behaves.
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 parameter information. The agent cannot understand the meaning of 'target', 'session_id', or 'scan_type' 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 'Secret and credential scanner' clearly states the tool's purpose as scanning for secrets and credentials. It distinguishes it from sibling tools like nmap and sqlmap, which have different 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?
No guidance is provided on when to use this tool versus alternatives. The description does not specify contexts or prerequisites, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Web Application Firewall detection
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as the tool's network activity, authentication needs, or potential impact. The description carries the full burden, which it fails to meet.
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 extremely short (two words), it is under-specified and fails to convey necessary information. Conciseness is not an asset here as it sacrifices completeness.
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 two required parameters and no output schema, the description should provide more context about its operation. It is completely inadequate for an agent to understand how to invoke it 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 schema has 0% description coverage for parameters, and the description adds no meaning to 'url' or 'session_id'. The purpose of 'session_id' is unclear, and no parameter details are given.
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 'Web Application Firewall detection' states a verb and resource, indicating the tool detects WAFs. However, it lacks specificity about what exactly is detected (e.g., presence, type) and does not differentiate from sibling tools like whatweb, which also detect web technologies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description is too brief to offer any context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Web application fuzzer
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | Yes | ||
| fuzz_param | No | FUZZ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose any behavioral traits such as whether it makes read or write operations, requires specific permissions, or any side effects. It simply labels the tool without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but severely underspecifies the tool. Conciseness is not valuable if it omits essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and parameter descriptions, the one-line description is completely inadequate. It does not cover the tool's behavior, parameters, 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%, meaning the parameters are not explained in the schema. The description provides no information about the parameters url, session_id, or fuzz_param, failing to add any meaning 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 'Web application fuzzer' states the tool's general purpose but is too vague to distinguish it from sibling fuzzing tools like ffuf, gobuster, and nuclei. It lacks specificity about what aspects of a web application are fuzzed.
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 wfuzz versus other fuzzing tools. No mention of prerequisites, context, or scenarios where it is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Web technology fingerprinting
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | Yes | ||
| consent | No |
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. It doesn't mention that this is a read-only reconnaissance operation, nor does it explain the role of 'consent' or potential 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 phrase, but it is underspecified rather than concise. It fails to pack necessary information into its brevity, missing opportunities to explain usage or parameters.
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 three parameters and no output schema, the description is insufficiently complete. It does not explain what the tool returns, how 'consent' is used, or any error conditions, leaving significant gaps for agent understanding.
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 adds no meaning beyond the schema parameter names. With 0% schema description coverage, the three parameters (url, session_id, consent) are entirely undocumented, leaving the agent to guess their purpose and constraints.
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 'Web technology fingerprinting' clearly states the tool's purpose: identifying technologies used by a website. It distinguishes from sibling tools like nmap or nikto which are more general network or 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?
The description provides no guidance on when to use this tool or when to use alternatives. There is no context about prerequisites, such as requiring an active session or consent handling.
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.
v3.0.0amassarjuncommixcorscannerdalfoxdnsreconextensive_scanffufget_reportgit_dumpergobustergraphql_copinit_sessionjwt_toolmasscanniktonmapnucleiquick_scanretiresqlmapsslyzesubfindertestssltheharvestertrufflehogwafw00fwfuzzwhatwebScored across 29 tools
Most tools have distinct purposes (e.g., sqlmap vs nmap), but some overlap exists between masscan and nmap for port scanning, and multiple fuzzing tools like ffuf, wfuzz, and gobuster may cause confusion for an agent. Descriptions help differentiate but are not entirely unambiguous.
Tool names are consistently lowercase with underscores for multi-word names, but they do not follow a strict verb_noun pattern. Some are single words (e.g., amass, nikto) while others are compound (e.g., git_dumper, jwt_tool), which is consistent but not highly patterned.
With 29 tools, the server covers a broad range of penetration testing tasks, which is appropriate for a comprehensive tool set. While on the higher end, the count is justified by the diversity of functionality and does not feel excessive.
The tool set covers most key areas of penetration testing: reconnaissance, scanning, web fuzzing, vulnerability detection, and reporting. However, it lacks network vulnerability scanners (e.g., OpenVAS) and exploitation tools, leaving minor gaps. The inclusion of quick_scan and extensive_scan helps cover comprehensive workflows.
AI pentesting: run scans, triage vulnerabilities, review PRs, manage schedules and assets.
Pay-per-call cybersecurity for AI agents: vuln scans, threat intel, compliance, code security.
Security-first WordPress MCP server. 129 tools for Claude, ChatGPT, Gemini. Free on wp.org.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
