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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the exact checks performed (live TLS, reachability, no off-domain redirect, registration age disclosed), the output artifacts (Observation Log record, live badge, status URL), the 90-day validity, the limitation that Onyx does not claim honesty/safety, and the badge-serving mechanism to prevent faking. This goes well beyond inferable behavior.

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 verbose and includes marketing-style phrasing and an analogy (like a CA certificate). While the core purpose is front-loaded, the text is a dense paragraph with multiple clauses. Some sentences could be tightened without losing important details, so it earns a 3 rather than higher.

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 explains the main outputs and context well, including what happens on pass, the queryable endpoint, the badge, and the status URL. However, there is no output schema and the description does not specify the exact function return value (e.g., JSON success object). Given the tool's side-effect nature, the coverage is strong but not fully complete, so a 4 is appropriate.

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 100%, so baseline is 3. The description does not add significant parameter-specific meaning beyond what the schema already provides for domain, contact, and agent_id. It mentions 'your domain' but does not elaborate on contact or agent_id usage.

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's function: to get a domain Onyx Verified by running objective checks and issuing a signed record upon pass. It specifies the resource (domain) and the verb (verify/issue), and it distinguishes from sibling tools by focusing on domain verification issuance rather than verification of existing attestations or fact-checking.

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 clear usage context: domain owners use this to get verified so agents can trust them before payment. It mentions the use case and even the price/tier, but it does not explicitly name alternatives or exclusions (e.g., when not to use this vs. onyx_attestation_verify), so it stops short of a 5.

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