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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds useful behavioral detail: it enumerates the status categories (building, ready, live, needs paid plan) and explains that waitSeconds causes the answer to wait for a running build to finish first. This goes beyond the annotations by disclosing wait semantics and output categories.

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 compact and front-loads the core purpose before covering the optional waitSeconds behavior. It is appropriately sized for a two-parameter read tool. The first sentence is dense but every element listed corresponds to a meaningful output category.

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 low complexity, full schema coverage, annotations covering the safety profile, and the presence of an output schema, the description is nearly complete. It explains what is returned and the wait behavior. The main missing element is explicit routing guidance relative to sibling tools, but that is a minor gap for a straightforward single-site retrieval tool.

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 both parameters are already well documented in the schema. The description reinforces waitSeconds by stating that the answer waits up to 20 seconds for a running build to finish, but it adds little beyond what the schema already says. The baseline score of 3 is appropriate when the schema carries the parameter documentation burden.

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 that the tool reports on a single website, enumerating its status, links, builder message, and suggested changes. It implies a read-only retrieval purpose and distinguishes itself from list_sites by focusing on one site. However, it does not explicitly name any sibling tool or contrast its role with alternatives like create_site or publish_site.

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 offers no guidance on when to use this tool versus alternatives such as list_sites or change_site. It only describes what information is returned and the optional wait behavior. There is no mention of prerequisites or contexts that would select this tool over another.

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