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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description goes further and reveals a non-obvious behavioral quirk: the accessMode field is largely ignored on the marketing site, where collections are created append_only, and recipes that read their own collection show nothing until public_read is explicitly requested by name. This is exactly the kind of context that prevents a mistaken agent from assuming the listed mode is honored. It also notes that no site context is required.

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 a single, information-dense paragraph. It front-loads the purpose and usage, then adds the accessMode nuance and the 'No site needed' note. Every sentence contributes meaning; there is no filler. It is slightly long, but the complexity of the behavioral quirk justifies the length. It could arguably be split into a second sentence for readability, but it remains efficient.

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?

For a read-only list operation with no output schema, the description provides the essential behavioral context (accessMode nuance) and the usage pairing with apply_data_template. It does not specify the return format, but for a list tool the examples given are enough for an agent to infer what the list contains. The annotations cover safety, so nothing critical is missing. A brief note on the structure of the returned list would have made it a 5, but it is sufficiently complete.

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?

The schema documents the only parameter, workspace_id, with 100% coverage, including its optionality and the rules about which workspace it applies to. The description adds nothing about this parameter, which is acceptable because the schema already fully explains it. Baseline 3 applies when schema does the heavy lifting.

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 opens with a specific verb ('List') and a concrete resource ('ready-made data features'), then enumerates examples (contact form, waitlist, etc.) that make the scope unmistakable. It also names the companion tool (apply_data_template) that this one feeds into, which distinguishes it from the many other list_* siblings.

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 explicitly instructs 'Use with apply_data_template to add one to a site end-to-end,' giving a clear when-to-use context. It also states 'No site needed,' which clarifies the prerequisite. It does not explicitly name alternatives or exclusions, but the pairing with apply_data_template is sufficient guidance for an agent deciding whether to call this tool.

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