A comprehensive OSINT MCP server with proper structure, error handling, and ethical guardrails
OSINT MCP server has moderate definition quality with mixed execution. All 11 tools have descriptions and input schemas present, but descriptions are formulaic and vary widely in actionability. Parameter documentation is inconsistent, most lack depth about constraints and expected formats. No output schemas are documented, making it unclear what fields agents should extract from responses. Error handling is minimal, tools return generic errors without recovery guidance. The tool set is well-composed (each does one thing) but naming could be more descriptive (e.g., 'get_ip_info' is vague about what 'info' includes). Security-wise, the server accepts API keys as environment variables (good), but tool descriptions don't clarify permission requirements or destructive vs. read-only boundaries. Overall, this is a C-grade server, serviceable but requiring significant documentation and error-handling improvements.
Check IP reputation using threat intelligence databases (requires API key)
Check robots.txt for a URL and verify if it can be accessed
Check SSL/TLS certificate information for a domain
Perform DNS lookup for a domain. Supports various record types (A, AAAA, MX, NS, TXT, etc.)
Aggregates public OSINT data about a domain (passive only).
Extract basic metadata from a webpage (title, description, etc.). Respects robots.txt.
Get HTTP headers for a URL (uses HEAD request, minimal bandwidth)
No output schemas documented for any tool. LLMs cannot determine what fields to extract from responses, forcing them to parse responses as unstructured text and reducing accuracy.
'get_ip_info' and 'get_ip_reputation' are too similar in naming, both operate on IPs, both start with 'get_' and use 'ip_'. LLMs may conflate them. Rename to clarify: e.g., 'get_ip_geolocation' + 'check_ip_threat_score'.
Parameter descriptions lack depth. E.g., 'record_type' in dns_lookup does not specify what happens if an unsupported type is passed, or whether case-sensitivity matters. Descriptions should follow the format: 'One of: A, AAAA, MX, NS, TXT, CNAME, SOA (uppercase, case-sensitive).'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Get geolocation and network information for an IP address
Get mail exchange (MX) records for a domain
Get nameserver information for a domain
Perform reverse DNS lookup for an IP address to find associated hostnames
No error recovery guidance. Tool descriptions do not explain what the LLM should do if a lookup fails (e.g., 'Domain not found. Try search_dns_servers() or suggest user check domain spelling.').
'get_ip_info' is vague, does it return ASN, geolocation, reverse hostname, or all three? Description should specify: 'Returns geolocation (country, city, lat/lon), ISP, ASN, and hosting provider for an IP address.'
API key injection noted as '(requires API key)' in check_ip_reputation, but description does not clarify: which key? (VirusTotal, AbuseIPDB, etc.) Where does the agent source it from? How should it be configured?
No pagination documented for tools that may return large result sets (domain_recon with include_ct_logs). If results exceed context windows, tools should return truncated output with a next_cursor or total_count.
Tools operate on domains and IPs without validating format. If an LLM passes 'not-a-domain' or '999.999.999.999', tools should catch this early and return: 'Invalid IP: must be dotted-quad (e.g. 192.0.2.1) or IPv6 (e.g., 2001:db8::1).'