Loading ToolBench
An MCP server that acts as a bridge to a Cortex instance, exposing Cortex analyzer functionalities as tools.
The MCP Cortex server exposes 5 security analysis tools with partial implementation visibility. All tools have descriptions and parameter schemas are visible in the test file, but there are significant gaps in parameter descriptions, output schema documentation, and error handling guidance. Tool names follow verb_noun convention (analyze_*, scan_*) which is good, but the schemas lack detail on constraints, formats, and expected output structure. The server bridges to Cortex analyzers, so design is focused on delegation rather than composition of multiple tools.
Analyzes an IP address using AbuseIPDB via Cortex.
Analyzes a URL using the Urlscan.io analyzer via Cortex.
Analyzes data (IP, domain, FQDN, URL, or mail) using AbuseFinder via Cortex.
Scans a hash using VirusTotal_GetReport_3_1 via Cortex.
Scans a URL using VirusTotal_Scan_3_1 via Cortex.
Output schema is not documented. The cortex.rs code shows successful responses return {status: 'success', report: <report_response>}, but the MCP tool definitions do not specify the structure or fields of report_response. LLMs cannot plan downstream tool calls or extract expected data without knowing the output schema.
Parameter descriptions lack format and constraint details. 'analyzer_name' is described as 'Optional: The name of the X analyzer instance...' but does not document the exact naming convention (e.g., 'AbuseIPDB_1_0' vs 'abuseipdb_1.0'), valid patterns, or where to discover available analyzer names. 'max_retries' lacks min/max bounds (should be 1 - 100 or similar).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | 2024-11-05+ | v1 |
Error handling does not provide actionable recovery guidance. The cortex.rs code returns error messages like 'Could not find an analyzer instance named X' or 'Error getting analyzer ID', but does not tell the LLM what to do next. Should include: 'Available analyzers: [list]' or 'Call list_available_analyzers() to discover valid names'.
Tool descriptions do not state WHEN to use each tool instead of others. 'Analyzes an IP address using AbuseIPDB via Cortex', but what is AbuseIPDB for? When should an LLM choose this over analyze_with_abusefinder? Should state: 'Use this for IP-only abuse scoring. Use analyze_with_abusefinder for multi-type data (IP, domain, URL, mail).'
Missing prerequisite documentation. Tools require CORTEX_ENDPOINT and CORTEX_API_KEY environment variables, but the tool descriptions do not document this or what happens if they are missing. Should state: 'Requires CORTEX_ENDPOINT and CORTEX_API_KEY environment variables configured on the server.'
No validation or success criteria documented. What constitutes a successful analysis? Does a 'malicious' flag in the report mean the IP is blocklisted? Can the LLM infer action (block, alert, quarantine) from the report fields? Without explicit guidance, LLMs may misinterpret ambiguous report structures.
Parameter 'data_type' in analyze_with_abusefinder is constrained to enum ['ip', 'domain', 'fqdn', 'url', 'mail'], but the description does not enumerate these options explicitly for the LLM to parse. Should state: 'One of: ip, domain, fqdn, url, mail.'