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

Annotations already declare readOnlyHint and openWorldHint, but the description adds substantial context they don't cover: a rate limit and pricing model (3 free calls/day across all tools, then $0.005 USDC via x402 or card credits, paid in-band via params._meta), the upstream providers and their fallback order, and the fact that only currently valid certificates are returned, newest first. These are exactly the operational facts an agent needs before calling a paid external 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 core purpose sentence is dense and informative, but the definition is bloated by pricing boilerplate placed before the purpose, and the closing "When to use" sentence repeats what the earlier sentences already said. Content is present but not efficiently ordered or de-duplicated.

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 an output schema present and read-only annotations set, the description covers the remaining essentials: data source, filtering semantics (valid certs only), ordering, and cost model. Minor gaps remain around behavior when no certificates exist or when the fallback provider also fails, but nothing critical to correct invocation is missing.

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 single parameter already documents "exact hostname, e.g. www.example.com." The description only echoes "for a hostname" and does not clarify edge cases (bare domain vs. www, wildcard handling, IP addresses), so the schema does the real work 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 and resource (TLS/SSL certificate check for a hostname) plus the data source (Certificate Transparency logs via Cert Spotter, crt.sh fallback) and exactly what is returned: issuer, validity dates, days left, SAN names, expiring flag. This clearly separates it from siblings like dns, domain_whois, or page_check without opening their 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 gives a use context ("expiry monitoring and phishing/subdomain vetting") and a "When to use" line, but that line merely restates the purpose rather than contrasting with alternatives such as dns, domain_whois, or link_check. No exclusions or negative conditions are offered, so usage is implied rather than disambiguated.

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