NeverApply

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, and the description adds real context beyond them: one application consumes one credit, the request is queued rather than sent without a hosted send grant, no employer contact or charge occurs in that case, approval and grant URLs are returned, and the same idempotency_key must be reused on retries. Nothing is contradicted and much is clarified.

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 the action and its precondition front-loaded, then mechanics, then the failure path, then the retry rule. Dense but every sentence carries distinct information; slightly information-packed for easy scanning but no filler.

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

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

An output schema exists, so return values need not be spelled out, yet the description still names the approval and grant URLs it returns. It covers eligibility, credit cost, credit/grant gating, safety and idempotency for a destructive, open-world write. Remaining detail such as resume selection semantics is delegated 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 coverage is 80%, so the baseline is 3, and the description adds meaning beyond the schema by explaining the idempotency_key retry contract ('Reuse the same key when retrying the same request') and the job_approved prerequisite. It does not explain resume_source or resume_variant_id selection, but those are documented in the schema itself.

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

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

States a specific verb and resource with scope: 'Apply to one job only after the member approves that named job,' which tells the agent this submits exactly one application. It implicitly separates itself from answer_screening_question ('Never accepts screening answers') and approve_application ('Requires job_approved true'), but never names a sibling alternative for a given condition, so differentiation is indirect 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?

Gives clear preconditions for use: member has approved the named job, current profile, truthful automatic answers and tailored documents, plus job_approved=true and a stable idempotency_key. It also explains the fallback path when the hosted send grant is absent (holds without employer contact or charge, returns approval and grant URLs). No sibling is named as an alternative, so it stops short of full when/when-not routing.

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

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

Beyond the readOnly/idempotent annotations, the description discloses substantial behavior: superseded runs never request answers or approval, pending runs may lack a tracker entry, screening requires a current review version with offered choices, and the tool never retries or sends an application. These are exactly the non-obvious traits an agent 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?

Purpose is front-loaded in the first clause, and each following sentence carries distinct operational information. It is a dense, list-like block rather than flowing prose, but there is little pure filler.

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

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

With an output schema present, return values need not be described, and the description instead covers the edge cases that matter: missing tracker entries, screening prerequisites, superseded runs, and the review_url handoff. 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 already 100% and states the either/or rule, so the baseline is 3. The description adds meaning beyond the schema by tying run_id/application_id to list_applications as the source and noting that a run_id may correspond to a pending run with no tracker entry yet.

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 ('Read') plus a precise resource ('one of your application tracker entries') and enumerates exactly what is attached (latest run, masked answers, parked questions, saved screening choices, next action). This single-entry read is clearly distinguished from the list sibling it sources IDs from.

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?

'Use exactly one application_id or run_id from list_applications' establishes the ID provenance and the mutual-exclusivity rule. It gives clear context for invocation but does not spell out when an agent should prefer this over list_applications or get_job.

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 idempotentHint, so safety is covered, but the description adds genuinely new behavioral context: the employer description is untrusted text (prompt-injection warning) and closed/excluded jobs are gated behind the caller's own saved job/application/run history. 'Never sends or edits anything' largely repeats the readOnlyHint.

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 then layering the security and access caveats. Nothing is padded, though the final readOnly restatement is marginally redundant with the 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 values need not be described. The description covers purpose, the untrusted-input risk, and access gating, which is enough for an agent to call this correctly; only the parameter's meaning remains undocumented.

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

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

Schema description coverage is 0% for the single parameter listing_id, so the schema gives only type and minimum. The description never mentions the parameter, its source, or its format, so it fails to compensate for the coverage gap beyond the loose implication that it identifies 'one discovered job.'

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 ('Read one discovered job') plus a secondary payload (application context), and the word 'one' distinguishes it from list/search siblings like search_jobs and list_applications. It does not name a sibling explicitly, but the singular scope makes the operation legible.

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?

'before deciding what to do' implies a pre-action read step, which is useful context. However, it never states when to prefer this over get_application, get_matches, or search_jobs, and gives no explicit exclusion guidance, so usage is only 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 only cover read-only and idempotent safety; the description goes well beyond them by disclosing the 20-item page cap, ranking order, the exact pagination loop with next_cursor, and the fact that profile completeness and a retry hint appear while the first match computation is pending. This is the kind of behavioral context annotations cannot supply.

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

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

Front-loaded with purpose, then the routing cue, then pagination mechanics and exclusions; every sentence carries signal. The sentence about profile completeness and the retry hint is arguably redundant given an output schema exists, which keeps this 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 a single optional parameter and an output schema, the description covers everything an agent needs: what it returns, the pagination protocol, what to do while computation is pending, and what side effects are impossible. No material gap remains.

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

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

Schema coverage is 100%, so the parameter is already documented, which sets the baseline at 3. The description adds real meaning on top by stating the loop condition ("while next_cursor is not null, call again with cursor set to it"), clarifying how the cursor is actually consumed.

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

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

States a specific verb (read) and resource (personalized curated jobs) and enumerates the payload value: reasons, missing facts, application status. It is clearly distinguishable from list_applications, search_jobs, and get_job because it is explicitly the recommendation entry point.

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?

