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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=false, so the description should add the context those hints cannot convey. Instead it says nothing about whether adding a duplicate is destructive, whether the record is removable, or which fields are mutable later — it merely restates the mutation the annotations already flag.

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. It is efficient, though its brevity is closer to under-specification than true economy.

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 full schema coverage and no output schema, the description only needs to cover behavior and routing, and it covers neither fully. For a destructive write tool it omits reversibility, duplicate handling and post-add state, leaving an agent with a workable but incomplete 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 100%, so all five parameters are already documented in the schema. The description adds only the framing that the contact is a recruiter or referrer, which marginally hints at how fields like company/title are used, but supplies no syntax or format detail 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 (adds) and resource (contact) plus the subtypes it covers (recruiter or referrer) tied to the account. It is clear in isolation, but it never distinguishes itself from the sibling list_contacts or explains how a contact relates to the surrounding account/application flow.

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 guidance on when to add a contact versus using list_contacts or other contact-related siblings, and no prerequisites or dedup conditions. Usage is only implied by 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=false, destructiveHint=true and openWorldHint=false, so safety is partly covered. The description adds real value beyond them: it discloses the pack-allowance quota consumption and the crucial boundary that no application is submitted, which prevents an agent from assuming a full apply flow.

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 compact sentences, front-loaded with the action and its target, then the conditional side effect, then the negative scope constraint. No filler, and each sentence contributes distinct information.

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

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

For a 6-param mutation tool with no output schema, the description covers the action, the accepted inputs, the conditional pack-allowance side effect, and the explicit non-effect (no submission) that an agent most needs to reason about. What remains (response shape, duplicate handling) is minor.

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% (just title and company), so the description has to carry the load. It names all six fields and explicitly separates required (title, company) from optional (description, URL, contact email, application method), compensating for the schema gap even though it adds no format detail.

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

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

The description gives a specific verb and resource ("Adds a job to the account's private pipeline") and enumerates the fields it accepts, so the agent knows exactly what the tool does. It does not, however, distinguish itself from the similar siblings save_job and import_job, which is the main missing piece.

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 conditions a behavior ("For eligible accounts, a new job can also create and queue its application materials, using pack allowance") and bounds the action ("No application is submitted"), which implies when it applies. But it never states when to pick this over save_job or import_job, or what makes an account "eligible".

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 readOnlyHint and destructiveHint=false, yet the description adds substantial behavioral context: anonymous browsing support, plan-dependent page-size clamping (100 → 25), the 1,000-result cap on sorted walks versus the uncapped stable unsorted walk, cursor/filter consistency requirements, overlapping discovery windows via addedAfter, and the semantic gap between url and sourceUrl.

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 paragraph is dense but front-loaded with purpose and filter scope before the pagination and pay caveats. For a 20-parameter tool the length is defensible, though the run-on enumeration of filters and mechanics could be broken up for easier scanning.

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

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

An output schema exists, so return-shape explanation is optional, yet the description still clarifies url versus sourceUrl. Combined with the pagination limits, cursor rules, and pay-filter behavior, an agent has everything needed to call this 20-parameter tool 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 carries parameter meanings and a baseline of 3 applies. The description still adds value beyond it, notably the pay-filter semantics (whole annual US dollars matching posted bands that reach the bound), the url/sourceUrl return distinction, and the rationale for addedAfter overlapping windows.

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 indexed listings') and enumerates the filterable dimensions, which clearly separates it from single-listing tools like get_listing or AI-curated tools like list_matches. It does not explicitly name a sibling as the alternative, so it stops short of full differentiation.

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

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

Usage is implied by the described filters and pagination mechanics rather than stated ('use this to browse; use X to...'). The cursor-continuation rule ('nextCursor requires identical filters and sort') is genuinely useful operating guidance, but there is no explicit when-to-use versus alternatives language.

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 only declare destructiveHint=true, readOnlyHint=false, openWorldHint=false; the description goes well beyond by disclosing persistence scope (feed, alerts, Autopilot), the one-minute undo window, permanent reversibility via restore_match, that the reason is discarded, and two negative side-effect exclusions. That is the kind of context annotations cannot carry.

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

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

