Worklittle Jobs

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

Annotations already indicate this is a write operation (readOnlyHint=false) with openWorldHint=true. The description adds the behavioral nuance of launching a browser session vs submitting a hosted application, but does not disclose deeper consequences like irreversibility or external effects beyond what openWorldHint implies.

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 concise sentences. The first sentence front-loads the core purpose and the two application modes; the second gives immediate invocation guidance. No wasted words.

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

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

The description covers the two distinct workflows and essential input requirements. It is complete enough for an agent to initiate a call, especially with an output schema present. Minor gaps exist around edge cases (e.g., auto_submit behavior) but those are partially covered by parameter descriptions.

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% with clear parameter descriptions. The description adds value by clarifying that hosted postings require name, email, and resume (not in schema), and by explaining the intended usage of job_id as the primary selector. This goes beyond the schema's basic field descriptions.

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

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

The description clearly states a specific verb ('Start applying' / 'submit') and the resource (a catalog job or hosted Worklittle application). It distinguishes itself from sibling tools like delete_applied_job and search_jobs by focusing on the application action.

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

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

It provides clear context on when to use: 'applying' to a job, with a distinction between browser-session catalog jobs and hosted postings. It tells the agent to pass job_id and mentions required fields for hosted postings, but does not explicitly exclude scenarios or name alternative tools.

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 description doesn't need to restate the destructive nature. It adds useful context about scope ('API key owner's personal saved-jobs pipeline') and the concept of unhearting, which supplements the structured annotations without contradicting them.

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

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

The description is a single sentence that front-loads the action, specifies the scope, and provides common synonyms. No wasted words; the prefix 'Jobs —' is minimal and does not detract from clarity.

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 one-parameter tool with a full schema, output schema present, and annotations covering destruction/read-only flags, the description fully covers necessary context. It even clarifies ownership and pipeline semantics, leaving no important gaps for correct invocation.

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

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

Schema description coverage is 100%, so the job_id parameter is fully documented in the schema. The description does not add extra semantic detail about the parameter format or constraints, which is acceptable per baseline since the schema carries the full 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?

Description states a clear verb ('Remove') and resource ('a job from the pipeline'), with clarifying aliases 'unheart / remove from Saved'. It distinguishes itself from siblings like delete_resume and track_applied_job by specifying it targets the user's saved-jobs pipeline, not a resume or application tracking record.

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

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

The description clearly implies when to use: when removing a saved job from the personal pipeline. It does not explicitly name alternatives or exclusion conditions, but the context is unambiguous enough for an agent to decide without confusion against siblings such as apply_for_job or track_applied_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 mark destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds meaningful context: 'Requires jobs:apply' permission and specifies the target is the 'connected account's profile resume file,' clarifying the scope of deletion.

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 two sentences: one functional statement and one context/permission note. Every word earns its place, and the key scoping detail ('connected account's profile resume file') 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?

The description is mostly complete for a zero-parameter destructive action. It names the permission requirement and the functional context. With annotations carrying the safety profile and output schema present, the main missing element would be an explicit note about irreversibility, but destructiveHint already covers that.

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

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

The schema has zero parameters and 100% coverage trivially. With 0 params, no parameter descriptions are needed. The description doesn't need to add parameter semantics; the baseline 4 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 clearly states the action ('delete the connected account's profile resume file') with a specific verb and resource. It distinguishes itself from siblings like upload_resume and get_resume, and names the client surface (Job Cards You/Settings).

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

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

The description provides some context for when the tool is used: 'Used by Job Cards You/Settings.' While it doesn't explicitly mention alternatives or when-not-to-use, the pairing with get_resume/upload_resume in sibling tools implies a resume-management context.

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 readOnlyHint and destructiveHint, so safety is known. The description adds valuable context about the data source (API key/OAuth account) and the session-dependent nature, though it does not specify failure behavior when not connected. This goes beyond annotations without contradicting them.

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 concise sentences: first states the return payload, second gives usage contexts, third provides a clear constraint. Every sentence earns its place with no fluff or repetition.

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

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

