TLS Radar

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

Annotations already declare idempotentHint=true, so the description adds the authentication requirement and the limit-reached payload behavior. This is useful but limited; no details on whether the operation is safe or what exactly happens on success.

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 front-loaded with the core purpose. The second paragraph is detailed but arguably excessive for a description; however, it provides actionable guidance. Could be slightly more concise.

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?

Given the simple input (one parameter with full schema coverage) and the presence of an output schema, the description covers the main functionality and a key edge case (limit reached). It feels complete for this tool's interface.

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% with a clear description for the single parameter 'domain'. The tool description adds no additional meaning beyond the schema's parameter description.

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 the action ('Add a domain to ongoing certificate monitoring with expiry alerts'), which is specific and distinguishes from sibling tools like 'add_monitors' (plural bulk add) and 'remove_monitor'.

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 mentions authentication requirement and provides detailed instructions for handling the plan limit scenario, including how to present upgrade options. However, it does not contrast with alternatives like 'add_monitors' or 'remove_monitor' for different use cases.

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?

Beyond annotations (readOnlyHint=false, idempotentHint=true), the description reveals that the tool returns per-domain status for partial success and enforces plan-limit checks. This adds valuable behavioral context not present in structured fields.

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, front-loaded with the primary action, and contains no unnecessary information. Every sentence adds value.

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

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

Given the existence of an output schema (not shown), the description adequately covers tool purpose, behavior, and constraints. It references sibling add_monitor for alignment and mentions plan-limit checks, providing sufficient context for an agent.

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% with a description for the 'domains' parameter. The tool description does not add further details about parameter meaning beyond restating the purpose; it is at the baseline for full coverage.

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 the verb 'Add', the resource 'multiple domains to monitoring', and distinguishes from the sibling 'add_monitor' by focusing on batch operation. It also mentions returning per-domain status for partial success, which adds specificity.

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 says it 'Honors the same plan-limit checks as add_monitor', providing context about constraints. It implies use when adding multiple domains at once, but does not explicitly state when not to use or provide alternatives.

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, idempotentHint, openWorldHint. Description adds that it returns per-record resolver results and the polling condition, going 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.

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

Two sentences, front-loaded with the verb and resource. Every sentence adds value—no wasted words.

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?

Given the tool has only one parameter, rich annotations, and an output schema, the description provides sufficient context including the return type and the condition to proceed.

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% for the single required parameter. Description adds context by specifying 'The order_id from create_certificate', linking it to the previous step.

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?

Description clearly states it checks DNS TXT record propagation for a certificate order, specifies it is step 2 of issuance, and instructs to poll until all_found is true then call finalize_certificate. It distinguishes from sibling tools like create_certificate and finalize_certificate.

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 states when to use (after create_certificate, before finalize_certificate) and the polling pattern. Mentions the resolvers used. Lacks explicit 'when not to use' but the context is clear.

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?

Beyond annotations indicating non-readonly and non-destructive, description discloses that issuing automatically starts monitoring with email, and to not add a monitor manually. Also explains the multi-step process and return values.

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?

Description is front-loaded with a clear one-liner, then details challenge options, return values, next steps, and additional guidance. Every sentence adds value without redundancy.

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

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

Given 5 parameters, existence of output schema, and sibling tools, the description is complete: it explains purpose, parameters, steps, return values, and even warns against redundant monitor addition. Output schema exists so return values need not be fully described.

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% with descriptions, but description adds semantics: domain format (apex, no scheme/www), challenge implications (dns-01 covers apex+www, http-01 exact domain), client_id behavior (optional, if omitted response provides ID), and marketing_consent default.

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 it starts issuing a Let's Encrypt certificate and is step 1 of 3, distinguishing it from sibling tools like check_certificate_propagation and finalize_certificate. It also explains validation methods and next steps.

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?

Description explicitly says when to use this tool (step 1), what to do next (poll propagation, then finalize), and when to choose each challenge method. Also recommends CSR path at finalize.

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 idempotentHint=true. The description adds critical safety information: 'Tokens and PII are NEVER included — only domain configuration.' This goes beyond annotations and is highly valuable for an agent to avoid privacy risks. No contradictions.

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, each earning its place. The first sentence defines the core purpose, the second adds a crucial behavioral caveat. No fluff, perfectly front-loaded.

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

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

