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

Annotations cover the safety profile (readOnly, non-destructive), and the description adds real value beyond them: 'Does not change saved designs' confirms no side effects despite using the export renderer, images may be downscaled, and output is inspection-only. Doesn't mention rate limits or return shape, but the key behavioral traits are disclosed.

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?

Three tight sentences, front-loaded with the core action and scoping, then limits, then the no-mutation guarantee. Almost every clause earns its place; 'including independent phone formats' is slightly cryptic but not wasteful.

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 render tool with no output schema, the description tells the agent what the output is (downscalable inspection images, not store exports), the per-request limits, and that designs are unchanged. Some param-level detail is missing but the calling agent has enough to invoke correctly.

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 moderate (63%) and the description adds the non-obvious cross-parameter constraint that only one platform/device/size/language may be used per request, which is not in the schema. The 'including independent phone formats' note adds meaning to device/displaySize. Undescribed params (device, displaySize, projectId) remain a minor gap.

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?

Specific verb (renders) and resource (selected screens of a saved screenshot variant), plus a clear scoping note that output is inspection imagery rather than store-delivery exports. It distinguishes the output kind but does not explicitly contrast with the sibling render_screenshots, leaving that inference to the agent.

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 line 'not store-delivery exports' hints that render_screenshots is the delivery path, but it never names that sibling or states when to prefer each. Constraints like 'one platform, device, size and language per request' and 'at most ten screens' give usable context but are not framed as when-to-use guidance.

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