Uptimeify

Server Details

Free anonymous website, DNS, email and TLS checks, plus read-only access to your monitors.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-06 03:35
Transport: Streamable HTTP
URL

Available Tools

20 tools

asn_lookupA

Read-only

Inspect

ASN lookup for a public IP or domain: the autonomous system and its network owner.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Public IP address or domain name

Output Schema

ParametersJSON Schema

Name	Required	Description
`cc`	No
`ip`	No
`ok`	No
`asns`	No
`found`	No
`query`	No
`prefix`	No
`registry`	No

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds meaningful context: it specifies the input type (public IP or domain) and the output (ASN and network owner). It also distinguishes 'public' IPs, implying private IPs may not work. This adds value beyond annotations without contradicting them.

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

Conciseness5/5

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

The description is a single sentence that immediately identifies the tool's purpose, output, and input constraints. Every word contributes value with no filler or redundancy.

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

Completeness4/5

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

This is a simple lookup tool with one parameter, a read-only annotation, and an output schema. The description fully covers the essential purpose and input scope. It could optionally mention example queries or error behavior, but such details are not necessary given the simplicity and existing schema/annotations.

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 coverage is 100%, with the parameter description already stating 'Public IP address or domain name.' The tool description repeats this information almost verbatim ('for a public IP or domain') and does not add new semantics like format examples or validation constraints. Baseline 3 is appropriate since the schema carries the full meaning.

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

Purpose5/5

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

The description clearly states the tool performs an 'ASN lookup' for a public IP or domain and returns 'the autonomous system and its network owner.' This is a specific verb + resource + outcome, and it distinguishes itself from sibling tools like whois or ip_geolocation, which focus on different network attributes.

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?

The description implies when to use the tool (when you need ASN information for a public IP or domain) but does not explicitly mention alternatives or provide exclusion criteria. Usage guidance is implicit rather than explicit, which aligns with a score of 3.

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

check_dnsA

Read-only

Inspect

Check a domain's DNS records (A/AAAA/CNAME/TXT/NS and more).

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Domain name, e.g. deinkunde.com

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`found`	No
`domain`	No
`records`	No
`warnings`	No

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the specific record types, but no limits, return format, or other behavioral details. No contradiction with annotations.

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

Conciseness5/5

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

A single, front-loaded sentence that clearly states the purpose without any fluff. Every word earns its place.

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

Completeness4/5

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

For a simple one-parameter tool with an output schema, the description is adequately complete. It could specify what 'and more' includes, but the output schema likely covers details.

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 coverage is 100% for the single 'domain' parameter, and the description adds no parameter semantics beyond what the schema already provides.

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

Purpose5/5

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

The description clearly states the tool's action ('Check') and resource ('domain's DNS records'), and enumerates specific record types (A/AAAA/CNAME/TXT/NS), which distinguishes it from siblings like mx_lookup (specific record) and dns_propagation (propagation status).

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?

The description implies use for checking DNS records but gives no explicit guidance on when to choose this tool over siblings like mx_lookup or dns_propagation. No alternatives or exclusions are mentioned.

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

check_sslA

Read-only

Inspect

Check a host's TLS/SSL certificate: issuer, validity dates, expiry, chain and trust verdict.

ParametersJSON Schema

Name	Required	Description	Default
`host`	Yes	Domain name (not an IP), e.g. deinkunde.com
`port`	No	TLS port, default 443

Output Schema

ParametersJSON Schema

Name	Required	Description
`ip`	No
`ok`	No
`san`	No
`host`	No
`port`	No
`found`	No
`expired`	No
`issuerO`	No
`trusted`	No
`validTo`	No
`issuerCN`	No
`subjectCN`	No
`validFrom`	No
`selfSigned`	No
`notYetValid`	No
`serialNumber`	No
`hostnameMatch`	No
`fingerprint256`	No
`daysUntilExpiry`	No
`authorizationError`	No

TDQS

A3.8/5.0

Behavior3/5

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

The readOnlyHint annotation already signals a safe read operation, so the description adds value by listing the specific certificate details returned. However, it does not discuss edge cases (e.g., SNI behavior, timeouts) or the trust verdict semantics beyond the minimal list.

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

Conciseness5/5

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

The description is a single, well-structured sentence that gets straight to the point. It is concise, informative, and front-loads the core action and object.

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

Completeness4/5

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

Given the tool's simplicity, the readOnlyHint annotation, and the presence of an output schema, the description sufficiently covers the tool's purpose and key details. It does not need to explain return values because the output schema handles that, and the description provides enough to invoke the tool correctly.

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 coverage is 100% for both parameters (host and port), with descriptions including the port default. The description itself does not add parameter-level detail beyond referencing 'host', so it neither detracts nor meaningfully enhances what the schema already provides.

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

Purpose5/5

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

