ResumeQuick

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds real value: append-only behavior, the 15-fact read window used by vacancy analysis, the return value (fact_id), and the 'invalid_payload' error condition with its 500-char limit. It doesn't cover auth requirements or explicit rate limits, but the behavioral disclosure is strong.

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 purpose, then scope, then error semantics in a compact few sentences. The long enumeration of sibling field names is slightly dense but earns its place by clarifying the boundary with upsert_career_memory.

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?

An output schema exists, so the description needn't restate return structure, yet it still names the returned fact_id and the error case. Combined with the append-only semantics and the downstream read window, the description is complete for an agent to call this 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?

Schema description coverage is 0% for the single nested fact parameter, so the description must compensate and largely does, explaining the 1..500 character constraint and giving example facts. It doesn't fully specify the nested 'input' object shape, but the single meaningful field is well covered.

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 ('Remember a single durable career fact about the user') and immediately grounds it with concrete examples. The append-only scope and contrast with the sibling upsert_career_memory makes the boundary clear.

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?

Explains the append-only semantics and that vacancy analysis reads the 15 newest facts, and it points to upsert_career_memory for structured-field equivalents. It does not spell out when to prefer this over upsert_career_memory beyond the structured-vs-durable distinction.

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 readOnly=false, destructive=false, idempotent=false; the description goes well beyond that with async semantics, the offer_id/get_offer handoff, per-plan quota accounting, the profile fallback for missing country, and five named error outcomes. This is exactly the behavioral context 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?

Front-loads purpose, then the verbatim-input constraint, then async behavior and the get_offer follow-up, then parameters, then quota and error codes. It is dense but every sentence carries new information; nothing is 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?

For an async, quota-metered write tool with a referenced schema and an output schema, the description covers invocation, retrieval of results, fallback behavior and failure modes. 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?

The nested schema already describes all five fields well, but the description still adds meaning: vacancy_id links the offer to the tracker, countries default to the profile when omitted, and source_text loses extracted numbers if paraphrased. The only gap is that it doesn't surface the employment_type enum values, which the schema does.

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 ('Analyse a job offer ... draft the negotiation scripts') and immediately distinguishes it from the vacancy/radar siblings by scoping to a received offer. An agent can tell this apart from analyze_vacancy and analyze_tracked_vacancy without opening a 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?

Clearly says the source text must be verbatim wording from the recruiter and that summarised text loses the numbers, and it routes the agent to get_offer(offer_id) for the result. It also says when to pass optional fields ('when the user said them'). It lacks an explicit 'use X instead' for the vacancy-analysis siblings, so it stops short of a 5.

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 (which only give the generic destructive/readOnly/idempotent flags), the description discloses quota cost per match, asynchronous execution with get_vacancy_detail(analysis_id) to retrieve the result, and precise side-effect semantics for each failure path (posting_closed sets closed_at and puts the match away; teaser spends nothing). There is a mild tension with idempotentHint=false given the reused=true caching path, but the description's disclosure level is far richer than the annotations and is not a genuine contradiction.

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 and every sentence carries real information (teaser handling, quota, async retrieval, error codes). It is dense as a single block, which slightly hurts scanability, but there is essentially 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?

For a one-parameter, output-schema-backed, asynchronous tool, the description covers the operation, its alternatives, its cost model, how to fetch results, and the full set of terminal error states with their side effects. Nothing material needed to invoke it 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?