For a zero-parameter tool with an output schema and read-only annotations, the description covers purpose, usage timing, and constraints. Nothing essential for an agent to invoke the tool correctly is missing.

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

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

The input schema has zero parameters, so there is nothing for the description to add on parameter semantics. Per the baseline for 0-param tools, a score of 4 is appropriate as the description effectively communicates that no inputs are required.

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

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

The description uses a specific verb 'Return' and enumerates exact fields (user_id, email, display name, etc.), making the resource and scope unambiguous. It clearly differentiates from sibling tools by focusing on the connected account data, not jobs or resumes.

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 explicitly states when not to call ('Do not call for anonymous browse') and when to call ('only after Connect or when already linked'). It also provides concrete usage contexts (Job Cards You overlay, overflow account row, Apply resume gate), giving clear operational 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 the tool read-only and non-destructive, so the description only needs to add behavior beyond that. It does so by disclosing the fallback behavior: when query is used, the tool loads the first matching live listing, and it notes the detail level returned. It does not cover every edge case, but the annotation coverage lowers the burden.

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 tight and front-loaded: it states the core purpose first, then gives the preferred input path, then the fallback path with a concrete example. Every sentence contributes useful guidance without redundancy or 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?

Given the rich input schema, output schema, and safety annotations, the description covers the essential decision logic for selecting and invoking the tool. It explains the two invocation modes and leaves parameter-level details to the schema, which is fully documented. Nothing critical is missing for an agent to use the 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 documents all four parameters meaningfully. The main description adds little that is not already in the parameter descriptions, though it reinforces the relationship between job_id and query and clarifies the fallback flow with an example. This is the expected baseline for fully documented schemas.

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

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

The description clearly states the tool fetches detailed information about a specific job, naming the resource and the kind of content returned (responsibilities, qualifications, company details). It distinguishes itself from list-oriented siblings like search_jobs and get_job_keywords by emphasizing 'detailed information about a specific job' and 'full details.'

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 explicit routing guidance: use job_id when available from search_jobs, or fall back to query plus optional location when the user asks for full details without an id. This directly tells the agent when to call this tool and how to supply the right inputs, including a concrete example.

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 indicate a safe, read-only, open-world operation. The description adds useful behavioral context beyond the annotations: it deals with 'live' job data, returns 'keywords plus keyword_count', and explicitly states that a prior search is not required for general role questions. This gives agents a clear picture of the tool's operating assumptions.

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 compact and every sentence earns its place: it states the core purpose, gives parameter selection guidance, notes return fields, and adds a critical open-world caveat. It is front-loaded with the tool's function and avoids unnecessary examples or 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, 100% parameter schema coverage, and clear annotations, the description fully equips an agent to invoke the tool correctly. It covers the main decision (job_id vs query), optional location usage, return contents, and the important instruction not to force a prior search. Nothing essential is missing for this read-only, straightforward 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?

Although the schema already covers all three parameters (100% coverage), the description adds decision-making context: job_id is for one listing, query is for aggregating across roles, and location is optional for the query path. This goes beyond raw schema definitions by connecting each parameter to the use case that should trigger 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?

The description clearly identifies the action ('Get') and the resource ('skill and technology keywords from live Worklittle job data'), and distinguishes this tool from similarly named siblings like get_job_details by focusing on keyword extraction rather than job details. It also clarifies that it can operate on either a single job_id or an aggregated query, leaving no ambiguity about what the tool returns.

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 explicitly states when to pass job_id vs query, including the condition 'if the user asks what keywords show up for a role ... and you do not have a job_id'. It also provides an explicit exclusion by saying 'Do not require a prior search when the question is about a role in general', which directly guides tool selection behavior.

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 read-only and non-destructive behavior. The description adds useful behavioral detail such as salary signals only coming from listings that publish pay, and the difference between full-market and filtered results. This exceeds the baseline without contradicting 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?

