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

Far exceeds the annotations: it discloses fresh identifiers, the 'created' vs 'already-created' states, idempotency-via-cloneID retry semantics, rollback on mid-way failure ('removes the half-created survey and reports that nothing was created'), and readback verification. The annotation idempotentHint=false is not contradicted but refined — the tool is only idempotent when cloneID is supplied.

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?

Core action and source addressing are front-loaded, and each sentence carries functional content (states, retry, rollback, readback). It is dense and slightly over-long — the readback sentence restates return values already implied — but nothing is filler.

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 mutation tool with a full input schema and an output schema, this covers everything an agent needs: how to identify the source, how to make retries safe, what states to expect, and how failures are handled.

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, but the description adds genuine meaning: sourceCode/sourceSurveyID are mutually exclusive alternatives for identifying the source, and cloneID's role as the idempotency key for safe retries is spelled out behaviorally rather than just as a UUID format.

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?

Specific verb (clone) + resource (survey) + explicit scope: a complete copy including pages, questions, logic, quotas and translations, landing as a fresh NOT-yet-started publication. This plainly distinguishes it from create_survey and the other siblings without needing the schema.

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?

Gives clear operating context: the source is addressed by sourceCode or sourceSurveyID (the latter from list_surveys) and must belong to the account or be a public example survey, plus an explicit retry-with-same-cloneID recipe after a timeout. It stops short of naming an alternative tool for the non-duplicate creation case, so it is strong context rather than full routing.

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