Loading ToolBench
ADEO CTI MCP Server with Shodan and VirusTotal integration for threat intelligence and vulnerability research
The ADEO CTI MCP server provides 20 well-described tools across threat intelligence, vulnerability analysis, and malware detection domains. All tools have non-empty descriptions (194 chars average baseline met for most), and input parameters are documented with types. However, critical gaps emerge: (1) NO output schemas are documented, LLMs cannot predict what fields these tools return, making chaining difficult; (2) parameter constraints are loose, many accept free-form strings (queries, hashes) without format validation or enumeration guidance; (3) error handling is absent from descriptions, LLMs have no recovery path if a lookup fails; (4) naming inconsistencies exist (e.g., 'host-info' vs verb_noun convention). The server reaches 'fair' grade due to present descriptions and clear intent, but falls short of 'good' due to missing output documentation and weak constraint enforcement. This is a typical community-grade server.
Retrieve account information including membership status, available credits, and account creation date.
Get information about the current API status, plan details, scan credits, usage limits, and available features.
Search for CPE (Common Platform Enumeration) entries to identify software products and versions.
Set up continuous monitoring for new threats or vulnerabilities. Get notified when new systems matching your criteria appear. Essential for ongoing threat hunting operations.
Search for specific vulnerabilities by CVE ID. Provides detailed information about known vulnerabilities including severity, description, and remediation.
Remove a network alert from your Shodan account. This stops monitoring for the specified alert criteria.
Output schemas completely undocumented. No tool in the server declares what fields or structure it returns. LLMs cannot plan multi-tool workflows or extract specific data without guessing. This violates the pattern:tool requirement to document return types and breaks tool chaining (pattern:tool-chain).
Parameter constraints are loose or absent. Tools like 'search-host' accept 'query' as free-form string with no format guidance or example constraints. Tools like 'cve-lookup' accept 'cve' with no validation hint (should be CVE-YYYY-NNNNN format). Tools like 'host-info' and 'vt-file-analysis' accept hashes without specifying which hash types are valid (MD5, SHA-1, SHA-256). This violates pattern:constrained-input and causes LLM hallucination of invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Resolve domain names to their corresponding IP addresses, identifying hosting infrastructure and tracking domain infrastructure changes.
Provide comprehensive information about domains including subdomains, DNS records, and metadata. Essential for understanding the attack surface of a target.
Retrieve detailed information about a specific alert, including its configuration and current matches.
Retrieve comprehensive information about a specific IP address, including open ports, services, vulnerabilities, location data, and ownership information.
List all active network alerts configured for the Shodan account. Useful for managing and reviewing alert configurations.
Retrieve the IP address of the client making the request. Useful for verification and debugging.
Map IP addresses back to hostnames, useful for understanding the ownership and purpose of suspicious IPs and revealing patterns in attacker infrastructure.
Search for specific internet-connected devices, services, or vulnerabilities using Shodan query syntax. Perfect for finding patterns across multiple targets.
Get statistics about search results without the full details. Great for understanding the scale of a threat or exposure.
Understand how search queries are interpreted. Helps in refining and optimizing complex searches by breaking down query components.
Investigate domains for malicious associations. Understand historical reputation and threat intelligence. Critical for infrastructure analysis.
Analyze suspicious files for malware signatures. Get comprehensive reports from multiple antivirus engines. Essential for malware investigation.
Investigate IP addresses for malicious associations. View historical threat intelligence and reputation data. Critical for infrastructure analysis.
Check if URLs are associated with malicious activities. View detailed reports from multiple security engines. Perfect for validating suspicious links.
No error handling guidance in tool descriptions. If a DNS lookup fails, a CVE lookup returns no results, or an API rate limit is hit, the descriptions do not tell LLMs how to recover (retry, try alternative tool, ask user, etc.). This violates pattern:recovery-guide and pattern:error-classification, leaving agents unable to handle failures gracefully.
Naming convention inconsistency. Tools use hyphens (host-info, dns-lookup, reverse-dns) instead of underscores (host_info, dns_lookup, reverse_dns). While hyphens work, the standard verb_noun pattern (get_host_info, list_alerts) would be clearer for LLM intent parsing. The pattern 'search-host' also lacks clarity, is it searching hosts or searching within a host? Better: search_internet_hosts or search_shodan.
Destructive operations (delete-alert) lack confirmation/dry-run pattern. The delete-alert tool accepts only an alert ID with no preview, no confirmation step, and no undo mechanism. An LLM could accidentally delete critical monitoring alerts. This violates pattern:confirmation-request and pattern:idempotent-operation.
Resource and prompt capabilities are declared but implementation is incomplete. The 'resources' capability is enabled in server metadata, and a 'threat-hunting-guide' resource is partially defined in the source, but the resource handler contains incomplete markdown (cuts off mid-sentence). The 'prompts' capability is enabled but no prompt definitions are visible. This violates the principle of complete feature implementation.
Tools returning lists (list-alerts, search-host, search-host-count, cpe-lookup) do not document pagination parameters or result limits in their descriptions. The 'search-host' tool accepts a 'page' parameter but the description does not specify: what is the default page size? Is there a max limit? Does the tool return a total_count or next_cursor? This violates pattern:paginated-result and forces agents to guess.
No audit trail or logging framework visible. The source code shows no logging of tool calls, parameters, or results. For a security/CTI tool handling sensitive threat intelligence, this is a compliance gap. Pattern:audit-trail requires logging who called what, with which params, at what time, and what happened.