ctscout

Reverse-lookup organization for one or more domains

ctscout_lookup_domain

Read-only

Reverse-look up one or more apex domains to identify the organization attributed to each. Returns cert-based ownership attribution and sibling domains from Certificate Transparency data.

Instructions

Reverse-lookup ctscout.dev's domain-attribution warehouse: given one or more apex domains, return the organization(s) attributed to each.

Args:

domains (string[], required): apex domains to look up. Each between 3 and 253 chars. Max 10 per call. Examples: ["gs.com"], ["coalition.com", "at-bay.com"].
response_format ('markdown' | 'json', default 'markdown'): output format.

Returns (on success, structuredContent follows the declared outputSchema — the same one as ctscout_search_company; a failed call is isError with no structuredContent):

In markdown: a snapshot line, then a table of (domain, attributed to, cert count, subdomain count). Only domains found in the warehouse appear; a missing domain means no attribution in this snapshot, not a negative finding.
In JSON: the same structure as ctscout_search_company, including "snapshot" / "snapshot_source". The 'domains' array contains one entry per attributed (domain, org) pair found. Reverse lookups never return semantic candidates.

Examples:

Use when: "Who is gs.com attributed to?" -> { domains: ["gs.com"] }
Use when: "Are coalition.com and at-bay.com attributed to the same parent?" -> { domains: ["coalition.com", "at-bay.com"] }
Don't use when: You have a company name and want to enumerate its domains — use ctscout_search_company instead.

Coverage caveat:

Returns 0 results if domain isn't in the warehouse. Either the domain is not in our index, or no OV/EV certs have been issued for it. DV-only domains (Let's Encrypt etc.) are typically not indexed.
When a domain IS in the warehouse but the attributed org is a subsidiary (e.g. an Allianz brand domain), the 'org' field shows the cert-subject organization which may differ from the brand on the homepage.

Auth & limits: same as ctscout_search_company.

Corrections:

Wrong attribution? Open an issue at https://github.com/minghsuy/ctscout-mcp/issues. Missing entity? Email pro@ctscout.dev. Include the domain queried, the result returned and why it is wrong.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domains`	Yes	Apex domains to look up (e.g. ['gs.com', 'goldmansachs.com']). Returns the organization(s) attributed to each domain, plus any sibling domains in the warehouse attributed to the same orgs. Max 10.
`response_format`	No	Output format: 'markdown' for human-readable summary, 'json' for the raw API response.	markdown

Output Schema

TableJSON Schema

Name	Required	Description
`total`	No	Matching pairs in the warehouse before any cap.
`source`	No	'warehouse' on /scan (both tiers); 'live-enriched' / 'cache-only' on a deep-dive result.
`domains`	Yes	Attributed (domain, organization) pairs. Empty when nothing is attributed.
`snapshot`	Yes	Warehouse/D1 sync date (YYYY-MM-DD) the answer was read from; the warehouse syncs daily. null when the API could not determine it.
`truncated`	No
`candidates`	No	Present only when match_type is 'semantic'. Candidates are not attributions.
`match_type`	No	'exact' = domains are warehouse attributions; 'semantic' = domains is empty and candidates holds name-similarity guesses; 'none' = nothing matched.
`empty_reason`	No
`upgrade_hint`	No
`snapshot_source`	Yes	'scan' = the API response carried the date; 'unavailable' = it did not, snapshot is null and must be treated as unknown, never as current.
`org_match_strategy`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.6.0Sep 8, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedInput schema / properties / domains / description

Previous value: -"Apex domains to look up (e.g. ['gs.com', 'goldmansachs.com']). Returns the organization(s) that own each domain, plus any sibling domains in the warehouse owned by the same orgs. Max 10."New value: +"Apex domains to look up (e.g. ['gs.com', 'goldmansachs.com']). Returns the organization(s) attributed to each domain, plus any sibling domains in the warehouse attributed to the same orgs. Max 10."

changedInput schema / properties / response_format / enum

