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

The description meaningfully extends the annotations (readOnlyHint=false, destructive=false) by detailing cloning scope, title override semantics, and post-creation mutability. Crucially, it discloses non-idempotency and the retry-after-timeout risk with actionable guidance to check before retrying. This is exactly the behavioral context agents need beyond structured 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?

Four sentences, each earning its place: purpose plus template ID source, cloning scope and title override, post-creation workflow, and idempotency warning. Front-loaded with the primary action, then progressively operational details. No filler or repetition yields a tight, high-signal definition.

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?

Given the tool's moderate complexity and the presence of an output schema, the description covers everything needed to invoke it correctly: input format, where to get the ID, what gets cloned, why to prefer it, and what to do on timeout. The non-idempotency warning is especially valuable for reliable agent execution.

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. The description adds value by pointing to list_templates as the source for valid template IDs and by clarifying that title overrides the template title, paralleling the schema. It doesn't fully expand parameter meanings, but the added context is helpful and non-redundant.

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 precise verb-resource pair: 'Create a new form in the current team from a public template.' It also names the sibling tool it is not — create_form — and emphasizes this is the template-based pathway. Clear, unambiguous, and distinct from 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?

The description explicitly guides when to choose this tool: 'This is the fastest way to build a quiz when a suitable template exists — prefer it over building from scratch with create_form.' It also references list_templates for finding IDs and update_form/update_question for subsequent changes. It does not exhaustively state when not to use it (e.g., no template exists), but the context is clear enough.

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