ssl_checker

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'SSL Checker' reveals nothing about what the tool actually does operationally - whether it makes external requests, requires authentication, has rate limits, returns structured data or raw output, or what happens when invoked. For a tool that presumably interacts with external SSL infrastructure, this complete lack of behavioral information is inadequate.

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?

While technically concise with just two words, this is a case of harmful under-specification rather than effective brevity. The description fails to provide any meaningful information about the tool's function, making it inefficient for an AI agent. Every word should earn its place, but here the words don't provide actionable information.

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 likely complexity (checking SSL certificates involves multiple technical aspects), the absence of annotations, no output schema, and a completely inadequate description, this is severely incomplete. The description fails to explain what the tool returns, what aspects of SSL it examines, or how to interpret results. For a technical checking tool, this minimal description is completely inadequate.

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 has 100% description coverage with a clear parameter 'domain' and example value. The description adds no additional parameter information beyond what the schema provides. Since schema_description_coverage is high (>80%), the baseline score of 3 is appropriate - the schema does the heavy lifting, and the description doesn't compensate or add value.

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 'SSL Checker' is a tautology that merely restates the tool name without specifying what it actually does. It doesn't indicate what aspect of SSL is being checked (certificate validity, expiration, configuration, etc.) or what action the tool performs. No verb is present to distinguish this from its many sibling tools that also perform various domain/website 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 provides absolutely no guidance about when to use this tool versus alternatives. With numerous sibling tools performing various domain-related checks (DNS records, HTTP headers, hosting, etc.), there's no indication whether this should be used for SSL certificate validation, security assessment, or other purposes. No context, prerequisites, 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.