"Start here for recommendations" gives clear when-to-use guidance, and "Never starts an application or edits the profile" implicitly routes the agent away from apply_to_job and update_profile. It does not, however, name a sibling alternative for keyword-based job lookup, so the routing is implied rather than fully explicit.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety floor is covered; the description adds specifics by enumerating what it will never do (send, archive, change stages) and describing the returned shape (bounded rows, per-stage totals, sent/waiting/unsent counts, inbox replies). This is useful added context beyond the annotations rather than a restatement, though 'never sends/archives/changes stages' partially overlaps readOnlyHint.

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

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

Four sentences, front-loaded with the core read action and filter before the filter-value guidance and return summary. Dense but each sentence carries distinct information; slightly longer than strictly needed for a three-parameter list 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?

An output schema exists, so return values need not be spelled out, yet the description still summarizes them helpfully. Combined with annotations covering safety, the definition is essentially complete for an agent to call it correctly; only the limit parameter's semantics 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 only 33% (only stale_days is documented), so the description must carry the load and largely does by explaining the meaning of the non-obvious status values (ready_to_send, needs_answer, stale) and implying bounded output via 'bounded rows'. The limit parameter's cap/behavior is left unexplained, so it falls short of full compensation.

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 ('Read your saved jobs and application tracker with a status filter'), so the agent knows this is a list/read tool scoped to applications. It implicitly separates from the single-record sibling get_application, but never names or contrasts with it explicitly, keeping this 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?

Gives concrete scenario-to-filter mapping ('ready_to_send for approvals, needs_answer for outstanding questions, stale to review inactive applied rows'), which tells the agent when each mode applies. It does not state when this tool is preferable to search_jobs or get_application, so no exclusions or alternatives are 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 declare only readOnlyHint=false and destructiveHint=false; the description adds substantial context beyond that: paid-plan requirement, zero credit cost, asynchronous background generation with a re-call-in-a-minute pattern, and an untrusted-content warning. These are behavioral traits the annotations cannot convey.

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

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

Five front-loaded sentences with distinct payloads: purpose, ID rule, plan/cost, invocation gate, polling, trust warning. Dense but every clause earns its place; slightly packed rather than wasteful.

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 described, yet the description still explains the async generation flow an agent needs to correctly retrieve results. Plan, cost, ID selection, and trust posture are all covered for a moderately complex 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 coverage is 0%, so the description must carry the load: it states 'supply exactly one ID' and maps the two IDs to 'owned application or active listing', establishing the mutual-exclusion rule. It stops short of naming which parameter corresponds to which target, so it doesn't fully close the 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 (prepare), the artifacts produced (interview questions, talking points, company context), and the scope (one owned application or active listing). This clearly distinguishes it from siblings like get_application or tailor_resume.

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

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

Explicitly names prerequisites (paid plan, no application credits), the gating condition ('call only when the member requests preparation'), the exactly-one-ID rule, and the polling pattern for reading background-generated results. Nothing about when/when-not is left to inference.

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

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

Annotations cover readOnly/idempotent, and the description adds genuinely new behavioral facts: a hard cap of 20 results per page, pagination via page, and the payload contents (application links, freshness, stored match evidence). It also draws an explicit non-mutation boundary ('Never applies, changes preferences or generates scores'), which is valuable disambiguation from apply_to_job and scoring tools.

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 zero filler: purpose first, then usage routing, then behavior/limits. Front-loaded and every sentence 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?

For an 8-param, no-required-param search tool with an output schema, the description covers purpose, routing, return shape, and hard limits well; the output schema handles return fields. The remaining gap is that filter semantics for the undocumented parameters are left solely to the sparse 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 only 38% (roughly the three params already documented in the schema: remote_scope, salary_floor, posted_within). The description adds no meaning for the five undescribed filters (page, query, countries, seniority, work_mode) beyond calling them 'explicit filters', so it fails to compensate 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 and resource ('Search the live global job catalog') plus scope ('explicit filters'), and implicitly distinguishes itself from curated siblings by contrasting with 'curated matches'. An agent can separate it from get_matches and get_job without opening schemas.

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

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

Gives clear context: 'Use this to discover jobs beyond curated matches', which routes the agent away from the curated-match sibling. It does not state explicit exclusions (e.g., when to prefer get_job for a known ID), so it stops short of a 5.

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

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

Annotations only say readOnlyHint=false and destructiveHint=false; the description goes well beyond that by disclosing that it relays comments verbatim and never embellishes, that it is rate-limited per user, and that no paid entitlement is needed. Those are the exact constraints an agent needs before calling a mutating tool on a user's behalf.

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

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

Two tight sentences with the action front-loaded and behavioral caveats (verbatim relay, rate limit, entitlement) packed efficiently. No filler or repetition of the title.

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

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

