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

With no annotations provided, the description carries the full burden and does disclose a key behavioral trait: overwriting existing job_id fields while preserving application status, and default ID generation as 'manual:<slug>'. It could add return/error behavior but covers the main side effect.

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 well-structured with a clear opening purpose, followed by a concise usage note and an organized Args list. Every sentence adds value and nothing is redundant.

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?

Despite having 9 parameters and no schema descriptions, the description provides complete context: usage scenarios, parameter meanings, ID behavior, and overwrite semantics. An output schema exists, so not explaining return values is acceptable. It is fully sufficient for an agent to invoke 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 coverage is 0%, but the description includes a detailed Args section explaining all 9 parameters with examples (e.g., 'Remote', '$150,000 - $180,000', 'python, backend'), fully compensating for the schema's lack of 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 identifies the specific verb (add), resource (job), and key context (found elsewhere, not from search_jobs), distinguishing it from sibling tools like search_jobs and save_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?

Explicitly states 'Use this to paste a full job description for a listing that did not come from search_jobs' and describes the behavior of reusing an existing job_id (overwrite fields while keeping status), giving clear when-to-use vs alternative 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that non-text files are converted to text for matching while the original is preserved, and that re-using a name overwrites the stored resume. These are non-obvious behaviors that directly affect how the agent should invoke the tool and what to expect.

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 well-structured with an introductory purpose line, a usage paragraph covering input options and file handling, and a concise Args list. Every sentence adds useful information; there is no redundancy or filler. It remains compact despite covering multiple behavioral details.

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 three-parameter tool with no required fields and no annotations, the description provides all necessary context: what the tool does, how to pass input, file formats accepted, conversion behavior, and overwrite semantics. The presence of an output schema means the response format does not need to be described. This is complete for the tool's complexity.

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 provides only types and defaults with no descriptions (0% schema description coverage). The description compensates fully by explaining each argument in the Args section: `name` is a label, `text` is full resume text, and `path` is the file path. It also clarifies that exactly one of `text` or `path` should be given, which is critical for 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?

The opening sentence 'Store a resume so it can be tailored against job listings' precisely states the action (store), the object (resume), and the intended purpose (tailoring). It clearly distinguishes this tool from siblings like list_resumes, get_resume, delete_resume, and tailor_resume by indicating that it is the storage/upload step.

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 clear usage context: it instructs to provide either `text` or `path`, enumerates accepted file formats, and explains that re-using a name replaces the existing resume. However, it does not explicitly mention when not to use this tool or name alternative tools for other operations (e.g., 'use tailor_resume to create a tailored version'), so it stops short of a full when/when-not guide.

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?

With no annotations, the description must carry full behavioral disclosure. It states the core destructive fact: both the stored resume entry and the original file are deleted. However, it does not disclose irreversibility, potential permission requirements, or side effects (such as what happens if the resume is set as default). This is a moderate level of transparency, better than a bare 'delete' but missing several important details.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the action and the scope (including the original file). This is exemplary conciseness.

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 1-parameter delete tool, the description is largely complete. It states the primary action and the additional effect on the original file. Since an output schema exists, return values need not be described. The only gap is the lack of any note on irreversibility or prerequisites, but given the low complexity, this is acceptable.

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 one required parameter 'name' with a string type, and schema description coverage is 0%. The description does not mention the parameter or clarify what 'name' refers to (resume name vs. file name). Since the schema provides no description and the description doesn't compensate, the agent lacks sufficient semantic detail for the parameter.

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

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

The description clearly states the tool's function: 'Delete a stored resume and its original file.' The verb 'Delete' and the specific resource (stored resume plus original file) make the purpose unambiguous. It also distinguishes from sibling tools like delete_saved_job since it explicitly targets 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 offers no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. For instance, it doesn't clarify whether this should be used only when a resume is no longer needed or if there are restrictions (e.g., cannot delete default resume). The agent must infer usage from the name and purpose, which is insufficient.

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?

