start_project

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

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds useful behavior: 'reset' semantics, the interactive prompt for the public :8080 URL when no Zeus URL is stored, and the gating rule — but it also instructs about a zeus_url parameter that does not exist in the schema, muddying the picture.

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 core purpose is front-loaded in one line, but it then sprawls into sample routing, alias disambiguation, gating notes, and URL guidance. The yelp/demo_yelp disambiguation is stated twice ('Not the yelp demo. Utterances yelp-demo / demo_yelp use sample=demo_yelp') and concerns are interleaved, so several sentences do not earn their place.

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 description does cover sample routing and multi-agent gating. Gaps remain: the three schema parameters have no descriptions, and the description references zeus_url (including a password warning) that the schema does not expose, leaving an agent unclear on what it can actually pass.

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 0% across all 3 parameters, so the description must carry the load. It does enumerate meaningful sample values (travel, beer, demo_yelp, api, yelp/multi) and explains goal=multi and force_multi, which is genuine added meaning. It still leaves the `goal` values under-specified and references a nonexistent zeus_url field, so it only partially compensates.

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 opening sentence gives a clear verb+resource: it starts or resets a first-app coaching checklist, with the single-agent default stated. However, sibling differentiation is muddled rather than clean — use_sample is described as an internal routing mechanism here rather than a distinct tool, and the yelp/demo_yelp distinction is repeated without clearly separating this tool's purpose from the sample-selection concern.

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 gives real conditions (multi-agent goals gated until single-agent smokes pass unless force_multi=true, and sample routing guidance). But this is guidance for parameter selection inside the tool, not when to choose start_project over siblings like next_step, explain_scope, or scaffold_app, so routing rivals remains implied.

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