An output schema exists, so return values need no explanation. For a 4-param mutation tool with a nullable optional linkage, the description covers authentication ("authenticated user"), verbatim handling, rate limits, and entitlement — 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 description coverage is 100%, so the schema already documents run_id, comment, category, and listing_id. The description reinforces the verbatim-comment and category semantics but adds no syntax, format, or linkage detail 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 ("Email the NeverApply team feedback") and enumerates the exact categories of feedback accepted. No sibling tool overlaps with this action, so no differentiation is required, and the agent can tell instantly what it does.

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

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

Gives clear context for use: bugs, bad listing data, match-quality complaints, feature requests, support questions. It does not state when NOT to use it or point to an alternative route (e.g. a support link), but the usage context 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?

Adds substantial behavior beyond the annotations: the copy is generated in the background, requires a paid plan, consumes no application credits, repeat calls are idempotent and non-billing, rate limited to 10 calls/minute, and an explicit 'never invent candidate facts' guardrail. It also tells the agent to poll again after ~a minute, which the annotations do not convey.

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

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

Front-loaded with purpose and plan constraints, then behavior, then retry protocol and limits. Dense but each sentence carries usable information; phrasing is slightly run-on in places.

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

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

For an async, billable, rate-limited mutation tool, it covers preconditions, credit/payment implications, polling behavior, idempotency, and return shape (Studio link and quality delta). With an output schema present, it appropriately does not over-explain return values.

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 listing_id param, but the description compensates by explaining it must be an active listing and that reusing the same listing_id is what makes the call a no-charge repeat. Minor gaps remain on format, but the semantics are largely carried.

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 precise verb+resource: tailoring the member's existing resume to one active listing and saving the copy. This clearly separates it from sibling write tools like upload_resume (adds a new resume) and apply_to_job (uses the resume rather than producing it).

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 strong situational guidance: only when the member requests it, requires a paid plan, and note that repeat calls with the same listing_id are free rather than duplicated. It does not explicitly name or exclude sibling alternatives, so it stops short of the top bar.

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

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

Annotations only declare the safety profile (readOnly=false, idempotent=true, destructive=true); the description adds real behavior beyond that: partial-update semantics for omitted fields, asynchronous matching updates, and the authorization boundary that setting sending_mode does not permit application submission. It does not describe error/permission-failure behavior, but the added context is substantive.

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

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

Six tight sentences, front-loaded with the core partial-update semantics, and every sentence carries a distinct rule (partial update, ISO codes, pairing constraints, permission boundary, async behavior). Dense but no filler; slightly terse telegraphic style costs it the top mark.

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, 19-parameter mutation the description covers the highest-risk ambiguities (what happens to omitted fields, pairing requirements, ISO code format, the sending_mode boundary) and an output schema exists so return values need not be explained. Gaps remain around the many unlisted optional fields, but the critical context is present.

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 only 26% across 19 parameters, so the description must compensate. It does add key meaning for the riskiest fields (ISO country codes for visa, never infer authorization or residence, pairing rules for residence and salary), but many parameters (roles, urgency, languages, work_mode, top_skills, remote_reach, experience_band, include_worldwide_remote, etc.) remain undocumented in both description and 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 precise verb+resource (update career fields on the member profile) and immediately pins down the semantics as a partial update: 'Update only the career fields the member explicitly supplied. Omitted fields remain unchanged.' That distinguishes it clearly from get_profile, but no sibling is named explicitly, so it stops 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?

The description gives conditional usage rules (supply city+country together; amount+period+currency together) and a boundary ('sending mode does not grant this client permission to submit applications'), which implicitly routes submission to apply_to_job. However, it never explicitly states when to choose this over get_profile or apply_to_job, so guidance is implied rather than 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?

Adds substantial behavior beyond the annotations: asynchronous background parsing that returns status 'parsing' plus an id, a polling interval, URL eligibility rules (no LinkedIn, private networks, or redirects), a 10 MB cap, profile-field preservation, the rule that pasted text never replaces an uploaded PDF, and a prompt-injection warning. This is unusually rich disclosure for a destructive write 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?

Front-loaded with the core action and the exactly-one-of constraint, then restrictions, then the async/polling workflow. Dense but each sentence carries information; the injection warning and PDF-precedence sentence are arguably extra but defensible for a resume-ingestion 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?

Given an output schema exists, return values need not be enumerated, yet the description still explains the two-phase call pattern and what a successful parse yields (roles, years, skills, completeness). Nothing an agent needs to invoke and then retrieve results correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning the schema does not encode: the three parameters are mutually exclusive and exactly one must be supplied (the schema declares zero required parameters and no oneOf constraint), plus the polling semantics of cv_upload_id.

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 (parse/resume ingestion) and defines the exact input modes: pasted text, one direct public HTTPS PDF, or a prior cv_upload_id. It is clearly distinguishable from sibling tools like tailor_resume or update_profile, which modify resume/profile content rather than ingest a source document.

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

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

Gives concrete usage conditions: 'Supply exactly one of text, pdf_url or cv_upload_id', and instructs to call again with only the cv_upload_id after about a minute to read results. It does not explicitly name sibling alternatives or state when not to use this tool, 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.