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

Annotations already establish that this is a non-destructive write in a closed world, and the description adds real context beyond them: the project is created empty and then opened (a state change affecting the active project), and it inherits a brand kit when created inside such a folder. It omits behavior on name collisions and whether the new project becomes the working project persistently, so it stops short of full disclosure.

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?

Two short sentences, front-loaded with the primary action and followed by the one non-obvious behavior. There is no filler or redundancy.

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 creation tool with no output schema and four parameters, the definition covers the core action and the brand-kit inheritance, but leaves two parameters (name, fps) unaddressed and says nothing about the returned project identifier or failure modes. An agent can call it, but must open the schema to understand half the inputs.

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 50%, with aspect and folder documented inline, but name and fps carry no schema description. The tool description does not compensate: it never explains what fps means for a new project or any constraints on name, and its folder reference only restates the brand-kit side effect rather than clarifying the folder parameter's create-if-missing behavior beyond the schema text.

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 states a specific verb and resource ("Create a new empty project") and adds a side effect ("open it"), which distinguishes it from open_project and duplicate_project without naming them. It is clear what the tool produces, though it never explicitly contrasts itself with those siblings.

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?

Usage is only implied by the verb "create"; there is no explicit when-to-use or when-not-to-use guidance against siblings like open_project or duplicate_project. The brand-kit sentence hints at a situational behavior but is framed as an outcome, not as a selection rule.

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