Front-loaded with the core effect, then alternatives, then caveats, and nearly every sentence carries distinct information. The 'reason is not stored' sentence largely duplicates the schema description, which is the only real 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?

An output schema exists so return values need no explanation, and the description still supplies the return-relevant detail (an undo receipt). With only two params and full schema coverage, nothing an agent needs to call and reason about 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 description coverage is 100%, so jobId sourcing and the reason field are already documented in the schema ('Accepted but not stored'). The description restates the reason-not-stored behavior rather than adding new semantics, so the baseline 3 applies.

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

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

States a specific verb (hides/dismisses) and resource (one listing), plus the exact surfaces affected: match feed, job alerts, Autopilot. It clearly distinguishes itself from the siblings restore_match and list_dismissed_matches by naming them and describing the inverse operation.

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 alternatives with conditions: restore_match reverses it at any time, list_dismissed_matches enumerates dismissed listings, and the receipt's undo window is time-boxed to one minute. It also states two explicit non-uses: it does not hide other listings from the same company and does not move or remove an existing pipeline card.

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 already declare destructiveHint=true, readOnlyHint=false, and non-idempotent, and the description usefully clarifies that no email is sent. However, it does not explain what the destructive aspect actually is (e.g., overwriting an existing draft) or whether it requires the profile/resume to be populated.

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

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

Two tight sentences with the core action front-loaded and the safety clarification immediately following. 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?

Covers both required parameters and the key side-effect question (nothing is sent), and annotations carry the safety profile. The only minor gap is not stating whether the generated draft is returned in the response, which matters given there is no output schema.

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

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

Schema description coverage is 100%, so both UUID parameters are already documented by the schema. The description only restates that a contact and job are required, adding no format or validation detail 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 (generates) and resource (personalized outreach-email draft) and scopes it to a contact and job. It's clearly distinguishable from siblings like generate_pack or reply_to_recruiter, though it doesn't explicitly name a sibling it is not.

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 routing to alternatives such as reply_to_recruiter or generate_pack. The agent must infer when an outreach draft is appropriate versus a different generation 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?

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 destructiveHint=true, idempotentHint=false, readOnlyHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact (no application is submitted) but says nothing about whether existing resumes are overwritten, whether it consumes credits/quota, or what 'its result' contains.

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, front-loaded with the action, with no filler. The trailing 'and returns its result' is slightly redundant and vague but does not bloat the definition.

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 generation tool with rich annotations and no output schema, the definition covers the essentials. It still leaves the return payload unexplained despite promising 'its result', and gives no hint about the destructive/non-idempotent consequences an agent should expect.

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

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

Only one parameter and schema coverage is 100%, so the schema already documents applicationId fully. The description adds the ownership constraint ('account-owned'), which is minor added meaning, matching the baseline 3 for schema-covered 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?

Specific verb (generates) plus resource (a tailored resume) scoped to the account-owned application, which separates it from upload_resume, format_resume, and edit_resume. It stops short of explicitly naming those siblings, so the differentiation is inferred from scope 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?

The sentence 'This does not submit an application' draws a useful boundary against apply, which is real routing guidance. However it gives no positive when-to-use condition and never contrasts with format_resume, edit_resume, or generate_pack, which are the closest 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 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 the safety profile is covered. The description adds real value beyond that by clarifying that reading settings does not start any applications — a side-effect guarantee an agent might otherwise worry about for an Autopilot 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?

Two short sentences, front-loaded with the returned values and closed with the non-triggering guarantee. No padding or 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?

