operant-mcp is a security testing MCP server with 51 tools covering penetration testing, network forensics, memory analysis, and vulnerability assessment.
SQL Injection — WHERE clause bypasses, login form bypasses, UNION-based extraction, boolean/time-based blind SQLi, and file reading via LOAD_FILE().
XSS — Reflected XSS testing with 10 payloads; context-aware payload generation (html_body, attribute, javascript, url, css) with filter evasion.
Command Injection — OS command injection with multiple shell operators; blind detection via time delays and OOB callbacks.
Path Traversal — Directory traversal with plain, URL-encoded, double-encoded, and null-byte variants at multiple depths.
SSRF — Localhost bypass variants (10+); cloud metadata endpoint access (AWS, GCP, Azure).
PCAP / Network Forensics — Protocol hierarchy and endpoint stats, credential extraction (FTP/HTTP/SMTP), DNS analysis, HTTP object export, port scan detection, TCP/UDP/HTTP stream following, TLS/SNI analysis, LLMNR poisoning detection, and NTLM credential extraction.
Reconnaissance — Quick recon (robots.txt, headers, common dirs), full DNS enumeration, vhost discovery, TLS SAN extraction, directory brute-force, git secret scanning, and S3 bucket permission testing.
Memory Forensics — Volatility 2 Linux and Volatility 3 Windows plugin execution; Linux rootkit detection via syscall table and hidden module analysis.
Malware Analysis — Full OLE document analysis (streams, VBA macros, IOCs) and raw VBA macro extraction.
Cloud Security — AWS CloudTrail log parsing and anomaly detection (unusual IPs, API calls, role assumptions).
Authentication — CSRF token extraction, username enumeration, credential brute-force, and cookie tampering for privilege escalation.
Access Control — IDOR testing via ID/GUID iteration; cookie/parameter-based privilege escalation.
Business Logic — Client-side price/quantity manipulation; coupon stacking and alternation abuse.
Clickjacking — X-Frame-Options/CSP header checks with PoC iframe HTML; sandbox attribute bypass for JS frame busters.
CORS — Misconfiguration testing (origin reflection, null origin trust, subdomain wildcards).
File Upload — Web shell upload via Content-Type and extension bypass techniques.
NoSQL Injection — MongoDB auth bypass via operator injection; injection point detection in query params and JSON bodies.
Deserialization — Detection and manipulation of serialized objects in cookies (PHP, Java, .NET ViewState, JSON).
GraphQL — Full schema introspection (types, fields, mutations); hidden field discovery via suggestion errors.
Methodology Guides — 8 structured prompts covering web app pentesting, PCAP forensics, memory forensics, recon, malware analysis, cloud security, SQLi, and XSS.
Searches Git repositories for exposed secrets and credentials during the reconnaissance phase of a security assessment.
Performs full GraphQL schema introspection and discovery of hidden fields to identify potential security vulnerabilities.
Provides tools for Linux-specific security tasks, including memory forensics and rootkit detection.
Tests for MongoDB-specific vulnerabilities, including authentication bypass and NoSQL injection detection.
Performs deep packet inspection and network forensics on PCAP files, including protocol analysis and credential extraction using TShark.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@operant-mcp analyze this network capture and extract any found credentials"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Security testing MCP server with 51 tools for penetration testing, network forensics, memory analysis, and vulnerability assessment.
npx operant-mcpOr install globally:
npm install -g operant-mcp
operant-mcpRelated MCP server: pentestMCP
Add to your MCP config:
{
"mcpServers": {
"operant": {
"command": "npx",
"args": ["-y", "operant-mcp"]
}
}
}sqli_where_bypass — Test OR-based WHERE clause bypass
sqli_login_bypass — Test login form SQL injection
sqli_union_extract — UNION-based data extraction
sqli_blind_boolean — Boolean-based blind SQLi
sqli_blind_time — Time-based blind SQLi
sqli_file_read — Read files via LOAD_FILE()
xss_reflected_test — Test reflected XSS with 10 payloads
xss_payload_generate — Generate context-aware XSS payloads
cmdi_test — Test OS command injection
cmdi_blind_detect — Blind command injection via sleep timing
path_traversal_test — Test directory traversal with encoding variants
ssrf_test — Test SSRF with localhost bypass variants
ssrf_cloud_metadata — Test cloud metadata access via SSRF
pcap_overview — Protocol hierarchy and endpoint stats
pcap_extract_credentials — Extract FTP/HTTP/SMTP credentials
pcap_dns_analysis — DNS query analysis
pcap_http_objects — Export HTTP objects
pcap_detect_scan — Detect port scanning
pcap_follow_stream — Follow TCP/UDP streams
pcap_tls_analysis — TLS/SNI analysis
pcap_llmnr_ntlm — Detect LLMNR/NTLM attacks
recon_quick — Quick recon (robots.txt, headers, common dirs)
recon_dns — Full DNS enumeration
recon_vhost — Virtual host discovery
recon_tls_sans — Extract SANs from TLS certificates
recon_directory_bruteforce — Directory brute-force
recon_git_secrets — Search git repos for secrets
recon_s3_bucket — Test S3 bucket permissions
volatility_linux — Linux memory analysis (Volatility 2)
volatility_windows — Windows memory analysis (Volatility 3)
memory_detect_rootkit — Linux rootkit detection
maldoc_analyze — Full OLE document analysis pipeline
maldoc_extract_macros — Extract VBA macros
cloudtrail_analyze — CloudTrail log analysis
cloudtrail_find_anomalies — Detect anomalous CloudTrail events
auth_csrf_extract — Extract CSRF tokens
auth_bruteforce — Username enumeration + credential brute-force
auth_cookie_tamper — Cookie tampering test
idor_test — Test for IDOR vulnerabilities
role_escalation_test — Test privilege escalation
price_manipulation_test — Test price/quantity manipulation
coupon_abuse_test — Test coupon stacking/reuse
clickjacking_test — Test X-Frame-Options/CSP
frame_buster_bypass — Test frame-busting bypass
cors_test — Test CORS misconfigurations
file_upload_test — Test file upload bypasses
nosqli_auth_bypass — MongoDB auth bypass
nosqli_detect — NoSQL injection detection
deserialization_test — Test insecure deserialization
graphql_introspect — Full schema introspection
graphql_find_hidden — Discover hidden fields
Methodology guides for structured security assessments:
web_app_pentest — Full web app pentest methodology
pcap_forensics — PCAP analysis workflow
memory_forensics — Memory dump analysis (Linux/Windows)
recon_methodology — Reconnaissance checklist
malware_analysis — Malware document analysis
cloud_security_audit — CloudTrail analysis workflow
sqli_methodology — SQL injection testing guide
xss_methodology — XSS testing guide
Tools require various CLI utilities depending on the module:
Most tools: curl
PCAP analysis: tshark (Wireshark CLI)
DNS recon: dig, host
Memory forensics: volatility / vol.py / vol3
Malware analysis: olevba, oledump.py
Cloud analysis: jq
Secrets scanning: git
MIT
Username enumeration and credential brute-force.
First enumerates valid usernames (if failure messages differ), then brute-forces passwords against confirmed usernames.
Returns: {"username_enumeration": [{"username": str, "exists": bool}], "valid_credentials": [{"username": str, "password": str}], "requests_sent": int}.
Side effects: Sends login requests. May trigger account lockout.
Errors: Rate limiting may block requests. Use realistic credentials to avoid WAF detection.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Login form URL | |
| usernames | Yes | Usernames to test | |
| passwords | Yes | Passwords to test | |
| username_field | No | Form field name for username | |
| password_field | No | Form field name for password | |
| method | No | HTTP method | |
| success_indicator | No | String in response that indicates success (e.g. 'dashboard', 'welcome') | |
| failure_indicator | No | String in response that indicates failure (e.g. 'invalid', 'incorrect') | |
| content_type | No | Request content type | |
| concurrent | No | Concurrent requests |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It excellently describes side effects ('Sends login requests. May trigger account lockout'), error conditions ('Rate limiting may block requests'), and provides the exact return format. This gives the agent crucial information about the tool's impact and output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. Each sentence adds value: the process flow, return format, side effects, and error conditions. It could be slightly more concise by combining some sentences, but overall it's efficient with zero wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex security testing tool with 10 parameters and no annotations or output schema, the description provides excellent completeness. It covers the tool's purpose, process flow, return format, side effects, and error conditions - giving the agent everything needed to understand when and how to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all 10 parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. This meets the baseline of 3 when the schema does the heavy lifting, but doesn't provide additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'username enumeration and credential brute-force' with specific steps: enumerates valid usernames first, then brute-forces passwords against confirmed usernames. This is a specific verb+resource combination that distinguishes it from sibling tools like 'auth_cookie_tamper' or 'sqli_login_bypass' which target different authentication vulnerabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (for testing login forms) and mentions specific risks like account lockout and WAF detection. However, it doesn't explicitly state when NOT to use it or name alternative tools for similar purposes (e.g., 'sqli_login_bypass' for SQL injection-based bypass).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test cookie manipulation for privilege escalation.
Sends requests with tampered cookie values and checks for access.
Returns: {"results": [{"cookies": dict, "status": int, "length": int, "response_snippet": str}]}.
Side effects: Sends GET requests with manipulated cookies.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to test with tampered cookies (e.g. /dashboard, /admin) | |
| cookies | Yes | Cookie name-value pairs to send, e.g. {"logged_in": "true", "admin": "1"} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes side effects ('Sends GET requests with manipulated cookies'), return format, and the tool's testing nature, though it could add more on error handling or 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 front-loaded with the core purpose, followed by return details and side effects in three concise sentences. Every sentence adds value without redundancy, making it efficiently structured.
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 (security testing with side effects), no annotations, and no output schema, the description does well by explaining purpose, returns, and side effects. However, it could improve by detailing prerequisites or error scenarios for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (url and cookies). The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Test cookie manipulation for privilege escalation') and resources ('cookie values'), and distinguishes it from siblings like auth_bruteforce or auth_csrf_extract by focusing on cookie tampering rather than other authentication attacks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for testing privilege escalation via cookie manipulation, but does not explicitly state when to use this tool versus alternatives like auth_bruteforce or idor_test. It provides context but lacks explicit guidance on exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract CSRF tokens from HTML forms.
Searches for the token in hidden input fields, meta tags, and script blocks.
Returns: {"tokens_found": [{"source": str, "value": str}], "cookies": [str]}.
Side effects: Single GET request.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the form page containing CSRF token | |
| token_name | No | CSRF token field name to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it performs a 'Single GET request' (indicating network interaction and potential side effects), specifies search locations ('hidden input fields, meta tags, and script blocks'), and outlines the return structure. However, it doesn't mention error handling, 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 front-loaded with the core purpose in the first sentence, followed by implementation details and return format. Each sentence adds value: the second explains search methods, the third specifies output, and the fourth notes side effects. There is zero wasted text, making it highly efficient.
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 moderate complexity (2 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, behavior, output structure, and side effects. However, it lacks details on error cases or performance considerations, which could be helpful for an agent invoking this tool in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents both parameters ('url' and 'token_name') well. The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints, but doesn't contradict it either. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Extract CSRF tokens from HTML forms.' It specifies the verb ('extract'), resource ('CSRF tokens'), and scope ('from HTML forms'), and distinguishes itself from sibling tools like 'auth_bruteforce' or 'auth_cookie_tamper' by focusing on token extraction rather than authentication attacks or cookie manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it searches for tokens in 'hidden input fields, meta tags, and script blocks,' which suggests it's for web security testing. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., other auth-related siblings) or any prerequisites, such as needing accessible HTML pages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check X-Frame-Options and CSP frame-ancestors headers; generate PoC iframe HTML. Fetches response headers and checks for framing protections. If protections are missing, generates a ready-to-use PoC HTML page that embeds the target in a transparent iframe with a decoy button overlay. Returns: {headers, x_frame_options, csp_frame_ancestors, vulnerable, poc_html}. Side effects: Single HEAD/GET request.
| Name | Required | Description | Default |
|---|---|---|---|
| target_url | Yes | URL to test for clickjacking vulnerability, e.g. https://target/my-account |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It explicitly describes side effects ('Single HEAD/GET request'), output structure, vulnerability assessment logic, and the conditional generation of PoC HTML. This provides excellent transparency about how the tool behaves.
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 efficiently structured with zero wasted sentences. It front-loads the core purpose, explains the process, describes the output, and notes side effects—all in three concise, information-dense sentences that each earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (security testing with conditional PoC generation) and the absence of both annotations and output schema, the description provides complete contextual information. It explains what the tool does, how it works, what it returns, and side effects, making it fully self-contained for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context by specifying that the target_url should be tested for clickjacking vulnerability and providing an example ('e.g. https://target/my-account'), which enhances understanding beyond the schema's basic parameter 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 clearly states the tool's purpose with specific verbs ('check', 'generate', 'fetches') and resources (X-Frame-Options and CSP frame-ancestors headers, PoC iframe HTML). It distinguishes itself from sibling tools by focusing specifically on clickjacking vulnerability testing rather than other security tests like XSS, SQLi, or authentication attacks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to test for clickjacking vulnerabilities by checking specific headers. However, it doesn't explicitly state when not to use it or name specific alternatives among the sibling tools, though the security testing context is implied by the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse and analyze AWS CloudTrail logs.
Extracts event timeline, unique users, event types, and source IPs.
Returns: {"event_count": int, "unique_users": [str], "event_types": [str], "source_ips": [str], "timeline": str}.
Side effects: Read-only file analysis. Requires jq.
| Name | Required | Description | Default |
|---|---|---|---|
| log_dir | Yes | Directory containing CloudTrail JSON log files |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well by disclosing key behavioral traits: it specifies the tool is 'read-only file analysis' (indicating non-destructive operation), mentions a prerequisite ('Requires jq'), and details the exact return structure, which is crucial for understanding output 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 appropriately sized and front-loaded, with each sentence earning its place: the first states the purpose, the second lists extracted data, the third specifies the return format, and the fourth covers side effects and prerequisites, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (data analysis with one parameter) and lack of annotations and output schema, the description is complete enough: it explains the purpose, usage, return values in detail, side effects, and prerequisites, providing all necessary context for an agent to use 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 input schema has 100% description coverage, clearly documenting the single parameter 'log_dir'. The description does not add any additional meaning beyond what the schema provides, such as format examples or constraints, so it meets the baseline of 3 for adequate but no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('parse and analyze') and resources ('AWS CloudTrail logs'), and distinguishes it from sibling tools like 'cloudtrail_find_anomalies' by focusing on extraction of specific data fields rather than anomaly 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?
The description provides clear context for when to use this tool (for analyzing CloudTrail logs to extract specific data), but does not explicitly mention when not to use it or name alternatives among sibling tools, such as 'cloudtrail_find_anomalies' for different analysis purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find anomalies in CloudTrail logs: non-AWS IPs, unusual API calls, role assumptions.
Returns: {"non_aws_ips": [str], "unusual_events": [str], "role_assumptions": [str], "data_exfil_indicators": [str]}.
Side effects: Read-only file analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| log_dir | Yes | Directory containing CloudTrail JSON log files |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully adds valuable context: it specifies the return format with detailed keys, explicitly states 'Read-only file analysis' (indicating no destructive operations), and mentions it analyzes files in a directory. However, it doesn't cover error conditions, performance characteristics, 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 appropriately concise with three sentences that each serve distinct purposes: stating the tool's function, specifying the return format, and declaring side effects. It's front-loaded with the core purpose. Minor improvement could be made by integrating the return format more naturally into the first sentence.
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 moderate complexity (anomaly detection in logs), no annotations, no output schema, and 100% schema coverage, the description does a reasonably complete job. It explains what the tool does, what it returns, and its safety profile. However, it lacks information about error handling, performance expectations, and how it differs from the sibling 'cloudtrail_analyze' 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 100% (the single parameter 'log_dir' has a clear description in the schema). The tool description doesn't add any additional parameter information beyond what's already in the schema. According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find anomalies in CloudTrail logs' with specific examples (non-AWS IPs, unusual API calls, role assumptions). It uses a specific verb ('Find') and resource ('CloudTrail logs'), but doesn't explicitly differentiate from sibling 'cloudtrail_analyze' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention the sibling 'cloudtrail_analyze' tool or explain what distinguishes this anomaly-finding tool from general CloudTrail analysis. There's no context about prerequisites or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect blind command injection via time delay and OOB callbacks. Tests sleep-based delay detection and optional out-of-band (curl/nslookup to callback). Returns time_based results array and oob_payloads list. Side effects: Executes sleep on target if vulnerable. OOB payloads call back to callback_url.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL | |
| parameter | Yes | Vulnerable parameter name | |
| base_value | No | Legitimate parameter value | |
| method | No | HTTP method | |
| callback_url | No | Out-of-band callback URL for OOB detection (e.g. Burp Collaborator) | |
| delay_seconds | No | Sleep duration for time-based detection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so effectively. It explicitly states side effects: 'Executes sleep on target if vulnerable. OOB payloads call back to callback_url.' It also describes what the tool returns: 'Returns time_based results array and oob_payloads list.' This provides crucial information about the tool's behavior that isn't in the 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 efficiently structured in three sentences: purpose statement, return values, and side effects. Every sentence adds essential information with zero waste. It's front-loaded with the core purpose and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a security testing tool with no annotations and no output schema, the description provides good contextual completeness. It covers purpose, methods, return values, and side effects. The main gap is that without an output schema, more detail about the structure of 'time_based results array' and 'oob_payloads list' would be helpful, but the description gives enough context for effective 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 schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some context about callback_url ('e.g. Burp Collaborator' is implied) and mentions delay_seconds in the context of time-based detection, but doesn't provide significant additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Detect blind command injection via time delay and OOB callbacks.' It specifies the detection methods (sleep-based delay and out-of-band callbacks) and distinguishes it from siblings like 'cmdi_test' by focusing on blind injection detection rather than general command injection 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?
The description provides clear context for when to use this tool: for detecting blind command injection using time delays and OOB techniques. It doesn't explicitly state when not to use it or name specific alternatives, but the context makes it clear this is for blind injection scenarios rather than other types of command injection testing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test command injection using various shell operators. Tests ;, &&, ||, |, backtick, $(), and %0a (newline) operators with 'id' and 'whoami' as detection commands. Returns results array with operator, payload, status, output_snippet, likely_vulnerable. Side effects: Read-only detection commands (id, whoami). Sends ~14 requests.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL that processes the parameter server-side | |
| parameter | Yes | Vulnerable parameter name, e.g. 'storeId' | |
| base_value | No | Legitimate value for the parameter, e.g. '1' | |
| method | No | HTTP method | |
| operators | No | Injection operators to test. Default: all common operators. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so excellently. It explicitly states side effects ('Read-only detection commands'), execution details ('Sends ~14 requests'), and the return format ('Returns results array with operator, payload, status, output_snippet, likely_vulnerable'), providing comprehensive behavioral context beyond the input 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 perfectly front-loaded and concise. The first sentence states the core purpose, followed by specific details about operators, commands, return format, and side effects. Every sentence earns its place with zero wasted words, making it highly efficient for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a security testing tool with no annotations and no output schema, the description provides exceptional completeness. It covers purpose, methodology, return format, side effects, and execution characteristics. Given the complexity of command injection testing, this description gives the AI agent everything needed to understand when and how to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what the schema provides, but it does give context about the testing approach (shell operators, detection commands) that helps understand parameter usage. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Test command injection using various shell operators' with specific detection commands ('id' and 'whoami'). It distinguishes itself from sibling tools like 'cmdi_blind_detect' by focusing on explicit operator testing rather than blind detection, making the verb+resource+scope specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for testing command injection vulnerabilities with shell operators. It doesn't explicitly mention when not to use it or name alternatives, but the context is sufficiently clear given the tool's specialized nature among security testing siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test CORS misconfigurations: origin reflection, null origin trust, subdomain wildcards. Sends requests with various Origin headers and checks Access-Control-Allow-Origin and Access-Control-Allow-Credentials in the response. Misconfigurations allow attacker sites to read authenticated API responses. Returns: {results: [{test, origin_sent, acao, acac, vulnerable}], exploit_html}. Side effects: Read-only requests with custom Origin headers. Sends ~8 requests.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Base URL of the target application, e.g. https://target.com | |
| api_endpoint | Yes | API endpoint to test CORS on, e.g. /api/account or /api/users/me | |
| auth_cookie | No | Session cookie to include for authenticated CORS tests |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does an excellent job describing what the tool does: sends ~8 requests with custom Origin headers, checks specific response headers, identifies vulnerabilities, and explicitly states 'Read-only requests' (important safety context). It also describes the return format and side effects, though it doesn't mention rate limits or authentication requirements beyond the auth_cookie parameter.
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 efficiently structured with zero wasted sentences. It front-loads the purpose, explains the methodology, describes the return value, and clarifies side effects - all in four concise sentences. Every sentence earns its place by providing 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?
For a security testing tool with no annotations and no output schema, the description provides substantial context: it explains what the tool tests, how it works, what it returns, and side effects. The main gap is the lack of explicit output schema documentation, but the description does describe the return structure. Given the complexity of CORS testing, the description is quite complete, though it could benefit from more explicit guidance about when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description doesn't add any additional parameter semantics beyond what's in the schema - it mentions 'authenticated API responses' which relates to the auth_cookie parameter, but doesn't provide format details or usage guidance beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Test CORS misconfigurations', 'Sends requests', 'checks Access-Control-Allow-Origin') and resources ('CORS misconfigurations', 'Origin headers', 'API responses'). It distinguishes itself from siblings by focusing specifically on CORS testing rather than other security testing domains like SQL injection or XSS.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('Test CORS misconfigurations', 'authenticated API responses') but doesn't explicitly state when to use this tool versus alternatives. While it's clear this is for CORS testing, there's no guidance about prerequisites, timing, or comparison to other tools in the sibling list that might also test web vulnerabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test coupon stacking and alternation bypass.
Tests each coupon individually, then alternates between coupons to see if discounts compound past the intended limit.
Returns: {"individual_results": [...], "stacking_results": [...], "stacking_possible": bool}.
Side effects: Applies coupons to the cart. May modify cart totals.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Coupon application endpoint URL | |
| coupon_endpoint | Yes | Full URL for applying coupons, e.g. https://target/cart/coupon | |
| coupons | Yes | Coupon codes to test, e.g. ['NEWCUST5', 'SIGNUP30', 'FREESHIP'] | |
| coupon_param | No | Form parameter name for the coupon code | |
| auth_cookie | No | Session cookie for authenticated requests | |
| stacking_rounds | No | Number of alternation rounds to test for coupon stacking |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well disclosing key behavioral traits. It explicitly states 'Side effects: Applies coupons to the cart. May modify cart totals' which is crucial for a mutation tool. It also describes the testing methodology and return structure. However, it doesn't mention authentication requirements (implied by auth_cookie parameter), rate limits, or whether changes are reversible.
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 perfectly structured and concise. First sentence states purpose, second explains methodology, third documents return format, fourth discloses side effects. Every sentence earns its place with zero wasted words. It's front-loaded with the most important information (what it does) followed by critical behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no annotations, and no output schema, the description is adequate but has gaps. It covers purpose, methodology, returns, and side effects well. However, it doesn't explain authentication context (despite auth_cookie parameter), doesn't mention error conditions, and doesn't provide examples of typical usage scenarios. Given the complexity, it should ideally include more 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 description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter semantics beyond what's in the schema descriptions. It doesn't explain relationships between parameters (e.g., url vs coupon_endpoint) or provide examples of valid values. The baseline 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Test coupon stacking and alternation bypass' with specific testing methodology. It distinguishes from security-focused siblings by focusing on coupon abuse testing rather than authentication or injection vulnerabilities. However, it doesn't explicitly differentiate from potential similar commerce testing tools that might exist elsewhere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing a valid cart), doesn't specify what scenarios warrant coupon abuse testing, and doesn't reference any sibling tools that might be used in related testing workflows. The agent receives no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect and manipulate serialized objects in cookies. Analyzes cookie values for serialization patterns (PHP serialize, Java, .NET ViewState, base64-encoded JSON). If a serialized format is detected, attempts privilege escalation by modifying fields (admin=1, role=admin). Returns: {detection: {format, decoded, fields}, manipulation_results: [...]}. Side effects: Sends requests with modified cookies. May escalate privileges if successful.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL to test, e.g. https://target/my-account | |
| cookie_name | Yes | Cookie name that may contain serialized data, e.g. 'session', 'user', 'data' | |
| cookie_value | No | Current cookie value to analyze. If not provided, fetches from the target URL | |
| auth_cookie | No | Additional auth cookies to send, e.g. 'session=abc123' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and effectively discloses key behavioral traits: it describes actions ('sends requests with modified cookies'), potential outcomes ('may escalate privileges if successful'), and side effects. However, it lacks details on rate limits, error handling, or specific prerequisites.
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 appropriately sized and front-loaded, starting with the core purpose. Every sentence adds value, such as detailing detection patterns, manipulation attempts, returns, and side effects, with minimal redundancy. A slight improvement could be made by structuring it more explicitly for quick scanning.
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 security testing tool with no annotations or output schema, the description is fairly complete: it covers purpose, behavior, returns, and side effects. However, it could benefit from more details on error cases, prerequisites, or example scenarios to fully guide an agent in complex environments.
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 add meaning beyond the input schema, which has 100% coverage with clear parameter descriptions. It mentions 'cookie value to analyze' and 'target URL' but does not provide additional syntax, format details, or usage examples. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('detect and manipulate serialized objects in cookies') and resources ('cookies'), distinguishing it from sibling tools like 'auth_cookie_tamper' or 'role_escalation_test' by focusing on serialization patterns and privilege escalation through field modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for security testing of serialized objects in cookies, but does not explicitly state when to use this tool versus alternatives like 'auth_cookie_tamper' or 'role_escalation_test'. It provides some context (e.g., 'if a serialized format is detected') but lacks clear exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test web shell upload with Content-Type bypass variants. Attempts to upload a PHP web shell using various techniques: 1) Direct .php upload 2) .php with image/jpeg Content-Type (Content-Type bypass) 3) Alternative extensions (.php5, .phtml, .phar, .php7, .phps) 4) Double extension (.php.jpg) 5) Null byte (.php%00.jpg). After each upload, attempts to access the uploaded file to check execution. Returns: {results: [{technique, upload_status, execution_status, output, successful}]}. Side effects: Uploads files to the server. May achieve remote code execution.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Base URL of the target application, e.g. https://target.com | |
| upload_endpoint | Yes | Upload endpoint path, e.g. /my-account/avatar or /api/upload | |
| upload_field | No | Form field name for the file upload, e.g. 'avatar', 'file', 'upload' | file |
| upload_path_prefix | No | Path where uploaded files are accessible, e.g. /files/avatars/ | /files/avatars/ |
| auth_cookie | No | Session cookie for authenticated uploads | |
| shell_command | No | Command the PHP shell should execute | id |
| extra_fields | No | Additional form fields, e.g. 'user=test&csrf=abc123' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behaviors: 'Side effects: Uploads files to the server. May achieve remote code execution.' It also describes the testing flow (upload then access check) and return format. However, it doesn't mention rate limits, authentication requirements beyond the auth_cookie parameter, or error handling.
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 appropriately sized and front-loaded with the core purpose. It lists techniques clearly and ends with side effects. Some redundancy exists (e.g., 'Attempts to upload...' followed by 'After each upload...'), but overall it's efficient with zero wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex security testing tool with 7 parameters and no output schema, the description provides good context: it explains the testing methodology, techniques, return structure, and side effects. However, it doesn't detail the output schema (only mentions return format vaguely) or error cases, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain how url and upload_endpoint combine or provide examples for extra_fields). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Test web shell upload with Content-Type bypass variants' and details specific techniques (direct .php upload, Content-Type bypass, alternative extensions, double extension, null byte). It clearly distinguishes this as a file upload security testing tool, unlike sibling tools focused on authentication, SQL injection, XSS, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for security testing of file upload vulnerabilities but doesn't explicitly state when to use this tool versus alternatives (e.g., path_traversal_test or other sibling tools). It mentions 'Attempts to upload a PHP web shell' which suggests a specific testing context, but lacks explicit guidance on prerequisites or comparisons with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test sandbox attribute bypass for JavaScript frame busters. Generates PoC HTML that uses iframe sandbox='allow-forms' to disable JavaScript execution (neutralizing frame-busting code) while still allowing form submission for clickjacking. Also checks if the target page contains common frame-busting patterns. Returns: {frame_buster_detected, patterns_found, sandbox_poc_html}. Side effects: Single GET request to detect frame-busting code.
| Name | Required | Description | Default |
|---|---|---|---|
| target_url | Yes | URL that uses JavaScript frame-busting code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it makes a single GET request, generates PoC HTML, checks for common patterns, and returns specific data structure. It doesn't mention rate limits, authentication needs, or potential side effects beyond the GET request.
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 efficiently structured in two sentences: first explains the tool's function and mechanism, second details the return values and side effects. Every element serves a purpose with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations and no output schema, the description provides good completeness: explains what the tool does, how it works, what it returns, and side effects. It could benefit from more detail about the returned data structure or example patterns, but covers the essential context well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'target_url', so the schema already documents it adequately. The description adds context about what kind of URL (one with JavaScript frame-busting code) but doesn't provide additional syntax or format details beyond what the schema provides.
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 specific action ('Test sandbox attribute bypass for JavaScript frame busters') and resource (target URL with frame-busting code). It distinguishes from siblings by focusing on frame-buster bypass techniques rather than other security tests like clickjacking_test or xss_reflected_test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (testing JavaScript frame-busting code) but doesn't explicitly state when to use this tool versus alternatives like clickjacking_test or other bypass methods. It provides clear functional context but lacks explicit comparison or exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run introspection query to enumerate all types, fields, and mutations. Sends the standard GraphQL introspection query (__schema) to discover the full API schema including hidden/undocumented fields, mutations, and types. Returns: {introspection_enabled, types: [{name, kind, fields: [str]}], mutations: [str], queries: [str]}. Side effects: Single POST request. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | GraphQL endpoint URL, e.g. https://target/graphql or https://target/api | |
| auth_header | No | Authorization header value, e.g. 'Bearer abc123' | |
| auth_cookie | No | Session cookie for authenticated requests |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's read-only (explicitly stated), makes a single POST request (side effects), and returns specific data (introspection_enabled, types, mutations, queries). However, it lacks details on error handling, rate limits, or authentication requirements beyond what parameters imply.
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 appropriately sized and front-loaded, starting with the core purpose. Every sentence adds value: the first states the action, the second elaborates on scope and output, and the third covers side effects and read-only nature. It could be slightly more structured but is efficient with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (GraphQL introspection with authentication parameters) and lack of annotations and output schema, the description is mostly complete. It covers purpose, behavior, output structure, and side effects. However, it could improve by mentioning error cases or linking to sibling tools for better 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 100%, so the schema already documents all three parameters (url, auth_header, auth_cookie) with descriptions. The description does not add meaning beyond the schema, such as explaining parameter interactions or usage examples, but the baseline of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run introspection query to enumerate all types, fields, and mutations.' It specifies the verb ('run introspection query'), resource ('GraphQL API schema'), and scope ('all types, fields, and mutations'), distinguishing it from sibling tools like 'graphql_find_hidden' which likely has a different focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering the full API schema, including hidden/undocumented elements, but does not explicitly state when to use this tool versus alternatives like 'graphql_find_hidden' or other recon tools. It provides context but lacks explicit guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test Insecure Direct Object References by iterating through IDs/GUIDs.
Sends requests with each ID and compares response status codes and lengths. Differing responses suggest IDOR — the server returns data for other users' objects without proper authorization checks.
Returns: {"baseline": dict, "results": [{"id": str, "status": int, "length": int, "different": bool, "snippet": str}], "idor_candidates": [str]}.
Side effects: Read-only requests. Sends len(id_list) + 1 requests.
Errors: ConnectionError if target unreachable.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL with ID parameter, e.g. https://target/my-account?id=123 or https://target/api/users/123 | |
| parameter | Yes | Parameter name containing the ID, e.g. 'id'. Use '__path__' if the ID is in the URL path | |
| id_list | Yes | List of IDs/GUIDs to test, e.g. ['1','2','3'] or ['abc-def-123', 'ghi-jkl-456'] | |
| auth_cookie | No | Session cookie to send (e.g. 'session=abc123'). If None, tests without auth | |
| method | No | HTTP method to use |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's read-only ('Read-only requests'), specifies side effects ('Sends len(id_list) + 1 requests'), and outlines error conditions ('ConnectionError if target unreachable'). It also explains the testing logic and return structure, adding valuable context beyond basic parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. It efficiently covers testing logic, returns, side effects, and errors in clear sections. While slightly detailed, each sentence adds value (e.g., explaining IDOR detection and request count), with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a security testing tool with 5 parameters, no annotations, and no output schema, the description is quite complete. It explains the tool's purpose, behavior, return format, side effects, and errors. The only minor gap is the lack of an explicit output schema, but the return description compensates adequately for this 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?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add specific parameter semantics beyond what the schema provides (e.g., it doesn't explain parameter interactions or usage examples). However, it implies the relationship between parameters like 'url' and 'parameter' in the testing process, offering minimal additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Test Insecure Direct Object References by iterating through IDs/GUIDs.' It specifies the action (test), the vulnerability type (IDOR), and the method (iterating through IDs/GUIDs). This distinguishes it from sibling tools focused on other security tests like auth_bruteforce or xss_reflected_test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by explaining what IDOR testing involves and when it suggests a vulnerability ('Differing responses suggest IDOR'). However, it does not explicitly state when to use this tool versus alternatives (e.g., other security testing tools in the sibling list) or provide exclusions. The guidance is functional but lacks comparative direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full malware document analysis pipeline.
oledump.py — list OLE streams, identify macro-containing streams (marked 'M')
olevba — extract VBA macro code
Identify auto-execution triggers (Document_open, AutoOpen, Workbook_Open)
Look for obfuscation patterns and base64 payloads
Search for PowerShell, WMI, and shell execution indicators
Returns: {"ole_streams": str, "vba_macros": str, "auto_exec_triggers": [str], "suspicious_strings": [str], "iocs": [str]}.
Side effects: Read-only file analysis. Does NOT execute any payloads.
Errors: Requires oledump.py and olevba (pip install oletools).
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the suspicious OLE document (.doc, .xls, .bin) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: 'Read-only file analysis', 'Does NOT execute any payloads', and error conditions ('Requires oledump.py and olevba'). It also describes the multi-step analysis pipeline, giving good insight into tool behavior beyond basic function.
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 appropriately sized and well-structured with numbered analysis steps, return format specification, side effects, and error conditions. Each section adds value, though the numbered steps could be slightly more 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?
For a complex analysis tool with no annotations and no output schema, the description provides substantial context: analysis pipeline details, return format specification, side effects, and prerequisites. It adequately compensates for the lack of structured metadata, though could potentially elaborate more on output interpretation.
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 the single parameter 'file_path' well-documented in the schema. The description doesn't add any additional parameter semantics beyond what's in the schema, but with complete schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'Full malware document analysis pipeline' with specific steps (oledump.py, olevba, etc.), distinguishing it from sibling tools like 'maldoc_extract_macros' which appears to be a subset function. It specifies verb ('analyze') and resource ('malware document').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the analysis steps and mentions 'Read-only file analysis' and 'Does NOT execute any payloads', providing clear operational boundaries. However, it doesn't explicitly state when to use this tool versus alternatives like 'maldoc_extract_macros' or other security analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract raw VBA macros from an OLE document.
Returns: {"macros": str, "stream_count": int, "macro_streams": [str]}.
Side effects: Read-only file analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the OLE document |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively states the return format and explicitly mentions 'Read-only file analysis,' which clarifies that it's a safe, non-destructive operation. However, it doesn't cover potential errors, file size limits, or performance aspects.
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 and front-loaded, with three sentences that each earn their place: stating the purpose, specifying the return format, and clarifying side effects. There is zero waste or redundancy, making it highly efficient.
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 moderate complexity (extracting macros from documents) and lack of annotations or output schema, the description is fairly complete. It covers purpose, return values, and behavioral traits, but could improve by addressing usage guidelines or potential limitations to fully compensate for missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single parameter 'file_path.' The description adds no additional parameter semantics beyond what's in the schema, but since coverage is high, the baseline score of 3 is appropriate as the schema handles the heavy lifting.
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 specific action ('Extract raw VBA macros') and resource ('from an OLE document'), distinguishing it from sibling tools like 'maldoc_analyze' which likely performs different analysis. It precisely defines what the tool does without being vague or tautological.
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 'maldoc_analyze' or other security testing tools. It lacks context about prerequisites, scenarios where extraction is needed, or exclusions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check for rootkits via syscall table tampering and hidden kernel modules. Runs linux_check_syscall and linux_hidden_modules plugins. Returns syscall_check, hidden_modules, rootkit_indicators, and likely_compromised. Read-only analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| dump_path | Yes | Path to the Linux memory dump file | |
| profile | Yes | Volatility 2 profile name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only analysis', which clarifies this is a non-destructive inspection tool. However, it doesn't mention performance characteristics, rate limits, authentication requirements, or what happens with invalid inputs. The return fields are listed but not explained.
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 appropriately sized at three sentences. It's front-loaded with the core purpose, followed by implementation details and behavioral characteristics. While efficient, the second sentence could be slightly more concise by combining plugin information with return values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, 100% schema coverage, no annotations, and no output schema, the description provides adequate but incomplete context. It covers the purpose, methods, and read-only nature, but lacks output format details, error handling information, and usage guidelines. The absence of an output schema means the description should ideally explain the return structure more thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description.
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 specific action ('Check for rootkits'), methods ('via syscall table tampering and hidden kernel modules'), and tools used ('Runs linux_check_syscall and linux_hidden_modules plugins'). It distinguishes itself from sibling tools by focusing on memory-based rootkit detection rather than network, web application, or other security testing functions.
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. While it mentions specific plugins, it doesn't indicate scenarios where this tool is preferred over other memory analysis tools like 'volatility_linux' or 'volatility_windows', nor does it mention prerequisites or limitations beyond the required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test NoSQL operator injection ($ne, $gt, $regex) for authentication bypass. Sends payloads that abuse MongoDB query operators to bypass password checks. E.g., {"username":"admin","password":{"$ne":""}} matches any non-empty password. Returns: {results: [{payload_name, status, length, likely_bypass, snippet}]}. Side effects: Sends POST requests to the login endpoint. May create sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Login endpoint URL, e.g. https://target/login or https://target/api/auth | |
| username_param | No | JSON field name for username, e.g. 'username' or 'email' | username |
| password_param | No | JSON field name for password | password |
| target_username | No | Username to bypass auth for, e.g. 'admin' | admin |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (sends POST requests with injection payloads), mentions side effects (may create sessions), and specifies the return format. However, it doesn't mention potential risks, rate limits, or authentication requirements for the tool itself.
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 efficiently structured with three sentences covering purpose, example, and behavioral aspects. Each sentence adds value: the first states the core function, the second provides a concrete example, and the third covers side effects and return format. It could be slightly more front-loaded by moving the return format earlier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a security testing tool with no annotations and no output schema, the description provides good coverage of what the tool does, how it works, and what to expect. It explains the testing technique, gives an example payload, describes the return structure, and mentions side effects. The main gap is lack of explicit security warnings or usage prerequisites.
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 100% schema description coverage, the input schema already documents all 4 parameters thoroughly. The description doesn't add any additional parameter semantics beyond what's in the schema - it focuses on the technique and behavior rather than parameter usage. This meets the baseline expectation when schema coverage is complete.
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 specific action ('Test NoSQL operator injection for authentication bypass'), identifies the target resource (authentication mechanism), and distinguishes from siblings by focusing on NoSQL injection techniques rather than other auth bypass methods like SQL injection or brute force. It provides a concrete example of the technique being tested.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (testing authentication bypass via NoSQL injection) but doesn't explicitly state when to use this tool versus alternatives like 'sqli_login_bypass' or 'auth_bruteforce'. It does mention the specific technique ($ne, $gt, $regex operators) which helps differentiate from other approaches, but lacks explicit comparison or exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test NoSQL injection detection in query parameters. Tests MongoDB operator injection ($ne, $gt, $regex, $where) in GET parameters and JSON body to detect NoSQL injection points. Returns: {baseline, results: [{payload_name, status, length, different}], injectable}. Side effects: Read-only. Sends ~10 requests.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL with query parameter to test, e.g. https://target/api/products?category=Gifts | |
| parameter | Yes | Parameter name to test for NoSQL injection | |
| method | No | HTTP method | GET |
| content_type | No | 'query' for URL params, 'json' for JSON body | query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the tool sends ~10 requests, is read-only (no side effects), and returns a structured result including baseline, results with payload details, and injectable status. This covers operational impact and output format, though it could add more on error handling or limitations.
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 appropriately sized and front-loaded, with three concise sentences that cover purpose, behavior, and side effects without any wasted words. Each sentence adds value, making it efficient and well-structured for quick understanding.
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 (security testing with multiple parameters) and no output schema, the description is mostly complete. It explains what the tool does, its behavior, and return structure, but could benefit from more details on error cases or specific injection techniques. However, it adequately covers the essentials for an agent to use 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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add any additional meaning or context beyond what the schema provides (e.g., it doesn't explain how parameters interact or provide examples beyond the schema). Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Test NoSQL injection detection') and resources ('in query parameters'), and distinguishes it from siblings by specifying it targets MongoDB operator injection ($ne, $gt, $regex, $where) in GET parameters and JSON body. This is distinct from other security testing tools like 'sqli_blind_boolean' or 'xss_reflected_test'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (testing NoSQL injection in query parameters and JSON body), but does not explicitly state when not to use it or name alternatives. It implies usage for detecting injection points, which is sufficient for context but lacks explicit exclusions or comparisons to similar tools like 'nosqli_auth_bypass'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test path traversal with encoding variants at multiple depths. Tries plain ../, URL-encoded %2e%2e/, double-encoded %252e%252e/, and null-byte/truncation bypasses. Returns results array with payload, status, length, contains_target per attempt, and vulnerable_payloads list. Side effects: Read-only GET requests. Sends ~32 requests.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL with file parameter, e.g. https://target/image?filename=photo.jpg | |
| parameter | Yes | Parameter that accepts filenames | |
| target_file | No | Server file to attempt reading | |
| depth | No | Maximum directory traversal depth |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's read-only (GET requests), sends approximately 32 requests, and returns results in a specific format (array with payload, status, length, contains_target, vulnerable_payloads list). This covers most critical aspects for a testing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: it front-loads the core purpose, lists specific encoding variants, details the return format, and notes side effects in just two sentences with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (security testing with multiple variants) and no annotations or output schema, the description is mostly complete. It explains what the tool does, how it behaves, and what it returns, though it could benefit from more detail on error handling or specific use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add any parameter-specific details beyond what the schema provides, such as examples or usage notes for the parameters. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: testing path traversal vulnerabilities with specific encoding variants (plain ../, URL-encoded, double-encoded, null-byte/truncation bypasses) and returning structured results. It distinguishes itself from siblings by focusing on path traversal testing rather than other security tests like SQL injection or XSS.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for path traversal testing but does not explicitly state when to use this tool versus alternatives. While it's clear from context (sibling tools include various security tests), no specific guidance is provided on prerequisites, target scenarios, or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect port scans by analyzing SYN packets without ACK. Returns scanners (ip + syn_count), top_scanned_ports, and a hint. Read-only file analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| pcap_path | Yes | Path to the PCAP file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool as 'read-only file analysis,' indicating it does not modify data, and specifies the output structure ('Returns scanners, top_scanned_ports, and a hint'), which helps the agent understand what to expect. However, it lacks details on rate limits, error handling, or performance characteristics.
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 front-loaded with the core purpose, followed by output details and a behavioral note, all in two efficient sentences with zero waste. Each sentence adds value, making it appropriately sized and well-structured.
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 (analyzing PCAPs for port scans) and the absence of annotations and output schema, the description is mostly complete: it states the purpose, output structure, and read-only behavior. However, it could improve by mentioning limitations (e.g., file size constraints) or error cases, but it covers the essentials well for an analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'pcap_path' clearly documented. The description does not add meaning beyond the schema, as it only mentions 'PCAP file' without further details on format or constraints. The baseline score of 3 is appropriate since the schema adequately covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('detect port scans by analyzing SYN packets without ACK') and resources ('PCAP file'), distinguishing it from sibling tools like pcap_dns_analysis or pcap_extract_credentials by focusing on port scan detection rather than other analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for analyzing PCAP files to detect port scans, but it does not explicitly state when to use this tool versus alternatives like pcap_overview or pcap_follow_stream, nor does it provide exclusions or prerequisites. The context is clear but lacks explicit guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract and analyze DNS queries from a PCAP. Returns dns_queries_by_frequency, dns_servers, and ipv6_dns_endpoints. Read-only file analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| pcap_path | Yes | Path to the PCAP file | |
| source_ip | No | Filter DNS queries from a specific source IP |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: it's read-only (safe operation), performs file analysis (not live traffic), and returns three specific data structures. However, it doesn't mention potential limitations like file size constraints, processing time, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - two sentences that each earn their place. First sentence states purpose and outputs, second sentence adds crucial behavioral context. No wasted words, front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only analysis tool with 2 parameters (100% schema coverage) and no output schema, the description provides good completeness. It covers purpose, outputs, and safety profile. The main gap is lack of output format details (structure of returned data), but given the tool's relative simplicity, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., file format requirements for pcap_path, IP format for source_ip). Baseline score of 3 is appropriate when schema does the heavy lifting.
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 specific action ('Extract and analyze DNS queries from a PCAP') and lists the exact outputs (dns_queries_by_frequency, dns_servers, ipv6_dns_endpoints). It distinguishes itself from sibling tools like 'pcap_detect_scan' or 'pcap_tls_analysis' by focusing exclusively on DNS analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'Read-only file analysis' and the tool's name suggests it's for DNS analysis within PCAP files. However, it doesn't explicitly state when to use this tool versus alternatives like 'recon_dns' or 'pcap_llmnr_ntlm', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract credentials from FTP, HTTP, and SMTP traffic. Returns ftp_credentials, http_authorization_headers, http_post_data, and smtp_data. Read-only, may contain sensitive credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| pcap_path | Yes | Path to the PCAP file | |
| protocol | No | Protocol to extract credentials from | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It effectively discloses key behavioral traits: the read-only nature (safety profile), sensitivity warning ('may contain sensitive credentials'), and output structure. However, it doesn't mention potential limitations like file size constraints, processing time, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences with zero waste. First sentence covers purpose, scope, and output. Second sentence adds crucial behavioral context (read-only, sensitivity). Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema, the description provides good coverage: purpose, protocols, outputs, and behavioral context. However, it doesn't explain the format/structure of returned data (e.g., whether ftp_credentials is a list of dictionaries) or potential error cases, leaving some gaps for an agent to interpret.
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%, providing complete parameter documentation. The description doesn't add any parameter-specific information beyond what's in the schema (pcap_path, protocol with enum). Baseline score of 3 is appropriate since the schema already fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Extract credentials'), target resources ('FTP, HTTP, and SMTP traffic'), and output format ('Returns ftp_credentials, http_authorization_headers, http_post_data, and smtp_data'). It distinguishes itself from sibling PCAP tools like pcap_detect_scan or pcap_dns_analysis by focusing specifically on credential extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying the protocols (FTP, HTTP, SMTP) and mentioning it's 'read-only', but doesn't explicitly state when to use this tool versus alternatives like pcap_follow_stream or pcap_http_objects. No explicit exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Follow a TCP/UDP/HTTP stream in a PCAP. Returns stream_content, stream_num, and protocol. Read-only file analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| pcap_path | Yes | Path to the PCAP file | |
| stream_num | Yes | TCP stream number to follow | |
| protocol | No | Stream protocol | tcp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: the tool is 'Read-only' (non-destructive) and returns specific data (stream_content, stream_num, protocol). However, it lacks details on error handling, performance characteristics, file size limits, or whether it requires specific PCAP formats. The transparency is adequate but incomplete for a file analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that efficiently convey core functionality and safety. The first sentence states purpose and return values, the second adds behavioral context. No wasted words, though it could be slightly more structured by separating return values from purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with full schema coverage but no output schema or annotations, the description provides basic completeness. It covers purpose, returns, and safety, but lacks details on output format (e.g., structure of stream_content), error conditions, or performance expectations. For a read-only analysis tool, this is minimally adequate but leaves gaps an agent might need.
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%, providing good parameter documentation. The description adds minimal value beyond the schema, only implying that stream_num relates to 'TCP stream number' (though the tool handles UDP/HTTP too). It doesn't clarify parameter interactions or provide examples. With high schema coverage, baseline 3 is appropriate as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Follow a TCP/UDP/HTTP stream in a PCAP' with specific verbs and resources. It distinguishes from some siblings like pcap_detect_scan or pcap_dns_analysis by focusing on stream following rather than detection or analysis of specific protocols. However, it doesn't explicitly differentiate from pcap_http_objects which might overlap in HTTP stream handling.
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 minimal usage guidance. It mentions 'Read-only file analysis' which implies safety but doesn't specify when to use this tool versus alternatives like pcap_http_objects for HTTP-specific extraction or pcap_extract_credentials for credential-focused analysis. No explicit when/when-not instructions or sibling tool comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export HTTP objects (files) from a PCAP to a directory. Returns exported_count, output_dir, files list, and tshark_output. Creates files in the output directory.
| Name | Required | Description | Default |
|---|---|---|---|
| pcap_path | Yes | Path to the PCAP file | |
| output_dir | Yes | Directory to export HTTP objects to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: it creates files in the output directory (indicating mutation/write operations) and returns specific data (exported_count, output_dir, files list, tshark_output). However, it lacks details on permissions needed, error handling, or rate limits, leaving gaps for a tool that modifies the filesystem.
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 front-loaded with the core action in the first sentence and efficiently covers key outputs and side effects in the second. Both sentences earn their place by providing essential information without redundancy, though it could be slightly more structured.
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 (filesystem mutation, PCAP processing) and lack of annotations and output schema, the description is moderately complete. It covers the action, outputs, and side effects but misses details like error conditions, performance expectations, or security implications, which are important for such an operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (pcap_path and output_dir). The description adds no additional meaning beyond what's in the schema, such as format examples or constraints. The baseline score of 3 reflects adequate but minimal value added by the description.
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 specific action ('Export HTTP objects from a PCAP') and resource ('files') with the destination ('to a directory'). It distinguishes itself from sibling tools like 'pcap_detect_scan' or 'pcap_extract_credentials' by focusing on HTTP object extraction rather than scanning, credential extraction, or other PCAP analyses.
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 'pcap_extract_credentials' for credential extraction or 'pcap_dns_analysis' for DNS analysis. It mentions what the tool does but offers no context on prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect LLMNR poisoning and extract NTLM credentials from SMB. Returns llmnr_queries, ntlm_auth_entries, counts, and poisoning_indicators. Read-only file analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| pcap_path | Yes | Path to the PCAP file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively states the tool is 'read-only file analysis,' clarifying it doesn't modify data, and lists specific return values (llmnr_queries, ntlm_auth_entries, etc.), which helps predict behavior. However, it doesn't mention potential errors, performance aspects, or authentication needs.
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 front-loaded with the core purpose, followed by return values and a key behavioral note ('read-only file analysis'). Every sentence adds value with zero waste, making it efficient and well-structured.
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 (security analysis with multiple return types), no annotations, and no output schema, the description does a good job by specifying the purpose, return values, and read-only nature. However, it could be more complete by detailing error cases or output formats, though it's largely adequate for the 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 100%, so the schema already documents the pcap_path parameter. The description doesn't add any parameter-specific details beyond what's in the schema, such as file format requirements or path examples. Baseline 3 is appropriate when the schema handles parameter 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 clearly states the tool's purpose with specific verbs ('detect', 'extract') and resources ('LLMNR poisoning', 'NTLM credentials from SMB'), distinguishing it from sibling tools like pcap_detect_scan or pcap_extract_credentials by focusing on LLMNR/NTLM analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for analyzing PCAP files for LLMNR/NTLM attacks but doesn't explicitly state when to use this tool versus alternatives like pcap_dns_analysis or pcap_extract_credentials. It provides basic context but lacks explicit guidance on exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get protocol hierarchy and endpoint statistics from a PCAP. Returns protocol_hierarchy, endpoints, packet_count, and capture_info. Read-only file analysis, no network access.
| Name | Required | Description | Default |
|---|---|---|---|
| pcap_path | Yes | Path to the PCAP file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it's read-only, involves file analysis (not network access), and specifies the return values (protocol_hierarchy, endpoints, packet_count, capture_info). It doesn't mention error handling or performance limits, but covers essential safety and scope.
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 front-loaded with the core purpose, followed by return values and behavioral notes in two concise sentences. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 and no output schema, the description compensates well by specifying return values and behavioral constraints. It's complete enough for a read-only analysis tool, though it could benefit from mentioning error cases or input format requirements to reach a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with pcap_path clearly documented. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 for adequate but not enhanced parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get protocol hierarchy and endpoint statistics') and resources ('from a PCAP'), distinguishing it from sibling tools like pcap_detect_scan or pcap_dns_analysis by focusing on overview statistics rather than specific analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'Read-only file analysis, no network access,' suggesting it's for offline PCAP analysis, but it doesn't explicitly state when to use this tool versus alternatives like pcap_extract_credentials or pcap_follow_stream, leaving the agent to infer based on the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze TLS handshakes, SNI values, and certificate data in a PCAP. Returns sni_values, tls_versions, server_ephemeral_keys, and client_randoms. Read-only file analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| pcap_path | Yes | Path to the PCAP file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it specifies the return data fields (sni_values, tls_versions, etc.), declares it as 'Read-only file analysis' (indicating non-destructive operation), and implies file-based input. However, it doesn't mention error handling, performance characteristics, or output format 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 efficiently structured in two sentences: the first states purpose and return values, the second adds behavioral context. Every word earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only analysis tool with no output schema, the description provides good context: purpose, return fields, and safety declaration. It could be more complete by specifying output format or error conditions, but it's largely adequate given the tool's simplicity.
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% (the single parameter 'pcap_path' is fully described in the schema as 'Path to the PCAP file'). The description doesn't add any parameter-specific information beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Analyze TLS handshakes, SNI values, and certificate data in a PCAP') and resource ('PCAP'), and distinguishes from siblings by focusing on TLS analysis rather than other PCAP tools like pcap_dns_analysis or pcap_extract_credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for TLS analysis in PCAP files but doesn't explicitly state when to use this tool versus alternatives like pcap_detect_scan or pcap_overview. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test client-side price manipulation by sending modified price values.
Sends price=0, price=1, price=-1, and negative quantity variants to check if the server validates prices server-side.
Returns: {"results": [{"test_case": str, "payload": str, "status": int, "length": int, "accepted": bool, "snippet": str}]}.
Side effects: May add items to cart or create orders at manipulated prices.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL that processes the purchase/cart action | |
| price_param | Yes | Parameter name for the price, e.g. 'price', 'amount', 'total' | |
| cart_endpoint | No | Separate cart/checkout endpoint to verify final price after manipulation | |
| extra_params | No | Additional form parameters, e.g. 'productId=1&quantity=1' | |
| auth_cookie | No | Session cookie for authenticated requests | |
| content_type | No | Request content type: 'form' or 'json' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully describes what the tool does (sends specific test cases), what it returns (detailed results structure), and importantly discloses side effects ('May add items to cart or create orders at manipulated prices'). This covers the mutation risk and potential consequences well.
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 efficiently structured with three focused sentences: purpose statement, return value specification, and side effect disclosure. Every sentence earns its place by providing essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a security testing tool with 6 parameters, 100% schema coverage, and no output schema, the description provides good contextual completeness. It explains the tool's purpose, what it tests, the return format, and critical side effects. The main gap is that without an output schema, the description doesn't fully explain the meaning of each field in the results array (e.g., what 'accepted: bool' specifically indicates).
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 100% schema description coverage, all 6 parameters are already documented in the input schema. The description doesn't add any additional parameter semantics beyond what's in the schema descriptions. It mentions 'price=0, price=1, price=-1, and negative quantity variants' which relates to the tool's behavior but doesn't provide parameter-specific guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('test client-side price manipulation by sending modified price values') and the resource being tested (price validation). It distinguishes itself from sibling tools by focusing specifically on price manipulation testing rather than authentication, SQL injection, XSS, or other security tests listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to check if the server validates prices server-side'), which implicitly suggests it's for security testing scenarios. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools for similar validation testing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Directory brute-force using parallel curl requests. Returns results (path/status/length), found_count, and paths_tested. Read-only GET requests, sends one request per wordlist entry per extension.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Base URL, e.g. https://example.com | |
| wordlist | No | Path to wordlist file. Uses built-in common paths if not provided. | |
| threads | No | Concurrent request count | |
| extensions | No | Comma-separated extensions to append, e.g. 'php,html,txt' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and effectively discloses key behavioral traits: it's read-only (GET requests), performs parallel requests, sends one request per wordlist entry per extension, and returns specific metrics (found_count, paths_tested). However, it lacks details on error handling or 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 appropriately sized and front-loaded, with two sentences that efficiently convey the tool's function, behavior, and output without any wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers purpose and basic behavior but lacks details on output format, error scenarios, or performance implications, which could hinder an agent's ability to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal value beyond the schema, mentioning 'parallel curl requests' and 'one request per wordlist entry per extension', which slightly clarifies the 'extensions' parameter usage but doesn't provide additional syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Directory brute-force using parallel curl requests') and resources ('Returns results (path/status/length), found_count, and paths_tested'), distinguishing it from siblings like 'recon_dns' or 'recon_quick' by focusing on HTTP directory 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?
The description implies usage for directory enumeration via HTTP requests but provides no explicit guidance on when to use this tool versus alternatives like 'recon_quick' or 'path_traversal_test', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full DNS enumeration: A, AAAA, MX, TXT, NS, CNAME, AXFR, BIND version. Returns records object, axfr_result, and bind_version. Read-only DNS queries.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target domain, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that the tool is read-only ('Read-only DNS queries'), which is crucial for safety. It also specifies the return structure ('Returns records object, axfr_result, and bind_version'), adding valuable context beyond basic functionality.
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 highly concise and front-loaded, packing essential information into three efficient sentences: the enumeration scope, return values, and safety note. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (DNS enumeration with multiple record types), no annotations, and no output schema, the description does well by specifying the return structure and read-only nature. However, it lacks details on error handling, rate limits, or authentication needs, leaving some gaps for a security tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'target' parameter clearly documented as 'Target domain, e.g. example.com.' The description doesn't add any additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3.
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 specific action ('Full DNS enumeration') and lists the exact record types (A, AAAA, MX, TXT, NS, CNAME, AXFR, BIND version) being queried. It distinguishes itself from sibling tools by focusing exclusively on DNS enumeration rather than other reconnaissance or attack techniques.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'Full DNS enumeration' and 'Read-only DNS queries,' suggesting it's for information gathering rather than exploitation. However, it doesn't explicitly state when to use this tool versus alternatives like 'recon_quick' or 'recon_vhost,' nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search git history for secrets: commit messages, author info, branches, deleted files. Returns secrets_in_code_history, unique_authors, branches, deleted_files_summary, and suspicious_commit_messages. Read-only git operations on local repository.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | Path to the git repository |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: it's a read-only operation (no mutations), works on local repositories, and returns specific data types (secrets_in_code_history, unique_authors, etc.). However, it doesn't mention performance aspects like rate limits or error handling, leaving some gaps.
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 front-loaded with the core purpose, followed by details on what it searches and returns, ending with operational context. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.
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 and no output schema, the description does a good job covering the tool's behavior and return values. It specifies the output structure (secrets_in_code_history, etc.) and operational constraints. However, it could be more complete by detailing error cases or example outputs, slightly reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single parameter 'repo_path' well-described. The description doesn't add meaning beyond the schema, as it doesn't elaborate on parameter usage or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to.
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 specific action ('Search git history for secrets') and resource ('git history'), distinguishing it from sibling tools like recon_directory_bruteforce or recon_dns. It explicitly lists what it searches (commit messages, author info, branches, deleted files) and what it returns, making the purpose unambiguous and 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?
The description implies usage for security auditing of git repositories but doesn't explicitly state when to use it versus alternatives like recon_quick or other recon tools. It mentions 'Read-only git operations on local repository,' which provides some context but lacks explicit guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quick reconnaissance: robots.txt, security.txt, common dirs, response headers. Returns robots_txt, security_txt, response_headers, accessible_directories, and error_page_snippet. Read-only, sends ~10 GET requests.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target domain or URL, e.g. example.com or https://example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it is 'read-only', sends '~10 GET requests', and returns specific data fields (robots_txt, security_txt, etc.). This covers safety (read-only), network impact (request count), and output structure, though it doesn't mention error handling or 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 highly concise and front-loaded, packing essential information into two sentences: the tool's purpose and scope, its read-only nature and request count, and the return values. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (reconnaissance with multiple checks), no annotations, and no output schema, the description does well by specifying the return data fields and behavioral traits. However, it lacks details on error responses or exact request patterns, leaving minor gaps for a tool with no structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'target', which is well-documented in the schema. The description does not add any additional meaning or examples beyond what the schema provides, so it meets the baseline of 3 without compensating for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'quick reconnaissance' with specific actions: checking robots.txt, security.txt, common directories, and response headers. It distinguishes itself from sibling tools like 'recon_directory_bruteforce' by emphasizing a quick, broad scan rather than intensive directory 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?
The description implies usage for initial reconnaissance with 'quick' and lists specific checks, but does not explicitly state when to use this tool versus alternatives like 'recon_dns' or 'recon_vhost'. It provides clear context for initial scanning but lacks explicit exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test an S3 bucket for public access (listing, reading). Returns bucket_url, listable, listing_snippet, and readable_files. Read-only requests to S3.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket_name | Yes | S3 bucket name to test, e.g. 'assets.example.com' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: it's a read-only operation (explicitly stated), performs security testing, and returns specific data fields (bucket_url, listable, listing_snippet, readable_files). It doesn't mention rate limits, authentication requirements, or potential side effects, but covers the core behavior well.
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 perfectly concise with two sentences that each earn their place: the first states the purpose and return values, the second clarifies the read-only nature. No wasted words, well-structured, and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations and no output schema, the description provides good completeness: it explains what the tool does, what it returns, and its read-only nature. The main gap is lack of explicit output format details, but given the tool's relative simplicity, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'bucket_name' parameter. The description doesn't add any additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for high schema coverage.
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 specific action ('Test an S3 bucket for public access'), the resource ('S3 bucket'), and the scope ('listing, reading'). It distinguishes from siblings by focusing on S3 bucket security testing rather than other recon or attack tools like 'recon_directory_bruteforce' or 'sqli_blind_boolean'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to test S3 buckets for public access vulnerabilities. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the context implies it's for S3-specific reconnaissance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract Subject Alternative Names from the TLS certificate. Returns common_name, subject_alternative_names, issuer, validity, and san_count. Read-only TLS handshake.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target domain or IP:port, e.g. example.com or 1.2.3.4:443 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively states the tool is 'Read-only' (indicating non-destructive operation) and performs a 'TLS handshake' (implying network interaction), which covers key behavioral traits. However, it lacks details on error handling, rate limits, or authentication needs, leaving some gaps in 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 front-loaded with the core purpose in the first sentence, followed by return details and behavioral notes. Every sentence adds value without redundancy, and the structure is efficient with no wasted words, making it highly concise and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (TLS analysis with one parameter) and lack of annotations or output schema, the description is reasonably complete. It covers purpose, returned data, and behavioral traits ('Read-only TLS handshake'), but could improve by detailing output format or error cases. It adequately compensates for the missing structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'target' parameter clearly documented in the schema. The description does not add any additional meaning or context beyond what the schema provides (e.g., no examples of valid targets beyond the schema's 'example.com or 1.2.3.4:443'). Baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
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 specific action ('Extract Subject Alternative Names from the TLS certificate') and resource (TLS certificate), distinguishing it from sibling tools like 'recon_dns' or 'recon_quick' by focusing on TLS certificate analysis. It explicitly lists the returned data fields (common_name, subject_alternative_names, etc.), making the purpose highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for TLS certificate analysis (e.g., 'TLS handshake'), but does not explicitly state when to use this tool versus alternatives like 'recon_dns' or 'pcap_tls_analysis'. No guidance is provided on prerequisites, exclusions, or specific scenarios where this tool is preferred over others, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Brute-force virtual hosts by fuzzing the Host header. Returns baseline_length, results (vhost/status/length/length_delta), unique_vhosts, and tested count. Read-only, sends one request per wordlist entry.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target IP or domain to send requests to | |
| base_domain | Yes | Base domain for vhost names, e.g. hackycorp.com | |
| wordlist | No | Path to wordlist file. Uses built-in common subdomains if not provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it is read-only (safety), sends one request per wordlist entry (rate/performance implication), and returns specific data fields (baseline_length, results, etc.). However, it lacks details on error handling, timeouts, or output format specifics.
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 front-loaded with the core purpose, followed by return details and behavioral notes in two efficient sentences. Every sentence adds value without redundancy, making it appropriately sized and structured.
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 (brute-force operation with multiple parameters) and lack of annotations or output schema, the description does well by covering purpose, behavior, and return data. However, it could improve by detailing output structure or error cases to be fully complete for 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 description coverage is 100%, so the schema already documents all parameters well. The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints, meeting the baseline for high schema coverage.
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 specific action ('brute-force virtual hosts by fuzzing the Host header') and resource ('virtual hosts'), distinguishing it from sibling tools like recon_directory_bruteforce or recon_dns by focusing on host header fuzzing rather than directory or 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, scenarios where it is most effective, or how it differs from other recon tools in the sibling list, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test cookie/parameter-based role escalation.
Sends requests with various role cookie values (Admin=true, roleid=2, etc.) and checks for privilege escalation. Also tests JSON body field manipulation for profile update endpoints.
Returns: {"baseline": dict, "results": [{"value": str, "status": int, "length": int, "escalated": bool}], "escalation_candidates": [str]}.
Side effects: If json_body is set, sends POST/PUT requests that may modify state.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Protected URL to access, e.g. https://target/admin or https://target/api/users | |
| cookie_name | Yes | Cookie name for role control, e.g. 'admin', 'role', 'is_admin' | |
| cookie_values | Yes | Values to test, e.g. ['true','1','admin','2','yes'] | |
| extra_cookies | No | Additional cookies to include, e.g. 'session=abc123; logged_in=true' | |
| json_body | No | JSON body for POST-based role escalation, e.g. '{"roleid":2}'. Will test each value substituted | |
| json_field | No | JSON field to manipulate in json_body, e.g. 'roleid' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: sending requests with different cookie values, testing JSON body manipulation, returning structured results, and importantly disclosing side effects: 'If json_body is set, sends POST/PUT requests that may modify state.' This is crucial information for a security testing tool that could potentially alter system state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with the core purpose, explains the testing methodology, specifies the return format, and ends with important side effect warnings. Every sentence adds value, though it could be slightly more concise by combining some related concepts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a security testing tool with 6 parameters, no annotations, and no output schema, the description provides good contextual completeness. It explains what the tool does, how it works, what it returns, and critical side effects. The main gap is that without an output schema, the return format description could be more detailed, but the provided JSON structure gives adequate guidance.
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 100% schema description coverage, the schema already documents all 6 parameters thoroughly. The description adds minimal parameter semantics beyond what's in the schema - it mentions 'cookie/parameter-based role escalation' which aligns with the parameters but doesn't provide additional syntax, format, or usage details. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Test cookie/parameter-based role escalation' with specific actions like sending requests with role cookie values and JSON body manipulation. It distinguishes itself from siblings like 'auth_cookie_tamper' or 'idor_test' by focusing on privilege escalation testing through role manipulation rather than general authentication or IDOR 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?
The description provides clear context for when to use this tool: testing for privilege escalation via cookies or JSON parameters. It doesn't explicitly state when not to use it or name specific alternatives, but the context implies it's for security testing scenarios where role-based access control needs validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Boolean-based blind SQLi with binary search character enumeration. Uses ASCII(SUBSTRING(...))>N technique with binary search for efficiency. Determines true/false by comparing response lengths. Returns extracted_value, characters_found, requests_sent. Side effects: Read-only. Sends ~8 requests per character (binary search on ASCII 32-126).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL with injectable parameter | |
| parameter | Yes | Vulnerable parameter name | |
| query | No | SQL sub-query to extract, e.g. 'database()' or '(SELECT password FROM users LIMIT 1)' | |
| max_length | No | Maximum string length to extract |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behaviors: 'Read-only' (safety profile), 'Sends ~8 requests per character' (rate/volume impact), and 'Determines true/false by comparing response lengths' (mechanism). It also describes output format ('Returns extracted_value, characters_found, requests_sent') and efficiency characteristics. Missing details about error handling or specific side effects beyond request count.
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 and well-structured: first sentence defines purpose and technique, second explains mechanism, third describes outputs, fourth covers side effects and efficiency. Every sentence earns its place with zero wasted words, and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex security testing tool with no annotations and no output schema, the description provides substantial context: purpose, technique, mechanism, outputs, side effects, and efficiency characteristics. It doesn't explain the binary search algorithm in detail or provide examples, but covers the essential operational context well given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain how 'query' interacts with the binary search technique). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'Boolean-based blind SQLi with binary search character enumeration', specifying both the technique (SQL injection) and method (binary search). It distinguishes from siblings like 'sqli_blind_time' (time-based) and 'sqli_union_extract' (union-based) by explicitly mentioning its boolean-based approach with response length comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'Boolean-based blind SQLi' and mentions efficiency ('binary search for efficiency'), but doesn't explicitly state when to use this tool versus alternatives like 'sqli_blind_time' or 'sqli_union_extract'. It provides technical context but lacks explicit comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Time-based blind SQLi detection for MySQL, PostgreSQL, and MSSQL. Sends sleep-inducing payloads and measures response time to detect injection. Returns vulnerable, dbtype, and results array with payload, response_time, triggered. Side effects: Read-only but slow (each payload waits up to delay_seconds). Sends 3 requests.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL with injectable parameter | |
| parameter | Yes | Vulnerable parameter name | |
| dbtype | No | Target database type | |
| delay_seconds | No | Sleep duration for true condition |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it's read-only (stated explicitly), slow due to delay mechanisms, sends 3 requests, and returns specific outputs ('vulnerable, dbtype, and results array'). It also mentions side effects like waiting up to 'delay_seconds', adding useful context beyond basic functionality.
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 appropriately sized and front-loaded, starting with the core purpose. However, the second sentence could be more streamlined (e.g., combining detection and measurement aspects), and some details like 'Sends 3 requests' might be slightly redundant if implied by the process.
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 (security testing with multiple parameters) and no output schema, the description is fairly complete: it covers purpose, behavior, side effects, and return values. It could improve by specifying error handling or prerequisites, but it adequately informs usage without structured annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add significant meaning beyond the schema, such as explaining how 'delay_seconds' affects detection accuracy or interactions between parameters. Baseline 3 is appropriate as the schema handles most 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 clearly states the tool's purpose with specific verbs ('detection', 'sends', 'measures') and resources ('MySQL, PostgreSQL, and MSSQL', 'sleep-inducing payloads', 'response time'). It distinguishes itself from sibling tools like 'sqli_blind_boolean' by specifying time-based detection rather than boolean-based.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for SQL injection detection with time-based techniques but does not explicitly state when to use this tool versus alternatives like 'sqli_blind_boolean' or 'sqli_union_extract'. It provides some context (e.g., 'for MySQL, PostgreSQL, and MSSQL') but lacks clear exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read server files via UNION SELECT LOAD_FILE(). Requires MySQL FILE privilege. Uses LOAD_FILE() in a UNION SELECT. Returns file_content, success, target_file. Errors: FILE privilege required. Returns empty if privilege denied.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL with injectable parameter | |
| parameter | Yes | Vulnerable parameter name | |
| target_file | No | Server-side file to read, e.g. /etc/passwd | |
| column_count | No | Number of columns (from previous UNION discovery) | |
| string_column | No | 1-indexed column that displays strings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does this well. It specifies technical requirements ('MySQL FILE privilege'), implementation details ('Uses LOAD_FILE() in a UNION SELECT'), return values ('Returns file_content, success, target_file'), and error conditions ('Errors: FILE privilege required. Returns empty if privilege denied'). The only minor gap is not mentioning potential side effects or 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 perfectly front-loaded and efficient. The first sentence establishes the core purpose, followed by essential requirements, implementation details, return values, and error conditions - all in just 4 sentences with zero wasted words. Every sentence earns its place by providing 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?
For a complex security testing tool with 5 parameters and no output schema, the description provides excellent coverage of what the tool does, how it works, requirements, and error conditions. The only gap is the lack of output schema, which means the description doesn't fully document the structure of returned data (though it lists the fields). Given the complexity and absence of annotations, it's nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description mentions 'target_file' in the return values section, which provides some additional context about that parameter's purpose, but doesn't add meaningful semantic information beyond what's already documented in the comprehensive input schema descriptions for all 5 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Read server files via UNION SELECT LOAD_FILE()' - a specific verb ('Read') and resource ('server files') with the exact technique ('UNION SELECT LOAD_FILE()'). It distinguishes itself from sibling SQL injection tools like sqli_union_extract, sqli_blind_boolean, and sqli_blind_time by focusing specifically on file reading rather than general data extraction or blind techniques.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Requires MySQL FILE privilege' and 'Uses LOAD_FILE() in a UNION SELECT' indicate it's specifically for MySQL databases with file reading vulnerabilities. However, it doesn't explicitly state when NOT to use it or mention alternatives among the many sibling SQL injection tools, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bypass login via SQL comment truncation (administrator'--). Extracts CSRF token from form, then POSTs with SQLi in the username field. The -- comment truncates the password check. Returns csrf_extracted, status_code, response_length, headers, likely_bypass.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Login form URL, e.g. https://target/login | |
| username | No | Target username to bypass auth for, e.g. 'administrator' | |
| csrf_field | No | Name of the CSRF token field in the form | |
| username_field | No | Name of the username form field | |
| password_field | No | Name of the password form field |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses the multi-step behavior (extracts CSRF token, then POSTs with SQLi), the specific SQL injection technique (comment truncation), and what the tool returns (csrf_extracted, status_code, etc.). It doesn't mention error handling, rate limits, or authentication requirements, but covers core behavioral traits adequately.
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 perfectly concise: two sentences that efficiently explain the technique, process, and return values with zero wasted words. Every element earns its place, and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a multi-step security testing tool with 5 parameters and no output schema, the description provides good context about the technique and return values. It could benefit from mentioning prerequisites (e.g., requires a vulnerable login form) or limitations, but covers the essential operational context well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter 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 clearly states the tool's purpose: 'Bypass login via SQL comment truncation' with a specific technique example ('administrator'--'). It distinguishes from siblings like 'sqli_blind_boolean' or 'sqli_union_extract' by focusing on authentication bypass rather than general SQL injection exploitation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when targeting login forms with SQL injection vulnerabilities and CSRF tokens. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among the many sibling tools, though the technique specificity provides some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step-by-step UNION-based data extraction. 1. Finds column count via ORDER BY. 2. Identifies string-displayable columns via UNION SELECT. 3. Extracts database name and version. 4. Lists tables and columns. Returns column_count, string_columns, db_name, db_version, tables, user_columns. Side effects: Read-only GET requests. Sends ~30 requests depending on column count.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL with injectable parameter, e.g. https://target/filter?category=Gifts | |
| parameter | Yes | Vulnerable query parameter name | |
| max_columns | No | Maximum columns to probe with ORDER BY |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels by disclosing key behavioral traits: it specifies the return values (column_count, string_columns, db_name, db_version, tables, user_columns), side effects ('read-only GET requests'), and performance characteristics ('sends ~30 requests depending on column count'). This provides comprehensive insight into the tool's operation and 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 efficiently structured with a clear step-by-step breakdown, followed by return values and side effects. Every sentence adds value without redundancy, making it easy to scan and understand the tool's purpose and behavior quickly.
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 multi-step SQL injection tool with no annotations and no output schema, the description does an excellent job covering behavior, returns, and side effects. However, it could slightly improve by mentioning error handling or what happens if the target isn't vulnerable, but overall it's highly complete for the 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?
The schema description coverage is 100%, so the schema already documents all three parameters (url, parameter, max_columns) adequately. The description doesn't add any additional meaning or context about the parameters beyond what the schema provides, such as examples of vulnerable parameters or guidance on setting max_columns. This meets the baseline for high schema coverage.
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 specific action ('step-by-step UNION-based data extraction') and enumerates the exact steps (finding column count, identifying string columns, extracting database info, listing tables/columns). It distinguishes itself from sibling tools like sqli_blind_boolean or sqli_login_bypass by focusing on UNION-based extraction rather than blind or authentication bypass techniques.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the step-by-step process and mentions it's for UNION-based extraction, which suggests it should be used when SQL injection vulnerabilities are suspected. However, it doesn't explicitly state when to use this tool versus alternatives like sqli_blind_boolean or sqli_file_read, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test WHERE clause bypass via OR 1=1 variants. Sends multiple payloads (OR 1=1--, OR '1'='1, OR 1=1/*, etc.) against the target parameter and compares response lengths to the baseline. Returns baseline_length and results array. Side effects: None (read-only GET requests). Sends 7 requests total.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL with query parameter, e.g. https://target/filter?category=Gifts | |
| parameter | Yes | Vulnerable query parameter name, e.g. 'category' | |
| value | Yes | Legitimate parameter value to base the injection on, e.g. 'Gifts' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds significant behavioral context. It discloses that the tool sends multiple payloads (listing examples like OR 1=1--), sends 7 requests total, compares response lengths, returns specific data (baseline_length and results array), and explicitly states side effects: 'None (read-only GET requests).' This covers safety, scope, and operational details well.
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 efficiently structured in three sentences: first states purpose and method, second details output and side effects, third specifies request count. Every sentence adds value without redundancy, and it's front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description provides good completeness: it explains what the tool does, how it behaves (read-only, 7 requests), and what it returns. However, it could improve by detailing the structure of the results array or error handling, but given the context, it's largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (url, parameter, value) with clear descriptions. The description doesn't add any parameter-specific semantics beyond what's in the schema, such as format examples or constraints, but it implies the parameters are used for injection testing. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action: 'Test WHERE clause bypass via OR 1=1 variants.' It identifies the exact technique (SQL injection testing with OR 1=1 variants) and distinguishes it from sibling tools like sqli_blind_boolean, sqli_blind_time, and sqli_union_extract by focusing on WHERE clause bypass rather than other SQLi methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it targets a 'vulnerable query parameter' and compares response lengths to a baseline, suggesting it's for detecting SQL injection vulnerabilities. However, it doesn't explicitly state when to use this tool versus alternatives like sqli_blind_boolean or sqli_login_bypass, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test SSRF access to cloud metadata endpoints (AWS/GCP/Azure). Attempts to reach instance metadata services through the SSRF vector. Returns results array with provider, endpoint, status, length, response_snippet. Side effects: May cause target to request cloud metadata. Could expose IAM credentials if successful.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL with SSRF-vulnerable parameter | |
| parameter | Yes | Parameter that accepts URLs | |
| cloud_provider | No | Cloud provider to test metadata endpoints for | |
| method | No | HTTP method |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does so effectively. It clearly discloses the tool's behavior: it attempts to reach metadata services through SSRF, returns specific result fields, and importantly warns about side effects (may cause target to request cloud metadata, could expose IAM credentials if successful). This provides crucial behavioral context beyond what parameters indicate.
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 perfectly sized and front-loaded: first sentence states the purpose, second describes the return format, third warns about side effects. Every sentence earns its place with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a security testing tool with no annotations and no output schema, the description provides excellent context about behavior and side effects. However, it doesn't describe the format or structure of the returned results array in detail, leaving some ambiguity about what 'status', 'length', and 'response_snippet' actually contain.
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 100% schema description coverage, the schema already documents all 4 parameters thoroughly. The description doesn't add additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Test SSRF access to cloud metadata endpoints'), identifies the target resources (AWS/GCP/Azure metadata services), and distinguishes it from the sibling 'ssrf_test' tool by focusing specifically on cloud metadata exploitation rather than general SSRF 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?
The description implies usage context (testing SSRF vulnerabilities targeting cloud metadata) but doesn't explicitly state when to use this tool versus the general 'ssrf_test' sibling or other security testing tools. It provides good context but lacks explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test SSRF with localhost bypass variants. Sends 10+ representations of localhost (127.0.0.1, 0, decimal, hex, IPv6, etc.) to check if the server fetches internal resources. Returns results array with variant, payload_url, status, length, different_from_baseline per attempt. Side effects: May cause the target server to make internal requests.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL that accepts a URL/host parameter | |
| parameter | Yes | Parameter that accepts URLs, e.g. 'url', 'src', 'redirect' | |
| internal_target | No | Internal resource to reach, e.g. 'http://localhost/admin' | |
| method | No | HTTP method |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool sends multiple localhost variants, returns results in a structured array, and warns of side effects (may cause internal requests). However, it lacks details on error handling, timeouts, or 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 front-loaded with the core purpose, followed by details on behavior and side effects. It uses three sentences efficiently, with minimal waste, though it could be slightly more structured (e.g., separating side effects into a distinct note).
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 (security testing with side effects) and no annotations or output schema, the description provides good context: purpose, behavior, return format, and side effects. It covers essential aspects but could benefit from more detail on output structure or error cases to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add specific meaning beyond what the schema provides (e.g., examples of 'parameter' values or 'internal_target' usage). Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Test SSRF with localhost bypass variants', 'Sends 10+ representations of localhost', 'check if the server fetches internal resources') and distinguishes it from siblings by focusing on SSRF testing with localhost bypass techniques, unlike other tools like 'ssrf_cloud_metadata' or general recon tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for SSRF testing with localhost bypass, but does not explicitly state when to use this tool versus alternatives like 'ssrf_cloud_metadata' or other testing tools. It provides context (testing server-side request forgery) but lacks explicit guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Volatility 2 Linux plugin against a memory dump. Returns plugin, profile, success, output, and errors. Read-only analysis. Requires volatility2 (vol.py) on PATH.
| Name | Required | Description | Default |
|---|---|---|---|
| dump_path | Yes | Path to the Linux memory dump file | |
| profile | Yes | Volatility 2 profile name, e.g. 'LinuxCentOS7_7_1908x64' | |
| plugin | Yes | Volatility 2 Linux plugin to run |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it specifies the tool is 'Read-only analysis' (indicating non-destructive operation), lists what it returns ('Returns plugin, profile, success, output, and errors'), and states a system requirement ('Requires volatility2 (vol.py) on PATH'). This covers safety, output format, and prerequisites well, though it lacks details on error handling or performance 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 front-loaded with the core purpose in the first sentence, followed by return details and prerequisites. Each sentence adds essential information without redundancy, making it efficient and well-structured for quick understanding.
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 (memory analysis with external dependencies), no annotations, and no output schema, the description does a good job of covering purpose, behavior, and prerequisites. However, it could be more complete by detailing error scenarios or output structure, as the return values are listed but not explained in depth.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add any additional meaning or context beyond what the schema provides for the parameters (dump_path, profile, plugin). It mentions the plugin in a general sense but does not elaborate on parameter usage or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Run a Volatility 2 Linux plugin against a memory dump') and resource ('memory dump'), distinguishing it from sibling tools like 'volatility_windows' by specifying the Linux focus. It provides a complete picture of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Run a Volatility 2 Linux plugin against a memory dump') and mentions a prerequisite ('Requires volatility2 (vol.py) on PATH'). However, it does not provide guidance on when not to use it or name specific alternatives among siblings, such as 'volatility_windows' for Windows memory dumps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Volatility 3 Windows plugin against a memory dump. Returns plugin, success, output, and errors. Read-only analysis, Volatility 3 auto-detects OS. Requires vol3 (vol) on PATH.
| Name | Required | Description | Default |
|---|---|---|---|
| dump_path | Yes | Path to the Windows memory dump file | |
| plugin | Yes | Volatility 3 Windows plugin to run |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's 'Read-only analysis' (safety profile), 'Volatility 3 auto-detects OS' (automation behavior), 'Returns plugin, success, output, and errors' (output format), and has a prerequisite ('Requires vol3 (vol) on PATH'). It doesn't mention rate limits, timeout behavior, or specific error conditions, but covers the essential operational 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 perfectly concise and well-structured in three sentences. The first sentence states the core purpose, the second describes the return format and key behaviors, and the third specifies prerequisites. Every sentence earns its place with no wasted words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (memory analysis with external dependency), no annotations, and no output schema, the description provides good contextual coverage. It explains what the tool does, its safety profile (read-only), automation behavior (OS auto-detection), return format, and prerequisites. The main gap is the lack of output schema, but the description compensates by describing the return structure. Some behavioral details like error handling specifics could be added.
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 description coverage is 100%, with both parameters well-documented in the schema itself. The description adds minimal parameter semantics beyond the schema - it mentions 'memory dump' which relates to dump_path and 'Windows plugin' which relates to plugin, but doesn't provide additional context about parameter usage, constraints, or interactions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Run a Volatility 3 Windows plugin against a memory dump') and resources ('memory dump', 'Volatility 3 Windows plugin'). It distinguishes itself from sibling tools like 'volatility_linux' by specifying the Windows focus and from other security testing tools by describing memory analysis rather than network or web 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?
The description provides clear context for when to use this tool: for analyzing Windows memory dumps with Volatility 3. It mentions the prerequisite ('Requires vol3 (vol) on PATH') and distinguishes from 'volatility_linux' by specifying Windows. However, it doesn't explicitly state when NOT to use it or provide detailed alternatives beyond the sibling distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate context-appropriate XSS payloads with optional filter evasion. Returns a list of payloads tailored to the injection context and filter bypass requirements. Returns context, filter_bypass, payloads array, notes. Side effects: None. Pure payload generation, no network requests.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | Injection context: where the user input lands | |
| filter_bypass | No | Level of filter evasion needed | |
| callback_url | No | Attacker-controlled URL for data exfiltration payloads |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds value by stating 'Side effects: None. Pure payload generation, no network requests,' clarifying safety and operational scope. It also describes the return structure ('Returns context, filter_bypass, payloads array, notes'), which is helpful since there's no output schema. However, it doesn't cover aspects like rate limits or error handling.
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 highly concise and front-loaded, with three sentences that efficiently convey purpose, output, and behavioral traits. Each sentence earns its place by adding distinct value (payload generation, return details, side effects), with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is fairly complete. It covers purpose, output structure, and safety (no side effects), compensating for the lack of output schema. However, it could improve by mentioning error cases or example usage, slightly reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-documented in the schema (e.g., 'context' and 'filter_bypass' have enums and descriptions). The description adds minimal param semantics beyond the schema, only implying tailoring via 'context-appropriate' and 'filter bypass requirements.' Thus, it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate context-appropriate XSS payloads with optional filter evasion.' It specifies the verb ('Generate') and resource ('XSS payloads'), and distinguishes it from siblings by focusing on payload generation rather than testing (e.g., xss_reflected_test). However, it doesn't explicitly differentiate from all security tools in the sibling list, keeping it at 4 instead of 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?
The description implies usage through phrases like 'context-appropriate' and 'optional filter evasion,' suggesting it's for XSS testing scenarios. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., xss_reflected_test for testing reflected XSS) or prerequisites, leaving usage context somewhat inferred rather than clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test multiple reflected XSS vectors against a parameter. Sends 10 payloads (script tags, event handlers, SVG, attribute injection, case variation, template literals) and checks if they appear unescaped in the response. Returns results array with reflected/encoded/status per payload, and vulnerable_count. Side effects: Read-only GET requests. Sends 10 requests.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL with reflectable parameter, e.g. https://target/search?q=test | |
| parameter | Yes | Parameter name that reflects input, e.g. 'q' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels. It discloses key behavioral traits: sends 10 specific payload types, checks for unescaped reflection, returns detailed results array with vulnerable_count, and explicitly states side effects ('Read-only GET requests', 'Sends 10 requests'). This covers safety, scope, and operational 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 efficiently structured in three sentences: purpose, methodology, and side effects. Every sentence adds value—no fluff. It's front-loaded with the core function and maintains clarity throughout.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description does an excellent job covering behavior, side effects, and result structure. It mentions the return format ('results array with reflected/encoded/status per payload, and vulnerable_count'), which compensates for the missing output schema. The only minor gap is lack of explicit error handling or rate limit disclosure.
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%, providing clear documentation for both parameters. The description adds context by mentioning 'parameter' generically and implying it's reflectable, but doesn't provide additional semantic details beyond what the schema already states (e.g., examples or constraints). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: testing multiple reflected XSS vectors against a parameter. It specifies the action ('test', 'sends', 'checks'), the target ('reflected XSS vectors against a parameter'), and distinguishes from siblings by focusing on reflected XSS testing rather than payload generation (xss_payload_generate) or other security tests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you need to test for reflected XSS vulnerabilities in a specific parameter. It doesn't explicitly state when not to use it or name alternatives, but the specificity of 'reflected XSS' and 'parameter' provides clear guidance compared to other tools like sqli_test or ssrf_test.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0auth_bruteforceauth_cookie_tamperauth_csrf_extractclickjacking_testcloudtrail_analyzecloudtrail_find_anomaliescmdi_blind_detectcmdi_testcors_testcoupon_abuse_testdeserialization_testfile_upload_testframe_buster_bypassgraphql_find_hiddengraphql_introspectidor_testmaldoc_analyzemaldoc_extract_macrosmemory_detect_rootkitnosqli_auth_bypassnosqli_detectpath_traversal_testpcap_detect_scanpcap_dns_analysispcap_extract_credentialspcap_follow_streampcap_http_objectspcap_llmnr_ntlmpcap_overviewpcap_tls_analysisprice_manipulation_testrecon_directory_bruteforcerecon_dnsrecon_git_secretsrecon_quickrecon_s3_bucketrecon_tls_sansrecon_vhostrole_escalation_testsqli_blind_booleansqli_blind_timesqli_file_readsqli_login_bypasssqli_union_extractsqli_where_bypassssrf_cloud_metadatassrf_testvolatility_linuxvolatility_windowsxss_payload_generatexss_reflected_testMany tools have overlapping purposes that could cause confusion, such as multiple authentication testing tools (auth_bruteforce, auth_cookie_tamper, auth_csrf_extract), multiple SQL injection tools (sqli_blind_boolean, sqli_blind_time, sqli_union_extract, etc.), and multiple PCAP analysis tools (pcap_detect_scan, pcap_dns_analysis, pcap_extract_credentials, etc.). While descriptions provide some differentiation, the sheer number of similar tools makes it difficult for an agent to consistently choose the right one without deep domain knowledge.
Tool names follow a consistent snake_case pattern throughout, with clear verb_noun structures (e.g., auth_bruteforce, graphql_introspect, sqli_union_extract). There are minor deviations like 'maldoc_analyze' vs. 'maldoc_extract_macros' where 'extract' is used instead of 'analyze', but overall the naming is predictable and readable.
With 51 tools, the set is excessively large for a single server, making it overwhelming and difficult to navigate. While the domain (security testing) is broad, the tools could be better organized into subcategories or multiple servers. The high count suggests poor scoping, as many tools could be consolidated or split into logical groups.
The tool set provides comprehensive coverage for security testing, including reconnaissance, authentication testing, injection attacks, file analysis, and network traffic analysis. There are no obvious gaps; tools cover CRUD-like operations (e.g., test, detect, analyze, extract) across multiple security domains, ensuring agents can handle most security assessment workflows without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
MEOK MCP Hardening MCP — automated security red-team for any MCP server. Maps OWASP LLM Top 10
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/operantlabs/operant-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
