view

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

With no annotations provided, the description carries the full burden—and it delivers: it discloses that the URL stays live and re-renders on `edit`, that pinning freezes a revision, and that human saves create new revisions with engine-computed change summaries. It also warns against re-emitting a fresh URL every turn, which is exactly the kind of non-obvious behavior an agent needs.

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 dense but every sentence earns its place: core behavior, the critical 'emit once' instruction, the pin variant, and the downstream save/revision loop. The most important operational guidance is front-loaded, and there is no filler.

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, so the description must explain what is returned—and it does (a stable URL, or a frozen permalink when pinned). It also covers the lifecycle after the human saves, which is essential for the agent to continue from the right revision. Given the tool's moderate complexity, nothing critical is missing.

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 the baseline is 3, but the description adds real meaning beyond the schema: it translates `pin: true` into a 'frozen permalink' and ties it to concrete use cases like 'look at exactly this' or comparing revisions. It also clarifies that any revision resolves to its root and opens at the design head.

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 and resource: 'Get a URL the human can open to view and edit the design in CE.SDK.' It clearly distinguishes the tool's core output (a stable, live design URL) from the surrounding editing/management tools and explains the two modes (live vs pinned).

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 gives clear usage context: emit the live URL once, avoid re-emitting every turn, and use `pin: true` for exact revisions or comparisons. It doesn't explicitly name sibling alternatives or state when not to use this tool, but it provides strong operational guidance for the main decision point.

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