create_project

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

Annotations (readOnlyHint=false, destructiveHint=true) already indicate this is a mutating operation, and the description aligns with that by saying 'Creates'. It adds minimal behavioral context beyond the annotations, only clarifying the conceptual nature of a project. No additional details about permissions, side effects, or edge cases are provided, but the simple create operation is reasonably transparent given the annotations.

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 two sentences: the first states the core action, and the second defines the domain concept. Both sentences earn their place and no redundant information is included. It is front-loaded with the action verb, making it easy to parse.

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 simple create tool with one optional parameter, an output schema, and annotations, the description provides sufficient context. It explains what a project is, which helps the agent understand the effect of the operation. However, it omits any mention of what happens upon creation (e.g., whether the project is immediately available) or any prerequisites, though these may be covered by the output schema. Given the low complexity, this is nearly 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 input schema has 100% coverage: the single optional parameter 'title' has a clear description ('Optional. The title of the project.'). The tool description does not add any parameter-specific meaning beyond what the schema already provides, so the baseline score of 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 clearly states the action ('Creates') and the resource ('a new Stitch project'), while also defining what a project is (a container for UI designs and frontend code). This distinguishes it from sibling tools like create_design_system and delete_project. The verb+resource combination is specific and unambiguous.

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 does not explicitly state when to use this tool relative to alternatives. It implies the agent should use it to create a project, but there is no guidance on when not to use it or how it differs from create_design_system. The definition of a project provides some context, but no actionable usage instructions.

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