The description is compact and well structured: it opens with the core purpose, then gives no-arg and filtered usage, then lists what each call returns. Every sentence contributes necessary information with no filler.

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

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

With an output schema and annotations present, the description covers the key decision an agent needs to make: whether to pass query/location or call with no args. The only minor gap is that workplace_type filtering is not mentioned in the prose, but the schema fully covers that 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 coverage is 100%, so the baseline is 3. The description adds real semantic value by explaining that query and location define a market slice and by describing what changes in the returned data (match count, top companies, salary signals). It does not mention workplace_type in prose, but the schema already documents it clearly.

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

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

The description clearly states the tool returns aggregate job-market statistics, not individual jobs, which distinguishes it from siblings like search_jobs and get_job_details. It also explains both the full-market and filtered-slice behaviors, making the resource and purpose unmistakable.

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

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

The description gives explicit guidance for when to call with no args versus when to pass query and location, including a concrete example. It does not explicitly name alternative tools or state when not to use this tool, but the usage context is clear enough for correct routing in most cases.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so this is known to be a safe read operation. The description adds behavioral value by enumerating the exact statuses the tool may return, which helps an agent interpret results and know what to expect. It does not introduce any contradiction with 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?

The description is short and contains the essential status list, but the trailing phrase 'Job Cards analyzing phase' is unclear and adds little value. The opening 'Jobs —' prefix is also somewhat redundant. The structure is acceptable but not maximally concise because the extra phrase does not earn 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?

Given there is an output schema (though not shown), the description need not explain return values, and it does enumerate statuses. However, it references a tool that does not exist in the sibling list ('upload_profile_resume' vs 'upload_resume'), leaving a gap in the agent's understanding of the exact sequence. Also, 'Job Cards analyzing phase' is too vague to be actionable. Overall, the description is mostly complete but has a confusing reference.

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

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

The tool has zero parameters, so the schema provides no parameter details. The baseline for zero parameters is 4, and the description does not need to compensate. It adds no parameter semantics because there are none, which is appropriate.

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

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

The description clearly states that this tool polls the profile resume processing status and lists the possible statuses (ready, processing, idle, missing). However, it references 'upload_profile_resume' which is not among the sibling tools (the actual sibling is 'upload_resume'), causing potential confusion about the exact workflow. The phrase 'Job Cards analyzing phase' is vague but does not obscure the core purpose.

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 provides a specific trigger ('after upload_profile_resume'), which implies when to use this tool. However, it does not explicitly state when not to use it or compare with alternatives. Since no other tool polls resume status, the guidance is fairly clear, but the wrong tool name in the trigger undermines clarity and leaves an agent unsure whether it should follow up with 'upload_resume' or a non-existent 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?

Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint), the description adds meaningful behavioral details: returns a ranked list ('ranked typeahead'), filters to employers 'with open jobs', lists exact return fields, and describes handling of zero results with do-not-invent-ID and fallback instructions. This greatly exceeds the annotation's minimal safety hint and fully discloses the tool's behavior.

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 slightly longer than minimal but every sentence adds value: the return format, the trigger conditions, and the fallback rules are all necessary for correct invocation. It is front-loaded with the core purpose. The length is justified by the complexity of the tool; it isn't verbose. A 4 reflects good balance.

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 tool with two parameters, an output schema, and several behavioral nuances, the description is thorough. It covers what the tool returns (fields), the scope of the index (open jobs), when to use it, and how to handle empty results with explicit next steps. An agent has everything needed to call it correctly and decide when to use it. The presence of an output schema also reduces the need to exhaustively describe return values. This is a near-perfect contextual package.

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?

Both parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds extra semantics: 'q' is a 'ranked typeahead' and the index covers only employers with open jobs, which clarifies the meaning beyond the raw schema. This adds meaningful value but doesn't dramatically change the parameters' semantics, so a 4 is appropriate.

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

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

