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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description still adds real value beyond them: what a pack contains, the credit cost and ~2 minute runtime versus generation, and the handoff to create_site. It does not cover whether the list is paginated or filtered, so it is solid but not exhaustive.

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?

Front-loaded with what a pack is, then the return shape, then the alternative — a sensible order with no filler sentences. The opening sentence is long and stacks an em-dash aside plus an example, which costs a little crispness against an otherwise tight ~100 words.

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?

There is no output schema, and the description compensates by naming the returned fields (slug, intake_questions with required markers) and their destination. For a one-optional-param read-only lister, an agent has everything needed to call it and act on the result.

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?

Only one optional parameter (user_goal) and schema description coverage is 100%, so the schema already carries the semantics; baseline 3 applies. The description adds meaning about the returned fields (slug, intake_questions and their required flags) and how they map to create_site's pack_slug/pack_intake, but says nothing extra about the input parameter itself.

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 ('List the ready-made businesses available to set up') and immediately disambiguates the concept from a design template: 'a whole working site for a kind of business ... rather than a design to fill in.' An agent can distinguish this from create_site_from_design, read_design, and create_site without opening any schema.

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?

Gives an explicit routing rule: 'Prefer this over create_site whenever the user describes a business shape we already ship,' and explains why (curated copy vs. generation, no credits, ~2 minutes). It also names the downstream tools (create_site with pack_slug/pack_intake, or spin_up_pack), so both the entry point and the follow-up action are unambiguous.

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