create_task

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

Annotations already declare this is a non-read-only, non-destructive, closed-world operation; the description adds that the call dispatches the first step and blocks/wait for settlement, and documents the post-call contract around action_required and meeting_mode_notice. It does not spell out failure modes or what state is created on error, so it falls short of full transparency but clearly exceeds the annotation baseline.

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 most decision-relevant fact (alias of start_project_request, prefer the original) is front-loaded, and the remainder is conditional post-call handling. It is dense rather than padded, though the turn-management instructions ("do NOT end your turn", verbatim first line) are verbose relative to the tool's own semantics.

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?

An output schema exists, so return values need no explanation, and the annotations cover the safety profile. What remains for the description to supply, namely sibling routing, blocking behavior, and required follow-up on action_required/meeting_mode_notice, is all present.

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 100%, so every parameter already carries its own documentation, including the note that task_id is ignored. The description repeats the task_id-ignored point and adds nothing about workflow, acceptance, project_id, requirement, or wait_seconds beyond what the schema states, so baseline 3 applies.

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 names the concrete operation ("start a NEW project request, dispatch the first step, and wait") and explicitly frames the tool as a compatibility alias of start_project_request, so an agent can distinguish it from the sibling that should normally be used.

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 routing guidance ("Prefer start_project_request"), an explicit prohibition ("Never use it to continue an existing task"), and a downstream rule ("Do not call dispatch_agent again; continue according to workflow"). The only minor ambiguity is that it never says why the alias still exists, but the when/when-not picture is complete.

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