With no annotations, the description carries the full burden for behavioral disclosure. It mentions 'local tracker' which hints at a local-only effect, but it does not disclose whether deletion is permanent, irreversible, or has cascading consequences (e.g., affecting associated resumes). For a destructive operation, this is a significant gap.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to stating the operation, making it highly concise and easy to parse. It is appropriately sized for the simplicity of the 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 the absence of annotations and a single-parameter schema with no descriptions, the description is insufficiently complete. It lacks usage guidelines, parameter explanation, and behavioral caveats. The presence of an output schema covers return values, but the overall context remains thin for an agent to invoke the tool reliably.

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 coverage is 0%, so the description must compensate. It does not mention job_id at all. While the tool name and description imply job_id identifies the job to remove, the description adds no explicit meaning about the parameter's format, source, or constraints, forcing the agent to guess.

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 ('Remove') and resource ('a job from the local tracker'), clearly distinguishing it from other tools like delete_resume. The phrasing directly states the tool's action and scope, leaving no ambiguity about 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?

The description provides no guidance on when to use this tool versus alternatives such as delete_resume or update_job_status. There are no context cues, prerequisites, or exclusion criteria, leaving the agent to infer usage from the tool name alone.

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

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

No annotations are provided, so the description carries the full burden. It only states 'Show the full listing,' which implies a read-only operation but does not disclose behavior such as what happens if the job_id is invalid, whether any related data is included, or any side effects. The description adds source context but no behavioral depth.

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, direct sentence that front-loads the primary action ('Show the full listing') and immediately clarifies the ID source. No words are wasted, and the structure is optimal for quick comprehension.

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 getter with an output schema, the description is adequate: it states the purpose and the source of the ID. It does not explain return values, but the output schema likely covers that. The lack of annotations is a minor gap, but the tool's simplicity reduces the need for extensive context.

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

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

Schema description coverage is 0%, and the schema only provides a title ('Job Id') for the parameter. The description adds meaning by clarifying that job_id must be an ID returned by search_jobs or list_saved_jobs, which is helpful. However, it does not explain the parameter format or any constraints beyond that. This partially compensates for the lack of schema 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 uses a specific verb ('Show') and identifies the resource ('the full listing for a job id') with clear scoping: the job id comes from search_jobs or list_saved_jobs. This distinguishes it from sibling tools like search_jobs (searches) and list_saved_jobs (lists IDs), making the purpose unambiguous.

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 the tool is used to retrieve full details for a job ID returned by search_jobs or list_saved_jobs, giving contextual guidance. It does not explicitly state when not to use it or name alternatives, but the context is sufficient for a simple get-by-id 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?

No annotations are provided, so the description carries the full burden. It discloses the behavior of the `raw` parameter (returning LaTeX source when available), which is useful. However, it does not mention that the `name` parameter selects a particular resume, nor what happens when no resume matches, or any authorization requirements.

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, efficient sentence with a code-formatted parameter reference. It is front-loaded and contains 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?

For a simple two-param retrieval tool with an output schema, the description covers the core function and the `raw` behavior. However, it omits any explanation of the `name` parameter and provides no usage guidance, which makes it marginally adequate.

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 no descriptions (0% coverage), so the description must explain the parameters. It explains `raw` well ('returns the original LaTeX source when there is one'), but says nothing about the `name` parameter, leaving its purpose and format entirely undocumented.

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

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

The description uses a clear verb ('Show') and a specific resource ('a stored resume'), and adds a distinctive detail about the `raw` flag returning original LaTeX source. While it doesn't explicitly contrast with get_tailored_resume, the scope is clear enough to infer the tool's role.

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 no guidance on when to use this tool versus the many resume-related sibling tools, nor does it explain when the `raw` flag should be used. It only states what it does, leaving the agent to infer usage from the name and 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?

With no annotations, the description carries the full burden for behavioral disclosure, but it only states a basic read operation. It does not indicate what happens if no tailored resume exists for the job, whether the tool can error, or any side effects. The description adds no context beyond the tool's name and schema.

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

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