An output schema exists, so return-value detail is not strictly required, yet the description usefully summarizes the two key fields. The remaining gap is routing: it never distinguishes itself from the closely named get_autopilot_status and update_autopilot_settings siblings in the same Autopilot cluster.

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 per the rubric. There is nothing for the description to clarify at the parameter level, and the schema is trivially complete.

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 identifies the exact settings returned: the minimum Matches score and the default-vs-tailored resume choice. That is far more than a restatement of the title. It stops short of naming how it differs from siblings like get_autopilot_status or update_autopilot_settings, leaving the agent to infer from the name.

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

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

Usage is only implied: the sentence 'Reading settings starts no applications' hints at a safe, non-triggering read but does not state when to call this versus get_autopilot_status or update_autopilot_settings. No exclusions or prerequisites are given.

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

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

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 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 needs no restating. The description adds genuine behavioral context with 'unanswered identifies preference keys the account holder has not supplied', which tells the agent the response can signal missing data rather than simply being empty.

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 returned resource before the boundary statement. The long field enumeration partially duplicates what an output schema already carries, but it is compact enough to stay useful for relevance judgement 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?

With zero parameters and an output schema present, the description need not describe return structure, and it instead supplies the two things structured fields cannot: the 'unanswered' semantics and the explicit boundary against resume/work-history siblings. Only a pointer to update_preferences for the write path 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 to disambiguate and the baseline is 4. The description correctly does not invent parameter guidance.

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

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

States a specific verb (Returns) plus the exact resource content: target functions, locations, relocation, pay floor, deal-breakers, seniority, cover-letter settings. It also scopes itself negatively ('does not return resume content or work history'), which cleanly separates it from get_resume_work_history and get_profile.

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 exclusion of resume content and work history effectively routes the agent to other tools when the need is different, and the enumeration of returned keys tells the agent what this call is good for. However, no sibling is named as a direct alternative (e.g., update_preferences for writes, get_communication_preferences for channel settings), so selection still requires 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 establish the safe read-only, non-destructive, closed-world profile. The description goes beyond them by disclosing return-shape behavior: the profileIdentityVersion snapshot and the resumeUrl=null / resumeText fallback semantics for inline resumes. It stops short of covering freshness or caching, but the added context is real.

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 verb and the payload list, followed by one targeted edge-case clarification. No filler, no restatement of the title.

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

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

