certdesk

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

Annotations only declare readOnly/openWorld/non-destructive; the description goes well beyond by disclosing the multi-vantage measurement method (Korean point A full chain + CRL, Korean point B, overseas point), that cross-point disagreement becomes a WARN, and that an unmeasurable server yields UNKNOWN with CT data as an estimate only, never OK. These are exactly the behavioral traits an agent needs before trusting a verdict.

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

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

Front-loaded with purpose and verdict, and every clause (checks list, measurement points, UNKNOWN rule, detail flag) carries information. It is a single dense block though; the long enumerated check list and compat list would scan faster as structured fragments rather than one paragraph.

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 multi-vantage network measurement tool this is complete: the verdict vocabulary, the checks performed, the point-disagreement rule, the failure mode, and the CT caveat are all stated, and an output schema exists so return structure need not be explained.

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 port, critDays, warnDays and detail are already documented in the schema. The description only restates the detail=true effect ("full chain in the text output") and adds nothing about threshold interaction or port inference beyond what the schema says, making 3 the correct 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?

States a specific verb and resource ("Check one domain's TLS certificate") and an explicit return contract ("verdict: status OK | WARN | CRITICAL | UNKNOWN"). It is clearly separable from siblings like check_expiry (registration expiry) or check_security (broader posture) because it names the exact scope: the chain the server actually serves.

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

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

Usage is implied through a detailed enumeration of what the tool covers, which lets an agent infer fit, and the UNKNOWN path is described. However, no sibling is named and there is no explicit when-to-use-this-instead-of guidance (e.g. versus check_expiry or explain_tls_error), so selection still requires inference.

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?

Annotations already carry the safety profile (readOnlyHint=true, openWorldHint=true, destructiveHint=false). The description adds value by enumerating the facts returned, helping an agent understand what this read operation produces. It aligns with the annotations and adds coverage context; it doesn't mention network latency or rate limits, but for a simple read tool with annotations present this is adequate.

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 dense sentence, front-loaded with the core purpose before a colon-delimited fact list. Every item in the enumeration earns its place and there is no filler, though the list runs long.

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 low-complexity: a single required parameter, no output schema, and no nested objects. Annotations cover the read-only safety profile, and the fact list gives a strong sense of the return coverage. Given the low complexity, nothing critical is missing for an agent to call this correctly.

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

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

Schema description coverage is 100% — the single 'domain' parameter is fully documented with an example in the schema. The description adds no format details beyond what the schema already provides, so the baseline of 3 applies. No additional parameter semantics are needed here.

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 (check) and resource (DNS and hosting facts) with a detailed enumeration of coverage: nameservers with provider, A/AAAA with ASN owner, CNAME, MX, CAA, SPF/DMARC, DNSSEC, registrar, and RDAP expiry. This differentiates it from siblings like check_certificate and check_dns_propagation. However, it doesn't explicitly separate itself from check_expiry, which also reports expiry, leaving minor ambiguity.

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 offers no guidance on when to use this tool versus its alternatives. check_dns_propagation (propagation status) and check_expiry (expiry only) overlap meaningfully with this tool's fact set, yet no exclusions or alternative routing is provided. An agent must infer usage from the fact list alone.

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?

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description nonetheless adds a genuinely useful behavioral trait the annotations cannot: the measurement vantage point is a Korean network, with named Korean ISP and public resolvers, which affects what results mean. It omits timing/polling behavior and expected latency.

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, front-loaded with the core action and the resolver set before the use case. The parenthetical resolver list (KT, SK Broadband, LG U+, Cloudflare, Google, Quad9, OpenDNS) is long but earns its place by defining measurement scope.

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, so the description carries the burden of explaining what comes back; it never says whether the result is a match/mismatch verdict or a per-resolver answer list. It is adequate for selection but leaves the agent guessing about the return shape and about how long propagation checks may take.

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 50%: name is documented in the schema, while type has only an enum and no description. The description compensates partially by showing a record-name example (_acme-challenge.example.com) and highlighting TXT/CNAME, but adds no guidance on why a given type matters or on record-name formatting rules. Baseline 3 for a half-documented schema.

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

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

The description gives a specific verb (compare) and resource (answers for one DNS record) plus an explicit scope: authoritative nameservers, Korean ISPs, and public resolvers. That scope cleanly separates it from the generic-sounding sibling check_dns, so an agent can pick it without opening schemas.

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

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

It states a concrete use case: confirming a TXT/CNAME for certificate domain validation (e.g. _acme-challenge) has propagated. That is clear when-to-use guidance, but it names no alternative (e.g. check_dns, check_certificate) and gives no when-NOT-to-use condition.

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?

Annotations already cover read-only/open-world/non-destructive, and the description adds genuine context beyond them: certificate fields may be null when the server cannot be measured, registration expiry comes from RDAP, alert lines are Korean, and defaults shrink for short-lived certificates. It omits operational traits such as rate limits, caching, or latency for up to 5 domains.

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

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

Front-loads the core verdict semantics and status vocabulary before the use-case sentence; the two sentences are dense but earn their space. The first sentence is long and stacks several clauses (verification, days left, null case, RDAP, Korean lines), which slightly hurts scannability.

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

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

