Domain Intelligence

rsiddiq95/domain-intelligence

rsiddiq95--domain-intelligence

Destructive

This tool calls the Actor "rsiddiq95/domain-intelligence" and retrieves its output results. Actor description: Domain age, registrar and expiry (RDAP/WHOIS), DNS, email provider and SPF/DMARC, first and last Wayback Machine capture, website status and SSL certificate, for any list of domains.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domains": "<domains>"
    },
    "name": "rsiddiq95--domain-intelligence"
  }
}

Input Schema

Name	Required	Description
`domains`	Yes	REQUIRED Domains to check, one per line. You can paste website URLs (https://www.example.com/page) or email addresses (name@example.com) too; each is reduced to its domain and duplicates are checked once. Example values: ["stripe.com","apify.com"]
`waitSecs`	No	Max seconds (0–45, default 30) to cap the wait for the Actor run to reach terminal state. For long-running Actors the response returns at the cap with the current run status; follow `nextStep` to poll via get-actor-run. Set to 0 to fire-and-forget.
`includeDns`	No	IP addresses, name servers, MX hosts, email provider, SPF and DMARC policy. Example values: true
`includeWayback`	No	First and most recent capture of the site in the Internet Archive. Turn off for faster runs on long lists. Example values: true
`includeWebsite`	No	HTTP status, final URL after redirects, page title and description, and the SSL certificate issuer and expiry. Example values: true
`maxConcurrency`	No	How many domains to check at the same time. Example values: 5

Output Schema

Name	Required	Description
`tip`	No	Advisory guidance RAG Web Browser wrote to its key-value store under the reserved "TIP" key
`runId`	Yes	Actor run ID
`stats`	No	Run statistics
`status`	Yes	Run status: READY \| RUNNING \| TIMING-OUT \| TIMED-OUT \| ABORTING \| ABORTED \| SUCCEEDED \| FAILED
`actorId`	Yes	Stable Apify Actor ID from the run record
`summary`	Yes	Past-tense summary of the run state
`exitCode`	No	Actor process exit code; populated for terminal states (especially FAILED)
`nextStep`	Yes	One primary follow-up action with identifiers interpolated
`storages`	Yes	Dataset and key-value store metadata, keyed by alias. "default" is always the primary entry.
`actorName`	No	"username/actor-name"
`startedAt`	No	ISO timestamp when the run started
`finishedAt`	No	ISO timestamp when the run finished (terminal states only)
`statusMessage`	No	Pass-through from Apify run.statusMessage
`apifyConsoleUrl`	No	Personalized Apify Console link to the run; present only for Console sessions

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026
- changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / server / type
```
Previous value: -[
-  "string",
-  "null"
-]New value: +[
+  "null",
+  "string"
+]
```
Changed1 schema field changedNov 10, 2026
- changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / server / type
```
Previous value: -[
-  "null",
-  "string"
-]New value: +[
+  "string",
+  "null"
+]
```
First observedNov 10, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, openWorldHint=true and destructiveHint=true, so the description is not required to establish the mutation/external-effect profile. It does add that results are retrieved from an Actor run, but it says nothing about credit consumption, run duration, or that a capped wait can return an incomplete run — context that matters given destructiveHint=true. No contradiction with annotations, but value beyond them is thin.

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?

Two sentences, no filler, and the substantive capability list follows immediately after the wrapper. The generic first clause ("calls the Actor ... and retrieves its output results") is near-boilerplate but short enough not to hurt scanning.

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

Completeness3/5

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

An output schema exists and the input schema is fully documented, so the description needn't explain return shapes or parameters. However, for a tool annotated destructive with a time-capped wait, the description omits cost, runtime expectations and the fact that results may be partial — gaps an agent would otherwise have to discover from the schema alone.

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

Parameters3/5

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

Schema description coverage is 100%, with every parameter (domains, waitSecs, includeDns, includeWayback, includeWebsite, maxConcurrency) documented in detail including defaults, bounds and semantics. The description adds no parameter-level meaning beyond that, so baseline 3 applies.

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

Purpose4/5

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

The description names a concrete resource and enumerates exactly what is collected: domain age/registrar/expiry via RDAP/WHOIS, DNS, email provider and SPF/DMARC, Wayback captures, website status and SSL certificate, for a list of domains. This makes the tool's output distinguishable from siblings like get-dataset-items. The wrapper sentence ("calls the Actor ... and retrieves its output results") is generic, but the actor description carries the specificity.

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

Usage Guidelines3/5

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

"For any list of domains" implies the batch-lookup use case, but there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as get-actor-run for polling long runs. The waitSecs and include* tradeoffs are documented only in the schema, not in the description. Usage is inferable but not stated.

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

All Domain Intelligence tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.