With an output schema present and zero parameters, the description only needs to frame what the call fetches and flag non-obvious return semantics, which it does. The one gap is sibling disambiguation against get_preferences and get_career_record, which the description never addresses.

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 imposes nothing to explain; the baseline for a no-param tool is 4. The description correctly spends no space on parameter syntax and instead documents the return fields.

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 (the authenticated account's profile) and enumerates the payload contents (resume text, preferences, profileIdentityVersion). It is clear, though it does not distinguish itself from close siblings like get_preferences or get_career_record, which also return overlapping profile-adjacent 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 when-to-use guidance, no prerequisites, and no alternative named. With siblings such as get_preferences, get_resume_download_link, and get_career_record in the same namespace, the agent gets no help deciding when this consolidated profile call is the right one.

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?

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds one genuine behavioral detail beyond that: a null limit means unlimited allowance, which prevents a misread of the returned data. It says nothing about auth requirements, rate limits, or refresh cadence, so it is adequate rather than 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?

Two sentences, both load-bearing. The returned fields are front-loaded, and the null-limit caveat follows immediately as the one non-obvious interpretation rule. No filler, no restatement of the title or name.

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 is not obligated to enumerate return values, and with zero parameters and full annotation coverage there is little else to specify. The description still covers the account state, the consumed allowances, and the reset timing, plus the null semantics, which is everything an agent needs to call and interpret this correctly.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The schema is empty and complete, and the description introduces no parameter confusion.

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 an explicit enumeration of the resource contents: plan tier, packs, applications used today, allowance limits, and reset time. An agent immediately knows this is a read of current quota/consumption state. It does not, however, distinguish itself from nearby siblings such as get_stats or get_upgrade_link, so it falls short of a 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?

There is no statement of when to call this tool versus alternatives. With get_upgrade_link and get_stats present in the sibling list, an agent has no guidance on whether this is the tool to check remaining quota, or whether get_stats is the right call instead. Usage context is left entirely 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 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.

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

Usage is implied by the purpose: retrieve dismissed listings. However, the description does not explicitly say when to choose this over list_matches, dismiss_match, or restore_match, nor does it provide exclusions or alternative-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 the useful 'when known' caveat about partial data and the field list, but says nothing about ordering, pagination or result size, so it adds only modest context beyond the annotations.

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

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

Two tight sentences with the core purpose front-loaded and the scope caveat last. The 'No role filter is applied' clause is slightly awkward given the tool accepts no parameters at all, but the text is otherwise waste-free.

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 parameterless read-only list tool whose annotations cover safety, the description substitutes for the absent output schema by naming the fields returned. Ordering and pagination behavior remain unstated, which is a minor gap rather than a blocking one.

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 per the rubric the baseline is 4. There is nothing for the description to disambiguate beyond confirming that no role filter is available.

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 all interviews detected for the account') and enumerates the fields returned (role, company, time, platform). There is no interview-specific sibling in the tool list, so no sibling routing is needed, but the description never explicitly frames itself against the list_* family.

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: you call it to see interviews. The clause 'No role filter is applied' is a scope caveat that hints at a filtered alternative but names none and states no when-to-use/when-not conditions.

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

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

Annotations already declare readOnly/non-destructive/closed-world, so the bar is lower. The description adds real behavior: default page size of 10, a 50 cap, cursors preserving their issued page size, and notes describing applied filters and coverage. It stops short of stating failure modes beyond cursor/filter mismatch.

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

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

Front-loads the return payload, then pagination, then edge-case rationale. Dense but mostly earns its place; nextCursor is explained twice (once for continuation, once for page-size retention), a 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?

An output schema exists so return values need not be re-explained, yet the description covers pagination, filter narrowing, and notes semantics adequately for a 20-parameter list tool. Filter-interaction details (e.g. how filters combine) remain slightly thin.

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 high (85%), so the per-parameter docs already do the heavy lifting. The description adds cross-parameter semantics (cursor must reuse identical filters/sort, cursor keeps issued page size), but largely restates what limit and addedAfter already document.

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

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

States a specific verb and resource: returns the account's ranked live match pool, and enumerates returned fields (job id, company, salary, match percent, saved/applied state). The word 'live' implicitly scopes it apart from list_dismissed_matches, but no sibling is named 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?

Explains pagination usage (nextCursor continues a page, null ends the walk) and the addedAfter overlap rationale, but gives no guidance on when to choose this over browse_listings, get_listing, or list_dismissed_matches. 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 genuinely non-structured context: results are newest-first, scoped to account-owned actions from both the site and MCP, and the ledger stores action records rather than conversation text. Pagination and the default page size are not addressed.

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 and ordering first, then the two parameters, then a clarifying note about what the ledger contains. No filler, though the mid-sentence parameter enumeration makes the middle clause slightly denser than needed.

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 low-complexity two-parameter surface keeps the bar modest. However, the description leaves the status enum largely undocumented and gives no sibling differentiation, which are the two gaps an agent would most likely hit.

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 carry the burden and it only partially does: it says status filters ongoing/completed/failed work and limit bounds the result. The enum actually has seven values including queued, verifying, cancelled, and undone, and the description never mentions the default of 20 or the maximum of 50.

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 recent account-owned assistant actions') plus ordering ('newest first') and scope ('across the site and MCP'). It does not distinguish itself from sibling tools like get_task or get_updates_since, so an agent cannot route between them from this text alone.

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

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

Usage is only implied: 'recent account-owned assistant actions' tells an agent this is an activity-listing call, and the mention of filtering by status/limit hints at the use case. There is no explicit when-to-use or when-not, and no pointer to the adjacent get_task, get_updates_since, or undo_last tools.

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