Skip to main content
Glama
robyroro

osint-mcp-server

by robyroro
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Domain recon

recon_domain
Read-onlyIdempotent

Passively gather domain intel in one call: WHOIS, DNS, email security, TLS, headers, subdomains, ASN/reverse DNS, Shodan, plus highlights.

Instructions

Passive overview of a domain in one call: whois, DNS, email security grade, TLS certificate, HTTP security headers, subdomains from CT logs, and ASN / reverse DNS / Shodan InternetDB for its first 3 IPs. Ends with a 'highlights' list of things worth a look.

Start here for general questions about a domain. Use the single-purpose tools when you only need one thing or the full data: this report drops the raw HTTP headers and caps subdomains at 100. Takes 10-60s, mostly waiting on crt.sh. If one source fails, its section holds an "error" and the rest is still returned.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesDomain name, e.g. "example.com". A full URL works too, only the hostname is used.
include_activeNoAlso connect to the site for HTTP headers, TLS and the MTA-STS policy. Set false to use public APIs and DNS only.
include_subdomainsNoLook up subdomains in certificate transparency logs (crt.sh). It's the slowest part, set false for a run that takes seconds instead of up to a minute.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / include_active
      Added value: +{
+  "default": true,
+  "description": "Also connect to the site for HTTP headers, TLS and the MTA-STS policy. Set false to use public APIs and DNS only.",
+  "title": "Include Active",
+  "type": "boolean"
+}
  2. Changed2 schema fields changedv0.2.2
    • addedInput schema / properties / domain / description
      Added value: +"Domain name, e.g. \"example.com\". A full URL works too, only the hostname is used."
    • addedInput schema / properties / include_subdomains / description
      Added value: +"Look up subdomains in certificate transparency logs (crt.sh). It's the slowest part, set false for a run that takes seconds instead of up to a minute."
  3. First observedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description layers on behavior the annotations cannot express: latency (10-60s, mostly crt.sh), graceful partial failure ('if one source fails, its section holds an "error" and the rest is still returned'), and output caps (subdomains at 100, raw headers dropped). This is meaningful context beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the enumeration of what the report contains, followed by routing guidance and then operational caveats. Three tight paragraphs, each sentence earning its place with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-shape burden and does so: it names the sections returned, the trailing 'highlights' list, and the per-section error handling. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema documents all three parameters, establishing a baseline of 3. The description adds genuine meaning that maps to parameters: the subdomain cap of 100 (relevant to include_subdomains) and the omission of raw HTTP headers (relevant to include_active), plus the runtime implication of each. It stops short of syntax details, but adds real value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Passive overview of a domain in one call') and then enumerates exactly which data sources it aggregates (whois, DNS, email security, TLS, HTTP headers, subdomains, ASN/reverse DNS/Shodan). An agent can distinguish it from domain_whois, dns_lookup, tls_certificate, etc. without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Start here for general questions about a domain' and names the alternative condition: 'Use the single-purpose tools when you only need one thing or the full data.' It further sharpens the trade-off by noting this report drops raw HTTP headers and caps subdomains at 100, so the when/when-not decision is fully specified.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools