ATSPrep

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description goes further by disclosing what comes back ('direct swaps and why they read weak', 'matching verb groups with an example bullet'), which is valuable since there is no output schema.

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?

One front-loaded sentence with the core purpose first, then the input modes. Dense but every clause carries information; slightly heavy with nested parentheticals but no wasted sentences.

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 single-optional-param, read-only lookup with no output schema, the description covers purpose, input modes, and the empty-query case. It stops short of describing the shape of the returned groups (ordering, count, formatting), which would be the only remaining gap.

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 real meaning beyond the terse schema text: it explains what each form of the query buys you and that an empty query returns all groups. That is semantic guidance the schema does not carry.

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 ('Suggest resume action verbs') and implicitly distinguishes itself from sibling bullet-editing tools by focusing on verb selection rather than rewriting whole bullets. An agent can tell what it produces 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?

Explicitly describes three input modes and what each yields: a weak opener for direct swaps, plain-word work description for verb groups, or empty for every group. It gives clear usage context but never names a sibling alternative (e.g., improve_bullet) or states when NOT to use this tool.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context: input caps (30 bullets x 600 chars), that blank items are skipped and reported by index, and a dated rules version for reproducibility. It does not state latency or any failure behavior, keeping it short of a 5.

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?

A single dense paragraph, front-loaded with the output contract, then limits, then version. Every clause carries information, though the mid-sentence enumeration of defect categories is somewhat list-like and could be tightened.

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 burden of describing returns, and it does name the three return elements (score, verdict, fixes) plus stable codes for categorization. What is missing is the code list itself and the verdict scale, so an agent knows roughly what comes back but not its vocabulary.

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% and the single parameter is fully documented, so the baseline is 3. The description goes beyond the schema by clarifying that blank items are accepted-but-skipped and reported by index, which is behavior the schema's maxLength/maxItems cannot express.

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 concrete verb and resource ('Give each resume bullet a score, a verdict and specific fixes') plus the exact output shape (stable codes). It distinguishes itself from check_resume by scoping to individual bullets and explicitly claiming the same rule set, so an agent can route between the two.

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 mention of 'the same rules and severities as check_resume' plus the 30-bullet ceiling implies this is the batch/individual-bullet variant of the resume check, but there is no explicit when-to-use statement. Neither check_resume nor improve_bullet is named as an alternative with a selection condition.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavioral substance by disclosing the evaluation checklist the agent's input will be judged against. It does not describe output shape or scoring thresholds, but it goes beyond restating annotations.

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?

A single front-loaded sentence with a colon-led list; every item (preview truncation, identity, numbers, buzzwords, CTA, character limit) carries distinct information. Slightly dense but no 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?

With no output schema, the description compensates by naming the dimensions the check reports on, which is close to describing the return content. An agent knows what to send and roughly what it gets back; only scoring format and edge cases remain unspecified.

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% for both parameters, so the schema already documents 'about' (whole section) and the optional 'role' (job title to be found for). The description adds no syntax, format, or interaction detail beyond what the schema provides, so the 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 (check) and resource (LinkedIn About section) and enumerates the exact facets evaluated: mobile/desktop 'see more' truncation, opening identity statement, quantified results, buzzwords, CTA, and the 2,600-character limit. This clearly separates it from check_linkedin_headline and the other check_* siblings.

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?

Usage is implied (you have an About section and want it reviewed), but there is no explicit when-to-use statement, no prerequisites, and no routing to alternatives such as check_linkedin_headline or generate_linkedin_headline for a headline problem. Adequate but leaves selection to inference.

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

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

Annotations already declare this a safe, idempotent, non-destructive read with no external side effects, so the safety profile is covered. The description adds one useful domain constraint (the 220-character limit) and the analysis dimensions, but says nothing about permissions, rate limits, or output shape beyond the enumerated checks.

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?

A single front-loaded sentence led by the verb+object, then a tight colon list of the four checks. Each clause adds scoping information rather than filler, though the sentence is dense enough that a separate usage line might have been clearer.

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 burden of saying what the tool reports, and it does so by listing the four diagnostic dimensions. For a read-only analysis tool with full schema coverage and rich annotations, this is nearly complete; only explicit sibling routing 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 all four parameters (headline, role, focus, skills) are already documented in the schema, and the description adds no syntax or format guidance for the optional role/focus/skills inputs. Baseline 3 applies when the schema does the heavy lifting.

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?

Names a specific verb and resource (check a LinkedIn headline) and enumerates exactly what gets checked: length vs the 220-character limit, search-result truncation, job-title positioning, and buzzwords. It does not name its obvious sibling generate_linkedin_headline, so the check-vs-generate distinction rests on the verb alone.

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?

