Custom domains API for SaaS: connect, verify, and manage customer domains, SSL, and DNS
Scored across 18 tools
Several tools overlap in the data they return: domain_age_checker and whois_lookup both report registration/expiration dates; txt_record_lookup overlaps with the SPF/DKIM/DMARC checkers; and website_status_checker, http_header_checker, redirect_checker and ssl_check all fetch URLs/TLS and report partially redundant information. Descriptions help clarify boundaries, but misselection is plausible for an agent looking for a quick site or record check.
All tools use snake_case with a consistent 'tools_' prefix, and most follow a noun_action pattern (e.g. tools_dns_record_lookup, tools_ssl_check). Minor deviation: tools_ssl_check uses 'check' while similar tools use 'checker', but the overall convention is highly predictable.
18 tools is on the high side but justified by the breadth of the domain (DNS, email auth, TLS, HTTP, WHOIS, availability). Each tool covers a distinct diagnostic category, so the set does not feel bloated or redundant.
The surface covers core domain diagnostics thoroughly: DNS lookups, propagation, provider identification, email authentication records, SSL/TLS, HTTP headers/redirects, WHOIS, subdomain enumeration, reverse DNS, and Domain Connect. Missing DNSSEC validation and blocklist/reputation checks are minor gaps for a diagnostic suite.
Free public API. Resolve a hostname's CNAME chain. Useful for debugging custom-domain CNAME setups.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | Hostname to resolve, e.g. www.example.com. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds context the annotations cannot: it is a "Free public API," implying no credentials and potentially rate-limited public access. It says nothing about response shape, but the output schema handles that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, no wasted clauses, with the operation stated first and the access/nature context up front. The final debugging sentence borders on filler but does carry routing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only lookup with an output schema available, the description covers what the tool does, its access model, and its typical use case. Only the absence of sibling routing keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single parameter at 100% schema description coverage, the schema already documents the hostname input and its format. The description only echoes "hostname" without adding syntax, chain-depth semantics, or failure behavior, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Resolve a hostname's CNAME chain" gives a specific verb plus a precise resource, and the CNAME focus does separate it from generic siblings like tools_dns_record_lookup or tools_txt_record_lookup. It stops short of naming any sibling explicitly, so an agent must still infer which DNS tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Useful for debugging custom-domain CNAME setups" implies a usage context but offers no when-not guidance and never mentions the overlapping alternatives (dns_record_lookup, dns_propagation_checker) that an agent would weigh against it. Usage is suggested rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. Look up the DKIM record at ._domainkey., parse the public key, flag issues.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check DKIM for. | |
| selector | Yes | DKIM selector — `google`, `k1`, `mxvault`, `s1`, etc. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds modest behavioral context beyond that: it is a free public API (implies no auth) and it parses the public key and flags issues, hinting at the kind of analysis returned. It stops short of richer detail like rate limits or what categories of issues are flagged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three terse clauses with zero padding, and the core verb is front-loaded. 'Free public API' is a brief preamble that still earns its place by signaling no authentication is needed. Nothing is wasted, but there is no structural ordering beyond a single run-on sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, read-only lookup tool with an output schema present and annotations covering the safety profile, the description supplies everything needed to invoke it correctly: the resource, the DNS-name construction, and the fact that it returns issue flags. The only gaps — precise issue categories and error behavior — are plausibly covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3, but the description genuinely adds meaning by showing how the two parameters compose into the DNS lookup name ('<selector>._domainkey.<domain>'), clarifying the selector/domain relationship the schema states only separately. It does not add format or syntax rules beyond that construction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('look up the DKIM record') and even gives the exact DNS name it queries ('<selector>._domainkey.<domain>'), plus the follow-on actions ('parse the public key, flag issues'). It does not explicitly differentiate itself from the DKIM-adjacent siblings like tools_dmarc_record_checker or tools_spf_record_checker, which keeps it just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose — an agent can infer this is the tool for checking a specific domain's DKIM record — but there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as the DMARC/SPF checkers or the generic tools_txt_record_lookup. No prerequisites or exclusion conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. Look up the DMARC record at _dmarc., parse policy/alignment/reporting tags, flag missing or too-permissive settings.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check DMARC for. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety bar is low. The description still adds real value: it discloses that this is a free public API requiring no auth, that it performs an external DNS lookup at _dmarc.<domain>, and that it evaluates tags and flags risky configurations rather than just returning raw records.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, and the core action is front-loaded after a short access note. Every clause earns its place by adding scope (DNS location) or behavior (parsing and flagging).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and annotations cover the safety profile. The description covers what is queried and what is evaluated; the only minor gap is the lack of guidance on error cases such as a domain with no DMARC record.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is a single parameter, so the schema already carries the load. The description adds one useful nuance — that the domain is looked up at the _dmarc.<domain> prefix, implying the caller passes the bare domain — but no format or edge-case guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Look up the DMARC record'), names the exact DNS location ('_dmarc.<domain>'), and enumerates the work done (parse policy/alignment/reporting tags, flag missing or permissive settings). This clearly separates it from sibling email-auth tools like tools_spf_record_checker and tools_dkim_record_checker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the domain-name checker naming convention and the note that it is a 'Free public API'; there is no explicit when-to-use statement, no mention of choosing it over the SPF/DKIM checkers, and no prerequisites or exclusions. Adequate but clearly gapped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. Query the same hostname across ~10 public DNS resolvers worldwide and report which ones return the same answer. Useful right after a DNS change.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | Hostname to check. | |
| type | No | Record type. Default: A. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: it is a free public API, it fans out to roughly ten resolvers, and the result is a consensus comparison rather than a single answer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler: mechanism first, output second, use case last. Every sentence earns its place and the load-bearing detail is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only query with a full output schema, the description covers mechanism, scope and purpose adequately, so return values need no explanation. It leaves minor gaps such as resolver locations or any rate limits implied by 'free public API', but nothing an agent needs to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters (host, type with enum) are documented in the schema, so the baseline is 3. The description adds nothing about the host or record-type parameters beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Query the same hostname across ~10 public DNS resolvers worldwide') plus the distinctive output ('report which ones return the same answer'). The multi-resolver scope implicitly distinguishes it from the single-lookup sibling tools_dns_record_lookup, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Useful right after a DNS change' gives a clear triggering context, which is more than most. However, it names no alternative (e.g. the single-resolver tools_dns_record_lookup or tools_cname_lookup) and states no when-not condition, leaving the agent to infer that this is the multi-resolver variant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. Identify which DNS provider actually serves a domain, fingerprinted from its public NS records. Returns the record name written the way that provider's form expects it (providers disagree about whether the apex is '@', blank, or the full domain, and getting it wrong is the most common way a correct record lands in the wrong place), whether the provider can point a zone apex at a hostname, where its record editor lives, and the provider-specific settings that silently break custom domain setups. Use this before telling someone what DNS record to add. No Bearer required.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain or hostname. Subdomains are walked up to the zone holding the NS records. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds meaningful context beyond that: the returned data's real-world significance (apex notation differences, apex-to-hostname support, editor location, provider-specific gotchas) plus a concrete auth note, 'No Bearer required.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose and the key use instruction, and most sentences carry real information. The long parenthetical about apex notation is slightly run-on and could be tightened, but it is not padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, single-purpose lookup with an output schema present, this covers everything needed: what it identifies, how, when to reach for it, and auth expectations. No critical gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema coverage is 100%, so the schema already documents 'domain' including the subdomain walk-up behavior. The description adds no format or syntax guidance for the parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Identify) and resource (which DNS provider serves a domain), including the mechanism (fingerprinted from public NS records). This is clearly distinguishable from siblings like tools_dns_record_lookup or tools_cname_lookup, which resolve records rather than attribute them to a provider.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete usage trigger: 'Use this before telling someone what DNS record to add.' That is a real contextual instruction. However, it never names or contrasts an alternative sibling for the case where the user just wants record values, so it stops short of explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. Look up DNS records (A, AAAA, CNAME, MX, TXT, NS, SOA) for any domain.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Restrict to one record type. Default: all common types. | |
| domain | Yes | Domain to query, e.g. example.com. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description's only added behavioral detail is that the API is free and public, which implies no auth is required but says nothing about rate limits or behavior on nonexistent domains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler, leading with the operation and its scope. Nothing is wasted or buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and annotations carry the safety profile, so the description need not explain return values or side effects. It is adequate for a simple read-only lookup, though it leaves the sibling-selection question unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the 'type' parameter even has an enum, so the schema fully documents both inputs. The description's type list in parentheses merely echoes the enum values rather than adding format or semantic detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('look up') and resource ('DNS records') and enumerates the record types covered, so the scope is unambiguous. However, it does not distinguish itself from siblings like tools_cname_lookup, tools_txt_record_lookup, or tools_spf_record_checker, which overlap in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the numerous specialized siblings; the description only notes it is a 'Free public API.' An agent must guess whether this general lookup or a targeted sibling (e.g. tools_txt_record_lookup) is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. Returns a domain's registration date, age in days + years, last-updated date, and expiration.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds 'Free public API,' which implies no cost and likely no authentication, but omits rate limits, auth specifics, and error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the free/public nature and then the returned data. No filler or repetition beyond the brief return list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With rich annotations, a full output schema, and a single well-described parameter, the description is nearly sufficient for invocation. It still leaves a gap in selection guidance against whois_lookup, but the core operational picture is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single domain parameter is documented there as 'Domain to check.' The description does not add syntax or format details beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (a domain) and the specific outputs (registration date, age in days/years, last-updated date, expiration), so the agent knows exactly what this tool returns. It does not, however, explicitly differentiate from the sibling whois_lookup, which likely overlaps on registration data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, prerequisites, or alternatives are given. It does not say to prefer this over whois_lookup for age checks or when it is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. Check availability of a name across one or more TLDs. Pass a name (no TLD) and an optional tlds array.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Bare name without TLD, e.g. `mybrand`. | |
| tlds | No | Optional list of TLDs to check, e.g. ['com', 'io', 'dev']. Default: a standard SaaS set. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context - 'Free public API' implies no auth/credential setup - and notes the default TLD set behavior, but says nothing about rate limits or what an unavailable-vs-invalid result looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with zero waste; the 'Free public API' fact is front-loaded and each sentence carries a distinct piece of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation. For a simple two-parameter read tool with full annotation coverage, the description is essentially complete, missing only explicit sibling routing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already fully documented in the schema, including the 'no TLD' constraint and the default TLD set. The description restates this without adding new syntax or format detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Check availability of a name across one or more TLDs.' That clearly distinguishes it from siblings like whois_lookup or domain_age_checker, though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no exclusions, and no reference to sibling tools. Usage is only implied by the tool's stated function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. Check whether a domain's DNS provider implements the Domain Connect protocol, read live from the _domainconnect TXT record and the provider's settings endpoint. Reports the provider and whether it offers the synchronous flow (a signed redirect with no token exchanged, the one that works in practice) or only the asynchronous OAuth flow. Note that provider support is necessary but not sufficient for one-click setup: the service being connected must also have a template the provider has synced and enabled, which many providers do only after a per-service onboarding. No Bearer required.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. example.com. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: declares it is a free public API, that it reads live data from two specific endpoints, that no Bearer token is required, and it distinguishes the synchronous flow from the asynchronous OAuth flow and explains why that distinction matters in practice. This is meaningful behavioral context that readOnlyHint/idempotentHint alone could not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences with the key facts (free, public, no auth) front-loaded and no filler. Slightly longer than strictly necessary, but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described; the description instead covers the source of truth, the auth model, and the caveat about template sync. For a one-parameter read-only checker, nothing an agent needs is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'domain' parameter is self-evident with an example in the schema. The description adds no syntax or format detail about the parameter, so it does not exceed the baseline for a fully documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: checks whether a domain's DNS provider implements the Domain Connect protocol. It also names the data sources (_domainconnect TXT record and provider settings endpoint), which cleanly distinguishes it from siblings like tools_dns_provider_lookup and tools_txt_record_lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the context in which the result matters — whether one-click setup is feasible — and explicitly warns that provider support is necessary but not sufficient. It does not name an alternative sibling tool to use instead, but the decision criteria are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. Fetch a URL and return its response headers + security grade based on common security headers.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL with scheme, e.g. https://example.com. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds only 'Free public API', which hints at public availability but says nothing about rate limits, auth, or redirect/timeout behavior for a network fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no padding. The purpose clause is front-loaded enough, though leading with 'Free public API' precedes the more decision-relevant capability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and a single fully documented parameter is sufficient input detail. Only the missing sibling routing keeps it from being complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter with 100% schema description coverage ('Full URL with scheme, e.g. https://example.com'), so the schema already does the work. The description adds no format, protocol, or validation detail beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Fetch) and resource (URL), plus what it returns: response headers and a security grade derived from common security headers. That output shape distinguishes it from generic siblings like tools_website_status_checker, though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many overlapping siblings (status checker, redirect checker, SSL check). An agent must infer the use case purely from the output description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. Follow a URL's redirect chain and return every hop with status code, response time, final destination.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Starting URL. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds the useful 'free public API' note, implying no auth and possible rate limits, but does not state whether the chain is truncated on loops, a max-hop limit, or how failures are surfaced. Given the lower bar set by annotations, this is adequate but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no filler; the API-availability note leads and the purpose follows. Slight reordering could front-load the action verb, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single required parameter, an output schema, and rich annotations, the description covers what the tool does and roughly what it returns. The remaining gap is redirect-specific edge behavior (loop handling, hop limits), which matters for a chain-following tool but is arguably a schema/output concern.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter exists with 100% schema description coverage ('Starting URL.'), so the schema carries the semantics. The description adds nothing about URL format expectations, trailing slash behavior, or whether non-HTTP schemes are accepted, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('follow a URL's redirect chain') and enumerates the return contents (status code, response time, final destination), which clearly separates it from lookup-oriented siblings like tools_dns_record_lookup or tools_whois_lookup. It does not name or contrast itself against the closest neighbor, tools_website_status_checker, so an agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool rather than a sibling, no prerequisites, and no exclusions. 'Free public API' hints at accessibility but says nothing about selection between this and tools_website_status_checker or tools_domain_connect_checker, so usage must be inferred from the purpose sentence alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. Reverse-DNS (PTR) lookup for an IP address. Returns one or more hostnames if configured.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IPv4 or IPv6 address, e.g. 8.8.8.8. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description still adds value by flagging it as a free public API and warning that hostnames are returned only 'if configured,' which telegraphs a possible empty result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core purpose and followed by the return contract. No padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no further explanation, and the description covers the essential scope. The only minor gap is the absence of any when-to-use framing against the many sibling DNS tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter and schema description coverage is 100%, with the schema already specifying IPv4/IPv6 and giving an example. The description adds no format or syntax detail beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — a reverse-DNS (PTR) lookup keyed on an IP address — and explicitly notes it returns hostnames. This cleanly separates it from the forward-DNS siblings (cname_lookup, dns_record_lookup, txt_record_lookup) without needing their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (resolve an IP back to hostnames) but never states when to reach for this versus dns_record_lookup or cname_lookup, nor any conditions or exclusions. The 'Free public API' note gives context but not selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. Look up and validate the SPF record for a domain. Counts void/total DNS lookups, flags syntax issues, validates against RFC 7208's 10-lookup limit.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check SPF for. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description still adds real value by disclosing what the validation actually computes: void vs. total DNS lookup counts, syntax issue flags, and enforcement of RFC 7208's 10-lookup limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no redundancy, and the validation criteria are listed compactly. Leading with the 'Free public API.' fragment is slightly awkward since it delays the purpose statement, but it is brief enough not to hurt.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only lookup with an output schema that documents the return shape and rich annotations covering the safety profile, the description supplies everything needed to invoke it correctly. Only the accepted domain format is left unstated, which is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage ('Domain to check SPF for'), which sets the baseline at 3. The description adds no syntax guidance such as whether a bare domain, subdomain, or full email address is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('look up and validate') and resource ('the SPF record for a domain'), and the SPF resource type inherently separates it from the DKIM, DMARC, and generic TXT siblings. It never explicitly names or excludes those alternatives, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose: use it when you need to validate a domain's SPF configuration, and the 'Free public API' note hints at unrestricted experimentation. However, there is no statement of when to prefer this over tools_txt_record_lookup or tools_dmarc_record_checker, and no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. Check the TLS certificate of any public hostname. Returns issuer, subject, validity dates, days until expiry, full chain, cipher, protocol, and SAN list. No Bearer required.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | Hostname to check. Optionally with port, e.g. example.com:443. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond them: it is a free public API requiring no Bearer auth, which an agent needs in order to invoke it without configuring credentials. It stops short of noting rate limits or failure behavior for unreachable/invalid hosts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: capability, return contents, and auth requirement, with the core verb front-loaded. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the enumerated return fields (issuer, chain, cipher, SAN list) are somewhat redundant, but nothing an agent needs to call the tool correctly is missing — the auth-free access and public-host constraint are both stated. Minor gap: no mention of behavior for non-TLS or unreachable hosts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema itself documents the optional port syntax (example.com:443), so the baseline is 3. The description contributes only the 'public hostname' constraint, which is a mild addition over the schema but no format or edge-case detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Check the TLS certificate of any public hostname') and immediately scopes it to public hostnames, which cleanly separates it from DNS-record siblings like tools_dns_record_lookup or tools_cname_lookup. An agent can select it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource type (TLS certificate inspection) and the 'public hostname' scoping, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many DNS/domain siblings. The auth note ('No Bearer required') is operational context rather than routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. Enumerate subdomains for a target domain via Certificate Transparency logs + DNS resolution.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Apex domain to enumerate. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds real context beyond that: it is a free public API requiring no credentials, and it discloses the two data sources, which hints at coverage characteristics (only certificate-backed subdomains appear via CT). It stops short of noting rate limits or CT-log coverage gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler, and the core action leads. The opening 'Free public API' is a minor detour from the primary purpose, but it is brief and useful framing rather than waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not required, and annotations cover the safety profile for this read-only enumerator. What remains missing are coverage caveats (CT logs miss subdomains without certificates) and any sense of result volume, but the description is otherwise sufficient to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is a single required parameter, so the baseline is 3. The description's phrase 'target domain' loosely matches the schema's 'Apex domain to enumerate' but adds no syntax, format, or validation detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Enumerate subdomains for a target domain') and names the exact mechanism (Certificate Transparency logs + DNS resolution), which cleanly separates it from siblings like dns_record_lookup or reverse_ip_lookup. An agent can identify this tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus alternatives such as dns_record_lookup or whois_lookup, nor any preconditions, exclusions, or expected inputs. The description describes the technique, not the situation that should trigger the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. Fetch all TXT records on a domain, classifying each as SPF, DKIM, DMARC, BIMI, verification token, or general.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to fetch TXT records for. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact ('Free public API' implies no auth needed), but says nothing about rate limits, caching, or failure behavior on NXDOMAIN/no-records.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core action front-loaded and no redundancy. 'Free public API' is marginally promotional but still carries actionable information (no key required).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema and rich annotations, the description covers what it does and what it returns well enough to invoke correctly. Only edge-case behavior and comparison with the dedicated SPF/DKIM/DMARC checkers is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter with 100% schema description coverage, so the schema already defines 'domain'. The description adds no format guidance (apex vs subdomain, wildcard, IDN) beyond what the schema provides — the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch all TXT records on a domain') plus the classification it performs. The scope word 'all' implicitly separates it from the single-purpose siblings (spf_record_checker, dmarc_record_checker, dkim_record_checker), but no sibling is named, so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description never says when to use this tool versus the many per-record checkers in the sibling list, nor does it state prerequisites or exclusions. 'Free public API' is context about cost/auth, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. Check if a website is up or down. Returns HTTP status, response time, final URL after redirects, basic SSL info.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to check (include scheme). |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that redirects are followed ('final URL after redirects') and that the API is free/public, but says nothing about rate limits, timeouts, or what threshold counts as 'down'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, the core capability is front-loaded, and no sentence is filler. The 'Free public API' note earns its place as a cost/auth signal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with an output schema, most of what an agent needs is present. The gap is the absence of any definition of a 'down' result or timeout behavior, which matters for interpreting the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, and schema coverage is 100% with an in-schema note to include the scheme. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Check if a website is up or down') and enumerates the return fields. It does not, however, distinguish itself from overlapping siblings like tools_domain_connect_checker, tools_redirect_checker, or tools_ssl_check, all of which touch the same signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance and never names an alternative tool. With 17 network/DNS siblings, an agent gets no help deciding between this and the connect, redirect, or SSL checkers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free public API. WHOIS / RDAP lookup for a domain — registrar, status, created/updated/expires dates, nameservers.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to look up. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds one genuinely new behavioral fact — 'Free public API', implying no authentication or quota credential is needed — but says nothing about rate limits, behavior for non-existent or privacy-shielded domains, or latency of an external call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the access model then the verb and resource, with the returned field list carrying real information. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists and annotations are rich, so return values and safety need no restating. For a single-param external lookup the description is nearly sufficient; only edge-case behavior (invalid/nonexistent domain, rate limiting) is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single required parameter at 100% schema description coverage, the schema itself fully documents 'domain'. The description only restates the resource ('for a domain') and adds no format hints (TLD handling, IDN, subdomain acceptance), so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (lookup) and resource (WHOIS/RDAP record for a domain) and enumerates the returned data categories (registrar, status, dates, nameservers). This differentiates it cleanly from siblings like tools_dns_record_lookup, tools_domain_availability_checker, and tools_domain_age_checker without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no exclusions, and no mention of alternatives among the 17 sibling domain/DNS tools. The agent must infer that this is for registration metadata versus DNS resolution or availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
tools_cname_lookup1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "The hostname's CNAME target and what it resolves to.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "aRecords": {
+ "description": "A records of the target.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "cnames": {
+ "description": "CNAME answers; empty if the host has no CNAME.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "host": {
+ "type": "string"
+ },
+ "isApex": {
+ "type": "boolean"
+ },
+ "target": {
+ "description": "First CNAME target, or null.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "host",
+ "isApex",
+ "cnames",
+ "aRecords"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_dkim_record_checker1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "The DKIM record at the selector, parsed and validated.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "issues": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "level": {
+ "description": "error | warning | info.",
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "level",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "present": {
+ "type": "boolean"
+ },
+ "qname": {
+ "description": "Name queried: <selector>._domainkey.<domain>.",
+ "type": "string"
+ },
+ "record": {
+ "type": "string"
+ },
+ "selector": {
+ "type": "string"
+ },
+ "tags": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "domain",
+ "selector",
+ "qname",
+ "present",
+ "issues"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_dmarc_record_checker1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "The domain's DMARC record, parsed and validated.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "issues": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "level": {
+ "description": "error | warning | info.",
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "level",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "present": {
+ "type": "boolean"
+ },
+ "record": {
+ "type": "string"
+ },
+ "tags": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "description": "Parsed tags, e.g. {p: 'reject', rua: 'mailto:...'}.",
+ "type": "object"
+ }
+ },
+ "required": [
+ "domain",
+ "present",
+ "issues"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_dns_propagation_checker1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "Answers from several public resolvers and whether they agree.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "consistent": {
+ "description": "true when every resolver that answered returned the same set.",
+ "type": "boolean"
+ },
+ "domain": {
+ "type": "string"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "answers": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "error": {
+ "type": "string"
+ },
+ "location": {
+ "type": "string"
+ },
+ "ok": {
+ "description": "false = resolver query failed (see error).",
+ "type": "boolean"
+ },
+ "resolver": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "resolver",
+ "location",
+ "ok"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "domain",
+ "type",
+ "consistent",
+ "results"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_dns_provider_lookup1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "The DNS provider serving the domain and how to write records there.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "apex": {
+ "description": "true for a root domain.",
+ "type": "boolean"
+ },
+ "detected": {
+ "description": "false = provider not recognised from its nameservers.",
+ "type": "boolean"
+ },
+ "host": {
+ "type": "string"
+ },
+ "knownProviderCount": {
+ "type": "number"
+ },
+ "nameservers": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "provider": {
+ "additionalProperties": true,
+ "properties": {
+ "apexSupport": {
+ "description": "'alias' = can point the apex at a hostname (ALIAS/ANAME/flattening); 'none' = apex needs A records.",
+ "type": "string"
+ },
+ "dashboardUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "quirks": {
+ "description": "Provider-specific settings that silently break custom domain setups.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "recordEditorPath": {
+ "description": "Where the DNS record editor lives in the provider's UI.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "recordName": {
+ "description": "What to type in this provider's record name/host field for this hostname.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "recordName",
+ "apexSupport",
+ "quirks"
+ ],
+ "type": "object"
+ },
+ "zone": {
+ "description": "Zone that holds the NS records.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "host",
+ "apex",
+ "nameservers",
+ "detected",
+ "provider"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_dns_record_lookup1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "DNS records for the domain, keyed by type.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "records": {
+ "additionalProperties": {},
+ "description": "Map of record type (A, AAAA, CNAME, MX, TXT, NS, SOA) to an array of answers ([] if none; MX entries are {exchange, priority}, SOA is one object), or {error} if that lookup failed.",
+ "type": "object"
+ }
+ },
+ "required": [
+ "domain",
+ "records"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_domain_age_checker1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "Registration date and age of the domain.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "ageDays": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "ageYears": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "created": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "domain": {
+ "type": "string"
+ },
+ "expires": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "domain",
+ "ageDays",
+ "ageYears"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_domain_availability_checker1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "Availability of the name per TLD.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "available": {
+ "description": "true = appears unregistered, false = registered, null = could not tell.",
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "fqdn": {
+ "type": "string"
+ },
+ "method": {
+ "description": "rdap | dns | null.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "registrarHint": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "tld": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tld",
+ "fqdn",
+ "available",
+ "method"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "results"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_domain_connect_checker1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "Whether the domain's DNS provider implements Domain Connect.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "discoveryHost": {
+ "description": "Host from the _domainconnect TXT record.",
+ "type": "string"
+ },
+ "dnsProvider": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "domain": {
+ "type": "string"
+ },
+ "explanation": {
+ "type": "string"
+ },
+ "flows": {
+ "additionalProperties": true,
+ "description": "Present only when supported is true.",
+ "properties": {
+ "asynchronous": {
+ "description": "OAuth flow.",
+ "type": "boolean"
+ },
+ "synchronous": {
+ "description": "Signed-redirect flow; the one that works in practice.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "synchronous",
+ "asynchronous"
+ ],
+ "type": "object"
+ },
+ "nameservers": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "providerId": {
+ "type": "string"
+ },
+ "reason": {
+ "description": "When unsupported: no_discovery_record | settings_unavailable.",
+ "type": "string"
+ },
+ "supported": {
+ "description": "Provider implements Domain Connect (necessary, not sufficient, for one-click setup).",
+ "type": "boolean"
+ },
+ "urlControlPanel": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "domain",
+ "supported"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_http_header_checker1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "Response headers and a security-header grade.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "finalUrl": {
+ "description": "URL after following redirects.",
+ "type": "string"
+ },
+ "headers": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "responseTimeMs": {
+ "type": "number"
+ },
+ "security": {
+ "additionalProperties": true,
+ "properties": {
+ "findings": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "header": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "present": {
+ "type": "boolean"
+ },
+ "rating": {
+ "description": "good | warning | missing.",
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "header",
+ "present",
+ "rating",
+ "note"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "grade": {
+ "description": "A+ to F.",
+ "type": "string"
+ },
+ "score": {
+ "description": "0-100.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "grade",
+ "score",
+ "findings"
+ ],
+ "type": "object"
+ },
+ "status": {
+ "type": "number"
+ },
+ "statusText": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "finalUrl",
+ "status",
+ "statusText",
+ "responseTimeMs",
+ "headers",
+ "security"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_redirect_checker1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "Every hop of the URL's redirect chain.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "finalUrl": {
+ "type": "string"
+ },
+ "hopCount": {
+ "type": "number"
+ },
+ "hops": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "location": {
+ "description": "Location header, when the hop redirects.",
+ "type": "string"
+ },
+ "responseTimeMs": {
+ "type": "number"
+ },
+ "status": {
+ "type": "number"
+ },
+ "statusText": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "status",
+ "statusText",
+ "responseTimeMs"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "loop": {
+ "description": "Chain revisits a URL.",
+ "type": "boolean"
+ },
+ "startUrl": {
+ "type": "string"
+ },
+ "truncated": {
+ "description": "Stopped after 12 hops.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "startUrl",
+ "finalUrl",
+ "hopCount",
+ "loop",
+ "truncated",
+ "hops"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_reverse_ip_lookup1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "PTR hostnames for the IP, plus co-hosted domains when available.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "hostnames": {
+ "description": "PTR records.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "ip": {
+ "type": "string"
+ },
+ "ptrError": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "sharedHosts": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Other hostnames on this IP; null when unavailable."
+ },
+ "sharedHostsNote": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "sharedHostsSource": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "sharedHostsStatus": {
+ "description": "ok | unavailable | error.",
+ "type": "string"
+ },
+ "sharedHostsTotal": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "sharedHostsTruncated": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "ip",
+ "hostnames"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_spf_record_checker1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "The domain's SPF record, parsed and validated.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "issues": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "level": {
+ "description": "error | warning | info.",
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "level",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "lookupCount": {
+ "description": "DNS lookups consumed; RFC 7208 allows at most 10.",
+ "type": "number"
+ },
+ "mechanisms": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "qualifier": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "qualifier",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "present": {
+ "type": "boolean"
+ },
+ "record": {
+ "type": "string"
+ },
+ "records": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "domain",
+ "present",
+ "lookupCount",
+ "issues"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_ssl_check1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "TLS certificate details for the host.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "altNames": {
+ "description": "Subject Alternative Names (hostnames the cert covers).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "authorizationError": {
+ "description": "Why validation failed, e.g. CERT_HAS_EXPIRED.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "authorized": {
+ "description": "Chain validates against public roots and matches the hostname.",
+ "type": "boolean"
+ },
+ "chain": {
+ "description": "Leaf first, then intermediates and root.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "issuer": {
+ "$ref": "#/properties/data/properties/subject"
+ },
+ "subject": {
+ "$ref": "#/properties/data/properties/subject"
+ },
+ "validFrom": {
+ "type": "string"
+ },
+ "validTo": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "subject",
+ "issuer",
+ "validFrom",
+ "validTo"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "cipher": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "daysUntilExpiry": {
+ "description": "Negative once expired.",
+ "type": "number"
+ },
+ "expired": {
+ "type": "boolean"
+ },
+ "fingerprint256": {
+ "type": "string"
+ },
+ "host": {
+ "type": "string"
+ },
+ "issuer": {
+ "$ref": "#/properties/data/properties/subject"
+ },
+ "port": {
+ "type": "number"
+ },
+ "protocol": {
+ "description": "Negotiated TLS version, e.g. TLSv1.3.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "pubkeyBits": {
+ "type": "number"
+ },
+ "serialNumber": {
+ "type": "string"
+ },
+ "signatureAlgorithm": {
+ "type": "string"
+ },
+ "subject": {
+ "additionalProperties": true,
+ "properties": {
+ "C": {
+ "type": "string"
+ },
+ "CN": {
+ "type": "string"
+ },
+ "L": {
+ "type": "string"
+ },
+ "O": {
+ "type": "string"
+ },
+ "OU": {
+ "type": "string"
+ },
+ "ST": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "validFrom": {
+ "description": "ISO 8601.",
+ "type": "string"
+ },
+ "validTo": {
+ "description": "ISO 8601.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "host",
+ "port",
+ "authorized",
+ "expired",
+ "daysUntilExpiry",
+ "subject",
+ "issuer",
+ "validFrom",
+ "validTo",
+ "altNames",
+ "chain"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_subdomain_finder1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "Subdomains found via Certificate Transparency and a wordlist.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "counts": {
+ "additionalProperties": true,
+ "properties": {
+ "crtsh": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ },
+ "wordlist": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "wordlist",
+ "crtsh",
+ "total"
+ ],
+ "type": "object"
+ },
+ "domain": {
+ "type": "string"
+ },
+ "subdomains": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "addresses": {
+ "description": "Resolved IPs; empty if not resolved.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "host": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "host",
+ "addresses"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "domain",
+ "counts",
+ "subdomains"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_txt_record_lookup1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "All TXT records on the domain, classified.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "domain": {
+ "type": "string"
+ },
+ "records": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "category": {
+ "description": "SPF | DMARC | DKIM | Verification | MTA-STS | Other.",
+ "type": "string"
+ },
+ "service": {
+ "description": "For verification tokens, the service that issued it.",
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "value",
+ "category"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "domain",
+ "count",
+ "records"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_website_status_checker1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "Whether the site is up, with timing and basic SSL info.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "contentType": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "finalUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "responseTimeMs": {
+ "type": "number"
+ },
+ "server": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ssl": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "daysUntilExpiry": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "issuer": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "valid": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "valid",
+ "daysUntilExpiry",
+ "issuer"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "description": "HTTP status; 0 if the request failed.",
+ "type": "number"
+ },
+ "statusText": {
+ "type": "string"
+ },
+ "up": {
+ "description": "true when the status is below 500.",
+ "type": "boolean"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "up",
+ "status",
+ "statusText",
+ "responseTimeMs",
+ "ssl"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_whois_lookup1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "RDAP registration data for the domain.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "createdAt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "domain": {
+ "type": "string"
+ },
+ "expiresAt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "handle": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "nameservers": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "registrar": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "EPP status codes, e.g. client transfer prohibited.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "transferred": {
+ "description": "Last transfer date, if reported.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "updatedAt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "whoisServer": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "domain",
+ "status",
+ "nameservers"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}tools_dns_provider_lookuptools_domain_connect_checkertools_cname_lookuptools_dkim_record_checkertools_dmarc_record_checkertools_dns_propagation_checkertools_dns_record_lookuptools_domain_age_checkertools_domain_availability_checkertools_http_header_checkertools_redirect_checkertools_reverse_ip_lookuptools_spf_record_checkertools_ssl_checktools_subdomain_findertools_txt_record_lookuptools_website_status_checkertools_whois_lookupCustom domains for SaaS and AI agents: search, buy, connect DNS, verify ownership and issue HTTPS.
Connect custom domains via AI agents: DNS pre-flight checks, hand-off connect sessions and checks.
Claim a working subdomain in one call — A, CNAME and TXT records. No domain to buy, no account.
Manage hosts, redirects, SSL, and traffic analytics from Claude and other AI assistants.
Add one secure layer between your agents and this server.