Given the tool's simplicity (no parameters), the presence of an output schema covering return values, and the annotations, the description is complete. It covers safety (PII exclusion) and use cases. No gaps detected.

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 tool has no parameters, and schema description coverage is 100%. Per guidelines, baseline is 4 for zero parameters. The description does not need to add parameter details since none exist.

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 the verb 'dump' and the resource 'monitors', specifying the output format (JSON) and use cases (backup, migration, IaC). It effectively distinguishes from siblings like 'list_monitors' and 'import_monitors' by emphasizing the export-oriented purpose.

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 mentions suitable use cases: backup, migration, and infrastructure-as-code workflows. While it does not provide negative guidance or explicitly name alternatives, the context signals and sibling tools imply clear differentiation. A score of 4 reflects clear context without exclusions.

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?

The description discloses all key behavioral traits: validates DNS challenges, waits for Let's Encrypt, side effect of automatic monitoring handoff, idempotent nature (can be retried), and environment dependency on local openssl. Annotations already indicate idempotent and open-world, and description aligns without contradiction.

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 front-loaded with the main purpose, uses paragraphs for different aspects, and every sentence adds value. Slightly verbose but justified by complexity; could be more structured but remains clear and informative.

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?

Given the tool's complexity (5 parameters, side effects, environment constraints), the description covers all necessary aspects: purpose, usage, parameters, behavior, error handling, return values, and post-success actions. It is fully complete even without seeing the output schema.

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

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

Schema coverage is 100%, and the description adds significant context: emphasizes CSR over passphrase, explains resume_token for purged orders, and specifies default/cap for max_wait_seconds. This helps agents make informed parameter choices beyond schema descriptions.

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 the tool finalizes and issues a certificate order in one call, and explicitly places it as step 3 of issuance, distinguishing it from sibling tools like create_certificate (step 1) and check_certificate_propagation (step 2).

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 provides explicit when-to-use guidance ('call after check_certificate_propagation reports all_found'), alternative actions if DNS hasn't propagated, parameter preference (CSR vs passphrase), environment constraints, and a warning not to separately call add_monitor. This is comprehensive and actionable.

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 provide readOnlyHint and idempotentHint, so the description does not need to repeat those. The description adds business context but no additional behavioral traits (e.g., caching, rate limits), which is acceptable for a simple read-only 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?

The description is a single sentence that front-loads the action and resource, followed by the purpose. No unnecessary words; highly concise.

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 zero-parameter, read-only tool with output schema, the description fully conveys what it does and why. No gaps in context.

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?

