Get or save the user's answers

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

Goes well beyond the annotations: it discloses that save replaces the answer under the same question and that an empty answer removes it, which explains the destructiveHint=true and idempotentHint=true flags in concrete terms. It also warns that saved answers count as facts in freeapply_check_text, a downstream effect an agent could not infer, and lists error conditions.

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-loads the core verb+resource, then organizes the rest into labeled Use/Behavior/Returns/Errors segments, which is easy to scan. Slightly dense with parenthetical cross-references, but every sentence carries actionable 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?

With no output schema, the description compensates by spelling out both return shapes (job_id, answers, saved_answers, cover_letter for get; label, saved, removed, saved_answers for save) and the error cases. Nothing an agent needs to call this correctly is missing.

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 label, action, answer, and job_id are already fully documented with the same wording ('the user's own words', 'empty removes the saved answer'). The description adds error conditions tied to parameters (get without job_id, save without label) but little semantic detail beyond the schema, 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?

States a specific verb pair and resource: gets or saves the user's own answers to specific form questions. It immediately distinguishes itself from freeapply_get_settings (referenced as 'general details') and from freeapply_update_job with status needs_info for brand-new questions.

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 'Use:' sentence gives explicit triggering conditions for each action — get before retrying a re-queued job, save when the user answers in-conversation. It also names the alternative path for a new question (freeapply_update_job status needs_info), so when-not-to-use is covered.

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