An output schema exists, so return-value detail is covered, and the description still explains what composes each status and how thresholds behave. Missing only environmental details (per-host rate limits, failure/null handling across a batch of 5), which are minor for this tool's complexity.

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%, including the warnDays/critDays defaults and the shrink-for-short-lived-certificates behavior, so the schema already carries parameter meaning. The description adds only the 'up to 5 domains' cap at the whole-tool level and no new syntax or format detail, making the baseline 3 correct.

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/resource pair ('verdict ... per domain') and enumerates the exact outputs (OK | WARN | CRITICAL | UNKNOWN). The batch scope ('up to 5 domains at once') and the combination of served-certificate and RDAP registration expiry are clear enough to separate it from single-purpose siblings like check_certificate or watch_expiry.

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 names intended uses: inventories, CI gates ('fail unless status is OK'), and periodic checks. That is concrete context, but it never states when not to use it — e.g. no routing to check_certificate for deep single-domain detail or watch_expiry for continuous monitoring, which 'periodic checks' potentially overlaps.

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?

Annotations already establish read-only and non-destructive behavior, so the description adds valuable context: the tool uses a 'Korean network probe' for legacy TLS detection, checks specific security headers, and returns 'per-item pass/warn/fail and an overall grade'. This goes beyond the annotation safety profile and clarifies scope and output behavior.

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

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

The description is a single dense sentence with a front-loaded purpose and an early exclusion note ('no port scanning'). It packs a lot of specific detail into a structured list format without redundant wording, though it is slightly long.

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

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

With no output schema, the description appropriately discloses the return shape ('per-item pass/warn/fail and an overall grade'). It covers the main checks, the network probe behavior, and output format. It does not discuss error cases or timing, but for a single-parameter read-only tool this is sufficient.

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 only parameter, domain, is fully described in the schema ('Domain name, e.g. example.com'), giving 100% schema coverage. The description does not add parameter-level detail, but none is needed because the schema already covers it; this meets 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 clearly states a specific verb and resource: 'Security posture check of a web server', then enumerates exactly what is covered (TLS, headers, redirect, certificate strength). It also distinguishes itself from siblings by explicitly excluding port scanning and focusing on posture rather than DNS or certificate-only 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 gives clear context for when to use the tool: for a security posture assessment of a web server, including an explicit exclusion of port scanning. It does not name sibling alternatives such as check_certificate for deeper cert details, so it stops short of explicit routing guidance.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context: it works offline from a curated knowledge base, returns likely causes and fixes, and links to Korean step-by-step guides. This goes beyond the 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.

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

One dense sentence front-loads the action and then efficiently specifies supported sources, output contents, language, and offline behavior. Every part earns its place and there is 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 single-parameter read-only lookup tool, the description fully covers the input format, output contents, language, and operational constraint. The sibling tools are all checkers, so no additional routing guidance is needed.

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

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

Schema coverage is 100% and the schema already describes the single 'error' parameter with examples. The description adds context about supported error sources but no additional parameter-level constraints or format details, so the baseline of 3 applies.

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

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

The description states a specific verb ('Explain') and a clear resource ('TLS/SSL certificate error message'), and enumerates the supported source ecosystems. This distinguishes it from sibling tools that check certificates, DNS, or expiry rather than explaining an existing error.

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 clearly implies the trigger: when an agent has a TLS/SSL error string, this tool returns causes, fixes, and guides. It does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusions, but the input type and offline knowledge-base behavior provide strong contextual guidance.

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?

Annotations only give the generic readOnly=false/openWorld=true/idempotent=false/destructive=false profile; the description adds substantial operational behavior beyond that: double opt-in (monitoring starts only after link click), one confirmation email per address per 24 hours, post-confirmation alert delivery, and CT-log new-certificate alerting. It also clarifies the tool's non-destructive subscription semantics, consistent with destructiveHint=false.

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

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

Four dense sentences, front-loaded with the core action and scope before the caveats. Almost every clause carries information (alert scope, channels, CT alerting, opt-in flow, rate limit, consent rule), though it runs long for a single description and could lose a clause without loss.

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

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

With no output schema, the description carries the return/value burden and does so: it explains what triggers alerts, what channels receive them, and the confirmation flow. Together with the fully documented 6-parameter schema, an agent has everything needed to call it correctly and set user expectations.

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

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

Schema description coverage is 100% and the per-parameter descriptions are themselves very rich (contract end date, DCV method, '45/20' thresholds, webhook URL formats). The prose re-mentions the optional Slack/Discord/Telegram/webhook channel but adds no syntax or defaults the schema does not already carry, so the baseline 3 applies.

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

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

Opens with a precise verb+resource: 'Subscribe an email address to free daily expiry monitoring of up to 5 domains', and enumerates what is monitored (certificate, domain registration, security grade) plus alert channels. An agent immediately understands this is an ongoing subscription action, distinct from the one-shot check_* 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?

The subscription/ongoing nature implies when to use it over check_expiry, but no sibling is ever named and there is no explicit 'when-not-to-use' guidance. The ownership/consent constraint and the double opt-in caveat are stated, which is useful context, but routing to check_expiry for a one-time lookup is left to inference.

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