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

With annotations already declaring readOnly/non-destructive, the description goes well beyond them: it discloses that output is a hybrid of rule-based and AI drafts, names the exact models and backup, explains the ATSPrep guard that drops figures/names/tools absent from the user's text, and states the graceful-degradation path (rule-based part still returns, ai.message explains). This also substantiates the idempotentHint=false annotation.

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?

Four sentences, front-loaded with the when-to-use trigger, and each sentence adds a distinct fact (draft composition, AI/guard behavior, fallback). The model-infrastructure detail (Gemma 4, Llama 3.3 70B, Cloudflare Workers AI) is slightly heavier than the agent strictly needs, but it is not padding.

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 carries the return-value burden and does so partially: it explains that a rule-based part plus an AI part come back and that ai.message conveys failures, but it does not enumerate the output fields an agent should expect to consume. Adequate for calling the tool; slightly incomplete for interpreting results.

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 both parameters (resume_text, target_title) are already documented in the schema; the description merely alludes to resume structure ('title, skills and the bullets that carry a figure'). Baseline 3 applies when the schema does the heavy lifting and the prose adds no format or constraint detail.

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 names a specific verb (draft/write) and resource (resume summary or professional profile) and grounds it in the source artifact ('from their resume'). An agent can distinguish it from siblings like generate_linkedin_headline or draft_cover_letter without opening 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?

The opening clause gives an explicit trigger: 'Use this when the user wants a resume summary or professional profile written from their resume.' That is clear when-to-use guidance, but it never names an alternative or a when-not condition (e.g., vs. generate_linkedin_headline for a LinkedIn About), so routing still requires inference.

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