The description uses a specific verb ('Check') and identifies the resource ('host's TLS/SSL certificate'), then enumerates the key attributes examined (issuer, validity dates, expiry, chain, trust verdict). This clearly distinguishes it from sibling tools like check_dns or port_check.

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?

The description implies the use case (checking SSL certificate details for a host) but does not explicitly state when to use this tool over alternatives or provide exclusions. Sibling tools such as hsts_check or port_check are not referenced, so the context is clear but not contrasted.

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

dkim_checkA

Read-only

Inspect

Check a domain's DKIM public key for a given selector: fetch it and validate it.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Domain name, e.g. deinkunde.com
`selector`	Yes	DKIM selector, e.g. google or default

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`bits`	No
`tags`	No
`error`	No
`found`	No
`domain`	No
`hasKey`	No
`record`	No
`keyType`	No
`selector`	No
`warnings`	No

TDQS

A3.8/5.0

Behavior3/5

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

The readOnlyHint annotation declares the operation is read-only, and the description adds that it fetches and validates the key. However, it does not explain what 'validate' entails, error behavior, or any prerequisites, leaving some gaps beyond the annotation.

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

Conciseness5/5

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

The description is a single sentence that is front-loaded with the action (Check) and the resource (DKIM public key), then clarifies via 'fetch it and validate it.' Every word earns its place, with no filler or redundancy.

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

Completeness4/5

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

For a simple two-parameter read-only tool with an output schema and clear annotations, the description provides adequate context. It explains the core behavior, and the output schema covers return values, so no significant detail is missing.

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 both 'domain' and 'selector' already described with examples. The description merely restates these concepts without adding extra semantic detail, so it meets the baseline but does not exceed it.

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

Purpose5/5

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

The description clearly states the tool checks a domain's DKIM public key for a given selector, and explains it fetches and validates it. This specific verb+resource combination distinguishes it from sibling tools like dmarc_check, spf_check, and mx_lookup.

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?

There is no explicit guidance on when to use this tool over alternatives, but the name and description imply usage for DKIM key validation. The sibling list shows related DNS tools, yet no comparisons or exclusions are mentioned.

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

dmarc_checkA

Read-only

Inspect

Check a domain's DMARC policy record: fetch it and evaluate the policy.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Domain name, e.g. deinkunde.com

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`pct`	No
`tags`	No
`error`	No
`found`	No
`domain`	No
`policy`	No
`record`	No
`warnings`	No
`subPolicy`	No

TDQS

A3.8/5.0

Behavior3/5

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

readOnlyHint annotation already declares safety; description adds 'fetch' and 'evaluate' steps, but no additional behavioral detail like handling of missing records or response format. It doesn't contradict annotations.

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

Conciseness5/5

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

Two short sentences, front-loaded with the operation, no filler.

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

Completeness4/5

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

Given the simple one-parameter read-only tool with an output schema, the description is adequate and covers the core behavior; could mention when to use but not necessary for completeness.

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 fully describes the single 'domain' parameter with an example; description adds no parameter-level meaning, so baseline 3 applies.

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

Purpose5/5

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

The description uses specific verbs 'fetch' and 'evaluate' with the resource 'DMARC policy record', clearly distinguishing it from sibling tools like dkim_check and spf_check.

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?

No explicit when-to-use or alternatives are given; usage is implied by the domain-specific resource, but there's no guidance on exclusions or when other DNS tools might be preferable.

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

dnsbl_checkA

Read-only

Inspect

DNSBL check: whether a public IP address is listed on common DNS blacklists. Returns partial results if some blocklists are too slow to answer.

ParametersJSON Schema

Name	Required	Description	Default
`ip`	Yes	Public IPv4 or IPv6 address

Output Schema

ParametersJSON Schema

Name	Required	Description
`ip`	No
`ok`	No
`clean`	No
`total`	No
`partial`	No
`results`	No
`listedCount`	No
`zonesQueried`	No

TDQS

A4.2/5.0

Behavior4/5

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

The annotation readOnlyHint=true already indicates a safe read operation. The description adds a valuable behavioral detail: 'Returns partial results if some blocklists are too slow to answer,' which informs the agent about potential incomplete responses. This goes beyond annotations.

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

Conciseness5/5

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

The description is extremely concise, consisting of two short sentences. It front-loads the primary purpose and includes a brief caveat about partial results, with no wasted words.

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

Completeness4/5

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

The tool is simple with one parameter, an output schema, and a clear annotation. The description covers the core behavior and a key edge case (partial results). It does not mention any prerequisites or error conditions, but these are not critical for this straightforward tool.

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?

The input schema already provides a clear description for the 'ip' parameter ('Public IPv4 or IPv6 address') with 100% coverage. The description adds no additional semantic detail beyond reiterating 'public IP address,' so the schema does the heavy lifting.

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

Purpose5/5

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

The description clearly states the tool's function: checking whether a public IP address is listed on DNS blacklists. It uses a specific verb ('check') and resource ('public IP address' against 'DNS blacklists'), distinguishing it from sibling tools like check_dns or mx_lookup.

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

Usage Guidelines4/5

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

The description provides clear context for when to use the tool (to determine if an IP is blacklisted) and implies it is for IP reputation checks. It does not explicitly mention alternatives or exclusions, but the context is sufficient for most use cases.

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

dns_propagationA

Read-only

Inspect

Check DNS propagation of a domain across multiple public resolvers.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Domain name, e.g. deinkunde.com

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`type`	No
`domain`	No
`results`	No
`consistent`	No

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safe read nature is known. The description adds the behavioral detail of checking 'multiple public resolvers', which is useful but does not cover aspects like resolver count, timeout, or output details. With annotations present, this is adequate but not rich additional context.

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

Conciseness5/5

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

The description is a single, front-loaded sentence that directly states the tool's purpose. It contains no filler and every word contributes to understanding the tool's functionality.

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

Completeness4/5

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

Given the tool's simplicity (one parameter), the presence of an output schema, and readOnlyHint annotation, the description is fairly complete. It could potentially explain what 'propagation' means in terms of expected behavior, but for a simple read-only tool, the current description suffices.

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?

The input schema has 100% coverage for the single 'domain' parameter, with a clear example ('deinkunde.com'). The description does not add any additional parameter semantics, so the baseline of 3 applies.

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

Purpose5/5

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

The description clearly states the tool checks DNS propagation of a domain across multiple public resolvers. The phrase 'across multiple public resolvers' distinguishes it from sibling tools like check_dns, which likely performs basic DNS lookups. This gives a specific verb and resource with clear scope.

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?

The description implies usage when you need to verify DNS propagation, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternatives are mentioned, so the guidance is only implicit.

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

domain_expiryB

Read-only

Inspect

Check a domain's registration expiry date and the days remaining.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Domain name, e.g. deinkunde.com

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`tld`	No
`error`	No
`found`	No
`domain`	No
`statuses`	No
`createdAt`	No
`expiresAt`	No
`registrar`	No
`updatedAt`	No
`tldSupported`	No
`daysUntilExpiry`	No

TDQS

B3.4/5.0

Behavior2/5

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

Annotations declare readOnlyHint=true, and the description adds no extra behavioral context beyond confirming it is a read operation. It does not mention data sources, potential delays, or failure modes for unregistered/invalid domains, so it provides minimal value beyond the annotations.

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

Conciseness5/5

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

The description is a single, concise sentence that directly conveys the purpose without any redundant words or filler. It is appropriately front-loaded and easy to parse.

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

Completeness4/5

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

With an output schema present, return values are already documented. The simple tool has only one parameter and read-only annotations, so the description is mostly complete. However, it could benefit from a brief mention of how the expiry date is obtained (e.g., via WHOIS) or edge-case behavior, but this is not critical given the schema coverage.

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 coverage is 100% with a clear description for the 'domain' parameter including an example. The tool description adds no additional meaning, so the baseline score of 3 is appropriate since the schema fully documents the parameter.

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

Purpose5/5

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

The description clearly states the action ('Check') and the specific resource ('domain's registration expiry date and the days remaining'). This is specific and distinguishes it from broader sibling tools like whois, which would provide more general registry data.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives (e.g., whois, check_ssl). It merely states what it does without contextual hints or exclusions, so the agent receives no help in selecting this tool over siblings.

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

hsts_checkA

Read-only

Inspect

HSTS check: a domain's HTTP Strict Transport Security configuration.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Domain name, e.g. deinkunde.com

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`raw`	No
`domain`	No
`maxAge`	No
`preload`	No
`present`	No
`warnings`	No
`preloadReady`	No
`httpsRedirect`	No
`includeSubDomains`	No

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safe read-only nature is known. The description adds little behavioral context beyond what's implied by 'check'—it does not mention network calls, failure conditions, or what happens with domains lacking HSTS. No contradiction with annotations.

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

Conciseness3/5

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

The description is a single sentence that restates the tool name ('HSTS check') and adds the resource. It is concise but somewhat under-informative; it earns its place by specifying the resource, but could be more structured without being verbose.

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

Completeness4/5

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

The tool is simple with one parameter and an output schema exists. The description sufficiently defines the purpose for a basic check tool, and the annotations cover the read-only safety. It doesn't need to explain return values since output schema presumably handles that.

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% for the single 'domain' parameter with an example. The description doesn't add further semantic context, but since the schema fully documents the parameter, a baseline of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool checks a domain's HTTP Strict Transport Security configuration, which is specific and distinct from sibling tools like check_ssl or http_headers. The verb 'check' plus the resource 'domain's HSTS configuration' makes the purpose unambiguous.

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?

The description implies this tool is for checking HSTS configuration, but it does not explicitly state when to use it over alternatives or provide exclusions. It is clear from context that it's for security header checks, but no explicit guidance is given.

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

http_headersA

Read-only

Inspect

Fetch the HTTP response headers for a URL.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Full URL, e.g. https://deinkunde.com

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`url`	No
`status`	No
`headers`	No
`redirects`	No
`statusText`	No

TDQS

A3.7/5.0

Behavior3/5

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

Annotations declare readOnlyHint=true, and the description's 'Fetch' aligns with this read-only behavior. However, the description does not disclose any behavioral nuances such as redirect following, timeouts, or rate limits, so it adds only minimal context beyond the annotation.

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

Conciseness5/5

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

The entire description is an eight-word sentence that states the core function without redundancy. It is appropriately sized for a one-parameter read-only tool and front-loads the key information.

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

Completeness5/5

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

For a tool with a single required parameter, full schema coverage, a readOnly annotation, and an output schema, the description is sufficiently complete. No additional context is necessary for an agent to select and invoke it correctly.

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?

The input schema already documents the only parameter (url) with format guidance ('Full URL, e.g., https://deinkunde.com'), providing 100% coverage. The description adds no parameter-specific details beyond referring to 'a URL,' so baseline 3 is appropriate.

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

Purpose5/5

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

The description uses a specific verb ('Fetch') and resource ('HTTP response headers'), clearly identifying what the tool does. It also distinguishes this tool from siblings like check_ssl or whois by focusing on HTTP headers.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool vs alternatives. The description only states the action and target, with no mention of when it's appropriate, prerequisites, or exclusions.

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

ip_geolocationA

Read-only

Inspect

IP geolocation for a public IP address or a domain (country, region, ASN, org).

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Public IP address or domain name

Output Schema

ParametersJSON Schema

Name	Required	Description
`cc`	No
`ip`	No
`ok`	No
`ptr`	No
`asns`	No
`found`	No
`query`	No
`prefix`	No
`registry`	No
`resolvedFromDomain`	No

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=true, signaling a safe read operation. The description adds value by naming the output fields (country, region, ASN, org), but does not disclose potential limitations, input validation rules, or rate-level behaviors. This meets the baseline but goes no further.

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

Conciseness5/5

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

The description is a single, concise sentence that front-loads the tool's purpose and output. Every word adds meaning, with no repetition of schema or annotation information.

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

Completeness4/5

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

Given the tool's simplicity (one well-documented parameter, read-only annotation, and an output schema), the description provides sufficient context by stating input types and output categories. It lacks explicit notes on IP format variations or error behavior, but the complexity is low enough that this is not a significant gap.

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?

The schema provides full coverage for the single 'query' parameter with a clear description ('Public IP address or domain name'). The tool description adds no additional parameter-level detail, so the schema carries the burden. Baseline of 3 is appropriate.

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 clearly indicates the tool provides geolocation information for a public IP or domain, listing the main output fields (country, region, ASN, org). While it uses a noun phrase rather than a verb, it distinguishes itself from sibling tools by mentioning the broader scope of results, though it doesn't explicitly contrast with asn_lookup.

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?

The description implies usage when you need geolocation data for an IP or domain, but it provides no explicit guidance on when to choose this over alternatives like asn_lookup or whois. No exclusions or competitor comparisons are given.

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

mx_lookupA

Read-only

Inspect

MX lookup for a domain: its mail exchanger records and their addresses.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Domain name, e.g. deinkunde.com

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`found`	No
`domain`	No
`servers`	No

TDQS

A4/5.0

Behavior3/5

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

The annotation readOnlyHint=true already signals a safe read operation. The description adds that the tool returns MX records and 'their addresses,' which is useful output detail, but it does not disclose edge-case behavior such as missing MX records or resolved address semantics. With annotations covering safety, this modest additional context warrants a 3.

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

Conciseness5/5

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

The description is a single, focused sentence without filler. It front-loads the core purpose and includes the key output detail ('their addresses'), earning every word.

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

Completeness4/5

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

For a simple read-only tool with one fully documented parameter, an output schema, and a read-only annotation, the description is mostly complete. However, it lacks any guidance on how this differs from the many DNS-related siblings (e.g., check_dns), so a sentence about when to use it would make it fully complete.

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?

Input schema coverage is 100% with the 'domain' parameter already well-described ('Domain name, e.g. deinkunde.com'). The tool description does not add any parameter-level detail beyond what the schema provides, so it meets the baseline but does not exceed it.

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

Purpose5/5

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

The description clearly states the tool's specific action: 'MX lookup for a domain' and specifies what it returns ('its mail exchanger records and their addresses'). This distinguishes it from sibling tools like check_dns (generic DNS), dkim_check, and dmarc_check which focus on other record types.

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

Usage Guidelines4/5

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

The phrase 'for a domain' provides clear context for when to use this tool. However, it does not explicitly mention alternatives or exclusion scenarios (e.g., when to use check_dns instead), so it lacks the explicit when/when-not guidance that would earn a 5.

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

ping_testA

Read-only

Inspect

Ping test: measure TCP reachability and round-trip time to a host.

ParametersJSON Schema

Name	Required	Description	Default
`host`	Yes	Domain name or host
`port`	No	Port, default 443

Output Schema

ParametersJSON Schema

Name	Required	Description
`ip`	No
`ok`	No
`host`	No
`port`	No
`sent`	No
`avgMs`	No
`maxMs`	No
`minMs`	No
`lossPct`	No
`attempts`	No
`received`	No

TDQS

A4/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true, so the safety profile is clear. The description adds meaningful context by specifying that this measures TCP-level reachability (not ICMP ping) and reports round-trip time, which is valuable behavioral information beyond the annotation.

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

Conciseness5/5

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

The description is a single, grammatically efficient sentence that front-loads the core purpose. There is zero extraneous content, and the 'Ping test:' prefix is a helpful label rather than waste.

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

Completeness4/5

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

Given the tool's simplicity, presence of an output schema, and read-only annotation, the description is sufficiently complete. It covers the essential behavior (TCP reachability and RTT), though it could be improved with a brief usage context relative to sibling tools.

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?

The input schema already documents both parameters clearly (host, port with default). The description does not add new parameter-level detail, but with 100% schema coverage, the baseline of 3 is appropriate.

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

Purpose5/5

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

The description uses a specific verb ('measure') and identifies both the resource (TCP reachability to a host) and the metric (round-trip time). It clearly distinguishes from siblings like port_check (which likely just tests port openness) and response_time (HTTP-level timing).

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?

The description implies when to use this tool (for TCP reachability and RTT), but does not explicitly contrast it with alternatives such as port_check or response_time. It provides no when-not-to-use guidance or exclusions.

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

port_checkA

Read-only

Inspect

Check whether one or more TCP ports are open on a host. Pass a single port or a list, up to 10 per call.

ParametersJSON Schema

Name	Required	Description	Default
`host`	Yes	Domain name or host
`port`	Yes	TCP port, or a list of up to 10 ports, e.g. 443 or [80, 443, 25]

Output Schema

ParametersJSON Schema

Name	Required	Description
`ip`	No
`ok`	No
`host`	No
`port`	No
`state`	No
`timeMs`	No
`partial`	No
`results`	No
`portsRequested`	No

TDQS

A3.8/5.0

Behavior3/5

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

The readOnlyHint annotation already declares this as a safe read operation, so the description does not need to repeat that. The description adds 'up to 10 per call' which is also present in the schema, and does not disclose additional behavioral traits like connection timeouts or return format. It is consistent with annotations, no contradiction.

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

Conciseness5/5

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

The description is two short sentences, front-loaded with the primary purpose, and includes a necessary usage hint about the port list limit. Every word earns its place with no redundancy or filler.

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

Completeness4/5

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

For a simple two-parameter read-only tool with full schema descriptions and an output schema, the description provides adequate context for an agent to select and invoke it. Minor omissions like defining 'open' (e.g., TCP handshake success) are covered by the output schema, so the description is sufficiently complete.

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?

Both parameters are fully described in the schema (100% coverage), including an example for the port parameter. The description reinforces the ability to pass a single port or list but does not add meaning beyond the schema. Baseline of 3 is appropriate because the schema handles the heavy lifting.

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

Purpose5/5

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

The description clearly states a specific action ('Check whether one or more TCP ports are open on a host') with a specific resource (TCP ports on a host). It distinguishes from sibling tools by explicitly mentioning TCP ports, which differentiates it from DNS, SSL, ping, and other network checks.

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?

The description implies usage for checking TCP port availability but does not explicitly state when to use it over alternatives or mention exclusions. No comparison to sibling tools like ping_test or check_ssl is provided. Usage context is clear but implicit.

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

redirect_checkA

Read-only

Inspect

Check the HTTP redirect chain for a URL, tracing it to the final destination.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Full URL, e.g. https://deinkunde.com

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`hops`	No
`start`	No
`finalUrl`	No
`warnings`	No
`totalHops`	No
`finalStatus`	No
`finalStatusText`	No

TDQS

A3.9/5.0

Behavior3/5

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

The readOnlyHint=true annotation already covers the safety profile, and the description adds the behavioral detail that it traces the chain to the final destination. However, it does not disclose potential edge cases like redirect loops, hop limits, or whether relative redirects are handled. It provides minimal extra context beyond the annotation.

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

Conciseness5/5

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

The description is one sentence of 13 words, front-loads the verb and resource, and contains no filler or redundant phrases. It is concise and well-structured.

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

Completeness5/5

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

Given the tool's simplicity (one parameter, read-only annotation, and an output schema), the description sufficiently explains the tool's behavior and purpose. It does not need to explain return values because the output schema handles that. No critical information is missing for effective tool selection and invocation.

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?

The single parameter 'url' is fully described in the schema with a clear example. The description only repeats that it takes a URL, adding no new meaning. With 100% schema coverage, the baseline of 3 is appropriate; the description does not enhance the parameter understanding.

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

Purpose5/5

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

The description specifies a clear verb ('Check') and resource ('HTTP redirect chain for a URL'), and further clarifies the outcome ('tracing it to the final destination'). This distinguishes it from sibling tools like http_headers or website_status, which do not focus specifically on redirect chains.

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?

The description implies usage when you need to see redirects and the final URL, but it does not explicitly state when to use this tool over alternatives or list exclusions. There is no mention of when not to use it, e.g., if you only need response codes or headers. The context is clear but not elaborated.

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

response_timeA

Read-only

Inspect

Measure a website's response time (DNS, connect, TTFB, total).

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Full URL, e.g. https://deinkunde.com

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`up`	No
`avg`	No
`max`	No
`min`	No
`url`	No
`status`	No
`partial`	No
`samples`	No
`samplesRequested`	No

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds useful context by enumerating the measured network phases (DNS, connect, TTFB, total). It does not describe timeout behavior or response format, but the output schema covers return values, so the added context is sufficient.

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

Conciseness5/5

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

The description is a single front-loaded sentence: 'Measure a website's response time (DNS, connect, TTFB, total).' Every word contributes to understanding the tool's function, with no redundancy or irrelevant details.

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

Completeness5/5

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

With only one parameter, a clear output schema, and a simple purpose, the description fully captures what the agent needs to select and invoke the tool. It identifies the tool's niche and the measured metrics, making it complete for the tool's complexity.

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?

The input schema has 100% description coverage for the only parameter 'url' ('Full URL, e.g. https://deinkunde.com'). The description adds no additional meaning about the parameter, so the baseline score of 3 is appropriate.

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

Purpose5/5

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

The description uses a specific verb 'Measure' and a clearly defined resource 'website's response time', listing specific metrics (DNS, connect, TTFB, total). This distinguishes it from sibling tools such as ping_test or http_headers, which have different objectives.

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?

The description implies usage when detailed response-time breakdowns are desired, but it does not explicitly mention alternatives, nor does it state when not to use this tool. The context is clear enough to infer the use case, but no exclusions or comparisons are provided.

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

reverse_dnsA

Read-only

Inspect

Reverse DNS: resolve a public IP address to its PTR hostname.

ParametersJSON Schema

Name	Required	Description	Default
`ip`	Yes	Public IPv4 or IPv6 address

Output Schema

ParametersJSON Schema

Name	Required	Description
`ip`	No
`ok`	No
`error`	No
`hostnames`	No

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint: true, so the safety profile is covered. The description adds that the tool resolves to a PTR hostname, but it does not disclose edge-case behavior (e.g., what happens if no PTR record exists) or any potential rate limits. No contradiction with annotations.

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

Conciseness5/5

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

The description is a single sentence, front-loaded with the tool name and core action, with zero wasted words. It is appropriately sized for the tool's simplicity.

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

Completeness5/5

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

Given a single required parameter, a read-only annotation, and an existing output schema (not shown but signaled), the description is complete. It identifies the input type and output format, and no further details are needed for this straightforward lookup tool.

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?

The input schema provides 100% coverage with the 'ip' parameter described as 'Public IPv4 or IPv6 address'. The description does not add any additional meaning beyond what the schema already states, so the baseline score of 3 applies.

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

Purpose5/5

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

The description uses a specific verb 'resolve' with a clear object ('public IP address') and outcome ('PTR hostname'), making the tool's purpose immediately obvious. It also distinguishes itself from sibling DNS tools like asn_lookup or mx_lookup by focusing solely on reverse DNS.

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?

Usage is implied (use when you need a PTR hostname for an IP) but there is no explicit guidance on when to use this tool versus alternatives like check_dns or dns_propagation. With 25 sibling tools, clearer differentiation would help an agent select the correct tool.

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

spf_checkA

Read-only

Inspect

Check a domain's SPF record: fetch it and evaluate the policy.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Domain name, e.g. deinkunde.com

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`all`	No
`error`	No
`found`	No
`terms`	No
`domain`	No
`record`	No
`lookups`	No
`warnings`	No

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true, and the description adds useful behavioral context: it fetches the record and evaluates the policy. This goes beyond the annotation by clarifying the two-step nature of the operation. No contradiction with annotations.

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

Conciseness5/5

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

One concise sentence with a colon splitting the action into fetch and evaluate. No wasted words, front-loaded, and the structure aids quick comprehension.

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

Completeness5/5

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

For a single-parameter, read-only DNS lookup tool with an output schema available, the description sufficiently covers the core behavior. It does not need to explain return values because an output schema exists, and the simplicity of the tool means no additional context is required.

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?

The input schema has 100% coverage for the single 'domain' parameter with an example ('e.g. deinkunde.com'). The description adds no additional parameter-level detail, so it defaults to the baseline score of 3.

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

Purpose5/5

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

The description clearly states the tool's function: 'Check a domain's SPF record: fetch it and evaluate the policy.' It uses a specific verb ('check') and identifies the resource (domain's SPF record), which differentiates it from sibling tools like dkim_check and dmarc_check that target other DNS records.

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?

The description implies usage—if you need to check an SPF record, this is the tool—but it gives no explicit when-to-use or when-not-to-use guidance. It does not name alternatives or exclusions, so it falls short of clear contextual guidance.

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

website_statusA

Read-only

Inspect

Is a website up right now? Start here for any is-the-site-down question: up/down verdict, HTTP status, response time and redirect count in one call.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Full URL, e.g. https://deinkunde.com

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`up`	No
`url`	No
`server`	No
`status`	No
`redirects`	No
`statusText`	No
`responseTimeMs`	No

TDQS

A4.3/5.0

Behavior4/5

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

The annotation readOnlyHint:true already covers safety. The description adds valuable behavioral context by listing exactly what the call returns (up/down verdict, HTTP status, response time, redirect count) and indicating it checks 'right now' (real-time). It does not contradict annotations and provides useful expectations beyond the schema.

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

Conciseness5/5

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

The description is two short sentences that front-load the core question and immediately follow with usage guidance and output summary. Every phrase earns its place: 'right now' signals real-time, 'start here' gives behavioral priority, and the enumerated outputs set expectations with zero fluff.

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

Completeness5/5

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

Given the simplicity of the tool (one required parameter, fully documented in schema) and the presence of an output schema, the description is complete. It captures the purpose, usage trigger, and key return fields, and the sibling context makes it clear this is the default entry point for website status checks.

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 for the single 'url' parameter is 100%, with a clear example ('https://deinkunde.com'). The description does not add extra parameter-level information beyond confirming the resource is a website, so it meets the baseline for schema-heavy tools but doesn't exceed it.

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

Purpose5/5

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

The description uses a specific verb phrase ('Is a website up right now?') and resource ('website'), and lists concrete outputs (up/down verdict, HTTP status, response time, redirect count). It also distinguishes itself from siblings by explicitly positioning itself as the starting point ('Start here') for is-the-site-down questions.

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

Usage Guidelines4/5

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

The description provides clear usage context: 'Start here for any is-the-site-down question'—this tells when to use the tool. It implies that for more focused checks (e.g., response time alone) other sibling tools might be used, but it does not explicitly name alternatives or exclusions, so it stops short of the highest score.

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

whoisA

Read-only

Inspect

Retrieve WHOIS registration data for a domain.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Domain name, e.g. deinkunde.com

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`tld`	No
`error`	No
`found`	No
`domain`	No
`contacts`	No
`statuses`	No
`createdAt`	No
`expiresAt`	No
`registrar`	No
`updatedAt`	No
`nameservers`	No
`tldSupported`	No

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, and the description consistently describes a read operation. It adds minimal context beyond stating it retrieves 'registration data', but does not disclose any limitations, rate limits, or special behaviors. With annotations present, this is acceptable but not rich.

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

Conciseness5/5

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

The description is a single, focused sentence that is front-loaded with the verb and object. Every word adds value; there is no fluff or repetition.

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

Completeness5/5

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

For a single-parameter tool with a rich output schema and readOnly annotation, the description is sufficient. It clearly names the action and subject, and the output schema covers return values, so no further detail is needed.

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 coverage is 100% with a clear description for the 'domain' parameter (including an example). The description only repeats 'domain' without adding new meaning, so it meets the baseline but does not enhance parameter understanding.

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

Purpose5/5

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

The description uses a specific verb ('Retrieve') and clearly identifies the resource ('WHOIS registration data for a domain'). It distinguishes from siblings by focusing on WHOIS specifically, which is distinct from DNS, SSL, or expiry checks.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives like domain_expiry or check_dns. The description implies a general WHOIS lookup but provides no exclusions or alternative tool suggestions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

13 tool updatesSep 3, 2026
- Removedalert_history
- Removedbilling_summary
- Removedcheck_history
- Removedget_organization
- Removedlist_alert_channels
- Removedlist_customers
- Removedlist_incidents
- Removedlist_maintenance_windows
- Removedlist_monitors
- Removedlist_status_pages
- Removedlist_users
- Removedmonitor_status
- Removeduptime_summary
8 tool updatesSep 3, 2026
- Addedalert_history
- Addedbilling_summary
- Addedget_organization
- Addedlist_alert_channels
- Addedlist_customers
- Addedlist_maintenance_windows
- Addedlist_status_pages
- Addedlist_users

3 tool updatesSep 2, 2026

Changedcheck_history2 fields changed

addedInput schema / properties / kind

Added value: +{
+  "description": "Monitor family. Omit to cover all eight. One of: website, dns, icmp, tcp, ftp, smtp, ssh, imap_pop",
+  "enum": [
+    "website",
+    "dns",
+    "icmp",
+    "tcp",
+    "ftp",
+    "smtp",
+    "ssh",
+    "imap_pop"
+  ],
+  "type": "string"
+}

changedInput schema / properties / monitor_id / description

Previous value: -"The monitor/website id"New value: +"The monitor id"

Changedlist_monitors5 fields changed

addedInput schema / properties / kind

Added value: +{
+  "description": "Monitor family. Omit to cover all eight. One of: website, dns, icmp, tcp, ftp, smtp, ssh, imap_pop",
+  "enum": [
+    "website",
+    "dns",
+    "icmp",
+    "tcp",
+    "ftp",
+    "smtp",
+    "ssh",
+    "imap_pop"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / items / anyOf

Previous value: -[
-  {
-    "items": {
-      "additionalProperties": {},
-      "properties": {
-        "avgResponseDay": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "avgResponseMonth": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "avgResponseYear": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "hasCritical": {
-          "anyOf": [
-            {
-              "type": "boolean"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "hasWarning": {
-          "anyOf": [
-            {
-              "type": "boolean"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "id": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "isDown": {
-          "anyOf": [
-            {
-              "type": "boolean"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "isRecovering": {
-          "anyOf": [
-            {
-              "type": "boolean"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "monitoringType": {
-          "anyOf": [
-            {
-              "type": "string"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "name": {
-          "anyOf": [
-            {
-              "type": "string"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "publicId": {
-          "anyOf": [
-            {
-              "type": "string"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "upSinceAt": {
-          "anyOf": [
-            {
-              "type": "string"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "uptimeDay": {
-          "anyOf": [
-            {
-              "anyOf": [
-                {
-                  "type": "number"
-                },
-                {
-                  "type": "string"
-                }
-              ]
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "uptimeMonth": {
-          "anyOf": [
-            {
-              "anyOf": [
-                {
-                  "type": "number"
-                },
-                {
-                  "type": "string"
-                }
-              ]
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "uptimeYear": {
-          "anyOf": [
-            {
-              "anyOf": [
-                {
-                  "type": "number"
-                },
-                {
-                  "type": "string"
-                }
-              ]
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "url": {
-          "anyOf": [
-            {
-              "type": "string"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        }
-      },
-      "type": "object"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "additionalProperties": {},
+      "properties": {
+        "avgResponseDay": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "avgResponseMonth": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "avgResponseYear": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "hasCritical": {
+          "anyOf": [
+            {
+              "type": "boolean"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "hasWarning": {
+          "anyOf": [
+            {
+              "type": "boolean"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "id": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "isDown": {
+          "anyOf": [
+            {
+              "type": "boolean"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "isRecovering": {
+          "anyOf": [
+            {
+              "type": "boolean"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "kind": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "monitoringType": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "name": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "publicId": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "upSinceAt": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "uptimeDay": {
+          "anyOf": [
+            {
+              "anyOf": [
+                {
+                  "type": "number"
+                },
+                {
+                  "type": "string"
+                }
+              ]
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "uptimeMonth": {
+          "anyOf": [
+            {
+              "anyOf": [
+                {
+                  "type": "number"
+                },
+                {
+                  "type": "string"
+                }
+              ]
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "uptimeYear": {
+          "anyOf": [
+            {
+              "anyOf": [
+                {
+                  "type": "number"
+                },
+                {
+                  "type": "string"
+                }
+              ]
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "url": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        }
+      },
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / page

Removed value: -{
-  "anyOf": [
-    {
-      "type": "number"
-    },
-    {
-      "type": "null"
-    }
-  ]
-}

addedOutput schema / properties / partialFailures

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

removedOutput schema / properties / perPage

Removed value: -{
-  "anyOf": [
-    {
-      "type": "number"
-    },
-    {
-      "type": "null"
-    }
-  ]
-}

Changedmonitor_status2 fields changed

addedInput schema / properties / kind

Added value: +{
+  "description": "Monitor family. Omit to cover all eight. One of: website, dns, icmp, tcp, ftp, smtp, ssh, imap_pop",
+  "enum": [
+    "website",
+    "dns",
+    "icmp",
+    "tcp",
+    "ftp",
+    "smtp",
+    "ssh",
+    "imap_pop"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / kind

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

3 tool updatesAug 12, 2026

Changeddnsbl_check2 fields changed

addedOutput schema / properties / partial

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / zonesQueried

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

Changedport_check8 fields changed

addedInput schema / properties / port / anyOf

Added value: +[
+  {
+    "maximum": 65535,
+    "minimum": 1,
+    "type": "integer"
+  },
+  {
+    "items": {
+      "maximum": 65535,
+      "minimum": 1,
+      "type": "integer"
+    },
+    "maxItems": 10,
+    "minItems": 1,
+    "type": "array"
+  }
+]

changedInput schema / properties / port / description

Previous value: -"TCP port to test"New value: +"TCP port, or a list of up to 10 ports, e.g. 443 or [80, 443, 25]"

removedInput schema / properties / port / maximum
```
Removed value: -65535
```
removedInput schema / properties / port / minimum
```
Removed value: -1
```
removedInput schema / properties / port / type
```
Removed value: -"integer"
```

addedOutput schema / properties / partial

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / portsRequested

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / results

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "error": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "ip": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "port": {
+            "anyOf": [
+              {
+                "type": "number"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "state": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "timeMs": {
+            "anyOf": [
+              {
+                "type": "number"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

Changedresponse_time2 fields changed

addedOutput schema / properties / partial

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / samplesRequested

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

25 tool updatesAug 4, 2026

Changedasn_lookup1 field changed