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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the mutation profile is covered. The description adds nothing behavioral — no statement about duplicate handling, whether the contact is idempotent, or what side effects follow from adding.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence with the verb and resource first. The trailing clause 'using the supplied contact details' is near-filler, keeping it out of the top band.

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 5-parameter mutation with no output schema, the description covers the basic purpose but omits duplicate/existence behavior and whether any identifiers are returned. Annotations carry the safety profile, so the minimum viable bar is met but not exceeded.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented in the schema and the baseline is 3. The phrase 'using the supplied contact details' adds no syntax, format, or required-field meaning beyond what the schema provides.

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 ('Adds a ... contact to the account') and narrows the scope to recruiter/referrer contacts, which is more than a restatement of the name. It doesn't explicitly distinguish itself from the sibling list_contacts, but the add-vs-list split is self-evident.

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?

No when-to-use guidance, no prerequisites, and no mention of the sibling list_contacts for checking existing contacts or handling duplicates. The only usage signal is the implied scope ('recruiter or referrer'), which is not the same as 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?

Goes beyond the annotations by disclosing real side effects: the job lands in a 'private pipeline,' eligible accounts trigger creation/queuing of application materials, and this consumes 'pack allowance' (a quota/cost signal). It also clarifies nothing is submitted. It stops short of explaining eligibility criteria or auth needs, but this is materially more than destructiveHint=false provides.

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 the core action and fields, followed by the eligibility/pack-allowance side effect and the non-submission boundary. No filler; each sentence adds a distinct fact.

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 mutation tool with no output schema and thin param coverage, the description supplies the missing behavioral layer (scope, side effects, quota, non-submission). It omits duplicate handling, auth, and return shape, but covers what an agent needs to call it deliberately.

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 only 33% schema description coverage, the description compensates by enumerating all six inputs and signaling optionality ('title, company and optional description, URL, contact email and application method'). It doesn't explain the applicationMethod enum values, but the schema already carries that enum.

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 clear verb+resource ('Adds a job to the account's private pipeline') and names the fields it accepts. However, it never distinguishes itself from close siblings like save_job or import_job, leaving the agent to infer the 'manual' vs 'save/import' distinction from the title alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is implicit routing value in 'No application is submitted,' which separates this tracking action from apply/prepare_applications. But it offers no explicit when-to-use condition or named alternative (save_job, import_job, browse_listings), so usage remains 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?

Even though annotations already declare destructiveHint=true and openWorldHint=true, the description adds substantial context beyond them: submission 'cannot be recalled', it needs pre-existing materials and plan allowance, a mismatch on expectedRevision 'fences the send', and the confirmation hold is a real two-phase protocol with a token bound to identical arguments. That is exactly the behavioral texture an agent needs for an irreversible action.

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 dense sentences with the core action front-loaded and no filler; each sentence carries new constraints (preconditions, irreversibility, hold/token protocol). The middle sentence is long but every clause 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 destructive, open-world tool with no output schema, the description covers preconditions, irreversibility, and the shape of the held result (destination, material summary, token). It stops short of describing the successful-submission outcome or failure modes, which is a minor remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 67% schema coverage, only applicationId is undocumented in the schema. The description compensates by explaining that materials are taken at expectedRevision and that the token is bound to identical arguments, adding meaning over the schema text rather than repeating it.

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 ('Submits one application to an employer') plus the key scoping detail ('using the saved materials at expectedRevision'), which distinguishes it from preparation-oriented siblings like prepare_applications and strengthen_application. It does not, however, name or exclude any sibling explicitly, so an agent must infer the boundary itself.

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 conveys implied prerequisites ('requires existing materials and plan allowance') and the two-phase hold/confirm flow, which tells the agent the call is not a one-shot. But it never says when to reach for this tool instead of alternatives such as mark_applied_offsite, cancel_apply or generate_outreach, leaving the routing decision to inference.

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

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

Annotations already declare readOnly, non-destructive, closed-world behavior, but the description adds substantial operational detail: anonymous browsing, 25-item default and clamping, stable uncapped cursor walks versus 1,000-item sorted walks, cursor/filter coupling, and overlapping addedAfter discovery windows. This is rich behavioral disclosure beyond structured fields.

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 and filter scope are front-loaded, followed by dense but relevant pagination and cursor rules. No sentence is pure filler, though the description is long and a few clauses duplicate schema wording.

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. For a 20-parameter search tool, the description covers anonymous access, page size and clamping, cursor reuse requirements, sort walk limits, and pay matching semantics—everything an agent needs to invoke it 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 100%, so the schema already documents all 20 parameters. The description adds some meaning for pay-band matching and addedAfter overlapping windows, but much of its parameter-related text restates what the schema already says, making 3 the correct 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 ('Returns') and resource ('indexed listings') and enumerates the filter scope. It is clearly a search/browse operation, but it does not explicitly contrast itself with siblings such as get_listing or list_matches, so it falls short of 5.

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?

Provides clear context for filtered browsing, anonymous access, and cursor-based paging. However, it never says when to use this instead of list_matches/get_listing or gives any when-not conditions, so it stops at clear context without alternatives.

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 readOnlyHint=false, so the safety profile is covered. The description adds real context beyond that: the exact state boundary at which cancellation is impossible and the fact that the receipt reports that boundary, which is meaningful for a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, with the state constraint front-loaded and the failure boundary second. 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?

An output schema exists, so return values need not be explained, and the description still gestures at the receipt. For a one-parameter destructive tool the description is nearly complete; only the parameter's own semantics are unaddressed.

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%, so the description would need to compensate, and it does not mention applicationId at all. The single parameter is self-explanatory by name, which keeps this at a baseline 3 rather than lower.

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 (stops/cancel) plus the resource and its state (queued or in-progress application), so the action is unambiguous. It implicitly contrasts with the apply sibling by scoping itself to applications where submission can still be prevented, but never names an alternative tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear when-to-use condition (queued or in-progress, submission not yet sent) and an explicit when-not condition (already submitted applications cannot be recalled). No alternative tool is named for the submitted case, so it falls 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 only state destructiveHint=true/readOnlyHint=false. The description goes well beyond that, disclosing the delete-after-promote side effect, the branching outcome for a refusal (becomes a deal-breaker) vs other confirmations (become work-vault notes that do not filter matches), and the receipt behavior. This is exactly the kind of behavioral context a mutation tool needs.

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 that are front-loaded with the core action, then branching semantics, then return info; little waste. Minor redundancy in the final sentence, since an output schema already exists to describe the receipt.

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 mutation with annotations covering the destructive profile and an output schema covering the return value, the description supplies the essential branching and side-effect context. The remaining gap is the undocumented hypothesisId semantics, which is not compensated for anywhere.

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 there is a single required hypothesisId, yet the description never says what the id refers to, its format, or where to obtain it (presumably from remember_hypothesis). With low coverage the description should compensate and does not, leaving the one parameter undocumented everywhere.

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 (promotes) and resource (a stored hypothesis) and adds the defining behavior (deletes the hypothesis afterward), so an agent can tell what it does. It does not name sibling hypotheses tools like remember_hypothesis/forget_hypothesis, so sibling differentiation is only implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'after the person confirms it' implies the situational context and 'A stated refusal becomes a matching deal-breaker; other confirmations become work-vault notes' hints at branch outcomes, but there is no explicit when-to-use vs when-not guidance or named alternative for storing/forgetting hypotheses. Usage must be 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 declare destructiveHint=true, and the description earns that by spelling out exactly what becomes hidden, across which surfaces, and how long the undo window lasts. It further discloses that the supplied reason is not stored and does not affect later matches, and it bounds the blast radius by listing what is untouched.

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 scope, then the recovery paths, then the exclusions — a logical order with no filler sentences. It is dense (four clauses of surface names) but every clause carries distinct information, so it stays on the right side of verbose.

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 mutation with only two parameters and an output schema that covers the receipt/return, the description supplies the remaining essentials: blast radius, reversal path, and explicit non-effects. Nothing an agent needs to decide or call 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 100% and the schema already documents both jobId and reason, including the 'accepted but not stored' note. The description restates that the reason is not stored, adding emphasis but little new information; the useful nuance about matching scope belongs to behavior rather than parameters. Baseline 3 is appropriate when the schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (hides) and resource scope (one role plus every listing with the same employer and title in any location) and names the exact surfaces affected: match feed, job alerts, Autopilot. It is clearly separable from restore_match and list_dismissed_matches, which are named as the inverse and the list view.

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: restore_match reverses it at any time, list_dismissed_matches lists dismissed listings, and the receipt's one-minute undo window is called out as the immediate reversal path. It also gives negative guidance — it does not hide other roles from the same company and does not move or remove a pipeline card — which removes the most likely mis-invocation.

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 and destructiveHint=true, so the write/overwrite nature is covered. The description earns credit for adding blast-radius context beyond that: only the identified answer changes while 'other answers and documents remain unchanged', and it explicitly disclaims touching account settings. Missing is whether the change is reversible (an undo_last sibling exists) or what permissions are needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The core action and its granularity are front-loaded, and the second sentence is a compact scope exclusion rather than 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?

An output schema exists, so return values need no explanation, and the destructive/scope profile is well covered between annotations and text. The remaining gap is the semantics of the instruction parameter and any reversibility note for a destructive edit — minors against an otherwise complete picture.

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%, so the description carries the burden. It clarifies that questionId selects one employer question and that the edit is scoped to a single answer, which adds meaning. It says nothing about applicationId's role or, more importantly, what 'instruction' contains — a directive to be interpreted versus replacement prose — which is the highest-risk ambiguity here.

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 — 'Revises one employer-question answer identified by questionId' — and pins the granularity to a single answer. It also carves out what it is NOT (account-level factual screening, work-authorization, compensation, availability settings), which separates it from the settings siblings (update_preferences, update_autopilot_settings). It stops short of naming the closest sibling (save_application_answers) for a bulk-save case.

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 second sentence gives an implicit when-not by excluding account fact settings, so an agent can rule out the wrong tool family. But there is no explicit guidance on when to pick this over save_application_answers (bulk) or edit_cover_letter/edit_resume, and no prerequisites or ordering constraints are 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?

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is covered. The description adds the prerequisite ('existing materials are required') and the scope-resolution fallback behavior, but never states whether the previous letter text is overwritten or recoverable — a relevant omission for a destructive edit. Useful additions, but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences with no filler; the core action is stated first and the scope-resolution rules follow in the order an agent would need them. Slightly dense, but nothing is wasted.

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 no explanation, and the description covers the main ambiguity (scope vs. no scope) plus the prerequisite. The gap is the unmentioned section/answer scope kinds, which could lead an agent to believe only two target types exist for this non-trivial oneOf parameter.

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 only 33%, so the description must compensate, and it partially does by explaining scope's role and the no-scope fallback. However it describes scope as covering only 'a paragraph or selected passage', omitting the 'section' and 'answer' variants the schema's oneOf defines, leaving the parameter semantics incomplete.

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 (revises) and resource (an existing application's cover letter) plus the mechanism (supplied instruction). The resource alone separates it from edit_resume and edit_answer among the siblings, so an agent can route 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?

Explains the key conditional: a scope targets a paragraph/passage, no scope means the passage is inferred from the instruction, and a whole-letter instruction rewrites everything. It also states the prerequisite (existing materials required). No explicit sibling alternatives or exclusions are named, so it falls 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=false and destructiveHint=true, and the description goes further by disclosing side effects and boundaries: formatting is preserved, the PDF is regenerated, the user's default uploaded resume is untouched, and an active default variant is refused. For a mutation tool this is unusually strong disclosure of what changes and what is protected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four compact sentences, front-loaded with the action and side effect before the scope and precondition details. The telegraphic register ('scope identifies a section block or selected passage') is efficient, though the clipped final sentence reads more like a note than a complete statement.

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 values need no explanation, and annotations cover the safety profile; the description adds preconditions, scope semantics, and side effects. Remaining gaps are peripheral: no mention of authorization requirements or reversibility (undo_last exists as a sibling), and the full set of scope kinds is left to the 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 description coverage is 0%, so the description must compensate, and it only partially does: it explains that scope selects a section block or passage and that omitting scope falls back to instruction-based targeting. It never mentions the paragraph or answer scope variants that the schema supports, and it says nothing about applicationId or what the instruction string may contain.

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 ('Revises one application's tailored resume') and constrains the scope to a single application, which separates it in practice from cover-letter or base-resume siblings. It stops short of explicitly naming the adjacent tools (edit_cover_letter, replace_application_document, format_resume), 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?

It gives real usage context: scope may target a block or passage, otherwise the target is derived from the instruction, and it states preconditions ('Existing materials are required') plus a refusal condition ('an active default variant is refused'). No alternative tool is named for the cases where this one does not apply, so it is context-rich but not a full when/when-not map.

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 readOnlyHint=false, so the destructive nature is covered. The description adds genuinely useful scope beyond that: it states that confirmed career facts and stated preferences are untouched, which bounds the blast radius of a delete. It stops short of saying whether the deletion is reversible, which would matter given the sibling undo_last.

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 zero filler. The destructive action is front-loaded and the scoping reassurance follows immediately.

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 no explanation, and annotations cover the safety profile. The description covers what is deleted and what survives, but omits reversibility and how to discover a hypothesisId — minor gaps for a single-parameter destructive tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single hypothesisId parameter, so the description carries the full burden. It only identifies the target entity ('the specified unconfirmed career hypothesis') and gives no format, source, or lookup guidance for obtaining a valid ID, leaving the parameter effectively undocumented.

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 — deletes a stored 'unconfirmed career hypothesis' — and the qualifier 'unconfirmed' implicitly separates it from confirm_hypothesis and remember_hypothesis. It is clear without opening the schema, though it never names a sibling tool explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the agent can infer this is for discarding a guess rather than a confirmed fact. There is no explicit when-to-use statement, no mention of confirm_hypothesis as the alternative action, and no note on whether undo_last can reverse 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?

Adds real value beyond the annotations: it discloses that no writing model or allowance is consumed (cost profile) and that 'the receipt includes undo' (reversibility), which materially softens the destructiveHint=true flag. It does not cover permission requirements or rate limits, so it stops short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences, front-loaded with the primary action, followed by targeting, cost, and receipt. Every sentence carries distinct information with no 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 a mutation tool with an output schema present, the description supplies the essentials: scope of change, targeting interaction, cost, and undo. An agent could invoke it correctly; only preconditions/permissions are left unaddressed.

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 75% (baseline 3), and the description goes further than the schema by defining the precedence logic the schema states only piecemeal: line identifies a passage, section identifies a heading, and selected text supplies the target when neither is given. This interaction rule is genuinely additive.

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 (changes) and resource (alignment, bold, italic, underline formatting of a tailored resume) and explicitly bounds the operation with 'without changing its words.' This cleanly separates it from content-editing siblings like edit_resume or generate_resume, so an agent can tell them apart 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?

Explains the targeting mechanism (line vs section vs selected text) but never states when to choose this tool over alternatives such as edit_resume, nor any preconditions. Usage is implied by context rather than asserted.

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 mark this as non-read-only, non-idempotent, non-destructive. The description adds the crucial behavioral fact those annotations do not convey: the mutation creates only a draft and nothing is transmitted. It remains silent on whether regenerating overwrites an existing draft and on any rate limits, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero filler, and the core action leads while the safety clarification follows immediately. Every clause 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 two-parameter tool this covers the action and the key safety caveat, but with no output schema the description never says what comes back or where the draft lives (returned inline, saved to materials, viewable elsewhere) or what the agent should do with it next. That retrieval gap is the missing piece.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented as UUIDs of type contact and job; the description only restates that the draft is scoped to a contact and a job. Baseline 3 is appropriate since the schema carries the semantic load.

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 ('Generates') and resource ('personalized outreach-email draft') and scopes it to the two required inputs (contact and job), so an agent knows exactly what it produces. It does not, however, distinguish itself from other generation siblings in the list such as generate_pack or generate_resume, leaving the boundary to be inferred.

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?

'No email is sent by this call' usefully implies this is the drafting step rather than the sending step, which nudges the agent toward it. But no alternatives are named (e.g. reply_to_recruiter for replying, generate_pack for full application packages) and no prerequisite conditions (does the contact need to exist?) are 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, which only flag destructiveHint=true and readOnlyHint=false. The description specifies exactly what destruction means ('Existing materials can be overwritten'), that generation is asynchronous, and that allowance is spent per request regardless of subset — details an agent cannot derive from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences, front-loaded with purpose before cost and async behavior. No filler; each sentence contributes a distinct fact (scope, subset handling, cost, side effects).

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 no explanation, and the annotations plus description cover the safety and behavioral profile. Cost, async settlement, overwrite risk, and subset defaults are all present — nothing needed 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 100% and the schema already documents both jobId and assets, including 'Omit for all three'. The description largely restates the assets semantics, adding only the allowance-per-subset angle. Baseline 3 is appropriate when the schema carries the parameter burden.

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 ('Queues') and enumerates exactly what a pack contains: resume, cover letter and employer-question answers for one saved role. This distinguishes it from single-asset siblings like generate_resume or generate_outreach implicitly, but never names them, so the differentiation is inferential rather than 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?

Conveys cost context ('one pack allowance regardless of subset') and the default (omission requests all three), which helps an agent decide whether to request the full pack. However, it never states when to choose this over generate_resume/generate_outreach or what preparation state the role must be in, leaving usage 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 readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the meaningful caveat that no application is submitted, but says nothing about whether generation is async, where the result is stored, or how it relates to get_generated_resumes.

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 short sentences with the core action front-loaded and the 'does not submit' caveat second. No wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description's claim to 'return its result' is unelaborated—an agent cannot tell whether it receives the resume directly, a task handle, or nothing. For a non-idempotent mutation with a downstream get_generated_resumes sibling, a bit more would help.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single applicationId parameter, so the baseline is 3. The phrase 'account-owned application' adds a mild provenance constraint beyond the schema but no format or syntax details.

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 (Generates) and resource (tailored resume) scoped to an account-owned application. It is distinguishable from edit_resume/format_resume by the word 'tailored,' though it never explicitly contrasts with those 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?

The sentence 'This does not submit an application' is a useful when-not boundary and guards against confusion with apply. However, it gives no positive guidance on when to prefer this over format_resume, edit_resume, or generate_pack, leaving sibling selection implicit.

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 cover the safety profile (readOnly, non-destructive). The description adds substantial behavioral context beyond them: links expire in about ten minutes, open without login, packPageUrl requires sign-in, null links mean missing/excluded documents, and no cover-letter DOCX exists.

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 content, then four tight sentences each carrying distinct operational facts. Slightly fragmented close ('There is no cover-letter DOCX') but no wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be spelled out, yet the description still covers the critical caveats an agent needs (link expiry, auth exception, null semantics). Complete for a read-only document-link tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the schema does not document applicationId. The description compensates partly by framing the tool as operating on 'one application', but it adds no format, source, or id-sourcing detail for the single 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?

Names a specific verb (Returns) and resource (version-specific resume PDF/DOCX, cover-letter PDF, combined-pack PDF download links for one application). An agent knows exactly what it gets back 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 never says when to use this tool versus alternatives such as get_application_materials, get_resume_download_link, or get_pack_status. It implies a per-application document fetch but provides no routing or 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, openWorldHint=false, and destructiveHint=false, so the safe-read profile is covered. The description still adds useful behavioral context: material scope is 'account-owned,' the returned payload carries a lock state and optimistic revision for submission, and pdfBase64 is explicitly null. It stops short of describing pagination or size limits, but the added detail is 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?

Three sentences, front-loaded with what is returned before the exclusion and the routing to the sibling. Dense but every sentence carries information (contents, revision/lock fields, PDF exclusion, alternative tool); 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 no prose explanation, yet the description still enumerates the salient payload fields and clarifies the PDF/return-link split. For a single-parameter read tool, 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 (applicationId) exists and its schema coverage is 100% with a UUID format and pattern, so the schema fully documents it. The description adds no syntax or format detail beyond the schema, making the baseline of 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Returns) and resource (an account-owned application's resume, cover-letter materials, and draft employer-question answers), enumerating the exact contents. It is clearly distinguishable from sibling tools like get_application_documents, which it explicitly names.

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-not guidance (rendered resume PDFs are not included; pdfBase64 is null) and routes the agent to the correct alternative, get_application_documents, for download links. The condition selecting each tool is unambiguous.

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 reinforces it with 'This read sends nothing.' It goes further than the annotations by disclosing return-shape details and the meaningful semantic that a null answerShape means the user must act in the web app.

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 front-loaded sentences with no filler: what it returns, what the missing items contain, and the null-answerShape rule. The middle sentence is a dense enumeration but every item carries meaning, and the read-only caveat is kept to four 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?

With an output schema present the description need not explain return values, yet it still surfaces the one semantic an agent cannot get from schema structure alone (null answerShape = user action required in web app). Zero parameters and full annotation coverage leave nothing else materially 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 and the baseline of 4 applies. The field-level terms it does mention (question, answerShape, choices, webUrl) describe the payload rather than 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 names a specific verb and resource ('Returns readiness for one-off submission and Autopilot, plan entitlement and missing onboarding answers'), which is far more concrete than the vague sibling get_application_status or the action-oriented prepare_applications. It does not, however, explicitly state how it differs from those adjacent tools, so an agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance and no named alternatives, despite several plausible siblings (get_application_status, prepare_applications, strengthen_application). The reader can infer this is a pre-submission checklist, but nothing routes the agent between it and the alternatives.

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 mark this readOnly/no-destructive, so the safety profile is covered; the description adds real behavioral context beyond that: what Coverage means, that personalInboxConnected=false is normal rather than a setup step, that the board column is not submission evidence, and that submittedAnswers is null when the attempt or capture is unproven. It stops short of return-shape or ordering details, but the semantic caveats are 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?

Purpose is front-loaded in the first sentence and every following sentence carries a distinct constraint (coverage, inbox flag, board-column caveat, submittedAnswers nullability), so there is little dead weight. Density and unexplained domain jargon ('Dreamwork application address', 'proven submitted attempt') make it harder to parse than it needs to 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?

An output schema exists, so return structure need not be re-explained, and the description focuses on the interpretive semantics an agent needs (coverage scope, null semantics, what does not count as evidence). For a single-parameter read tool this is close to complete; only explicit sibling routing is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With one parameter and 100% schema description coverage, the schema already documents applicationId and even the matchId resolution rule. The description only restates 'An application id or pipeline matchId resolves the application', adding no format or edge-case detail beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb (Returns) and resource (an application's event timeline plus submitted/employerConfirmed/replied facts), which an agent can act on immediately. It does not, however, name or contrast with the nearest siblings (get_application_readiness, get_application_documents, get_pipeline), so differentiation is left to inference.

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 says the tool resolves via an application id or a pipeline matchId, which implies when it applies, and it warns that employer mail sent elsewhere 'is not visible here and stays unknown'. But there is no explicit when-to-use vs. sibling guidance (e.g. versus get_application_readiness or list_matches), so usage is implied rather than 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds meaningful behavioral context beyond that by stating that reading settings starts no applications, which is a domain-specific side-effect reassurance.

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 front-loaded sentence that immediately states what is returned. It is appropriately sized for a zero-argument read tool, though the trailing phrase "with that minimum" is slightly dense and could be clearer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Contextual completeness is high: there are no parameters to explain, annotations carry the safety profile, and an output schema exists for return details. The description still usefully names the settings returned and confirms that reading does not start applications.

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 are no parameter semantics for the description to compensate for. The baseline for a zero-parameter tool is 4, and nothing in the description makes the absence of parameters ambiguous.

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 ("Returns") and names the exact saved Autopilot settings exposed by the tool: minimum Matches score, resume choice, and salary-skip behavior. It is clear what the tool does, though it does not explicitly distinguish itself from siblings such as get_autopilot_status or update_autopilot_settings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this is the read-side settings tool because it returns saved settings. The sentence "Reading settings starts no applications" clarifies side effects but does not say when to use this over get_autopilot_status or before update_autopilot_settings, 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 declare the read-only safety profile, but the description adds real behavioral context: the on/off/unavailable state semantics, the null condition on nextRunAt, plan-restriction explanation via unavailableReason, and an explicit negative disclosure ('No last-run timestamp is provided'). This is well beyond what annotations convey, though it stays focused on output semantics rather than access constraints.

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?

It is front-loaded with the state values, but the middle is a long digression on dailyLimit vs usualDailyLimit first-day allowance logic that repeats itself and is partly redundant with the output schema. Some sentences earn their place, but the definition is longer than a zero-parameter status tool needs.

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 no-arg, read-only status tool with an output schema present, the description is essentially complete on the data model, including edge cases like the first-send-day allowance and unavailable plans. The one missing piece is any guidance on when to prefer this over sibling status/settings tools.

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 baseline is 4. The description correctly adds nothing parameter-related and instead spends its budget on output semantics, which is appropriate for a no-arg status read.

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 ('Returns Autopilot state') and enumerates the returned fields, so an agent knows exactly what it reads. However, it never distinguishes itself from the closely-named siblings get_autopilot_settings or set_autopilot, leaving the agent to infer that this reads runtime status rather than configuration.

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 contains no when-to-use, when-not-to-use, or alternative-tool guidance. With siblings like get_autopilot_settings, set_autopilot, and get_usage available, an agent gets no routing help about which to call to answer an Autopilot question.

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 genuine content-boundary information beyond that: it names the excluded material (resume text and document bodies), which tells the caller what they will not receive and therefore when another tool is needed.

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, front-loaded with the verb and the returned categories, with the exclusion caveat following. No filler, no repetition of the title or annotations.

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 explanation is unnecessary, and annotations cover the read-only safety profile; the description completes the picture with inclusion and exclusion scope. The remaining gap is routing guidance relative to the overlapping sibling reads, which is the one thing an agent could still get wrong.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the 'include' parameter already carries a detailed, well-explained description (omit for all four; omitted sections return empty rather than absent). The description adds no syntactic or semantic detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (returns) and resource (career record) and enumerates the five content categories returned as separate fields, which is well beyond a tautology of the name/title. However, it does not distinguish this consolidated read from overlapping siblings such as get_resume_work_history, get_preferences, or get_application_documents, so an agent can't tell from the text alone why it should pick this tool over those.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus the many sibling reads that surface the same subject matter (get_resume_work_history, get_preferences, get_profile, get_application_documents). The only guidance present is parameter-level (how to use 'include'), which belongs to the schema rather than tool 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: the inclusion of the 'all-optional-emails-off state' and the separate jobAlertEligibility channel for bounce/unsubscribe restrictions, plus explicit out-of-scope boundaries. It does not address auth, rate limits, or freshness, so it earns moderate credit rather than high.

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: what is returned first, then the jobAlertEligibility nuance, then the exclusion boundary. Nothing is padded, and the most important content is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return shapes need not be described, and the description correctly focuses on scope: what categories are included and which mail types are excluded. For a zero-parameter read tool this is nearly complete; only the routing relationship to sibling preference tools 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 schema or description to disambiguate; baseline is 4 for an argument-free tool.

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 ('Returns') and enumerates the exact preference categories covered: job-alert settings and cadence, Autopilot result-email mode, product-update consent, and the all-optional-emails-off state. This makes the tool's scope legible against sibling preference readers, though it does not explicitly name the alternative tools (e.g. get_preferences or update_communication_preferences) to sharpen 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 by the scoping sentence: 'Account, security, billing and essential employer mail are outside these settings' tells the agent what this tool does not cover, which is genuinely useful routing information. However, there is no explicit when-to-use versus alternatives guidance, and the read/write split with update_communication_preferences is left to inference from the tool name.

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. The description adds genuinely useful behavioral context beyond them by disclosing that rendered PDFs are excluded and pdfBase64 will be null, which prevents a wasted expectation about binary content.

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 zero waste. The core behavior and the notable PDF exclusion are both front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only lookup with full annotation coverage, the description is nearly complete and even flags the null PDF field. Without an output schema it could say more about the returned resume fields, but nothing essential for calling 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 100% for the single applicationId parameter, so the schema already documents it. The description reinforces that the ID must be account-owned but adds no format or syntax detail beyond the schema, matching 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 (Returns) and resource (tailored resumes) scoped to an account-owned application. It implicitly distinguishes itself from generate_resume by being the retrieval side, but it does not name any sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: call it to read resumes already generated for an application. There is no explicit when-to-use vs alternatives (e.g., get_application_materials, get_resume_download_link, generate_resume), so the agent must infer the correct tool.

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

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

Annotations already declare readOnlyHint/destructiveHint, but the description adds genuinely useful behavior: reading does NOT mark mail read, threads are ordered by newest activity, and mail bodies are third-party content. It stops short of naming mark_messages_read or noting auth/rate-limit constraints, so it is strong but not exhaustive.

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 purpose and scope, then filters, then pagination, then the side-effect caveat. Sentences are dense and each carries information, though the middle clauses about unanswered/needsReply are somewhat compressed.

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 needn't explain return values and instead covers everything else an agent needs: mode selection, filter semantics, pagination flow, and the non-marking read behavior. Nothing required 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?

With schema coverage at 80%, the schema already documents offset and the filter flags, so the baseline is 3. The description goes further by tying pagination together: 20-thread default page, limit up to 50, send previous nextOffset as offset, and null signals the end.

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 opens with a specific verb and resource ("Returns recruiter conversations ordered by newest activity") and enumerates the fields returned, so the agent knows exactly what it gets. It does not name any sibling tool, so differentiation from tools like get_unread_reminders or mark_messages_read is only implied.

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 distinguishes the two modes (listing vs. a single threadId) and explains the two filter flags (unreadOnly, unansweredOnly) with precise definitions. It also signals the safe-read behavior, but never explicitly names an alternative tool or an exclusion condition for 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 (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description goes well beyond them by defining the eligible tri-state and its concrete effect ('Only false blocks applying or Autopilot'), plus the url vs sourceUrl distinction and the possibility of an empty whyItMatches. That is genuinely useful behavioral context the agent cannot get from the annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The lead sentence is front-loaded and field-dense, and the eligibility paragraph earns its length because it changes agent behavior. The url/sourceUrl sentence is a slight digression given an output schema exists, keeping it just short of a 5.

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 explanation is technically redundant, and the description nonetheless supplies the interpretation the schema cannot (what null vs false eligibility means for applying). Nothing needed to invoke it correctly is missing; only sibling disambiguation 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?

There is a single parameter with 100% schema description coverage, so the schema already carries the semantics; per the baseline this is a 3. The description adds no syntax, format, or sourcing detail about jobId beyond what the schema states.

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 ('Returns one saved or corpus role by id') and enumerates the payload fields, so the agent knows exactly what it gets back. It does not, however, distinguish itself from siblings like get_listing or browse_listings, leaving the agent to infer the boundary between the corpus/private-job lookup and listing browsing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to call this versus get_listing, browse_listings, or list_matches, which is the primary selection problem for a single-role fetch. The eligibility paragraph guides downstream behavior (apply or not) rather than tool choice, so no real selection guidance is provided.

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 bar is lower. The description adds real value by clarifying the two URL fields (url = Dreamwork page, sourceUrl = employer posting) and stating 'No login is required' — auth context beyond annotations. Still no pagination/return-shape notes, so it stays at 3.

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 front-loaded sentences, each carrying distinct payload (what it returns, no login needed, meaning of the two URL fields). Zero waste and no 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?

For a single-param read tool with annotations covering safety and no output schema, the description is largely sufficient. It could go further by explaining the distinction from get_job, but nothing needed 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 100% and the single id parameter is fully described in the schema, so the baseline is 3. The description doesn't add id format or semantics beyond what the schema enforces.

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 ('Returns full details of a platform job listing') scoped by the identifying id, and distinguishes 'platform job listing' from adjacent tools like get_job and browse_listings. An agent knows exactly what this retrieves.

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?

Implied usage (fetch details for a known listing id), but there is no explicit when-to-use vs get_job/browse_listings, and no stated condition for picking this over a sibling. Adequate but with a clear gap given the crowded sibling 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 cover safety (readOnly, idempotent, non-destructive), and the description adds operational context the annotations cannot: the corpus is refreshed twice daily, all figures are worldwide with no filtering, and no login is required. The freshness cadence and the global-scope constraint are exactly the traits an agent needs to reason about data staleness and applicability.

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, no filler, and the most load-bearing facts come first: what is returned and the refresh cadence. The sibling routing clause and the advisory-use clause each carry distinct information rather than restating the opening 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?

An output schema exists, so return structure need not be spelled out, yet the description still summarizes the metric families an agent will see. Combined with zero parameters and full annotation coverage, 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description does add that scope is fixed to worldwide, which usefully tells the agent there is no filtering knob to look for.

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 ('Returns CURRENT worldwide hiring-market context from Dreamwork's live job corpus') and then enumerates the exact dimensions returned: companies tracked, open roles, 7-day additions, growing vs contracting, WoW movement, layoff pressure. It also distinguishes itself from the sibling that sounds most similar, get_top_hiring_companies, so an agent can route without opening either 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 names the alternative and the condition that selects it: 'for country- or function-scoped company lists use get_top_hiring_companies'. It also states the use case for this tool ('fresh evidence that postdates your training data when advising on job-search strategy, industry outlook, or where opportunity is moving'), giving both when-to-use and when-to-defer.

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 the useful nuance that a read will not kick off generation, plus the shape of returned fields (assets, edit/lock state, revision, review URL). It adds modest value on top of the annotations, hence a 3.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the enumerated states and followed by scope/behavior. Efficient, though the status enumeration is somewhat long.

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 spelled out, and annotations carry the safety profile. The description supplies the state vocabulary and the no-generation caveat, leaving only the relative positioning against sibling status tools 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?

Schema coverage is 100% and the schema itself explains that a card or listing id also resolves, which the description largely restates. With only one well-documented parameter, the baseline 3 is appropriate and the description adds little 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 (Returns) and resource (material preparation state) and enumerates the concrete status values (queued, generating, ready, partial, failed, stale, not_started, not_found). This is well beyond a tautology, but it does not explicitly distinguish itself from look-alike siblings like get_application_materials or get_application_readiness.

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 closing clause 'Reading starts no generation and changes no materials' gives clear when-to-use context, implicitly steering the agent here when it wants status without triggering work (as opposed to generate_pack). It stops short of naming any alternative explicitly, so it is clear context without 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 (readOnly, non-destructive, closed-world), so the description earns credit for adding real behavior: no next page, limit bounds, truncation signaled by 'complete', and the caveat that column values reflect board state rather than employer receipt. These are details an agent cannot infer from 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 what is returned, then pagination mechanics, then a semantic caveat. Every sentence carries distinct information; nothing is redundant with the schema or annotations.

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 handling return structure and annotations handling safety, the description fills the remaining gaps: pagination limits, truncation semantics, and how to narrow results. An agent has everything needed to call it 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 coverage is 0%, so the description must carry the burden. It documents 'limit' fully (default 50, max 100) and explains the purpose of 'status' (narrowing a truncated read), which meaningfully compensates for the missing schema descriptions, though it does not interpret the individual enum values.

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 ('Returns saved and applied roles as board cards') plus the payload shape (column, application id, last-updated time), so an agent can tell it apart from get_application_status or list_matches. It does not explicitly name a sibling, but the resource scope is distinctive enough.

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?

Provides operational guidance ('when complete is false narrow the read with status'), which is invocation-level rather than tool-selection guidance. It never says when to choose this over sibling read tools like get_application_status or list_matches, leaving selection 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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without description help. The description's added value is limited to naming the content categories returned; it does not disclose size, structure, or freshness of that context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; the capability list is long but informative rather than redundant. Nothing is wasted, though the enumeration could have been trimmed in favor of the more useful 'when to use' 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?

An output schema exists, so the description need not describe return values, and as a zero-parameter read-only tool the contract is simple. The description adequately frames what the tool is, with the only real gap being the absence of usage positioning relative to siblings.

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-vs-description burden is nil and the baseline is 4. Nothing in the description contradicts or misrepresents the empty input contract.

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 ('Returns Dreamwork's ... capabilities, plus its product context') and enumerates the capability areas covered (job-search, pipeline, resume-tailoring, application, outreach, interview). It is clearly distinguishable from any sibling, none of which is an overview/context tool, though it does not explicitly say so.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to call this versus the ~50 sibling tools. For an orientation/context tool the natural guidance would be 'call this first to discover platform capabilities before invoking domain tools', but nothing like that is stated or 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 and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the meaning of the 'unanswered' field and an explicit statement of what the call will not return.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler, and the capability statement is front-loaded. The opening sentence is a long comma-separated inventory, which is dense but each item is a real field, so nothing is wasted.

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 return shape need not be spelled out, yet the description still names the covered fields and the special 'unanswered' key, which is more than required. It is complete for a zero-parameter read 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 baseline of 4 applies; the description does not need to explain any input semantics, and the schema is 100% documented.

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 (returns job preferences) and enumerates the exact fields covered, which lets an agent distinguish it from siblings like get_resume_work_history and get_profile 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 the field inventory rather than stated; the negative clause ('does not return resume content or work history') helps route away from resume tools, but no alternative (e.g. update_preferences for writes, get_communication_preferences for messaging settings) is named as the when-to-use choice.

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 goes beyond that by disclosing a subtle data condition: resumeUrl is null when the resume is inline and resumeText carries its contents instead, plus that profileIdentityVersion is a snapshot. That is genuine behavioral context an agent could not derive from the name or 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?

Two sentences, no filler. The primary return payload is front-loaded and the resumeUrl/resumeText caveat follows as the one non-obvious detail.

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 no parameters, the description need not explain return structure, and it correctly restricts itself to the one nuance the schema may not convey (null resumeUrl). The only shortfall is the absent routing guidance versus sibling read tools.

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 schema coverage is 100%, so the baseline of 4 applies. There is no parameter detail the description could usefully 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?

The description gives a specific verb (returns) plus the exact resource bundle: profile, resume text, preferences, and the profileIdentityVersion snapshot. An agent can distinguish it from mutation siblings like update_profile, though it never contrasts itself with the other read siblings (get_preferences, get_career_record).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no stated when-to-use, no prerequisites, and no mention of alternatives despite a crowded field of get_* siblings that overlap on preferences and career data. The agent must infer that this is the canonical profile read from the name alone.

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 rich context beyond annotations: link expiry (ten minutes), no-login access, immutability ('only for the file that existed when it was made'), no file content, and detailed status values with non-error explanations. Annotations flag read-only/non-destructive, but the description covers operational behavior fully.

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 the core purpose and key constraints. Every sentence adds essential information without 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?

Complete for a zero-param, read-only tool with an output schema. The description covers link expiry, access constraints, immutability, content absence, and status values, leaving no ambiguity for correct invocation or interpretation.

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 baseline is 4 per guidelines. The description appropriately focuses on output semantics and doesn't need to discuss params.

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 (returns) and resource (download link for profile resume as PDF), and clarifies scope: 'main profile resume.' Distinguishes from siblings like get_profile, upload_resume, and edit_resume by narrowly defining it as link generation, not fetching content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies when to use by distinguishing it from content retrieval ('It returns no file content'), which is useful against siblings like get_profile that might return resume data. However, it doesn't explicitly name alternative tools or when-not scenarios beyond that.

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, so the burden is lighter, and the description layers on real value: the three status states with their meanings, the fact that data is parsed from page layout, and that a count is returned for bullets whose extracted position disagrees with the layout. It does not cover auth or rate limits, but the domain-specific caveats are unusually informative.

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?

Effectively two sentences, front-loaded with the return shape and then the status semantics. Dense but every clause carries meaning; slightly heavy for a single paragraph, though 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?

The tool is parameterless and read-only, with an output schema present, so the description need not restate return values. It still proactively explains the grouping model, residual anomalies, and the polling implication of 'pending', leaving no gap an agent must guess at before calling.

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 baseline of 4 applies. There is nothing for the description to disambiguate, and it does not invent or confuse any input contract.

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 (returns the account's main resume) and adds precise scope: 'grouped by role' with employer, title, location, dates, bullets, plus orphaned achievements and an anomaly count. This is clearly distinguishable from siblings like edit_resume, upload_resume, or get_resume_download_link.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit routing against alternatives (e.g., versus get_generated_resumes or edit_resume), but the description does give operational guidance for the pending state ('still being read; call again shortly') and defines when 'unavailable' applies. Usage is implied rather than 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds the meaningful scope qualifier 'account-owned' and enumerates the statistical domains, but says nothing about freshness, caching or aggregation window, which would be valuable for a stats tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no redundant or filler content. It is exactly the right size for a zero-parameter read tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained, and the zero-parameter schema plus read-only annotations cover structure. The scope is stated, so the definition is largely complete, though a hint about when to prefer this over similar siblings 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 document beyond what the empty schema shows. Baseline 4 applies; no parameter meaning is 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?

The description gives a specific verb ('Returns') and enumerates the exact resources covered: job, application, escalation and outreach statistics, scoped to account-owned data. This is clear, but it does not distinguish this tool from adjacent siblings like get_usage, get_pipeline or get_application_status, which also surface account-level data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to call this versus the many other get_* siblings, nor any stated prerequisites or context. The agent must infer usage entirely from the purpose statement.

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 that the entry includes action, status, receipt, error code, and timestamps, which is useful but largely restates what the existing output schema already carries.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core verb+resource and scoped by taskId, then a follow-on usage note. Efficient, though the field enumeration is somewhat redundant against 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?

For a single-parameter read tool with an output schema and full annotation coverage, the description supplies enough to invoke it correctly. The only gap is not naming list_tasks as the alternative when the agent wants more than one entry.

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 names taskId as the lookup key, but with 0% schema description coverage it adds no format, origin, or source detail (e.g. where a taskId comes from). It marginally exceeds the bare schema without compensating for the coverage 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?

States a specific verb (Returns) and resource (one account-owned assistant ledger entry) keyed by taskId, which is clear. It implies but never names list_tasks, so sibling differentiation relies on the reader inferring 'one entry' vs a list.

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 sentence 'Queued work can be followed through its recorded status' gives a usage context for following in-flight work. However, it never explicitly says when to use this over list_tasks or get_pack_status/get_autopilot_status, leaving the choice implied rather than 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?

Beyond the readOnly/idempotent/non-destructive annotations, it discloses the ranking methodology, an implicit eligibility filter (companies active in the last 7 days), the freshness guarantee, the meaning of the returned url field, and that no login is required. These are exactly the operational facts 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 core behavior and ranking logic are front-loaded in the first clause, followed by filters, use case, and auth note in a compact package. Some density ('with hiring trend, week-over-week velocity and median pay') lists return fields the output schema already defines, which is slight redundancy.

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 explain return values, and it covers ranking basis, freshness, filter set, URL meaning, and auth. Nothing an agent needs to invoke this zero-required-parameter tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the enums are already documented, so the schema carries the parameter burden. The description only restates three of the four filters (function, country, trend) and omits limit entirely, adding no syntax or semantics 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 ('Returns the companies hiring the most right now') plus the exact ranking rule ('ranked by open roles among companies active in the last 7 days'). An agent can distinguish this from browse_listings or get_market_pulse because the output is companies, not jobs or aggregate market stats.

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 an explicit use case: 'ground company recommendations in fresh data that postdates your training data.' That is a clear trigger condition, but no when-not guidance or named alternative sibling is offered.

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 the safety profile is covered. The description nonetheless earns credit for adding two things annotations cannot: that reading has no side effect on read state (idempotent polling), and that previews contain third-party email content.

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 return payload, then the side-effect guarantee, then the privacy caveat. No filler and nothing restated from the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present the description need not detail the return shape, yet it still summarizes it usefully for selection. Annotations cover safety and a zero-param schema needs no explanation, so nothing an agent needs to invoke 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; schema coverage is 100% with an empty object. Baseline of 4 for a parameterless tool applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource and enumerates exactly what is returned (unread counts, oldest unread time, previews with thread/company/role/kind). It distinguishes itself from a general inbox tool by the 'unread' scope. It never names the closest siblings (get_inbox, mark_messages_read) explicitly, so a small differentiation gap remains.

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 name and the 'unread' scoping rather than stated: an agent can infer 'use this to check whether anything needs attention.' The line 'Reading does not mark messages read' hints that mark_messages_read is a separate action, but neither the when-to-use condition nor the alternative is 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?

Goes well beyond the readOnly/openWorld annotations by disclosing that reading marks no mail read and creates no schedule, that repeated ids can appear (dedup is not guaranteed), and that truncation counts indicate older changes excluded by caps. These are exactly the behavioral traits an agent cannot infer from structured fields.

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 resource and change types, then the pagination contract, then side-effect guarantees. Dense but every sentence contributes; the overlapHours rationale is slightly interpolated mid-sentence, which mildly hurts 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 described, and the description still covers the chaining watermark, overlap semantics, duplicate ids, truncation signaling, and absence of side effects. Nothing needed to call or continue-iterate this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the schema already documents both parameters, but the description adds meaning beyond it: asOf is framed as the next watermark and overlapHours is justified by late-servable listings rather than merely restating its default.

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 ('Returns new matches, board-status changes, employer-mail threads and Autopilot state since the supplied timestamp'), enumerating the exact change types covered. This makes it clearly distinguishable from point-in-time siblings like list_matches, get_inbox, or get_autopilot_status.

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 invocation pattern precisely: pass the previous result's asOf as the next since, and the overlapHours default exists because listings may become servable after first discovery. It does not explicitly name alternatives or say when a full re-list (e.g. list_matches) is preferable, so it falls 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 establish readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context beyond them: the sign-in requirement that can precede checkout and the fact that no charge occurs until payment is confirmed on the checkout page.

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 with the core action front-loaded, then the sign-in caveat, then the no-charge reassurance. No filler and no 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?

With no output schema, the description correctly states what is returned (a browser link to checkout). Combined with the full schema coverage and annotations, an agent has what it needs to call it, though the absence of any sibling differentiation against 'start_checkout' leaves one open question.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema itself already documents the promo/billing incompatibility and quarterly discount. The description only echoes the parameter surface ('optional billing interval or promo code') without adding syntax, defaults, or conflict rules beyond what the schema provides. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: returns a browser checkout link for the Pro or Dreamer plan, with optional billing interval or promo code. The purpose is immediately legible, but it does not distinguish itself from the sibling 'start_checkout', which an agent could plausibly confuse it with.

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 plan/promo/interval framing, and it usefully notes that sign-in precedes checkout and no charge occurs until payment is confirmed. However, it never says when to prefer this over 'start_checkout' or other checkout-adjacent siblings, so the routing guidance is incomplete.

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 the safety profile is covered. The description adds genuinely non-obvious semantics — that the window is 'today' only, and that a null limit means unlimited rather than zero or missing — which is the kind of detail an agent would otherwise misread.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with what is returned, with the edge-case rule second. No filler, no restatement of the title or annotations.

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 and full annotations already present, the description does not need to enumerate return fields, and it sensibly focuses on the one interpretation trap (null = unlimited). The only gap is the absence of any usage trigger guidance, which is outside the structural data's reach.

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 no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The null-limit note is output semantics rather than parameter guidance, but it is still useful framing.

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 opens with a concrete verb and resource: it returns today's pack and application usage, per-item limits, and the next reset time. That is specific enough to distinguish it from every sibling (none of which report quota/limit data), though the phrasing is in domain jargon rather than plainly saying 'quota/usage check'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The mention of 'the account's limit' and 'next reset time' implies the use case (checking remaining allowance before generating), but the description never states when to call it versus alternatives or any preconditions. Usage is inferred rather than directed.

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 (readOnlyHint=false, openWorldHint=true, destructiveHint=true), and the description adds real context beyond them: extraction is asynchronous, the card appears only on completion, and an already-held posting returns completed without a re-fetch (idempotency). It does not clarify why destructiveHint is set, given the import reads as additive.

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, purpose front-loaded, then behavior, then the idempotency edge case. Every sentence 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?

An output schema exists, so return values need no explanation, and the description covers scope, async timing, and the duplicate-posting case. It leaves the destructiveHint annotation unexplained, which is the one gap an agent might care about before calling it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter, so the baseline is 3. The description adds a small but meaningful constraint ('public' URL), yet no format or validation detail beyond what the schema already declares.

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 (fetches/imports) and resource (a public job-posting URL into a private role in the pipeline), so an agent knows exactly what happens. It stops short of distinguishing itself from close siblings like add_jobs or save_job, leaving the agent to infer which one applies.

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 tool is for turning a URL into a pipeline role, but there is no explicit when-to-use, when-not, or named alternative. The note about postings already held by Dreamwork returning 'completed' is a behavioral fact, not routing 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 the safety profile is covered. The description adds that results are limited to the account's saved recruiter/referrer contacts and that filtering is optional, but says nothing about ordering, pagination, or result size, which matter for a list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that states the resource, its scope, and the optional filter, with no filler. Appropriately sized for a one-parameter read tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but for a simple filtered-list read tool whose safety semantics are already in annotations, the description covers what the agent needs before calling. It would be slightly stronger with a note on result ordering or volume, which is the only real gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and there is only one optional parameter, so the schema fully documents 'company'. The description's 'optionally filtered by company' merely restates that; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (returns/lists) and resource (the account's saved recruiter and referrer contacts), and the 'recruiter and referrer' qualifier narrows scope beyond a generic contacts list. It does not explicitly name the sibling add_contact, but the read/write distinction is obvious from the names, so clarity is high.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied — the description tells you the tool lists saved contacts with an optional company filter, but gives no when-to-use guidance, no prerequisites, and no explicit pointer to the complement (e.g. add_contact for creating contacts). Minimum viable.

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). The description adds useful behavioral details beyond that: results are newest first, total counts all dismissals, limit caps at 50, and pagination ends when nextOffset is null. It does not discuss auth or rate limits, but those are less critical for a read-only list.

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 purpose in the first sentence, then compactly covers total count, page size limits, and pagination continuation. Every sentence earns its place with no redundant 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?

The tool is a read-only list with an output schema and fully described parameters. The description supplies the ordering, total-count semantics, and pagination behavior, which is sufficient for an agent to call it 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 100%, so the baseline is 3. The description still adds meaning by clarifying that 'nextOffset continues the list and null ends it,' which helps an agent understand pagination termination beyond the schema's offset 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?

The description names the specific verb (Returns) and resource (account's dismissed listings), and the word 'dismissed' distinguishes it from the sibling list_matches. It also immediately states the ordering and returned fields, so an agent can tell what the tool 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.