ecp_ssl_available_certificates

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

With no annotations supplied, the description carries the behavioral burden. The verb 'List' conveys that this is a read-only, non-mutating operation, which is useful. However, it does not describe the response shape, pagination, scoping behavior when parameters are omitted, or whether the listed certificates are ready to apply.

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 one sentence, front-loads the primary action and resource, and uses a parenthetical to show the certificate_name constraint. There is no filler or redundant restatement of the tool name.

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 output schema and no annotations, the description is thinner than the tool call requires: it doesn't define the returned certificate list contents, doesn't state required vs optional parameters clearly, and doesn't connect the output to how it should be used with the SSL apply/update siblings. The tool is simple, but the missing details leave room for misinvocation.

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 0%, so the description must compensate, but it only restates the enum values already in the schema and labels the resource as 'a domain.' It does not clarify whether domain is actually required, what happens if certificate_name is omitted, or what value each parameter should take beyond repeating the enum.

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 action ('List') and resource ('certificates available for a domain'), and the verb clearly separates this from the SSL request/update/apply sibling tools. It doesn't explicitly say what makes a certificate 'available' or how this relates to ecp_ssl_apply_certificate, so it is clear but not fully differentiated.

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 only guidance is to pass certificate_name; there is no statement of when to use this tool instead of ecp_ssl_request_lets_encrypt, ecp_ssl_update_lets_encrypt, or ecp_ssl_apply_certificate. No prerequisites, exclusions, or alternatives are given, so an agent receives no routing help beyond the verb.

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