The description is a single, concise sentence with no filler words. Every word earns its place. It is front-loaded and easy to parse.

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 getter with an output schema, the description is minimally viable. It covers the core operation, but lacks edge-case behavior (e.g., 'not found' handling) and any context about the stored tailored resume relationship. Given the tool's simplicity, a score of 3 reflects adequate but not exceptional completeness.

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 0% description coverage for job_id, so the description must compensate. It only says 'for a job', which weakly ties to the parameter but does not explain what job_id represents, its format, or how it is used. The agent can infer from the shell but receives no explicit semantic enrichment.

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

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

The description states a specific verb ('Return') and resource ('tailored resume') and qualifies the scope ('for a job'). This clearly distinguishes it from sibling tools like list_tailored_resumes (which lists all) and get_resume (which likely fetches by resume ID). The connection to job_id is implied and confirmed by the schema.

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

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

No guidance is given on when to use this tool versus alternatives. It does not mention that this should be used when you need a single tailored resume for a specific job, nor does it exclude list_tailored_resumes for browsing multiple. There are no explicit exclusions or alternatives mentioned.

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?

With no annotations available, the description carries the full burden. It clearly indicates this is a read-only list operation and adds important behavioral nuance by noting that the default resume is marked. It does not disclose any side effects or additional behavior, but the simplicity of the tool and the verb 'List' imply safety.

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, front-loaded with the main action, and adds only the relevant extra detail about default marking. Every word 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?

Given zero parameters and the presence of an output schema (which covers return shape), the description is sufficient. It explains the core purpose and the distinctive default-marking behavior, making it complete for this simple list operation.

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 baseline is 4. The description does not need to elaborate on parameter semantics, and any parameter information would be redundant since none exist.

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 the specific verb 'List' with the resource 'stored resumes', and clarifies a unique behavior ('marking which one is used when none is named'). This clearly distinguishes it from sibling tools like list_tailored_resumes and get_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?

The description implies usage when you need to see all stored resumes, but does not explicitly state when to use this versus alternatives like list_tailored_resumes or get_resume. No exclusions or alternative tool names are mentioned, leaving the guidance implicit.

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

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

With no annotations, the description carries the full burden. It discloses the ordering behavior (newest first) and the filtering capability, which is useful. It does not mention pagination, limit semantics, or error handling, but for a simple list operation this is adequate.

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

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