The description states the specific verb 'search', the resource 'Worklittle market company index', and the exact retrieval goal ('by name or slug'). It also differentiates itself from sibling search_jobs by explicitly connecting the output (slug/id) to search_jobs filters. This enables an agent to select it correctly without ambiguity.

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

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

It clearly states when to use: when the user names an employer and you need a real slug/id for search_jobs company filters, job alerts, or automations. It also provides fallback steps and exclusions (never invent ids). While it doesn't explicitly list alternative tools for when not to use it, the context makes it clear. A score of 4 reflects this good but not exhaustive 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 readOnly/openWorld/non-destructive, and the description adds significant behavior beyond them: matching is via substring/FTS not vector emberdins; query hits TITLE text only while compary lives in a separate field; visa postings must be explicitly tagged and are sparse enough that the default 14-day cutoff is suspended when visa_Sponsorship is set; defaults are disclosed (14-day recency, 50-km radius, cursor-based pagination). Even the post-render follow-up script is specified. Rich, non-redundant disclosure.

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

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

The content is dense with zero filler — every sentence carries an operational rule, and the purpose is front-loaded in the first line. However, it is one unbroken paragraph packing roughly fifteen distinct rule areas (query syntax, compary slugs, visa, recency, location, messaging), which seriously hurts scannability. A few line breaks or groupings would make the same excellent content reach 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?

For a 20-parameter tool with a rich output schema, annotations, and 4 enums, the description covers every invocation concern: query construction, field scoping, negative-term syntax, exclusion rules, defaults, pagination, multi-metro handling, visa data-quality caveats, and post-response messaging. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema cannot express: query merges with keywords and maps to API title=; recency wording→posted_within_days conversion; the interack between visa_sSponsorship and the omitted posted_within_days default; the rule that negative-dash syntax applies in both query and company; and the mutual exclusivity between near_* and location_or. This goes well beyond the per-field schema texts and substantially improves correct invocation.

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

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

Opens with a crisp verb + resource statement: 'Search Worklittle's job listings by keyword, company, location, job type, seniority, or recency.' This immediately distinguishes it from siblings — search_companies (employer lookups), get_job_details (individual postings), get_market_overview (aggregates) — and states the ANY-industry scope explicitly. Nothing about the tool's core function 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?

Provides explicit when/when-not and alternative routing at the parameter level: 'Prefer this over the location substring when coordinates are known,' 'Use location only when you cannot geocode,' 'For two or more metros... use location_or,' and a concrete recency mapping (today→1, week→7, month→30, vague→14). Also gives procedural fallbacks ('When an include company filter returns 0 results, try a broader query') and hard exclusions ('Never pass display names as query,' 'Never merge many titles into one string'). It does not name sibling tools explicitly, but the invocation guidance is exhaustive.

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

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

Annotations already mark the tool as non-readonly and non-destructive. The description adds valuable behavioral details: status defaults differ by method ('in_progress for apply / apply_with_ai, applied for api') and maps UI actions to statuses. This goes beyond the structured annotations without contradicting them.

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 deliver a complete overview: purpose first, then status mapping and defaults. No filler or redundancy; every clause adds actionable information.

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

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

Given the presence of an output schema and annotations, the description covers the core behavior well. However, it does not explain where job_title and company_name come from (likely from search_jobs/get_job_details), nor does it clarify idempotency or distinguish when to use this tool versus apply_for_job. These gaps leave some ambiguity for an agent deciding between 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?

Schema coverage is 67%: job_id, method, status, and apply_url have descriptions, but required job_title and company_name lack descriptions. The description enhances the semantics of status and method via default rules, but it does not compensate for the undocumented required fields or add meaning to apply_url beyond its name.

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

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