Input schema has zero parameters, so schema coverage is 100%. The description adds no parameter info, but none is needed. Baseline score 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 specifies the verb 'Return' and the resource 'current user's plan, limits, and usage' with a clear business purpose ('so the client can render upgrade nudges proactively'). This clearly distinguishes it from sibling tools focused on monitors and certificates.

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 its usage context (when account-level info is needed) but does not explicitly state when not to use or provide alternatives. However, given the sibling set, the tool's purpose is distinct enough.

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, openWorldHint=true, and idempotentHint=true. The description adds behavioral context by specifying the returned states (dns_pending, validating, ready, completed, failed) and per-authorization statuses, enhancing transparency without contradicting annotations.

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 core functionality and a usage hint. Every word earns its place; no redundancy or fluff.

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 one parameter, rich annotations, and an output schema (though not shown, it's indicated), the description is sufficient. It clearly explains the tool's purpose and usage context, making it complete for an AI agent.

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%, but the description adds meaning by specifying that the 'order_id' parameter comes from 'create_certificate' and by listing the returned states, which clarifies the parameter's role in fetching status.

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 it returns the current state of a certificate order, listing possible states and per-authorization statuses. It uses the specific verb 'Return' and identifies the resource as 'certificate order status', distinguishing it from sibling tools like 'check_certificate_propagation' or 'create_certificate'.

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 it to resume an interrupted issuance', providing clear when-to-use guidance. While it doesn't explicitly state when not to use it, the context of resumption and the sibling tool set make the usage context clear.

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 convey read-only and idempotent behavior. The description adds context about returning 'recent' results for monitored domains, but does not elaborate on what 'recent means or any pagination limits. It partially compensates for the lack of annotation detail.

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 concise sentences provide all necessary information without redundancy. Every word adds value.

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

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

The description is complete for a read-only query tool with an output schema (not shown). It covers what the tool does and its typical use cases, but could briefly mention the optional limit parameter or the concept of historical data.

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%, so the schema fully documents both parameters. The description adds no additional details beyond mentioning 'domain the user monitors' which is already in the schema. Baseline score 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?

Clear verb 'Return' and resource 'recent scan results' are specified, with explicit use cases (issuer changes, grade drops, vulnerability appearances) that distinguish it from siblings like scan_domain (which initiates scans) or list_monitors (which lists domains).

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 mentions it is 'useful for spotting' specific changes, providing clear context for when to use it. However, it does not explicitly state when not to use it or name alternative tools for other scenarios.

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?

Discloses key behaviors beyond annotations: skips existing domains, honors domain limit, returns per-domain status. No contradiction with annotations (idempotentHint=true).

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 concise sentences convey the purpose, source, and behavior with no waste. Front-loaded with action and key details.

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?

Given the simple parameter structure and existence of output schema, the description covers essential details: source of input, duplicate handling, limit enforcement, and return status.

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 adds no additional meaning beyond the schema's own description of the payload parameter. 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?

Clearly states the tool creates monitors from a JSON structure produced by export, which is a specific verb-resource pair. Differentiates from siblings like add_monitor (single) by implying batch import.

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?

Mentions that the input is typically from the export tool, giving context for when to use it. However, does not explicitly contrast with alternatives like add_monitor for single additions.

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 indicate mutation (readOnlyHint=true? Actually readOnlyHint=false, so mutation). Description adds critical detail: returns upgrade payload on seat limit hit, which mirrors add_monitor behavior. No contradictions.

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, highly efficient. First sentence states purpose and mechanism; second adds important behavioral constraint. No冗余.

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?

Covers purpose, default behavior, and seat limit behavior. Does not mention prerequisites (e.g., authorization) or duplicate invite handling, but output schema exists so return value clarity is not required.

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%, baseline 3. Description adds 'by email' and 'defaults to current team', reinforcing parameter context beyond schema definitions.

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?

Clear verb 'Invite' with specific resource 'a user to a team' and mechanism 'by email'. Distinct from sibling tools, all of which deal with monitors or certificates.

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?

States default behavior ('Defaults to the user's current team') and edge case ('Honors the plan's seat limit...'). No explicit when-not-to-use, but siblings offer no direct alternative for inviting team members.

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 and idempotentHint, indicating safe, non-destructive behavior. The description adds behavioral context about handling a 'nudge' object in the response, advising a one-time mention of upgrades. It also discloses the default look-ahead of 30 days.

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 three sentences, with the core purpose in the first sentence and additional behavior in the second and third. It is front-loaded and avoids unnecessary detail, though the nudge instruction could be considered domain-specific.

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?

Given the output schema exists, the description adequately covers the tool's purpose and key behavioral nuance (nudge object). It does not explain pagination or empty results, but for a simple list tool, it is sufficiently 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?

The input schema fully describes the single parameter 'within' with type, default, bounds, and description. The description only echoes the default of 30, adding no extra semantic value beyond the 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 clearly states 'Return monitored certificates expiring within N days' with a default of 30, which is a specific verb and resource. The tool name and context distinguish it from sibling tools like list_monitors and get_certificate_status.

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 provides no guidance on when to use this tool versus siblings, such as list_monitors or check_certificate_propagation. It does not specify prerequisites or alternatives.

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?

The description goes beyond annotations by disclosing the nudge object behavior and providing handling instructions. It confirms read-only and idempotent nature, adding valuable context that annotations alone do not cover.

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 front-loaded with the main purpose, but the second sentence on nudge handling is somewhat lengthy. Still, every sentence adds value, and it remains concise overall.

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?

Given no parameters and presence of an output schema, the description adequately covers the tool's purpose, scope, and special response behavior. No missing context needed for correct usage.

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

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

There are no parameters, so the description does not need to add parameter info. According to guidelines, zero parameters gets a baseline of 4, and the description does not detract.

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 the tool lists all monitored certificates across teams. It uses a specific verb ('list') and resource ('certificates'), and is easily distinguishable from sibling tools like add_monitor or remove_monitor.

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

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

No explicit guidance is given on when to use this tool versus alternatives (e.g., list_expiring_certificates). The description focuses on how to handle the response but not on choosing this tool over others.

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?

Description states the tool is 'idempotent and harmless', consistent with the idempotentHint annotation. While readOnlyHint is false, the description clarifies it has no side effects in practice. Missing explicit mention of it being a no-op, but still transparent enough.

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?

A single sentence conveys all necessary information: obsolete status, reason, and alternative. No wasted words, front-loads the critical 'do not call' directive.

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 an obsolete tool, the description is complete: it explains why it exists (backward compatibility) and directs to the correct modern tool. The existence of an output schema is irrelevant since the tool should not be called.

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%, so the schema already documents all parameters. The description does not add any additional semantic info beyond noting the tool is obsolete. Baseline score 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 explicitly states the tool is obsolete and should not be called, clearly identifying it as a backward-compatibility stub. It distinguishes from siblings by explaining the modern replacement (create_certificate).

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 explicit guidance: 'do not call', explains why it's kept (old plugin versions), and points to the correct alternative (create_certificate). This covers both when-not-to-use and what to use instead.

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 provide destructiveHint=true and idempotentHint=true. Description adds that it accepts domain or host_id, which is useful behavior context. 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.

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

Two sentences, action first, no redundant words. Efficiently conveys the tool's purpose and parameter options.

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 simple tool with output schema (existence noted), description sufficiently covers what the tool does and acceptable inputs. Could mention idempotency but annotations cover that.

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 both parameters have descriptions. Description restates the acceptable inputs but adds no additional semantics beyond the 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?

Clearly states 'Stop monitoring a domain' with specific verb and resource. Distinguishes from sibling tools like add_monitor and list_monitors by focusing on removal.

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?

Implies usage (when you want to stop monitoring), but no explicit when-not or alternative tools. Siblings include only add_monitor and list_monitors, so context is clear but not formally guided.

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?

Discloses that it clones a recent order, notes that orders are purged after ~24h, and that it returns a new order_id and DNS TXT records. No contradiction with annotations (readOnlyHint=false, idempotentHint=false). All behavioral traits are covered.

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 concise and front-loaded, but the second sentence is somewhat lengthy. However, every part adds value, and there is no fluff.

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?

Given the tool's complexity, the description fully covers purpose, prerequisites, output, and next steps. It complements the schema and annotations well.

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

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

Only one parameter (order_id) is described in both schema and description. The description adds value by explaining the requirement and the 24h purge constraint, which is not in the 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 clearly states 'Renew a certificate by cloning a recent order', specifying the verb and resource. It distinguishes from the sibling tool create_certificate by explaining when to use each.

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 tells when to use (when you have an order_id) and when not to (if you don't, use create_certificate). Also outlines the post-call steps: polling check_certificate_propagation and finalize_certificate.

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 openWorldHint=true. The description adds value by confirming the scan is free, anonymous, and requires no account, which clarifies the authentication and cost model. This goes beyond the annotations' safety indicators, providing concrete behavioral context.

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

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

Two short sentences that are front-loaded with the core action. Every word is functional: 'Run a free, anonymous SSL/TLS scan against a hostname and return certificate details. No account required.' No filler or redundancy.

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

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

The description covers the essential purpose and distinguishes usage style (free, no account). With annotations and an output schema present, the agent can infer safety and response structure. It lacks mention of potential constraints (e.g., public domain only), but is sufficient for a simple scanning 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 coverage is 100% with clear descriptions for both parameters (domain and client_id). The description does not add new semantic meaning beyond reinforcing that the domain is a hostname and the scan is anonymous. 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 clearly states the action ('Run a free, anonymous SSL/TLS scan'), the target ('a hostname'), and the result ('return certificate details'). It distinctly differentiates from sibling tools like check_certificate_propagation or get_certificate_status by emphasizing anonymity and no account requirement.

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 provides no explicit guidance on when to use this tool versus alternatives. While it implies a quick, anonymous scan, it does not mention related tools like get_certificate_status or check_certificate_propagation for comparison, nor does it state any prerequisites or limitations (e.g., public hostname only).

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