design_start

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

No annotations are provided, so the description carries the full behavioral disclosure burden. 'Start or resume' implies a state-changing operation, but it does not disclose side effects, required permissions, what happens to an existing design on resume, whether validation occurs, or how approval_text is used. This is a significant transparency gap for a mutation-like tool.

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, compact sentence with no filler words; the main action and condition are front-loaded. It loses a point only because it is so terse that it omits information the agent needs, but judged purely on conciseness and structure, it is 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?

This is a complex tool with 7 parameters, 6 required, no annotations, and 0% schema coverage, yet the description provides almost no operational context. While an output schema exists, it does not offset the absence of parameter semantics, behavioral side effects, or workflow guidance. The description is far from sufficient for correct invocation.

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 description coverage is 0% and there are 7 parameters, yet the description adds no parameter-level meaning. It only alludes to 'natural-language direction approval,' which loosely maps to approval_text, but design_id, title, model_classification, requirements_json, proposal_summary, and source_path are entirely unexplained. The description fails to compensate for the absent schema descriptions.

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 clearly states the action ('Start or resume a design') and the triggering condition ('after natural-language direction approval'). It is a specific verb+resource statement, though it does not explicitly contrast itself with sibling tools like design_confirm or design_status, so it falls just short of full sibling differentiation.

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 phrase 'after natural-language direction approval' gives an implied usage context: the tool should be invoked once approval has been obtained. However, there is no explicit guidance about when not to use it, when to use design_confirm instead, or what prerequisites must be satisfied (e.g., whether design_id must already exist for resume).

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