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

The annotations declare idempotentHint=true and destructiveHint=false, which are useful. The description adds the behavioral nuance that pausing stops data collection but does not release funds, which is not inferable from the annotations. It implies the survey remains in a resumable state. No contradiction with annotations; a minor gap is lack of detail on what happens if called on a non-live survey, but overall it adds value beyond the structured fields.

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 sentence of 13 words, front-loading the primary action and effect ('stops collecting') and mentioning the related tool. There is no fluff; every word earns its place, and the key point about funds is highlighted.

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 simplicity (one required parameter, no output schema, clear annotations), the description is quite complete. It explains the purpose, the side effect on funds, and the path to undo (resume_survey). Could mention the prerequisite that the survey must be live, but the phrase 'a live survey' implies that; it might benefit from stating what happens if called on a non-live survey, but such edge cases are often left out. Overall, it's adequate for an agent to call it correctly.

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?

The single parameter survey_id is already well-described in the schema with a clear type, minimum, and a reference to list_surveys, giving 100% schema coverage. The description does not add any additional parameter semantics, but with full schema coverage, the baseline of 3 is appropriate. The schema description covers the parameter's purpose and origin, so the description does not need to repeat it.

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 clearly states the action (pause) and the resource (a live survey), and adds the key effect: 'stops collecting; funds stay reserved'. It is distinct from siblings like close_survey, launch_survey, and resume_survey, making the tool's purpose unambiguous.

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 mentions the condition for use ('a live survey') and names the counterpart tool (resume_survey) for the opposite action. This direct routing helps an agent decide when to call this tool versus resume_survey or even close_survey, which has different implications.

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