Usage is implied by the diagnostic nature of the output list and the phrase 'buzzwords or vague claims to replace', which suggests evaluating an existing headline. There is no explicit when-to-use, when-not, or pointer to generate_linkedin_headline for starting from scratch, leaving the routing to inference.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses the scoring weights (0.5/0.3/0.2), the cap for missing hard requirements or impossible claims, the 30,000-character limit, and that job_fit plus a keyword match summary are returned. It even pins the rules version (2026-10-19), which pins down reproducibility.

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 primary verb and output are front-loaded, and the two long sentences avoid filler. The second sentence is dense with parenthetical detail on scoring weights, which costs some scannability but each clause carries substantive 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 carries the return-shape burden and does so: issue codes, parsed structure, word counts, and the conditional job_fit/keyword summary. An agent has everything needed to call it and interpret the response.

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 real semantics: job_description does not merely filter, it redefines the score as job fit and adds job_fit/keyword outputs, and target_role unlocks role-specific advice. That is meaning beyond the schema's terse parameter blurbs.

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 gives a specific verb and resource: score a resume 0-100 with fixed rules and list each issue with a stable code. It also enumerates the parsed-text output, making the tool's scope distinct from narrower siblings like check_bullets. It never names a sibling to route against, so it stops short of full differentiation.

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?

It states the conditions that change behavior: role-specific advice only appears when the resume names a target title or target_role/job_description is passed, and passing job_description switches scoring to job fit. That is clear conditional guidance, but there is no explicit when-not or comparison to alternatives such as match_job or keyword_scan.

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

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

Annotations already declare this as a read-only, idempotent, non-destructive generation, so safety is covered. The description goes further by disclosing output composition (letter, gaps, checklist) and a non-obvious behavior: missing facts become [square-bracket] gaps and are never replaced with invented stand-ins, which is meaningful for trusting the result.

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?

Two sentences, front-loaded with the action and then the rule set; the long colon-delimited clause is dense but each element carries information. Slightly heavy for a description, but no 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?

There is no output schema, so the description correctly carries the return-value burden ('Returns the letter, the gaps and a checklist'). With 12 parameters and 0 required, the description implies resume_text and job_description are needed even though the schema marks them optional — a minor ambiguity, but otherwise complete.

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 the 3 baseline applies, but the description adds real semantic mapping: which fields feed which letter sections (name, contact details, up to two results, job title, top keywords), clarifying the purpose of the otherwise vague 'results', 'role' and 'why' parameters.

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 artifact ('Draft a cover letter') plus its inputs ('from the user's resume and the job posting'), which cleanly separates it from siblings like draft_resignation_letter and tailor_resume. It also enumerates the fixed content rules, so the agent knows exactly what the tool will produce.

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 implies the usage context (needs a resume and a job posting) and the schema adds a routing hint ('For a link, call fetch_job_post first'), but there is no explicit when-to-use/when-not guidance or comparison to siblings such as tailor_resume. Adequate but leaves routing to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behaviour beyond that: missing facts are surfaced as [square-bracket] gaps rather than invented, and the exact return payload (letter, last day, checklist with three named checks) is stated. No auth or rate-limit notes, but none appear relevant.

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?

Three short sentences: purpose and derived output first, then the gap-filling convention, then the return contract. No filler, no restatement of the title, and the most decision-relevant clause is front-loaded.

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 12-parameter, zero-required, no-output-schema tool, the description covers what it produces (letter, last day, checklist) and how gaps are handled. The only real omission is guidance on when this tool should not be used, which leaves a small hole in an otherwise complete definition.

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 every one of the 12 parameters is already documented with defaults, enums and formats. The description adds only the causal link that notice drives the computed last working day, which is marginal. Baseline 3 is appropriate when the schema does the heavy lifting.

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 and resource ('Draft a ... resignation letter') plus a secondary capability ('work out the last working day from the notice period'). This is instantly distinguishable from draft_cover_letter, tailor_resume, and the other career siblings, none of which touch resignation content.

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?

Usage is only implied: an agent can infer this is for someone leaving a job, but no explicit when-to-use, when-not-to-use, or alternative tool is named (e.g., no pointer for counter-offer or notice-negotiation cases). The notice vs. notice_days routing advice is parameter-level guidance rather than tool-selection guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious behavior: the list of supported ATS platforms, the fact that the result is plain text, and the failure mode where sites block reading and the user must paste text manually.

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?

Three short sentences, front-loaded with the action and returned fields, then supported sites, then the failure fallback. Every sentence carries information an agent would otherwise have to discover by trial and error.

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 naming the returned fields and their format (plain text). Combined with the supported-site list and the blocking fallback, an agent has everything needed to call it and to handle the likely error path.

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?

Only one parameter and schema description coverage is 100% – the schema already documents 'url' as a public https link with a max length. The description's 'from its link' adds no syntax or format detail beyond that, so the 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 (read) and resource (public job posting from its link) and enumerates the exact fields returned: title, company, location, full description. It also names the sibling tools that consume its output (match_job, tailor_resume, keyword_scan, interview_questions), so an agent can place it precisely in the workflow.

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 a clear upstream/downstream context by naming the four sibling tools this feeds, and provides an explicit when-not case with a fallback: 'Some sites block reading; then ask the user to paste the text.' It stops short of stating exclusions versus alternatives for the same job (there are none in the sibling list), so it is strong but not fully exhaustive.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful behavior: it returns multiple pattern-based options, annotates each with character length and approximate search-result truncation, and constrains generation to supplied answers only, which usefully rules out invented credentials. It does not say how many options are produced or whether the patterns are selectable.

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?

A single front-loaded sentence with the resource stated first, then the pattern list and the output traits. The parenthetical pattern enumeration with an ellipsis is slightly loose but each clause carries 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?

There is no output schema, so the description has to describe the return shape, and it does: multiple options, each labeled with a pattern, its length, and the search truncation point. The required role parameter and the "answers only" sourcing rule are covered. Minor gaps remain around option count and exact result formatting, but nothing essential to invoking the tool 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 the schema already documents all seven parameters with examples and lengths. The description adds no syntax or formatting detail beyond "the user's answers" and the pattern list, so the baseline 3 is appropriate.

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 ("Write LinkedIn headline options") and goes further by naming the pattern families used (title+focus, title+result, title+who you help). An agent can immediately distinguish this generative tool from the sibling check_linkedin_headline, which audits an existing headline.

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?

Usage is only implied: "from the user's answers" and the sibling name check_linkedin_headline make it inferable that this is the authoring counterpart to the checking tool. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g. write_summary, check_linkedin_headline).

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

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