Only one parameter (match_id), and the description references it only as 'by match id' without adding format, prefix, or lookup guidance. The schema carries the bulk of the meaning (its own description points to get_radar_matches), so a baseline 3 is appropriate rather than compensating heavily.

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 (analyze one radar match by id against the user's resume) and immediately bounds the operation ('using the posting text the radar already stored; it does not fetch the job page'). It also distinguishes itself from a near-sibling by naming analyze_tracked_vacancy for the full-posting case, so an agent can route correctly.

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 gives explicit when-to-use and when-not rules: teaser postings under 400 characters are not analyzed and instead should go to analyze_tracked_vacancy with the full text as 'description'. It also states the idempotent path (already-analyzed matches return reused=true) and quota conditions, so no routing is left 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?

Goes well beyond the annotations: states one quota unit is consumed, that it runs asynchronously with results visible via get_vacancy_detail 'usually within 10 seconds,' that a passed description replaces any teaser before analysis, and enumerates every error code (description_required, posting_too_short, already_processing, limit_exceeded, not_found) with what each implies for spend.

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 purpose and scope, then usage conditions, quota, async behavior, and error codes in one dense block. It's long but every clause carries operational information; minimal waste, though the error enumeration makes it 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 an output schema present, return-shape detail is unnecessary, and the description covers everything else an agent needs: quota cost, async result retrieval, teaser-replacement behavior, and the full set of failure modes. Complete for a write tool of this complexity.

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?

Explains the meaning and triggering conditions for 'description' (needed when has_description is false or analyze_radar_match returned needs_full_posting; pasted word-for-word; saved over the teaser) and clarifies vacancy_id refers to a tracked vacancy. Adds real value even though the schema also carries field descriptions.

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 ('Analyze a vacancy already in the user's tracker (by vacancy_id) against their active resume') and pins down the scope with 'in place — no duplicate is created.' This clearly separates it from a new-vacancy analysis path without needing to name the sibling.

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 explicit applicability: a never-analyzed vacancy ('none'), one whose analysis failed, or a re-run. It also flags quota consumption and async behavior. It stops short of naming the alternative tool (e.g. analyze_vacancy) for the not-tracked case, so it's strong but not 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?

Despite annotations only carrying generic CRUD hints, the description discloses the full behavioral profile: it creates a NEW vacancy, runs asynchronously and returns an analysis_id immediately, is polled via get_vacancy_detail (~10s), returns cached 'completed' results without spending quota unless resume/self-description changed, and emits 'not_found'/'limit_exceeded' errors. It also states it consumes one vacancy analysis against the plan — a cost/rate detail annotations do not capture.

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 its routing constraint in the first sentence, then layers dedup, async, storage, and error semantics. Dense but every clause carries a distinct, actionable fact with 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?

For an async mutating tool with a nested schema and an output schema, this covers the lifecycle (trigger → poll → result), cost, dedup/force, persistence of inputs, and failure codes. An agent has everything needed to invoke, poll, and handle errors 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 nested input schema documents each field, but the description adds meaning beyond it: company/location/url are persisted on the vacancy and make it findable via search_vacancies(location=...), resume_id defaults to the active resume, and force controls re-execution. This is genuine semantic value on top of the schema's field-level docs, though the individual param mechanics are largely already covered.

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 ('Analyze the text of a job posting... against a resume') and immediately scopes it to postings 'not in ResumeQuick yet'. It explicitly names the two sibling tools that handle the adjacent cases (analyze_tracked_vacancy, analyze_radar_match), so an agent can route correctly 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?

Gives explicit when-to-use (posting text not yet tracked), when-not (already tracked → analyze_tracked_vacancy; radar match → analyze_radar_match), and the dedup rule with the force=true escape hatch. Nothing about selection is left 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?

Adds extensive behavior beyond annotations: runs asynchronously returning a task_id, each applied suggestion creates a resume version, quota consumption with 'limit_exceeded', and explicit error codes ('not_found', 'invalid_payload', 'fact_required'). Notifications of what gets skipped and unchanged_count enrich this further.

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 purpose and indices/target semantics, but dense — a nearly continuous paragraph with nested parentheticals. Every sentence is relevant, though the density slightly harms scanability.

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?

Even though an output schema exists, the description explains the async task model, task_id/resume_id/copy_created returns, and how to poll via get_task_status. Nothing an agent needs to call or follow up 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?

Description adds real meaning beyond schema: indices selection logic, what omitted indices skip, where target defaults (Tailoring tab default), and the conditions for fact_required vs skip. The default-target resolution rule is a genuinely valuable clarification not present in 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+resource: 'Apply resume-improvement suggestions from a vacancy analysis,' with the indices indexed from the vacancy's resume_suggestions list. Clearly distinguishable from siblings like get_resume_suggestions and request_vacancy_resume_suggestions.

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?

Explains when to omit indices (applies all except fact-less questions and no-op suggestions), what target='copy' vs 'current' mean, what the default target does, and that 'needs_fact' suggestions require the user's own answer. Rival siblings and selection conditions are explicit.

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 destructiveHint=false and idempotentHint=true, but the description adds real behavioral context beyond them: the operation is reversible, results are preserved, the archive never expires, and it returns 'not_found' for a missing or non-owned interview. It stops short of describing permissions or any side effects on related data.

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 tight sentences, front-loaded with the primary action and immediately followed by the disambiguating intent and behavioral guarantees. No filler or repetition 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?

An output schema exists, so return-value detail is not needed, and the one notable return case ('not_found') is called out anyway. Combined with annotations covering safety/idempotency, the definition gives an agent everything needed to invoke a reversible two-state archive 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?

Schema description coverage is reported as 0% at the wrapper level, so the description must carry the semantics, and it does: 'archived=false restores' pins down the boolean's two states, and interview_id ownership rules are explained via the 'not_found' clause. It adds meaning beyond a bare field list.

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 ('Archive a mock interview ... or restore it') and clarifies the user-facing intent ('the remove it from my list action'). It implicitly contrasts with delete_interview by stressing reversibility and retained results, but never names that sibling, so an agent must infer the distinction.

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 rather than stated: the phrase 'this is the remove it from my list action' tells the agent the intent, and 'reversible, the results are kept' hints at when it is preferred over deletion. However, no alternative tool (e.g., delete_interview) is named and no explicit when-not condition is given.

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?

Adds substantial context beyond the annotations: operations apply instantly, consume no quota, the archive persists until the user deletes, and the call returns 'not_found' when the match belongs to another user (an ownership/auth condition). These side-effect and error behaviors are exactly what the readOnlyHint/idempotentHint/destructiveHint flags cannot convey.

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 sentences, each carrying distinct load: action + restore semantics, then behavioral guarantees, then the read path and error case. Front-loaded with the primary operation and free of 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?

For a single-parameter reversible mutation with an output schema and full annotation coverage, the description supplies everything an agent needs: both directions, reversibility, quota impact, the companion read tool, and the ownership error. No material gap remains.

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 description compensates for the reported 0% schema coverage by stating the effect of archived=false versus the default archiving behavior, tying the boolean to a concrete outcome. The nested schema happens to describe the same two fields, so the description adds emphasis rather than new syntax or edge cases.

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 reversible action on a named resource ('Put a saved radar match away in the radar archive, or restore it to the saved pile') and covers both directions of the operation. An agent can distinguish this from delete_radar_match, skip_radar_match and undo_radar_match because the description explicitly frames it as reversible, non-destructive archiving.

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 usage context: archive by default, pass archived=false to restore, and read the archive back with get_radar_matches(status="archived"), naming that tool explicitly. It stops short of an explicit exclusion ('to permanently remove, use delete_radar_match'), so the boundary with the delete sibling is only implied by 'reversible'.

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 non-readOnly, idempotent and non-destructive, and the description adds real value on top: reversibility, that history and quota accounting stay intact, that the archive never expires, and the 'not_found' failure condition. That is exactly the context an agent needs before invoking a state change.

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 with the action and its semantics front-loaded and the error case last where it belongs. Denseness is an asset here rather than padding, though the parenthetical gloss and the trailing failure clause could be trimmed slightly.

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 one-parameter mutation with an output schema already describing returns, the description covers scope, reversibility, side effects and the failure mode. Nothing an agent needs to call it 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 coverage is reported at 0%, so the description must carry the load, and it does: 'archived=false restores' pins the boolean's polarity, which is the one way to misuse this tool. The vacancy_id parameter itself gets no added meaning beyond the title.

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 ('archive a tracked vacancy... or restore it') plus a lay gloss ('hide it from the user's main list'), which lets an agent separate it from the many sibling archive_/delete_ tools. The reversible/reversible-pair scope is explicit.

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?

Frames the tool as 'the remove it from my list action', which gives clear context for when to reach for it. It never explicitly contrasts with the close-by delete_vacancy sibling, so an agent must infer that permanent removal is elsewhere.

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?

Adds real behavioral context beyond the annotations: irreversibility ('nothing brings a cancelled reminder back'), instant application, no quota consumption, and the returned count. There is mild tension with destructiveHint=false given the stated irreversibility, but cancelling is a state flip rather than data destruction, so this is not a hard contradiction.

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 scope, then the return value, then the risk/when constraint. No sentence is 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 an output schema present and annotations covering idempotency and safety profile, the description fills every remaining gap an agent needs: scope, irreversibility, return shape, and that no quota is consumed.

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?

Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The absence of arguments is consistent with an all-at-once bulk action.

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 with explicit scope: 'Cancel every active reminder of the user at once.' The word 'every ... at once' implicitly distinguishes this bulk operation from the singular cancel_reminder sibling, though it never names the sibling outright.

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?

'Nothing brings a cancelled reminder back, so this belongs behind an explicit request' gives a genuine when-to-use condition (explicit user request only). It stops short of naming cancel_reminder or list_reminders as the alternative for narrower cases.

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=false, idempotentHint=true and destructiveHint=false, but the description adds genuinely new behavior: instant application, no quota consumption, and the precise conditions under which 'not_found' is returned. That error semantics detail goes beyond what annotations provide.

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, with the core action and its id source front-loaded, followed by the operational and error-side notes. 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?

An output schema exists so return values need not be documented, and the description still covers the key non-obvious outcome ('not_found' cases) plus the instant/no-quota behavior. 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 reported as 0%, so the description must carry the reminder_id semantics. It does say 'by id (see list_reminders)', which tells the agent where the id comes from, but adds no format or validation detail beyond that.

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 ('Cancel one of the user's active reminders by id'), and the phrase 'one of' implicitly distinguishes it from the sibling cancel_all_reminders. An agent can tell exactly what this 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?

Points to list_reminders as the source of the required id, giving clear context for when to reach for this tool. It stops short of explicitly contrasting itself with cancel_all_reminders, the obvious alternative.

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?

With annotations marking this as destructive and non-idempotent, the description adds substantial context: the public address stops working immediately, visitors see the link was closed, the resume and file remain intact, and a later link gets a new address. It also returns 'no_link' and 'not_found' states, covering both side effects and 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?

The description is four tightly written sentences with the primary action front-loaded. Every sentence earns its place by covering effect, reversibility, alternative behavior, and return statuses.

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 destructive one-parameter tool with rich annotations and an output schema, the description is complete enough. It explains the immediate effect, what is preserved, how to create a replacement link, and the two error/empty states an agent might encounter.

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?

There is one parameter, resume_id, and the embedded schema documents it as returned by list_resumes. The description itself does not add further parameter semantics, such as format or acquisition details, so it relies on the schema for invocation guidance.

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 states a specific verb and resource: close the open public link to a resume's PDF. It distinguishes the action from sibling tools such as share_resume_link, which creates a new link, and makes clear this is about revoking public access rather than deleting the resume.

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 names the alternative share_resume_link for creating a later link and explains the no_link condition for when there is nothing to close. It does not explicitly contrast with get_resume_link or get_resume_pdf_url, but the intended use is clear from the purpose.

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?

Goes far beyond annotations: discloses asynchronous behavior (returns task_id immediately), quota consumption ('one resume generation from the user's plan', free-plan limit), side effects (turns on radar auto-search and runs first scan), return tokens ('already_set_up', 'limit_exceeded', 'invalid_payload'), and edge cases like guided answers without last_job. This is exactly what behavioral transparency should look like.

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 dense paragraph packed with semicolons and run-on clauses. While most information earns its place, the lack of structure (no bullets, no clear separation of concerns) makes it harder to parse than necessary for an agent.

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 complexity (async, quota, side effects, error states) and the presence of an output schema, the description is remarkably complete. It covers inputs, defaults, side effects, error semantics, and async follow-up, leaving no critical gap for correct invocation.

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 reported as 0%, so the description carries the burden and does so well: it clarifies that exactly one of resume_text or guided is passed, lists the guided fields, notes the effect of missing last_job, and enumerates allowed language codes. It omits field_of_study from the guided list, but otherwise adds substantial semantic value beyond 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: 'Create the first resume of an account that has no profile yet', clearly distinguishing it from siblings like create_resume_version or update_resume_section. The scope condition ('no profile yet') is front-loaded and 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?

Explicitly states the precondition (account with no profile), the two mutually exclusive input modes (resume_text vs guided), and that exactly one must be passed. It also notes it works before setup is finished. It does not name alternative tools for related tasks, but the context is clear enough for selection.

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 (which only mark it non-read-only, non-idempotent, non-destructive), the description discloses concrete behavioral traits: immediate effect, no quota, a hard cap of 20 active reminders surfacing as 'limit_exceeded', and the exact 'invalid_payload' triggers (past time, >180 days ahead, empty text). That is precisely the kind of failure-mode context 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?

Extremely dense with zero filler: purpose first, then the two key parameters, then the behavioral/limits clause. Every sentence carries operational information an agent needs before calling.

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?

The tool has an output schema, so return values need not be explained, and the description still flags the two error strings. Combined with annotations and the nested schema descriptions, an agent has everything required to invoke this correctly; the only soft gap is silence on the optional domain-linkage fields.

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 top-level `input` parameter has 0% schema coverage, but the nested properties do carry descriptions. The description reinforces the critical `fire_at_local` semantics (local wall clock, no zone, server converts) and adds delivery semantics for `text` ('delivered as written, on its own') that the schema states less directly. It says nothing about the optional `resume_id`/`vacancy_id`/`interview_id` linkage fields, leaving those entirely 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+resource: 'Schedule a reminder for the user', which an agent can act on immediately. It does not distinguish itself from the sibling `create_reminders` (plural), `list_reminders`, or `cancel_reminder`, so the agent must infer whether this is the single-item or batch variant.

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 says the operation 'applies instantly, no quota', which hints that rationing isn't needed, but it gives no when-to-use context and never routes the agent between this tool and the clearly related `create_reminders` sibling. There are no prerequisites or exclusions stated.

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?

Goes well beyond the annotations by disclosing atomicity ('all or nothing'), specific error codes (limit_exceeded, invalid_payload) and what each means, the 20-slot account limit, the 180-day ceiling, and instant application. Annotations only mark it non-read-only, so this carries real operational detail.

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 purpose, then parameters, then error behavior in three dense sentences with no filler. Every clause (limits, error names, atomicity) earns its place.

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 nested-object batch mutation with an output schema, the description covers everything an agent needs: batching rules, per-entry fields, failure semantics, and limits. Failure modes are the key gap an output schema wouldn't convey, and they are fully addressed.

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 schema documents fire_at_local and text, but the description adds value by explaining the user's wall-clock convention, that text is delivered verbatim, and the validation rules (past time, >180 days ahead, empty text) that live nowhere in the schema. Some overlap with schema text keeps it from a 5.

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 ('Schedule several reminders'), gives scope ('up to 20 per call'), and characterizes the intended use ('one thing spread over several dates'), which cleanly distinguishes it from the singular sibling create_reminder. An agent can pick between the two without opening a 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 description explains the batch context for using this over the single-reminder tool and explicitly routes the agent to cancel_reminder when reminder slots need freeing. It stops short of an explicit 'use create_reminder instead when scheduling one' statement, so it's clear context but not a full when/when-not rule set.

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 non-readOnly, non-destructive, non-idempotent, closed-world, so the bar is lower, yet the description adds real substance: the source is unmodified, the call consumes one plan generation, and it enumerates 'not_found' and 'limit_exceeded' failure modes including ownership scoping. It doesn't restate idempotency or reversal behavior, but the quota and error disclosures are valuable.

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 the non-destructive guarantee, then layers optional tailoring, cost, and error semantics in a logical order. It is a touch dense across three sentences but every clause carries information an agent would otherwise have to guess.

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 an output schema present, return-value detail is largely covered, and the description still adds quota, ownership, and error-name context plus the vacancy linkage. An agent has what it needs to invoke correctly, though explicit idempotency/retry expectations are left to the annotations.

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 reported top-level coverage is 0% (the visible parameter is a $ref), but the nested input properties do carry their own descriptions. The description largely restates the vacancy_id linkage already in the schema (default name from vacancy title, badge/vacancy-card display) and adds only marginal detail, so it neither compensates strongly nor falls below the documented-schema baseline.

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 ('Create a new draft resume as a copy of an existing one') and immediately clarifies scope with 'the original is left untouched'. This cleanly separates it from siblings like rename_resume, delete_resume, and request_resume_update without the agent needing to open 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?

Gives clear context for the optional tailoring path via vacancy_id and notes the plan-cost implication, plus it points to where ids come from (get_recent_vacancies, list_resumes). It stops short of explicit when-not guidance or naming an alternative copy mechanism, so it is context-rich but not fully routing.

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 destructiveHint=true, idempotentHint=false, readOnlyHint=false, but the description adds substantial beyond them: what exactly is destroyed (questions, answers, feedback, public share link), that a retry survives with its link cleared, the 'not_found'/ownership-scoping behavior, and that it consumes no quota and refunds none.

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 irreversible-delete fact, then error semantics, alternative routing, and quota behavior in tight clauses. Every sentence earns its place; density is high but nothing is redundant or padded.

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?

An output schema exists (so return values need not be re-explained), yet the description still pins the two failure codes and ownership scope. Combined with destinations, alternatives, and quota effects, an agent has everything needed to call this safely.

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?

With a single required parameter and (per the reported) 0% schema description coverage, the description carries the burden but only partially: it reinforces the ARCHIVED constraint and tells the agent where to find a valid id via get_interview_results(archived=true). It adds no format/syntax detail, which is acceptable for a plain id but leaves the compensation partial.

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 (permanently delete) and resource (an ARCHIVED mock interview) with explicit scope, and immediately contrasts with the sibling archive_interview. An agent can tell exactly what this does versus 'archive' or 'remove' 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?

Explicitly covers the when-not case (returns 'not_archived' if still active; archive it first, 'which is what the user usually means by remove it') and names the alternative tool. It also routes the agent to get_interview_results(archived=true) to obtain a valid id. Nothing is left 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?

Goes well past the annotations: irreversible, no quota consumed, the vacancy will not reappear in future scans, and a derived vacancy analysis is deliberately NOT deleted. It also documents the 'not_archived' and 'not_found' failure modes, which annotations cannot express.

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 action, then layers scope, irreversibility, side effects, and error codes with no filler. It is dense and slightly long, but essentially every clause carries decision-relevant 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?

Despite an output schema existing, the description still covers return/error semantics, side effects on related analyses, and the web-only alternative — all the context an agent needs for a destructive, non-idempotent operation. Nothing material 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?

With a single parameter and 0% reported coverage, the description compensates by specifying the ID must reference an archived/skipped match and showing where to obtain it (get_radar_matches). The inline schema description reinforces but does not exceed this, so a 4 rather than 5.

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 (permanently delete) plus resource (radar match) and scope (Skipped pile — status skipped or archived). This cleanly separates it from archive_radar_match, skip_radar_match, and undo_radar_match without needing to open 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?

Explains exactly which matches qualify (skipped/archived), points to get_radar_matches(status="archived") as the way to locate them, and explicitly excludes the bulk-clear case as web-only. The when-to-use and when-not-to-use boundaries are both present.

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?

With annotations already declaring destructiveHint=true and idempotentHint=false, the description goes beyond them by detailing the cascade (PDF deletion, broken links), irreversibility of spent generation, and specific error codes ('not_found', 'cannot_delete_active', 'cannot_delete_only'). This is exactly the kind of behavioral context that annotations cannot convey.

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, tightly packed sentence with zero waste, front-loading the permanent deletion and cascade effects, then the irreversibility, then the error codes. Every clause adds distinct value.

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 is a destructive mutation with annotations covering safety, an output schema exists (so return format need not be explained), and one required parameter, the description is nearly complete. The only minor gap is that it does not mention any alternative recovery path (e.g., undo), but that may be covered by sibling tools like restore_resume_revision.

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 0% and the description does not explicitly explain the 'resume_id' parameter, but it does contextualize the input by referencing how to obtain it ('as returned by list_resumes' is in the schema anyway). The description's focus on error conditions and cascade effects implies the parameter's role without adding format or origin details beyond 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?

The description states a specific verb (Permanently delete) and resource (a resume), and immediately differentiates cascade behavior (PDF files deleted, links stop working) from siblings like archive_vacancy or close_resume_link. This is far more specific than the title alone and leaves no ambiguity about what the tool does.

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 clearly establishes the destructive, irreversible nature and the constraints (cannot delete active resume, cannot delete only resume), which implicitly tells the agent when NOT to use it. However, it does not explicitly name an alternative (e.g., archive_vacancy, restore_resume_revision, or rename_resume) for users who want to preserve data, leaving full when-to-use guidance partially inferred.

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 flag destructiveHint=true and idempotentHint=false, but the description goes further: it discloses irreversibility, the cascade semantics (linked resume/interview/offer survives with link cleared, radar match deleted and never re-offered), and quota behavior. That is behavioral context an agent cannot get from the 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?

Front-loaded with the destructive action and precondition, then cascades, then error codes. Dense and every sentence carries information, though the cascade clause is a long compound sentence that could be split for readability.

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?

An output schema exists, yet the description still names the meaningful return codes and side-effect counts, so nothing an agent needs to call this correctly or interpret the result 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?

Only one parameter and the schema's own description is thin, but the tool description reinforces the key constraint (it must be an ARCHIVED vacancy) and explains what 'not_found' implies about ownership. Good compensation for the low schema coverage, though it doesn't discuss id formats.

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 ('Permanently delete') plus resource ('ARCHIVED vacancy') and its precondition, and immediately distinguishes itself from archive_vacancy and the other delete_* siblings. The uppercase ARCHIVED makes the scope unmistakable.

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?

Explicit when-to-use (only archived vacancies), when-not, and the alternative ('archive it first with archive_vacancy, which is what the user usually means by "remove it"'). Error routing ('not_archived', 'not_found') tells the agent exactly what to do next on failure.

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 say readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false; the description adds far more — no watermarking, a cached no-render fast path, async rendering with typical latency of a few seconds, a 60-minute pdf_url lifetime, and no plan quota. The only missing piece is whether failed renders are retryable or billed.

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 outcome ('the exact file the user downloads'), and every clause carries information — caching, async path, quota, error. The async sentence is a long multi-clause run-on (task_id, latency, get_task_status, get_resume_pdf_url) that costs some scannability.

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?

Covers both execution paths, latency expectations, the URL's expiry, quota absence, and the error case; output shape is documented by the output schema, yet the description adds the status/file fields anyway. Nothing an agent needs to call this correctly and handle the response 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 reported at 0%, and the description never discusses resume_id directly; it only implies ownership scoping through the 'does not belong to the current user' error note and indirectly through 'as returned by list_resumes' in the schema. The parameter's meaning is largely carried by the inline schema text, not the description.

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 ('Generate the PDF of a resume') plus a distinguishing property ('the exact file the user downloads, never watermarked'). It also implicitly separates itself from the lookalike siblings get_task_status and get_resume_pdf_url by casting them as follow-up steps rather than substitutes.

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 explicit conditional routing: if the resume is unchanged, the call returns the file directly; otherwise it returns a task_id and the agent must poll get_task_status then call get_resume_pdf_url. It also names the failure condition ('not_found' when the resume is missing or owned by another user), leaving nothing 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 destructiveHint=true and idempotentHint=false, so safety is covered. The description adds genuine behavioral context beyond them: the consequence ('no longer reaches vacancy analysis or the agent') and the precise semantics of the 'not_found' outcome including the ownership-scoped case. It does not contradict any 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?

Three tightly written sentences, front-loaded with the action and identifier, then the effect, then the error case. No filler and every sentence carries new 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 single-parameter destructive tool with an output schema present, the description covers identifier source, deletion effect, and the not_found cases. Nothing critical is missing for correct invocation, though it could note whether the deletion is recoverable.

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 the description supplies its provenance ('as returned by get_career_memory'), which is the operationally important detail for producing a valid value. This largely compensates for the reported 0% schema description coverage, though it adds little else about id format.

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?

Specific verb ('forget') plus the exact resource ('a single career fact by its id') and it names the sibling that produces the id (get_career_memory). An agent can distinguish this from add_career_fact / upsert_career_memory 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 description tells you the fact is identified by an id from get_career_memory, which implies the get-then-forget workflow, but it never states when to prefer this over add_career_fact or upsert_career_memory, nor any preconditions beyond id provenance. Usage is implied rather than routed.

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?

Far exceeds the annotations: it discloses that an existing letter is replaced (previous version in view, unset options inherit prior values), that generation runs asynchronously and returns only a task_id, that the letter text is never returned, that one plan credit is spent per call (and another on replacement), and enumerates error codes (not_found, no_resume, limit_exceeded). This is exactly the kind of mutation and cost/limit context annotations can't convey.

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 what the tool does and is dense with no filler, though the seven-sentence block mixes purpose, replacement semantics, async flow, cost, and errors into one paragraph. Slightly long, but nearly every sentence carries distinct operational 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 an async, credit-consuming, non-idempotent write tool, the description covers the full lifecycle: invocation inputs, replacement behavior, task_id polling path, success signal (has_cover_letter), credit cost, and failure modes. With an output schema present, nothing material is omitted.

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 auto-reported 0% coverage is misleading because the nested $defs properties carry rich descriptions, but the description still adds value by restating the option set (tone, length, up to three emphasis strengths, personal note) and, importantly, the inheritance rule that omitted options keep the previous letter's values. It largely mirrors rather than extends the schema, which caps it below 5.

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 the cover letter for a vacancy in the user's tracker') plus its inputs (resume, analysis), which cleanly separates it from sibling analysis/read tools like analyze_vacancy and get_vacancy_detail.

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?

Clearly frames usage context: it writes to the vacancy's Cover Letter tab, replaces an existing letter when one exists, and routes the agent to get_task_status and get_vacancy_detail for the result. It does not state an explicit 'do not use this when X' alternative, but the surrounding flow is well-scoped.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the explicit empty-state disclosure ('Empty if nothing is stored yet') tells the agent how to interpret a no-data result. It does not, however, describe scope restrictions or freshness of the memory.

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 content is front-loaded and delivered in essentially one dense sentence, with the higher-value empty-state note kept short. The trailing 'Args: {}' is redundant given the empty schema and the enumeration is long, but nothing is buried or circular.

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 an output schema present, the description need not restate return values, yet it helpfully summarizes the memory contents and the empty case. For a zero-parameter read tool it is nearly complete; the only gap is the absence of explicit when-to-use framing relative to upsert_career_memory.

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 and the schema is an empty object at 100% coverage, so the baseline is 4. The description confirms 'Args: {}' but adds no further parameter meaning, which is appropriate since there is nothing to document.

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?

Uses a specific verb ('Get') plus the resource ('career memory') and enumerates exactly what is returned: target roles, locations, remote preference, seniority goal, industries, salary, work authorization, search stage, blockers, motivation, and free-form facts. This clearly distinguishes a read of career memory from siblings like upsert_career_memory or get_career_tips, though it never names the write counterpart as the alternative.

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 only routing guidance is a parenthetical noting that each free-form fact carries an id usable with forget_career_fact, which points at one downstream sibling but does not say when to call this tool versus alternatives. No explicit when-to-use or when-not-to-use condition is stated, leaving usage implied.

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=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: the word-by-word matching rule, the 'at least half the query words' threshold, ignoring words under 3 letters, and relevance ordering — all beyond what annotations provide.

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 purpose, then filtering modes, then a compact args summary. Dense but every sentence carries information; the trailing args recap slightly 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?

An output schema exists, so return values need not be explained, and the description covers purpose, filters, and matching behavior. The only gap is the absence of guidance relative to siblings like get_career_memory.

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 schema $defs already document each parameter, including defaults and limits, so the description largely echoes it (limit default 10/max 30). It does add matching semantics not spelled out in the schema — the sub-3-letter word exclusion and the 'more words matched first' ordering — which justifies being above the baseline.

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 ('get short, fact-checked career cards') and enumerates the topical coverage (recruiter behaviour, ATS, resumes, etc.), which is far more than a restatement of the name. It does not, however, distinguish itself from nearby siblings like get_career_memory or add_career_fact.

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 use case ('ground advice in') and lays out three filtering modes, so an agent can infer when to reach for it. But it never states when to prefer it over get_career_memory or other retrieval siblings, and gives 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds real behavioral context beyond them: the null-when-unagreed case, the user's timezone framing, and the counting rule ('Progress counts only what was done'), which prevents misreading the metrics.

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 return contents and only two sentences long, but the second sentence is a dense list of progress metrics that borders on enumeration for enumeration's sake. It remains readable and every 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?

With an output schema present, return shape is already documented, and the description still adds the semantics an agent needs: the null case, timezone basis, and the rule that only completed work is counted. Nothing required to interpret or invoke this zero-arg 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool is 4. The trailing 'Args: {}' is redundant but harmless.

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+resource ('Get the weekly job-search plan') and enumerates exactly what it returns: goal, target roles, applications a week, review day, state, plus this week's progress. It is clearly distinguishable from the sibling mutators set_coach_plan and pause_coach_plan, which write rather than read.

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 gives clear context for reading the plan ('the plan the user agreed') and the null case ('plan is null when no plan was agreed'), which lets an agent decide whether it has anything to show. It does not explicitly route to alternatives like set_coach_plan or pause_coach_plan, so there is no exclusion 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=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuine context beyond that: the enumeration of how a card was earned, the meaning of milestones, and the explicit note that the list holds only earned items with no total or progress counter.

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, then supporting detail on card contents and milestone semantics. The milestone sentence is slightly discursive but earns its place by clarifying what counts as a card. No filler or repetition.

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?

An output schema exists, so return-value shape need not be described, and the tool is zero-parameter and read-only. The description covers purpose, entry contents, and the absence of a progress counter; only sibling disambiguation is missing, which keeps it short of a 5.

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 (schema coverage 100%, empty properties object), so the baseline is 4. The 'Args: {}' note simply confirms the no-argument contract, and there is no parameter meaning left to add.

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 ('Get the career cards this user has collected') and details what each entry contains: what, when earned, and how (deck | loader | agent | milestone | import). It does not explicitly name or rule out the nearest siblings such as get_user_stats or get_career_memory, so an agent must infer the boundary, but the resource itself is 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?

Usage is implied by the resource but no when-to-use or when-not-to-use guidance is given and no alternative sibling is named. The line 'There is no total to collect and no progress counter' weakly steers the agent away from a stats-style tool, which is the only routing signal present.

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 read-only annotations, the description discloses privacy boundaries ('Never other people's identities, member counts or rankings'), the meaning of the 'available' flag when guilds are closed, and the relevant time windows for cheers and game completion. This gives the agent concrete behavioral expectations for a read tool whose data is socially sensitive.

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 purpose is front-loaded, but the description is a single run-on sentence that enumerates return fields already covered by the output schema. The trailing 'Args: {}' is redundant filler for a zero-parameter tool. It remains informative, but structure and economy are weak.

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?

The description covers availability state, privacy exclusions, time windows, and what kinds of news/game data appear. Because an output schema exists, it does not need to enumerate return fields in detail, but doing so makes the definition complete rather than deficient. Minor gaps around error behavior are acceptable for this read-only 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?

The tool takes zero parameters, so the schema baseline is 4. The description confirms there are no arguments ('Args: {}'), though it adds no further parameter semantics because none are needed.

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 uses a specific verb ('Get') and clearly names the resource ('what is new for the user in the guilds'). It then scopes that resource precisely: six work-style guilds, a shared job-search step feed, games, cheers, and completion statuses. No sibling tool covers guild news, so it is clearly distinguishable.

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 content description ('get what is new for the user in the guilds'), but the description never states when an agent should choose this tool or when another tool is more appropriate. There are no explicit exclusions or alternatives. The 'available is false' note is a state condition, not usage 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=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds genuine behavior beyond that: newest-first ordering, exclusion of archived records, the default/max limits, and the reassuring 'Empty list is a normal result' — a real anti-misinterpretation cue.

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 tight sentences, front-loaded with the core action, then defaults, then the archived mode and the empty-list caveat. 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?

An output schema exists so return values need not be enumerated, yet the description still summarizes item contents (score, role, feedback, weak topics) for scanability. Ordering, filtering, limits and empty-result semantics are all present — nothing an agent needs to call it 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 coverage is reported as 0%, so the description must carry the load, and it does: it restates the limit default (5) and cap (20) and explains what archived=true actually selects. The added note that archived mode is required to obtain a deletable id is meaning the schema does not provide.

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 user's completed mock interviews') plus ordering scope ('newest first'), which separates it from archive_interview and delete_interview at a glance. No ambiguity about what is returned.

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 gives the condition that switches modes ('pass archived=true to list the archive instead') and cross-references the sibling that consumes the result ('the only way to find the id delete_interview needs'). The agent knows both when to call it and why.

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 read-only annotations, the description discloses the four-week radar scope, the important under-30-postings threshold where enough_data is false and only the count is given, and the invalid_payload error cases. This gives an agent substantial behavioral context for correct invocation and interpretation.

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 front-loaded with the main purpose and is not padded with irrelevant material. It is dense and run-on in places, especially the long list of returned metrics, but each clause generally adds useful scope or caveat 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?

Given the output schema, annotations, and one nested input object, the description is complete enough for an agent to know what the tool returns, its radar-only scope, the minimum-data threshold, and the error conditions. Nothing essential to a correct call appears to be 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?

The schema signal reports 0% description coverage, and the description adds only limited parameter guidance: role words are implied by the invalid_payload note, and country/everywhere is mentioned. The nested schema itself documents role and country, so the description does not substantially compensate for the coverage gap beyond what the schema already says.

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 a specific resource: a four-week job-market snapshot for a role, optionally scoped to one country or everywhere. It distinguishes the aggregate radar view from the whole market, but does not explicitly differentiate it from sibling tools such as get_radar_matches or search_vacancies.

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 gives clear usage context: what the radars found in the last four weeks, one country or everywhere, and the caveat that it does not cover the whole market. It also warns that under 30 postings only the count is returned, though it does not name alternative tools for different needs.

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=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the vacancy-step state machine (no step after applying until the employer answers, then it moves to new radar matches or another analysed vacancy) and the app_url deep link for where the step is performed.

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 purpose in the opening clause, then layers on the payload detail and lifecycle rule. The single dense sentence is a bit run-on and "Args: {}" is filler for an empty schema, but there is no padding or repetition.

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?

An output schema exists, so return values need not be explained, yet the description still characterizes the key fields (reason from their data, the vacancy and its inner step, app_url). With zero parameters and a declared read-only profile, an agent has everything needed to call this 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?

There are zero parameters and schema description coverage is 100%, so the baseline is 4; nothing about parameter meaning needs compensating. The trailing "Args: {}" adds nothing but also does no harm.

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 — "Get the user's one next step in the job search" — and pins it to the ResumeQuick home screen, so the agent knows exactly what this returns. It also enumerates the returned shape (step, reason, vacancy, step type, app_url). It never contrasts itself with adjacent readers like get_coach_plan or get_recent_activity, so sibling differentiation is implicit rather than stated.

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 — this is the canonical 'what should I do next' call — but the description never says when to prefer it over get_coach_plan, get_recent_activity, or get_radar_matches, nor does it give any exclusion. The lifecycle note (after an application the vacancy has no step until the employer answers) clarifies the data, not the when-to-call decision.

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; the description adds substantial context beyond that: the two status states the caller can observe, the 'not_found' result for missing or foreign offer ids, the caveat that market ranges are estimates rather than company pay bands, and the confidence field that can claim no position. That is exactly the kind of behavioral 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?

Front-loaded with what the tool returns, then status behavior, then the estimate caveat and error case — a sensible priority order with no filler. The opening is a long, dense enumeration, but every listed artifact (scripts, deltas, confidence) tells the agent something actionable, so the length is largely earned.

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 an output schema exists, the description could have stopped at purpose; instead it covers return contents, async status transitions, error behavior, and an important interpretive caveat about market estimates. An agent has everything needed to call this correctly and to interpret the response honestly.

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 the description gives no syntax detail beyond the schema, but the schema's own property description ('Id of the offer to fetch, from list_offers or analyze_offer') covers the parameter meaning and provenance. With a single, schema-documented parameter there is little left for the description to add.

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?

Opens with a specific verb+resource ('Full analysis of one offer') and then enumerates exactly what the analysis contains (health score, verdict, pay components, flags, leverage points, scripts). This clearly distinguishes it from list_offers (which enumerates) and analyze_offer (which produces the analysis), so an agent can route correctly 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 status semantics ('processing' while the analysis runs, 'completed' once done) implicitly tell the agent this is a poll/read tool that follows an analyze_offer call, and the schema's offer_id description names list_offers and analyze_offer as sources. However, the description never states explicitly 'call this after analyze_offer' or gives guidance about polling cadence, so the when-to-use context is strong but not fully spelled out.

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=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it identifies the tool as the live pricing source, specifies that prices are uniform across users, and lists the exact catalog dimensions returned.

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 front-loaded with 'Get the current pricing catalog' and then adds only relevant detail. Every clause earns its place by specifying what the catalog contains or how the data should be interpreted.

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 an output schema present and annotations covering safety, the description supplies enough context to call the tool correctly: it identifies the live source, the scope of pricing and limits, and the invariant that prices are the same for all users. Nothing material is missing for a zero-parameter read-only catalog 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?

The tool has zero parameters, so there is no parameter semantics for the description to clarify. The baseline for a parameterless tool is 4, and the description appropriately avoids discussing non-existent inputs.

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 states a specific verb and resource: 'Get the current pricing catalog.' It also enumerates the catalog contents (tiers, action packs, USD prices, duration, renewal, limits, current tier), so an agent can distinguish this from usage or plan-management siblings 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 description makes clear this is the live source of ResumeQuick prices and limits and notes that prices are the same for all users, which gives strong context for when to call it. However, it does not explicitly name alternatives such as get_usage or get_coach_plan or state when not to use it.

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, non-destructive, closed-world), and the description adds genuinely useful behavioral context beyond them: exactly which fields are returned and the two edge cases ('not_found' when no resumes exist; empty summary for an unfinished profile). It stops short of rate limits or auth requirements.

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 no waste. The core purpose and field list are front-loaded, and the edge-case behavior follows immediately after.

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?

An output schema exists, so return-shape explanation is not required, yet the description adds a field enumeration and covers the failure/empty-state paths. For a zero-parameter read tool, nothing an agent needs to call it correctly is absent.

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 and the baseline is 4. No parameter-level detail is needed or missing.

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?

Specific verb (Get) plus resource (compact summary of the current user's primary resume) with an enumerated field list. It is clearly distinguishable from heavier siblings like get_resume and list_resumes because it self-describes as a compact snapshot.

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 word 'compact' implies a lightweight overview use case versus a full-resume fetch, but it never names an alternative tool or states the condition for choosing this over get_resume/list_resumes. Usage is implied rather than explicit.

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 annotations, it discloses non-obvious behavior: the 30-item cap with offset paging, the total count, that match_percentage is a rough guess and not predictive of analysis, that the stored snippet is the full posting text held, and that title-derived filters (seniority, employment_type, posted_after) silently drop postings with no title/date signal.

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 ordering come first, and virtually every clause carries information (field meanings, filter pitfalls, paging). It is dense and reads as two long run-on paragraphs, which makes it harder to scan than a bulleted field list would be, but there is 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?

Covers what the list contains, the shape of each item, all filter semantics and their biases, paging, ordering, and the expected empty result. Even though an output schema exists, the extra notes about analysis_id/analysis_match_percentage and null-valued levels make the tool callable without further lookup.

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 description explains the practical meaning of status, the filter set, sort='fresh' vs the best-match default, and total/offset paging, adding semantic caveats (e.g. small results mean silent titles, not rare jobs) beyond the schema's own field descriptions. It does not mention the limit parameter's 1..30 range, which stays with 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?

Opens with a specific verb+resource ('List vacancies the user's job radar has found'), defines the radar as an automatic resume-based search, and states default ordering. It also names adjacent tools (get_vacancy_detail, analyze_radar_match, delete_radar_match) so an agent can separate this list tool from detail/analysis/mutation 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?

Gives explicit conditions for each status value, says 'Omit for new plus saved', explains that the archived pile is where delete_radar_match takes its ids, and warns that an empty list is normal before start_radar_scan. What is missing is an explicit contrast with search_vacancies/get_recent_vacancies for non-radar browsing.

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 establish that this is a safe read-only operation, and the description adds substantial behavioral context beyond them: last_scan_at only moves when new vacancies arrive, next_scan_at is set only on the free plan when the weekly scan is spent, and all zeros with auto_search_enabled=false is normal for a never-used radar. These are important interpretive traits that an agent would not get from the annotations alone.

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 front-loaded with the core status categories and then adds only field-specific interpretation. It is dense and longer than many definitions, but nearly every sentence clarifies a real ambiguity such as search_query versus search_role or why filters.role may be empty.

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 output schema and read-only annotations, the description is complete enough for correct invocation and interpretation. It covers the status categories, edge cases, plan-specific behavior, and the distinction between filters, last scan query, and next scan role.

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 has zero parameters, so the schema cannot provide parameter-level semantics and the description does not need to compensate. The baseline for a zero-parameter tool is 4, and the description appropriately focuses on returned state rather than inventing parameter guidance.

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 states a specific read operation and enumerates exactly what the status contains: working-list matches, pool, saved, deferred, skipped, last scan, auto-search, filters. It clearly distinguishes this summary view from paging through individual matches, making it easy to separate from siblings like get_radar_matches.

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 provides clear context for when to use this tool by framing it as 'the progress picture without paging through every match,' which implicitly points to get_radar_matches as the detailed alternative. However, it does not explicitly name that sibling or state any when-not conditions.

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 establish readOnly/destructive/openWorld, so the bar is lower; the description still adds real behavior: newest-first ordering, archived analyses included, and that an empty list is a normal result rather than an error. It is silent on whether results are ever truncated beyond `limit`, but the added context is substantive.

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 verb and resource, then the event enumeration, then the window/limit constraints, closing with the empty-result note. Dense but every clause carries information; the single long first sentence is the only mild readability cost.

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?

An output schema exists, so return field details needn't be described. The description supplies scope, ordering, defaults, caps, and the empty-result behavior, which is enough for a zero-required-parameter read tool; only truncation/pagination behavior beyond `limit` is left implicit.

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?

With schema description coverage reported at 0%, the description must carry the parameter burden and largely does: it restates the look-back window default and cap, the result-count default and cap, and the ordering. It doesn't clarify invalid-value handling (e.g., days > 180), which is the only remaining gap.

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?

Specific verb (list) plus a clearly scoped resource (recent profile-affecting events), with the included event types enumerated: resumes created/updated, vacancies analyzed, mock interviews completed. An agent can distinguish this from get_recent_vacancies or get_resume_history without opening a 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 'profile-affecting events' and the recency window, which hints at a dashboard-style summary rather than a per-entity lookup. However, no sibling is named and no when-not-to-use guidance is given, despite close neighbors like get_recent_vacancies and get_resume_history where routing matters.

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=true and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: ordering semantics, exclusion of in-flight/failed analyses, the meaning of 'total' across all matches, and the default/max limit. It stops short of describing pagination or response shape in depth, but the additions are meaningful.

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 purpose and ordering rule, then failure-mode and filter details. Sentences are dense but each carries information; nothing is wasteful, though the run-on second sentence could be split.

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 an output schema present, the description needn't enumerate return fields, yet it still names what analyzed vacancies include (match percentage, verdict, strengths/gaps) and explains total and empty-list semantics. An agent has everything needed to call and interpret this 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?

Schema description coverage is reported as 0%, so the description must carry parameter meaning. It covers the analysis_status and status filters plus limit defaults/caps, but omits the 'archived' parameter entirely, leaving one of the filters unexplained in prose. Partial compensation, so a 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+resource ('List the user's tracked vacancies') and immediately pins down the scope: pinned first, then newest by analyzed_at, with which analysis states are included vs excluded. This clearly distinguishes it from siblings like search_vacancies or get_vacancy_detail.

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 concrete selection context: vacancies with running/failed analyses are not listed, filters are tracker status and analysis_status, and an empty list is normal. It does not explicitly name an alternative sibling (e.g., search_vacancies for un-tracked results), so it falls just short of a 5.

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=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail: the exact structure returned, the presence of 'id' fields for edits, the not_found condition, and the ownership constraint ('does not belong to the current user'). This goes beyond what annotations alone provide.

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 front-loaded with the core action and return structure, then adds useful context about edit compatibility and error handling. It is a bit dense but every sentence adds value. Could be slightly more concise, but no wasted words.

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 that an output schema exists, the description needn't detail return values, but it helpfully summarizes them. It covers the ownership constraint and not_found behavior. However, it does not mention any potential pagination or size limits, and the parameter semantics are thin. Overall, it is complete enough for a read tool with annotations and output schema.

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 must compensate. It does mention that the resume is identified by id and that sections use field names accepted by update_resume_section, but it doesn't explain the format or constraints of the resume_id parameter itself beyond what the schema title implies. The schema provides the field name 'resume_id' with a description, but coverage is low. Baseline 3 is appropriate given the description partially compensates by linking to other tools.

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 it retrieves a specific resume by id and enumerates exactly what is returned (12 sections plus style). It distinguishes itself from siblings like list_resumes and get_resume_revision through the scope and detail of the return payload. However, it doesn't explicitly contrast with get_resume_history or get_resume_pdf_url, leaving minor ambiguity.

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 (call this when you need the full resume by id), but there is no explicit when-to-use versus alternatives like list_resumes or get_resume_revision. The description mentions the not_found return condition, which gives some context, but no exclusion 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=true, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds real behavioral context beyond that: newest-first ordering, what each entry contains (timestamp, producer/origin, per-section counts, diff flags), and the 'not_found' outcome for a missing or non-owned resume.

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 ordering, then the per-version payload, then the error case. The dense semicolon-chained sentence is information-rich rather than padded, though it borders on overstuffed for a single sentence.

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?

Covers ordering, content semantics, producer/origin enumeration and error behavior, which is more than enough for an agent to call it correctly; the output schema already handles return shape. Missing only pagination/truncation behavior for the limit parameter and any auth note.

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 description contributes no parameter-level detail; it never mentions resume_id or limit. The schema itself does document both fields (range 1..50, default 20, resume id from list_resumes), so the structured data carries the load, but the description neither compensates nor adds syntax, ownership, or pagination semantics of its own.

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 with scope ('List the saved versions of a resume, newest first') and clarifies what a version is ('the resume content as saved at that moment'), which cleanly separates it from get_resume (current content) and list_resumes (the resume list itself). An agent can pick this over its nearest siblings without opening a 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?

Gives a concrete use case — locating the version where missing content was last present via entry counts — which tells the agent when this tool is the right one. It stops short of naming an alternative for restoring that version (restore_resume_revision) or excluding cases where get_resume_revision would suffice, so it is clear context without explicit routing.

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=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuine behavioral context on top: the 'not_found' error condition for a missing or non-owned resume, and the fact that it 'creates nothing and spends nothing.' It stops short of describing pagination or the full return shape.

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 first front-loads the action and what is returned, the second handles the alternatives and the error case. 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?

An output schema exists, yet the description still flags the meaningful error return ('not_found'). Combined with the sibling routing and the read-only framing, an agent has everything needed to call this 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 description does not itself discuss resume_id, but the parameter is documented in the schema as 'Resume id, as returned by list_resumes.' With a single well-described parameter, the schema carries the semantic load, which lands at the 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 specific verb (read) plus resource (a resume's public share link) and enumerates the returned scope: whether a link is open, its address, and which file version it shows. It distinguishes itself from the sibling mutation tools share_resume_link and close_resume_link by name.

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 routes the agent: this tool only reads, share_resume_link creates/updates, and close_resume_link closes. The when-to-use and the when-to-use-something-else conditions are both spelled out, leaving nothing 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 a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), but the description adds real behavior beyond them: the URL lives for 60 minutes (expires_at), it is the user's private copy that creates no public link, and it enumerates the two failure statuses plus the meaning of is_current.

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 definition before branching into alternatives and status codes. Dense but each clause carries distinct information; the parenthetical status explanations are tightly integrated rather than padded.

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?

An output schema exists, so return structure needn't be documented, yet the description still explains the key status values and the is_current flag. Combined with the private-vs-public distinction and expiry, an agent has everything needed to call and interpret this 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?

There is a single parameter (resume_id) whose meaning is already carried by the schema field description ('Resume id, as returned by list_resumes'). The tool description adds no additional semantics for it, so with only one param this lands at the baseline.

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 ('Get the latest downloaded PDF of a resume') and immediately defines what the artifact contains (file name, pages, made date, URL). It distinguishes itself from siblings by naming share_resume_link and export_resume_pdf, so an agent can tell them apart 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?

Explicitly routes the agent: use share_resume_link to make a link for other people, and export_resume_pdf when no download exists yet. It also defines the exact conditions producing 'not_generated' and 'not_found', which is the when-not guidance most tools lack.

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=true and destructiveHint=false, so safety is known; the description goes further by disclosing the critical gotcha that entry ids belong to the old version and must be stripped before reuse, and by stating the 'not_found' failure condition including the ownership check. It stops short of describing pagination or output volume, but adds real behavioral value beyond the 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?

Three sentences, front-loaded with purpose, then the cross-version id caveat, then the error contract. Every sentence earns its place, though the restore-path sentence is dense enough that it could be split for readability.

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 an output schema present, return shape need not be explained; the description nonetheless covers id provenance, the version-vs-entry restore semantics, and the not-found/ownership failure mode. An agent has everything needed to call this 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?

Only one nested input parameter, and the description explains where revision_id originates (get_resume_history), reinforcing the schema's own field note. resume_id's provenance is left to the schema, which is a minor gap but not a material one for a single required parameter.

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 ('Get one saved version of a resume') and scopes it against siblings by tying revision_id to get_resume_history and describing the shape as identical to get_resume. An agent can distinguish this from get_resume, get_resume_history, and restore_resume_revision 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?

Explicitly routes the agent: use update_resume_section (resending the entry without its id) to restore a single entry, and restore_resume_revision to bring back the whole version. The creation path for revision_id is named (get_resume_history), so prerequisites are covered.

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 the safety profile (readOnly, non-destructive, closed-world), and the description adds substantial context beyond them: English-only output regardless of resume language, no quota, and a 'not_found' error for missing or non-owned resumes. Ownership and error semantics are exactly the kind of thing annotations can't express.

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 output shape are front-loaded, followed by disambiguation and error behavior. Every clause earns its place, though the quota/get_usage aside is a slight tangent that adds density.

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?

Despite an output schema, the description still conveys ordering ('highest-impact first'), tagging (section + priority), language behavior, quota status, and the not_found case. Nothing an agent needs to call it 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?

Only one parameter (resume_id) and the description adds little beyond 'by id'; the schema itself already documents it as 'Resume id, as returned by list_resumes'. With 0% description coverage but a self-evident single param, this is the minimum-viable baseline.

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+scope: 'Get a prioritized list of concrete improvements for a resume by id'. It also distinguishes itself from score_resume (numeric assessment) and request_vacancy_resume_suggestions, so an agent can route 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?

Explicitly names alternatives and the condition selecting them: 'score_resume gives the numeric assessment' and 'the resume_suggestions action in get_usage belongs to request_vacancy_resume_suggestions'. This tells the agent both when to use this tool and when a sibling is the right call.

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 establish read-only, non-destructive, closed-world behavior. The description adds substantial behavioral detail: statuses, progress, failure reasons, success artifacts mapped to task types, and a not_found result for missing or unauthorized tasks.

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 purpose is front-loaded and the definition is information-dense with little waste. However, it is a single very long sentence with a large parenthetical list and many semicolon-like clauses, making it harder to scan than it could be.

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 simple one-parameter input, existing output schema, and read-only annotations, the description provides all the context an agent needs. It covers valid sources of task_id, lifecycle states, failure behavior, success outputs by task type, and missing/unauthorized behavior.

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 low, so the description has to compensate for the single task_id parameter. It does so by explaining that task_id is the value returned by specific background tools and by tying that parameter to the not_found ownership behavior.

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 states a specific verb and resource: report a background task by task_id. It distinguishes this tool from siblings by naming the producer tools whose task_ids it tracks and by explaining the status/progress/result information returned.

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 clearly says to use the task_id returned by a tool that runs in the background and lists many such tools. It does not explicitly state when not to use it or name alternative status-checking tools, but the surrounding context makes its role clear.

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=true and destructiveHint=false, so the safety profile is covered, and the description still contributes substantive behavior: reset semantics for calendar vs rolling windows (oldest use drops out), that bonus/pack credits buy uses beyond an allowance, that background-generated resumes count against resume_generation, and that Radar scans are excluded from credit spending.

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 payload is front-loaded in the first clause (own use of the plan, per limited action) and each following clause carries distinct semantic content about resets, credits, and plan expiry. It is dense and somewhat long, but nearly every clause earns its place; the return-value detail overlaps with the output 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?

With an output schema present, the description need not restate return shape, yet it still supplies the domain semantics an agent needs: what a limited action is, how periods and rolling windows reset, which activities consume allowances, and where to go for pricing. Nothing required to call or interpret 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?

Zero parameters, so there is no schema surface for the description to compensate for; baseline 4 applies. The description also scopes the result set implicitly by talking only about the caller's own plan rather than arbitrary users.

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 (the user's own usage of their plan) and enumerates exactly what is returned: per-action counts, allowances, availability, reset timing, bonus/pack credits, and plan/trial end dates. It is clearly differentiated from the sibling get_pricing, which covers prices and other plans' limits.

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?

Names the alternative explicitly: prices and other plans' limits live in get_pricing, while this tool covers the caller's own usage and the same limited actions get_pricing enumerates. The condition that selects one tool over the other is stated, not inferred.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description still adds real value beyond that: window semantics (default 30, max 180), the fact that resumes_count is never windowed, and the reassurance that zero counts/averages are normal for new users.

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 that front-loads the purpose and window semantics before listing returned metrics. The long enumeration of fields is somewhat run-on but every clause is informative.

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?

Although an output schema exists so return values need not be re-explained, the description's coverage of window semantics, the non-windowed resumes_count, and the zero-result caveat makes it self-sufficient for correct invocation. Nothing an agent needs to call it 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?

Reported schema coverage is 0%, so the description must carry the parameter meaning, and it does: period_days defaults to 30, is capped at 180, scopes the activity counts, and explicitly excludes resumes_count from windowing. It does not cover validation/error behavior for out-of-range values, keeping it short of a 5.

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+resource ('compact numeric summary of the user's activity') and enumerates exactly what is summarized, which implicitly separates it from event-listing siblings like get_recent_activity or get_usage. It never names an alternative sibling explicitly, so differentiation is inferred rather than stated.

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 context is implied (read aggregate activity over a look-back window) and the default/cap are given, but there is no explicit when-to-use versus when-not guidance and no pointer to alternatives such as get_recent_activity for event-level detail.

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