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

Annotations already declare readOnlyHint=false, destructiveHint=true and idempotentHint=true, so the safety profile is known; the description adds valuable context beyond that: new version per answer, draft status, label requirement for questions found on the live form, that text is stored verbatim in the form's language, and the return shape. It does not explain why the tool is flagged destructive (e.g., whether prior draft versions are superseded or a live-form question is permanently added to the application), which is the one behavioral gap.

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?

Front-loaded with the core action and result state, then proceeds to per-field rules, return value, and permissions — a logical order with no filler. It is dense (four sentences of packed clauses) but every clause carries distinct information.

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 two-parameter mutation with no output schema, the definition covers action, resulting state, field semantics, return value ('the application as the extension reads it') and authorization ('applications:write and the Autopilot plan'). The remaining gap is the destructive side effect implied by destructiveHint=true, which an agent about to write 100 answers would want spelled out.

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%, so the description carries the full burden and largely meets it: it maps `text` to text questions, `choices` to radio/select/checkbox questions using option labels, and `label` to questions newly found on the live form. `questionKey` is never described, and none of the schema limits (5000-char text, 100 answers, 100 choices) are mentioned, so some meaning is still left to the schema.

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?

States a specific verb and resource ('Saves answers ... as drafts') plus the resulting state ('each is stored as a new version with status draft, not approved'), which separates it behaviorally from save/approve siblings. It never names getfund_save_answers, getfund_draft_answers or getfund_approve_answers, so the agent must infer the boundary rather than being routed explicitly.

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 phrase 'for the founder's review' and 'status draft, not approved' imply the use case (stage answers for human review rather than committing them), but no explicit when-to-use or when-not-to-use rule is given relative to the many sibling write tools. An agent reading only this definition gets an implied, not stated, selection rule.

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