Annotations only declare a safe read (readOnlyHint=true, destructiveHint=false). The description adds substantial behavioral context the annotations cannot: the AI-backed drafting (with named models), the guard that strips figures/names/tools absent from the user text, the [X%] placeholder convention, and graceful degradation to the rule-based result with ai.message explaining the failure. This is exactly the kind of beyond-annotation disclosure that earns a high score.

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 core function is front-loaded, then output shape, then AI/fallback behavior — a sensible order. It is dense but mostly earns its place; the specific model version names (Gemma 4, Llama 3.3 70B) are arguably more detail than an agent needs for selection.

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-shape burden well, naming score, verdict, fixes, up to three rewrites, and the ai.message fallback field. It is complete on behavior and output; only explicit when-to-use guidance 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 role, bullet, and company are already fully documented. The description's 'keep every fact as given' and placeholder notes speak to output content rather than parameter syntax, adding little beyond the schema. 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 and resource: check one resume bullet against fixed rules (score, verdict, fixes) and produce up to three rewrites. The singular 'one resume bullet' plus the rewrite emphasis distinguishes it from the plural check_bullets sibling. An agent can tell what it does 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?

Usage is implied by the phrasing (improve a single bullet, get rewrites) but there is no explicit when-to-use routing or exclusion against alternatives like check_bullets or tailor_resume. The agent must infer that this is the single-bullet improvement path.

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

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

Annotations already cover readOnly/idempotent/non-destructive/non-openWorld, so the bar is lower, and the description still adds that the tool is 'rule-based' (deterministic, no external lookup) and that output varies by supplied inputs. It does not describe limits, defaults, or output shape beyond the content itself.

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?

Two tightly written sentences with the core deliverable front-loaded and the conditional input semantics following immediately; 'Rule-based.' earns its place as a one-word behavioral signal.

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?

No output schema exists, so the description carries the return-value burden and does so by enumerating what each question includes (listening cues, STAR tips, research points, questions to ask). Nothing essential for correct invocation 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 coverage is 100% so the baseline is 3, but the description adds real meaning by explaining how job_description and resume_text change what is returned. The kind enum and limit are left entirely to the schema, which is acceptable.

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 concrete verb+resource: it produces interview practice questions with listening cues and STAR tips. The content is specific enough that an agent can tell it apart from review_interview_answer (which evaluates an answer), though it never names or contrasts a sibling 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?

