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

Annotations are all false, so the description carries the full burden. It discloses that the tool selects the new project for navigation, returns a project_id that must be copied into later calls, and that selection does not start automatically for shorts. It also explains the required explicit story arcs for make_shorts. This is exceptionally transparent about side effects and workflow requirements.

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 paragraph with multiple sentences, but each sentence earns its place by covering a distinct aspect: creation, side effect, usage options, and the shorts workflow. It front-loads the primary purpose and then adds necessary detail. It is concise relative to the complexity of the tool.

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 tool with significant behavioral nuance (selection, shorts workflow, required project_id usage), the description covers the main points thoroughly. It does not explicitly mention the default kind ('edit') or error/edge cases, but the schema covers the default and the description provides enough to call the tool correctly in typical scenarios. Given the absence of an output schema, the mention of the returned project_id is helpful.

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% (only kind has a description). The tool description adds context for kind ('shorts' creates a Podcast to Shorts intake project) but this largely repeats the schema's own description. For title, no additional meaning is provided beyond the schema's bare string type. The description adds some value for kind but does not compensate for the missing title semantics, so a 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 states a specific verb ('create'), resource ('empty project'), and a side effect ('select it for navigation'). It clearly differentiates from siblings like open_project and list_projects by focusing on creation and selection, and it also explains the special 'shorts' kind. This is a precise, non-tautological purpose statement.

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 explicit usage context: after creation, upload with upload_start or build a canvas program; for shorts, it outlines the post-analysis workflow with make_shorts. It does not explicitly say 'use this instead of open_project', but the creation vs. existing distinction is implicit and clear enough for an agent to decide.

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