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

Beyond the readOnly/idempotent annotations, the description discloses the real behavioral trait: this tool produces a user-visible artifact in the chat (screens they can enlarge, add to the chat, or open in Sleek). It also documents graceful degradation to names-only output in non-rendering clients and states what is returned.

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?

It is front-loaded with the core action and every sentence carries information (trigger, degradation, return contract). Slight cost for the mid-sentence interactive-capabilities clause, which is useful but slightly less essential than the rest.

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 two-parameter render tool with an output schema and full annotation coverage, the description covers the trigger, the fallback path, the screenId handoff to design, and return contents. An agent has everything needed to decide to call it and how to interpret 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?

Schema coverage is 100%, so both parameters are already documented, including runId's origin in data.runId. The description only adds the timing context for runId and restates the screenId interoperability, so baseline 3 is appropriate.

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 names a specific verb and resource ("Shows your user a project's screens inline, in canvas order") and immediately differentiates itself from the read-only data siblings by emphasizing user-facing inline rendering. It also explicitly names the sibling it defers to in degraded clients ("use screenshot to see the screens").

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?

It gives a concrete trigger for the optional parameter ("After a design run completes, call it with that runId to show what the run made") and an explicit fallback condition for clients that cannot render apps. What's missing is a direct comparison against the closer siblings get_project and get_project_view, which an agent must still infer.

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