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

No annotations are provided, so the description bears the full burden. It does disclose that the lookup is 'live' (no cache) and which record types are queried, which is useful. However, it does not describe behavior such as error handling, response format, or whether it follows CNAME chains, leaving some ambiguity for an agent.

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 with no filler. The primary action is front-loaded, and the use-case context is tucked into the second sentence. Every word earns its place.

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?

The tool is simple with two well-documented parameters, but there is no output schema and the description does not mention what the return data looks like (e.g., TTLs, resolved IPs, or a formatted record list). An agent might need to discover the output shape at runtime, so the definition is adequate but not 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?

Schema description coverage is 100%: both 'domain' and 'recordType' have descriptions, and recordType has an enum. The description adds no extra parameter-level meaning beyond the schema, so it meets but does not exceed the baseline.

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 uses a specific verb ('Looks up'), names the resource ('DNS records'), and enumerates the record types (A, AAAA, CNAME, MX, TXT, NS). This clearly distinguishes check_dns from sibling tools like check_http_status, check_ssl, and check_security_headers, which target different aspects of a domain.

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 second sentence explicitly states when to use this tool: 'diagnose propagation delays, missing records, or misconfigured mail/DNS setups.' This provides clear context but does not mention when not to use it or name alternative tools, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It states the tool makes a live network request and reports latency, status, and redirect chain. It does not mention timeouts, error handling, whether requests are followed, or that a live request can be slow—leaving some behavioral uncertainty.

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 with no filler. The core behavior and outputs are front-loaded, followed by concrete use cases. Every sentence earns its place.

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 tool with no output schema, the description gives enough key information: what it checks, what it reports, and common use cases. It could be more complete by mentioning possible failure modes or timeouts, but the essentials are covered.

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?

The input schema already fully documents the url parameter with type and an example. The tool description references making a request to a URL but does not add significant semantic detail beyond the schema. Baseline 3 applies because schema coverage is 100%.

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 clearly identifies the tool's action: making a live HTTP request to a URL. It also specifies the concrete outputs—status code, latency, and full redirect chain—which differentiates it from sibling tools like check_ssl, check_dns, or check_security_headers.

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 explicitly states when to use the tool: to check if a site is up, slow, or stuck in a redirect loop. However, it does not explicitly say when not to use it or mention alternatives, so it falls slightly short of the highest bar.

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

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

With no annotations, the description carries the behavioral burden and does disclose the key behavior: it fetches the URL, examines response headers only, and notes risk for missing headers. It could add caveats about timeouts or error handling, but the core side effect (outbound fetch) and output behavior are stated.

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?

One tightly written sentence with no filler. It front-loads the action, enumerates the checklist items, and states the risk output.

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 tool with no annotations or output schema, the description covers the input, the action, the checklist, and the general output nature. It does not specify exact return formatting, but the missing-header risk behavior is enough for an agent to select and call 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 coverage is 100%: the only parameter, url, is already described with an example. The tool description simply says 'fetches a URL' and adds no additional parameter-level guidance beyond what the schema provides, 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 uses a specific verb and resource: it fetches a URL and checks response headers against a named security checklist. It is clearly distinct from siblings like check_http_status, check_ssl, and check_dns.

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?

It clearly implies when to use it: when security-related response headers need to be verified for a URL. It does not explicitly name sibling alternatives or exclusion conditions, but the specific checklist makes the intended context obvious.

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

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

With no annotations, the description carries the full burden. It discloses that the tool performs a live TLS connection and reports issuer, validity window, days until expiry, and SANs, which are meaningful behavioral traits. It does not mention failure modes or whether the certificate chain is validated, so it is not fully exhaustive.

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?

The description is two sentences with no filler. It front-loads the core operation and output, then immediately provides the intended use case. Every sentence earns its place.

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?

There is no output schema, but the description lists the key returned fields, which provides the necessary return-value context. Combined with the schema-covered parameters, an agent can call the tool correctly. Missing edge-case behavior such as connection failures or validation semantics keeps it from a 5.

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 the schema already documents both hostname and port including the default port. The description adds little parameter-level meaning beyond what the schema provides, which matches the baseline of 3.

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 ('Opens a live TLS connection') and a precise resource ('a hostname'), and enumerates the exact certificate information returned. This clearly differentiates it from sibling tools like check_http_status, check_dns, and check_security_headers.

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 explicitly says 'Use this to diagnose SSL warnings or expiry issues,' giving a clear context for when to invoke the tool. It does not explicitly list when not to use it or name alternatives, so it falls just short of a 5.

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

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

No annotations are provided, so the description carries the burden; it discloses that all live checks run in parallel, that a knowledge-base search is included, and that the output is a single structured report. It does not mention potential side effects or error behavior, but for a read-only diagnostic this 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.

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

Two sentences, with the main function front-loaded and the usage alternative in the second sentence. 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?

For a tool with two simple parameters and no annotations, the description gives a good picture of scope, execution, and output. It stops short of detailing report contents or expected runtime, but an agent can call it correctly with the provided information.

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 description only echoes the two parameters without adding syntax or constraints beyond what the schema already provides. 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 'diagnose', identifies the resource (hosting issue via URL + symptom), and lists the exact checks run. Explicitly positions itself as the main entry point, distinguishing it from the check_* / search_troubleshooting_kb siblings.

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?

Explicitly instructs to use this tool first for open-ended 'why is my site doing X' questions, and names the alternative tools for when the exact check is already known. This is a clear when/when-not directive.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses that the search uses hybrid vector + keyword retrieval and that the results are the most relevant notes, which is useful. It does not detail output format, pagination, rate limits, or failure behavior, but none of those are critical for a simple, clearly read-only search tool.

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 with no wasted words. The main action and resource are front-loaded, the example topics are packed into a parenthetical that adds signal without bloat, and the return behavior is stated clearly.

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 search tool with a fully documented schema and no output schema, the description is nearly sufficient. It covers what the tool searches, how the search works, and what it returns. The only gap is the absence of guidance on when to prefer it over the sibling 'diagnose' tool.

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%, with both 'query' and 'limit' already described in the schema. The description reinforces the purpose of the query by mentioning 'described symptom' but does not add meaningful parameter details beyond what the schema provides, so the baseline of 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 uses a specific verb ('Searches') and clearly identifies the resource: a curated knowledge base of hosting/web-server troubleshooting notes. It names concrete topics and states the return value, and it is implicitly distinguishable from sibling diagnostic tools because it retrieves documented notes rather than performing live checks.

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 when the agent has a symptom description and needs relevant knowledge-base notes, and the examples give a sense of applicability. However, it does not explicitly explain when to choose this tool over siblings like 'diagnose' or the specialized check tools, nor does it state any exclusions.

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