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 declare readOnly, non-destructive, and closed-world, so safety is covered. The description adds genuine value by disclosing the conditional return state (connected: false when unlinked) and the Connect-dependency, though an output schema also exists that may document the same return shape.

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

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

Three short sentences, front-loaded with the purpose, then the fallback, then the exclusions. No filler; every clause changes how an agent would behave.

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 read tool with an output schema and full annotation coverage, the description supplies the one thing structured fields cannot: when the account is unavailable and what not to do about it. 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate and it correctly stays silent on 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?

States a specific verb and resource ('Return the connected Worklittle account') and immediately clarifies the conditional fallback ('connected: false'). It also explicitly walls itself off from search_jobs, so an agent can distinguish it from the sibling most likely to be confused with 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 an explicit precondition ('when the user already linked via Connect'), an exclusion ('Do not call this to search jobs'), and even a behavioral guardrail ('do not ask them to Connect just to browse'). This is exactly the when/when-not/anti-pattern guidance the dimension asks for.

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?

Annotations already declare read-only, non-destructive behavior. The description adds value by disclosing stateful behavior ('current search'), pagination semantics, and that this endpoint is wired to the Job Cards widget rather than a general model-facing search. It does not claim any mutating side effects, so there is no contradiction.

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

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

The description is two tight sentences with no filler. The essential action, pagination rule, widget context, and 'do not call' warning are all front-loaded and each 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 tool explicitly marked 'Do not call from the model,' the routing guidance is complete, and the output schema plus annotations cover return/safety details. It still leaves some dependency on search_jobs for full filter semantics, but given the explicit non-model use case, this is a minor 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 only 15% schema description coverage and 20 parameters, the description cannot defer all meaning to the schema. It adds cursor semantics and says filters are 'same as search_jobs,' which is helpful, but the remaining filter parameters (e.g., workplace_type, salary_min, near_lat) still have no self-contained semantics in this definition.

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 action and resource: 'Fetch Job Cards for the current search,' and differentiates it by referencing search_jobs and cursor-based pagination ('Omit cursor for the first page; pass next_cursor to page'). It is immediately clear this is a paginated job-card retrieval tool, not the general search 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?

It explicitly tells the agent when not to use the tool: 'Do not call from the model,' and explains the first-page vs. subsequent-page behavior with cursor. 'Same filters as search_jobs' and 'Used by the Job Cards widget' provide context on how it fits alongside sibling 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?

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 establish readOnly and openWorld safety, so the bar is lower. The description adds rich behavior beyond annotations: anonymous search, substring/FTS matching model, negative-term dash semantics, one-API-call preference for umbrella phrases, and the fallback when include-company returns zero. It stops short of describing rate limits or result-count behavior, but coverage is strong.

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

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

This is a wall of text with extensive guidance packed into an unstructured block. While dense with useful rules, it is not front-loaded by importance and repeats concepts (negative dash rule stated twice, multi-metro rule stated twice, recency encoded multiple ways). Every sentence is not equally earning 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 20 parameters, an output schema, and 4 enums, the description covers the tricky interaction cases (visa recency, multi-metro vs coordinates, company slug negatives, umbrella phrases) that an agent would otherwise get wrong. Output schema handles return values, so omission there is fine. Slightly overwhelming, but functionally complete.

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 baseline is 3, but the description adds real semantics beyond the schema: negative dash rules for query and company, why near_* beats location, the visa_sponsorship plus posted_within_days interaction, and recency-word-to-number mapping. It goes past restating schema 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 and resource ('Search Worklittle job listings') and immediately distinguishes scope: title/filter text substring matching, not vector embeddings. It also positions itself against siblings (get_job_details, search_companies) implicitly by defining what it searches.

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?

Extensive when-to-use guidance: call when users want jobs, do not call get_account/apply, use location_or for multi-metro vs near_* for coordinates, pagination via cursor. Explicitly names conditions and alternatives, including the visa_sponsorship/default-recency interaction.

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.