Gives clear conditional usage: with a job_description the questions derive from its skills and duties; with resume_text they come from the user's own roles. It omits any when-not guidance or explicit routing to alternatives such as review_interview_answer.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description goes beyond them by disclosing the ranking signals (repetition, position, required/preferred headings), that high-priority terms are flagged, and that a dated rules version governs the scoring — real insight into how the output is derived. It does not describe output shape in detail, which keeps it short of a 5.

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?

Three short sentences with the core action and ranking method front-loaded, then the sibling pointer, then the constraint and rules version. Every sentence carries information, though the length range duplicates the schema.

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?

There is no output schema, so the description must convey the return: it does, describing ranked keywords with high-priority flags. Combined with the routing hint to match_job, an agent has enough to call this correctly, though the exact result structure remains only roughly sketched.

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?

Only one parameter and schema coverage is 100%, so the schema already documents that job_description is the full plain-text posting with a 120–20,000 character bound. The description restates the same length range, adding little beyond the schema; baseline 3 is appropriate.

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+resource ('List the skills, tools and requirements a job posting asks for') plus the differentiating behavior (ranked emphasis). It explicitly separates itself from the sibling match_job, so an agent can pick between them without opening schemas.

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 routing context: use this to extract and rank posting keywords, and use match_job when the question is what a resume already covers. No explicit when-not or prerequisite beyond that, but the alternative is named with its selecting condition.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral detail — that results include Studio deep links and preview images, i.e. the tool returns actionable references, not just names.

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?

A single front-loaded sentence with no filler, but the repeated 'each with a link that opens Studio...' construction makes it denser than necessary. The two result sets could be enumerated more crisply.

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 must convey the return shape, and it does — two collections with links and a preview image. What's missing is scale/ordering hints (how many designs, are example resumes grouped or flat), which would help an agent plan consumption.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The empty schema is consistent with a fixed listing operation.

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 (List) and two concrete resources — resume designs and example resumes by role — plus what each item carries (Studio link, preview image). This clearly separates it from action siblings like open_in_studio or check_resume, which operate on a single artifact.

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?

Usage is only implied: an agent can infer this is the discovery/browse step before picking a design. There is no explicit 'use this when you need to see available designs' statement, no mention of open_in_studio as the follow-up action, and no exclusions.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds genuine value beyond that: it discloses the return shape (match categories exact/normalized/alias/stem, matched spans, source sentences for misses, term weights, required vs preferred, and coverage aggregates) and pins a rules version, which tells the agent results are deterministic and versioned.

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?

A single dense sentence, but it is front-loaded with the action and every clause carries a distinct output fact that has nowhere else to live given the absence of an output schema. Nothing is repeated or decorative.

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 properly absorbs the burden of explaining returns and does so comprehensively, and input constraints are enforced by the schema. The remaining gap is workflow context — it never says how it relates to fetch_job_post, keyword_scan or tailor_resume in a larger pipeline.

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 are already documented, and the description's '120–20,000 characters' simply restates the schema's minLength/maxLength. It adds no syntax, format or interaction detail beyond the schema, so the 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+resource pair ('Compare a resume with a job posting') and enumerates exactly what the comparison yields (matched/missing keywords, match type, weights, coverage). It does not, however, distinguish itself from plausible near-duplicate siblings such as keyword_scan or tailor_resume, so an agent cannot tell from the description alone which to pick.

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?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives, even though keyword_scan and check_resume sit in the same sibling set. The only usable precondition ('Posting 120–20,000 characters') is a constraint, not a usage rule, and the 'call fetch_job_post first' advice lives in the schema rather than the description.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description usefully adds the mechanism of the result: the resume text is carried in the URL #fragment and never sent to a server. This privacy detail is real added value, though nothing is said about length limits despite a 30000-char cap.

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?

Two tight sentences, the action front-loaded and the privacy note second. No filler or restatement of the title.

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 correctly explains that the result is a link the user opens elsewhere, and the fragment/server clarification answers the obvious agent question. Minor gaps (what to do with the link, size limits) remain but aren't blocking.

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?

One parameter at 100% schema coverage, so the schema already documents resume_text fully, including its line-based plain-text format. The description reinforces how the text is conveyed (via the link fragment) but adds no formatting or constraint detail beyond the schema — baseline 3.

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 concrete verb and resource — 'Make a link that opens this resume in ATSPrep Studio' — and clarifies the deliverable (an editor link, not an edit itself). This clearly distinguishes it from siblings like check_resume, tailor_resume, or list_templates.

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 purpose clause ('so the user can fix it, pick a template and download a PDF') implies this is the hand-off step after producing a resume, but it never states when to choose this over alternatives or any preconditions. Usage is implied rather than specified.

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

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