The description uses a specific verb ('Record') and resource ('job') and enumerates the exact actions covered: saved, applied, clicked Apply, or skipped. It also clarifies semantic mappings for status values, making the tool's purpose unmistakable and distinct from siblings like apply_for_job.

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 concrete guidance on when to use each status ('saved for heart/save and skipped for deck Skip') and explains default behavior based on method. It does not explicitly contrast with sibling apply_for_job, but the verb 'Record' implicitly distinguishes the tracking role from actual application submission.

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?

The description discloses key behavioral traits: it is a patch operation (partial update rather than wholesale replacement), it modifies the connected account, it requires jobs:apply permission, and it syncs to the cloud for worklittle.com. These traits go beyond the annotations, which only indicate not read-only, not open-world, and not destructive. No contradiction with annotations; readOnlyHint=false correctly permits the write 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?

Four sentences, each earning its place. The core action is front-loaded, followed by usage context, permission requirement, and sync behavior. No redundancy or filler. The field list is condensed into parenthetical categories rather than 20 separate tokens, and the 'Jobs —' prefix is useful context.

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

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

The tool has 20 optional parameters with poor schema-level descriptions, so the description carries a heavy burden. It gives usage context and discloses the patch/sync nature, but it omits critical facts such as how to clear fields (despite schema hints), what happens to unspecified fields, and exact meaning of ambiguous params like 'you_work' or 'phone_national'. The presence of an output schema reduces the need to explain return values, but overall the context is not fully complete for correct invocation.

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

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

Schema description coverage is only 15%, so the description must compensate. It does add high-level grouping of the many parameters into categories (name, school, desired role, phone, links, etc.), which gives rough meaning to otherwise bare string fields. However, it fails to map which exact parameter corresponds to each category (e.g., which field is 'desired role'), and does not explain details like clearing via empty strings or the profile_clear_fields array. Combined with self-explanatory names, this is adequate but leaves ambiguity.

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

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

The description uses a specific verb ('Patch') and a clear resource ('the connected account's Settings profile fields'), then enumerates the categories of fields (name, school, desired role, phone, links, work authorization, driver's license, interests). It is explicitly scoped to Job Cards You overlay, distinguishing it from siblings like get_account (read-only), upload_resume, or apply_for_job. This unambiguously identifies the tool's function.

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 provides clear context for use: it is called when patching the connected account's Settings profile and is tied to a specific feature (Job Cards You overlay). It also states the required permission (jobs:apply). It does not explicitly exclude alternative tools, but because it is the only account-update tool among siblings and the action is well-defined, an agent can infer the appropriate scenario.

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 indicate readOnlyHint=false, so mutating behavior is already implied. The description adds that it uploads to the connected account's profile, requires the jobs:apply permission, and accepts multiple file types. It could mention side effects like replacing previous resume or if it's idempotent, but the added context is valuable beyond annotations.

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

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

Two sentences: the first states the action, scope, file types, and exact use case; the second states required permission. Every word earns its place, no fluff, and critical info is front-loaded.

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

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

For a mutation tool with no destructive hint, the description covers the purpose, prerequisite permission, and use case. It doesn't explain return values, but an output schema exists. It could mention that it overwrites an existing resume, but given sibling delete_resume exists, that ambiguity 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 already provides 100% coverage with descriptions for all three parameters. The description adds that the file types can be PDF, Word, text, or image, which aligns with the MIME parameter and provides practical guidance. It doesn't deeply explain the content_base64 format beyond what schema says, but the schema is clear.

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?

Description clearly states the action (upload), the specific resource (connected account's profile resume file), and allowed file types. It distinguishes itself from siblings like get_resume and delete_resume, and mentions the specific use case (Apply resume gate before start_apply_with_ai).

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 explicitly says this is used by the Job Cards Apply resume gate before start_apply_with_ai, giving clear context of when it should be invoked. It also names a sibling (start_apply_with_ai) that likely follows this step, implying sequence. No explicit exclusions, but the context is strong enough.

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