The description is a single, front-loaded sentence that is concise and free of filler. It conveys the core behavior and key option efficiently.

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 output schema exists and the tool is straightforward, the description covers the main functionality. The only notable omission is the lack of any explanation for the 'limit' parameter, which is a minor gap in an otherwise complete description.

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 0% description coverage. The description clarifies the 'status' parameter as an application status filter, but it does not explain the 'limit' parameter or list possible status values. This partial compensation leaves gaps.

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 lists saved jobs, with a specific ordering (newest first) and an optional status filter. This distinguishes it from sibling tools like search_jobs (which searches broadly) and get_job_details (which retrieves a single 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 context is clear: use this to view saved jobs, with optional status filtering. However, it doesn't explicitly mention when not to use it or provide alternatives, so it falls short of a 5.

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

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

With no annotations, the description carries the burden. It discloses that the list is exhaustive ('every') and limited to those 'written so far' (completed ones), but it does not mention ordering, pagination, or other behavioral nuances. This is adequate for a simple list tool.

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

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

The description is a single, front-loaded sentence with no wasted words. It directly states the action and scope.

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 zero-parameter list tool with an output schema, the description is complete. It fully conveys the tool's purpose. A brief note distinguishing it from list_resumes could enhance clarity, but given the name and description, it is sufficiently 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?

The tool has zero parameters and the input schema is empty, so the schema fully covers parameter expectations. The description does not need to add parameter detail, and the baseline for 0 params is 4.

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 'List' and resource 'tailored resumes' with scope 'every...written so far'. This clearly distinguishes it from list_resumes and defines exactly what is returned.

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 implies this tool is for listing tailored resumes, but it does not explicitly mention when to use it over the sibling list_resumes or provide exclusion criteria. Usage guidance 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?

With no annotations, the description carries the full burden and does well: it reveals that the server runs on a background thread, is bound to 127.0.0.1, stops on client disconnect, and is idempotent (returns the running URL). It does not mention port-conflict behavior or auth, but the core behavioral traits are disclosed.

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 short paragraphs, front-loading the purpose in the first sentence and then providing essential behavioral details. Every sentence adds value, with no redundant or vague phrasing.

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 tool's simplicity (one optional parameter, no annotations) and the presence of an output schema, the description covers all necessary context: what it starts, how it runs, its lifecycle, and the return value. It is complete for an agent to decide and invoke 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?

The schema contains one optional 'port' parameter with a default of 8765, and schema coverage in the description is 0%. The description does not mention the port parameter or add any additional meaning to it. Since the parameter is self-explanatory and fully defined in the schema, this is adequate but not enhanced.

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-resource pair ('Start the local web UI') and clearly states the resource's purpose ('browsing saved jobs and their tailored resumes'). This distinguishes it from sibling data-retrieval tools like search_jobs or list_tailored_resumes, since it launches a UI rather than returning data.

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

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

The description gives clear context for when to use the tool: when the user wants to browse saved jobs and resumes via a local web UI. It implies the UI is for exploratory viewing rather than API-level access, but does not explicitly name alternatives or exclusions, 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. The description correctly implies a read-only aggregation, but it does not detail whether counts include all statuses (including zero counts) or only statuses with existing jobs. This is minimal but acceptable for a simple count 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?

The description is a single, direct sentence with no redundant words or filler. It efficiently communicates the tool's purpose.

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 tool has no parameters and an output schema is present, the description is largely sufficient. It clearly states what is counted and by what grouping, though it could marginally benefit from noting that it aggregates across all saved jobs.

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 the baseline score is 4. The description adds no parameter-specific information because there are none to describe, 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 'Count saved jobs by application status' uses a specific verb ('count') and resource ('saved jobs') with a clear grouping criterion ('application status'), distinguishing it from sibling tools like list_saved_jobs (which lists) and search_jobs (which 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?

The description implies this tool is for obtaining aggregate counts rather than individual job details, but it does not explicitly state when to use it over alternatives like list_saved_jobs or update_job_status. No when/when-not guidance is provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the save action and destination, but does not disclose behavior for duplicate saves, whether it creates or updates a record, prerequisites like requiring active search results, or side effects. This is a significant gap for a mutation 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?

The description is a single, front-loaded sentence with no redundant words. It conveys the core operation efficiently and 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 relatively simple save operation with an output schema, the description conveys the basic purpose, but it lacks details about duplicate handling, prerequisites, and parameter usage. With no annotations and incomplete parameter guidance, it is only minimally viable.

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

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

Schema description coverage is 0%, and the description does not mention 'job_id' or 'notes'. While the schema defines required fields and defaults, the description adds no meaning about what values to pass or how they affect the saved 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?

The description uses a specific verb ('Save') and identifies both the source ('from the latest search results') and destination ('to the local tracker'), making it clear what the tool does. This also distinguishes it from siblings like 'add_job' or 'list_saved_jobs' by specifying the origin of the 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 phrase 'from the latest search results' implies when to use this tool, but the description does not explicitly state when not to use it or mention alternatives such as 'add_job' or 'update_job_status'. It provides context but lacks exclusionary 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?

With no annotations, the description carries the full burden. It explicitly discloses the destructive behavior ('Replaces any previous version') and the LaTeX format, which are critical traits. It does not cover permissions or error handling, but for a simple save tool these are minor gaps.

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 plus a concise Args list. Purpose and replacement behavior are front-loaded, and every parameter explanation is direct and useful with 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 tool is simple and the description covers purpose, key behavior, and all parameters. An output schema exists, so return values need not be detailed. The description is complete enough for an agent to select and invoke 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 0%, so the description fully compensates by explaining all three parameters: job_id targets the job, content is the complete LaTeX document, and extension defaults to 'tex' with guidance. This adds essential meaning beyond the bare 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?

Description clearly states the tool stores a tailored resume as LaTeX and replaces any previous version for the job. The verb 'Store' with resource 'tailored resume for a job' is specific and distinguishes it from siblings like get_tailored_resume 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?

Provides clear context that this tool persists a tailored resume for a specific job and overwrites previous versions, which is a key usage consideration. It does not explicitly name alternatives or exclusions, but the context is sufficient for selecting this tool over related ones.

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?

No annotations are present, so the description must carry the behavioral burden. It does explain how each filter behaves (e.g., 'matched against title, tags, company and description', 'comma-separated tags that must all be present'). It also states the 'limit' controls maximum listings. However, it does not disclose side effects, ordering, or what happens with an empty query. For a read-only search tool, this is acceptable but not comprehensive.

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 concise and well-structured: a one-line purpose followed by a clean bullet list of parameters. Every sentence adds value, with no filler or repetition. The front-loaded purpose allows quick comprehension.

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 search tool with 5 optional parameters and an output schema, the description covers all necessary invocation details: each parameter's meaning and behavior. It does not explain return values, but the output schema likely covers that. The only missing element is explicit usage guidance, which is tracked separately. Overall, it is complete enough for an agent to select and invoke 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 0%, so the description is the sole source of parameter meaning. It provides rich semantics for all five parameters: 'query' specifies fields matched, 'location' is a substring filter, 'tags' must all be present, 'source' restricts to specific sources, and 'limit' caps results. This fully compensates for the schema's lack of 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 opens with a clear, specific verb and resource: 'Search job listings.' This distinguishes it from sibling tools like get_job_details (fetch one listing) and list_saved_jobs (show saved listings). The purpose is immediately understandable and non-tautological.

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 implies usage through its parameters (e.g., filtering by query, location, tags) but does not explicitly state when to use this tool over alternatives or mention any exclusions. No sibling alternatives are called out. The context is inferable from the name and parameter semantics, but explicit guidance is absent.

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?

No annotations are provided, so the description carries the full burden. It explains the effect (sets default resume) but doesn't mention persistence, overwriting, error handling, or validation requirements. Minimal but adequate for a simple setter.

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

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

A single clear sentence with no filler. The verb and object are front-loaded, and every word 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 simple one-parameter tool, the description gives essential context, but with no parameter documentation and no annotation coverage, it leaves ambiguity about the 'name' parameter and success/failure behavior. The output schema exists but is not described.

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 single parameter 'name' has no schema description and 0% schema description coverage. The tool description implies it refers to a resume, but doesn't specify what value is expected (exact name, ID), nor whether it must reference an existing resume.

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 specific action (choose/set) with a clear resource (default resume) and context (when tailoring call does not specify one). It distinguishes itself from sibling resume/job tools by focusing on the default-selection behavior.

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?

Description clearly indicates when this tool is applicable: when a tailoring call does not name a resume. It doesn't enumerate exclusions or alternatives, but the context is well-defined.

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?

No annotations are provided, so the description carries the full burden. It discloses the main behavior (replacing the description), but does not mention consequences such as overwriting existing text, whether the job must already exist, or any permission requirements. It adds some context beyond the schema but lacks depth for a mutation 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?

The description is two sentences with no filler. The first sentence states the action, and the second explains when it is useful. It is front-loaded and every word 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 simple update tool with two string parameters and an output schema, the description covers the key aspects: what it does and when to use it. It does not explain error cases or side effects, but the output schema likely handles return values. The description is sufficient for this level of complexity.

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 compensate for the bare schema. It implicitly explains that job_id identifies a saved job and description is the pasted full text. This adds meaningful context beyond the parameter names, though it could be more explicit about formats or constraints.

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: 'Replace the description of a saved job with pasted text.' This uses a specific verb and resource, and it distinguishes itself from sibling tools like save_job (which adds a new job) and delete_saved_job (which removes a 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 a clear use case: 'Useful when the listing was saved from a feed with a truncated or empty description and you have the full text.' This provides context for when to use the tool, though it does not explicitly mention when not to use it 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?

With no annotations, the description carries the burden of behavioral disclosure. It accurately explains that the whole document is embedded in the link, making it self-contained and usable offline. It does not mention permissions or error handling, but for a simple retrieval tool this is adequate.

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, front-loaded with the main purpose and a key behavioral detail. There is no filler or redundancy.

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

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

The tool has a simple input schema and an output schema, so the description need not explain return structure. It covers the essential behavioral aspect (data URI embedding) and is sufficiently complete for a low-complexity tool.

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

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

The single parameter job_id has no schema description and the tool description does not elaborate on it. However, the name is self-explanatory in context, and the tool is simple. The description adds minimal parameter meaning beyond what the schema provides.

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

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

The description clearly states the tool's function: returning the tailored resume for a job as a base64 data: URI. The verb 'Return' plus the specific resource and format make it distinct from sibling tools like get_tailored_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?

The description provides clear context for when to use this tool: when a self-contained link that can be pasted and downloaded without the server running is needed. However, it does not explicitly name alternatives or exclusions.

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

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

With no annotations, the description carries full responsibility for disclosing behavior. It explains the return format (must-have/frequent term split, resume text, LaTeX), the conditional LaTeX/source handling for .tex resumes, and that the tool does not save (must call save_tailored_resume). This is detailed and transparent beyond what schema or annotations could provide.

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 efficiently structured: a purpose statement, behavioral details, workflow note, and parameter descriptions. Every sentence earns its place, with no fluff or repetition. The front-loaded purpose makes it easy to grasp quickly.

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 tool's complexity (sibling tools for saving/retrieving, conditional behavior, output schema), the description provides a complete picture: what it produces, how it handles different resume formats, and the expected next step. It fully prepares an agent to invoke the tool and integrate it with the broader workflow.

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

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

Schema description coverage is 0%, so the description must compensate. It explains both parameters: job_id is sourced from search_jobs, add_job, or list_saved_jobs; resume is a stored resume name with an empty default. This adds meaningful context (source and default behavior) that the schema lacks.

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's function: building a tailoring brief by matching job requirements against a stored resume. It specifies the verb ('build'), the resource ('tailoring brief'), and the key output components, distinguishing it from related tools like save_tailored_resume and get_tailored_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?

The description provides clear context for when to use the tool: before writing a tailored CV, with a next-step instruction to save via save_tailored_resume. It does not explicitly contrast with alternative tools (e.g., get_tailored_resume), but the workflow is well-defined and the description of the stored resume handling gives practical usage 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It says 'Update' which implies a mutation, but it does not explain whether notes are overwritten or appended, what happens if the job_id does not exist, or how invalid statuses are handled. It lacks details on side effects, idempotency, or error conditions, leaving significant behavioral gaps.

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 concise sentences: the first states the action, the second lists valid statuses. There is no fluff or redundant information. It is front-loaded and every word 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?

The tool is relatively simple and the description covers purpose and valid statuses. However, it omits behavioral details like prerequisites, side effects, and error handling, which are not covered by annotations. The presence of an output schema likely handles return values, but the description still feels incomplete for a mutation tool. It is adequate but with clear gaps.

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 0% description coverage, so the description must compensate. It does by identifying that 'status' and 'notes' are the updatable fields and 'job_id' is the target job. It also lists all valid statuses, which is a critical constraint not present in the schema. This adds meaningful value beyond the bare parameter names.

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's function: 'Update the application status and/or notes of a saved job.' It specifies the exact fields it modifies (status and notes) and provides the list of valid statuses, which differentiates it from sibling tools like set_job_description or save_job. The verb+resource structure is specific and unambiguous.

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

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

The phrase 'of a saved job' implies this tool is for existing jobs, giving some context that it's not for creating or searching. However, there is no explicit statement about when to use this versus alternatives, nor any mention of when not to use it. The guidance is implied rather than stated, so it scores at the implied-usage level.

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