Previous value: -[
-  "json",
-  "markdown"
-]New value: +[
+  "markdown",
+  "json"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "candidates": {
+      "description": "Present only when match_type is 'semantic'. Candidates are not attributions.",
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "org": {
+            "description": "Candidate organization name — a semantic match, NOT an attribution.",
+            "type": "string"
+          },
+          "similarity": {
+            "description": "Name-embedding similarity, 0..1.",
+            "type": "number"
+          },
+          "top_apex_domain": {
+            "description": "The apex domain most often attributed to this candidate, if any.",
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "org"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "domains": {
+      "description": "Attributed (domain, organization) pairs. Empty when nothing is attributed.",
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "apex_domain": {
+            "type": "string"
+          },
+          "attributed_to": {
+            "type": "string"
+          },
+          "cert_count": {
+            "description": "Distinct certificates observed for this pair.",
+            "type": "number"
+          },
+          "domain": {
+            "description": "Deep-dive row shape: the apex domain (no apex_domain field).",
+            "type": "string"
+          },
+          "first_seen": {
+            "description": "When the warehouse first ingested this pair (observation time, NOT the CT log SCT / issuance time).",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "last_seen": {
+            "description": "When the warehouse last ingested this pair (observation time, not SCT time).",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "org": {
+            "description": "Organization the domain is attributed to. Free tier: the OV/EV cert subject O field. On /scan, both tiers: the OV/EV certificate subject. Multi-signal attribution lives in a deep-dive job result (attributed_to + enrichment), not here.",
+            "type": "string"
+          },
+          "subdomain_count": {
+            "type": "number"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "empty_reason": {
+      "type": "string"
+    },
+    "match_type": {
+      "description": "'exact' = domains are warehouse attributions; 'semantic' = domains is empty and candidates holds name-similarity guesses; 'none' = nothing matched.",
+      "type": "string"
+    },
+    "org_match_strategy": {
+      "type": "string"
+    },
+    "snapshot": {
+      "description": "Warehouse/D1 sync date (YYYY-MM-DD) the answer was read from; the warehouse syncs daily. null when the API could not determine it.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "snapshot_source": {
+      "description": "'scan' = the API response carried the date; 'unavailable' = it did not, snapshot is null and must be treated as unknown, never as current.",
+      "enum": [
+        "scan",
+        "unavailable"
+      ],
+      "type": "string"
+    },
+    "source": {
+      "description": "'warehouse' on /scan (both tiers); 'live-enriched' / 'cache-only' on a deep-dive result.",
+      "type": "string"
+    },
+    "total": {
+      "description": "Matching pairs in the warehouse before any cap.",
+      "type": "number"
+    },
+    "truncated": {
+      "type": "boolean"
+    },
+    "upgrade_hint": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "domains",
+    "snapshot",
+    "snapshot_source"
+  ],
+  "type": "object"
+}

First observedv0.2.5May 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations provide readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds substantial context beyond these: the open-world semantics are elaborated ('a missing domain means no attribution in this snapshot, not a negative finding'), it discloses the DV-only certification coverage caveat, explains subsidiary vs. cert-subject org differences, and documents auth/limits plus a corrections channel for wrong attributions. This far exceeds what the annotations convey alone.

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

Conciseness4/5

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

The description is long but earns its length with clearly delimited sections (Args, Returns, Examples, Coverage caveat, Auth & limits, Corrections). The purpose statement is front-loaded and every section addresses a real agent need. Slight redundancy with the input schema's parameter descriptions and with sibling references could be trimmed, but structure is exemplary.

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?

For a tool with two response formats, an output schema, and significant open-world caveats, the description is exceptionally complete: it explains both markdown and json return shapes, references the shared output schema, enumerates coverage caveats (DV-only domains, subsidiary attribution), and points to the corrections process. Nothing an agent needs to call it correctly or interpret results 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% (both parameters described), so baseline is 3. The description adds meaningful value on top: explicit char-length constraints (3-253), max-10-per-call limit, concrete usage examples for both parameters, and clarification of what 'markdown' vs 'json' return. Only minor redundancy with the schema's own parameter descriptions prevents a 5.

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?

The description opens with a specific verb+resource ('Reverse-lookup ctscout.dev's domain-attribution warehouse') and states the exact input (apex domains) and output (attributed organizations). It differentiates from the sibling by explicitly declaring 'Reverse lookups never return semantic candidates' and pointing to ctscout_search_company as the forward direction. Purpose is 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.

Usage Guidelines5/5

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

Provides explicit 'Use when' and 'Don't use when' examples with concrete queries ('Who is gs.com attributed to?') and names the alternative tool (ctscout_search_company) for the opposite use case. The guidance is actionable and leaves no inference to the agent.

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

Deploy Server