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

Annotations already establish read-only/idempotent/non-destructive behavior. The description adds meaningful behavioral context by revealing the calculation inputs, the 0-100 scale, and the band outputs, without contradicting the annotations. It stops short of disclosing potential latency, data freshness, or error conditions, but the annotation coverage lowers the burden.

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 dense sentences: the first front-loads what the tool computes and returns, the second adds a clear use case. No filler, repeated schema content, or vague boilerplate. Every clause earns its place.

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 adequately describes the return value (score, band, contributing factors) and the input context. It covers the main behavioral scope and use case for a single-parameter read-only tool. Slight gaps remain around domain input formatting and edge-case behavior, but nothing critical for a fraud-screening call 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 0%, so the description carries the burden, but the only parameter (domain) is self-evident from the tool name and schema. The description refers to 'domain age' and the overall purpose, implicitly confirming the input is a domain, yet it adds no format details (e.g., no protocol, punycode, or subdomain handling). This is adequate but not compensating beyond the obvious.

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 returns a composite 0-100 reputation score for a domain, listing the specific factors (domain age, registrar tier, expiration window, security grade, NS diversity, hosting tier) and outputs (band + contributing factors). This verb+resource+scope formulation distinguishes it from siblings like dns_lookup or dns_whois, which are unlikely to produce a scored band.

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 phrase 'Designed for fraud-screening pipelines' gives clear intended use context, signaling when an agent should pick this tool (domain reputation assessment for fraud risk). It does not explicitly name alternatives or when not to use it, but the context is specific enough to guide selection among the many sibling DNS/site/risk tools.

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