Annotations only declare the read-only safety profile; the description adds substantial beyond-schema behavior: an AI-drafted portion via named models with a backup, the ATSPrep guard that strips figures/names/tools absent from the user's text, and graceful degradation to a rule-based result with ai.message explaining unavailability. It even implicitly explains the non-idempotent hint via model variability.

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?

Purpose is front-loaded in the first clause and the output list is dense but informative. The middle sentence's model/infrastructure detail (Gemma 4, Llama 3.3 70B, Cloudflare Workers AI) is more implementation depth than an agent needs to select the tool, making it slightly top-heavy.

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 must carry the return-value burden and does: it enumerates the review components and explains the degraded-mode response plus the ai.message field. Nothing an agent needs to call this 4-parameter tool 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 the schema already documents all four parameters, including the kind enum's five modes and length limits. The description adds no parameter-level detail beyond what the schema provides, which sets the baseline at 3.

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 ('Review the user's answer to an interview question') and enumerates the concrete artifacts produced (rating, speaking time, STAR coverage, filler words, follow-up, stronger version). This is clearly distinct from the sibling interview_questions, which generates rather than critiques answers.

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?

Usage is implied by the function rather than stated: there is no explicit 'use this when you have a drafted answer and want feedback' or mention of alternatives like interview_questions. The kind enum in the schema carries the closest thing to usage routing, and the description itself offers no exclusions or prerequisites.

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

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

Beyond the annotations (readOnly, non-idempotent, non-destructive, closed-world), the description discloses that part of the answer is AI-drafted (Gemma 4 with Llama 3.3 70B fallback on Cloudflare Workers AI), that a guard drops any figure/name/tool not in the user's text, and that the rule-based portion still returns with ai.message explaining failure. This is rich disclosure of non-obvious runtime behavior that explains the non-idempotency.

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?

Purpose and scope are front-loaded in the opening clause, and the sentences carry substantive information. It is dense and slightly overstuffed with model/carrier detail, but each clause maps to real behavior rather than 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?

With no output schema, the description usefully sketches the return shape (missing keywords, suggested rewrites, borrowed-terms list, confirm_with_user list, ai.message) and the degradation path. It stops short of fully specifying the response structure, but is complete enough for an agent to invoke correctly for a two-param tool.

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% for both parameters, so the schema already documents plain-text format and length limits. The description adds no syntax or format detail for resume_text or job_description beyond what the schema provides, which is the baseline-3 case.

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+resource ('Tailor a resume to a job posting') and immediately differentiates the output from siblings by noting the missing keywords come 'from match_job's rules' and the rewrites touch only 'the user's own summary and bullets'. An agent can distinguish it from match_job, improve_bullet, and write_summary without opening any 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 reference to match_job's rules establishes the workflow context in which this tool is used, and the note that confirm_with_user terms are 'never to add unasked' frames correct invocation. However, there is no explicit when-to-use/when-not-to-use statement or named alternative for the tailoring task itself.

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

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

Annotations cover only the safety profile (readOnlyHint, openWorldHint, destructiveHint, idempotentHint), and the description adds substantial extra context: the hybrid rule-based/AI pipeline, the ATSPrep guard that strips figures, names and tools absent from the user's text, and graceful degradation where the rule-based draft still returns with an explanation in ai.message. That is exactly the kind of failure-mode and data-handling disclosure annotations cannot carry.

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?

Purpose and mechanism are front-loaded in the first sentence, and the degraded-mode sentence is genuinely useful. The middle sentence spends considerable words on vendor/model names (Gemma 4, Llama 3.3 70B, Cloudflare Workers AI) that an agent does not need in order to select or call the tool.

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 partly compensates by explaining that the response contains both a rule-based and an AI part and that ai.message carries the reason when the AI half is unavailable. It stops short of describing the overall response shape or field names, which is the remaining gap for a tool whose return value is undocumented.

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 resume_text and target_title are already documented in the schema, and the description adds no format, length or interaction detail beyond what the schema states. Baseline 3 is correct when the schema does all parameter-level work.

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 verb 'Draft' and resource 'professional summaries from a resume' are specific, and the description further narrows scope by explaining the rule-based + AI composition. It never names a sibling (e.g. draft_cover_letter or generate_linkedin_headline), so differentiation is left to the resource name rather than stated 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 text describes how the tool behaves but never says when to choose it over alternatives such as check_resume, tailor_resume or draft_cover_letter, nor any prerequisite beyond supplying resume text. Usage is only inferable from the tool name and first clause, which is the same gap that earned a 2 in the calibration example.

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