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

No annotations are provided, so the description carries the full burden. 'Build' implies a generative/mutating operation, but the description says nothing about required permissions, whether it depends on prior resume-import state, idempotency, generation latency, or side effects such as overwriting a prior PDF. Only the output artifact type (PDF) is 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?

A single short sentence with the verb and resource front-loaded and zero filler. It is efficient, though the extreme brevity is partly a symptom of under-specification rather than disciplined trimming.

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

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

With no annotations, no output schema, and 0% parameter schema coverage, the description is the only source of information, and it omits the job_id's origin, ordering relative to the import_resume_* siblings, and any prerequisite state. For a build/generation tool in a workflow with prepare/submit steps, that is a meaningful completeness gap.

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

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

Schema description coverage is 0% and the single parameter job_id has no description in either the schema or the tool description. The phrase 'for a job' hints that job_id identifies a job, but the description does not explain where that id comes from (e.g. list_jobs/job_details) or whether it must exist beforehand.

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 (Build) and a specific, well-scoped resource (the tailored PDF resume for a job), which is enough to distinguish it from the query siblings (find_jobs, list_jobs, job_details) and the import siblings. It stops short of explicitly naming how it differs from the import_resume_* tools, so it lands at 4 rather than 5.

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

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

There is no statement of when to use this tool versus alternatives, no prerequisites (e.g. whether a resume must first be imported via import_resume_prepare), and no exclusions. The only guidance is implicit: the tool builds a resume for a job, so it is presumably called with a job_id.

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 that problems include fix hints, but says nothing about whether the check is read-only, what permissions are needed, or how results are structured beyond the hint.

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

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

A single, front-loaded sentence that avoids waste. It is efficient, though the second clause is somewhat vague and could be more specific about output.

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 no annotations, no output schema, and an undocumented parameter, the description is too sparse. It omits when to use the tool, what the parameter does, and any behavioral details beyond the existence of fix hints.

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 the sole parameter 'check_sites' at all. With no explanation of what the boolean controls, the agent cannot infer its effect from the description.

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

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

States a specific verb ('Check') and resource ('installation and settings'), distinguishing it from the job/resume/config sibling tools. The added note that problems come with fix hints clarifies the diagnostic nature, though it does not explicitly differentiate from all siblings.

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 no guidance on when to use this tool versus alternatives. The mention of fix hints implies troubleshooting, but there is no explicit trigger condition, prerequisite, or alternative tool named.

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 behavioral burden, yet it only hints that a search may still be running. It never states whether the call blocks, what it returns (new results vs. status), whether it writes data to the site, or rate-limit/auth constraints.

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

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

A single tightly-worded sentence with the primary action front-loaded. It wastes no words but is under-specified rather than genuinely concise.

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?

A two-parameter search tool with no annotations, no output schema, and undocumented parameters needs more than one parenthetical sentence to be callable 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?

Both parameters have 0% schema description coverage, so the description must compensate and does not: 'source' is never mentioned, and only the phrase 'check on a search already running' loosely gestures at the polling semantics of wait_seconds.

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

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

States a specific verb and resource ('Search the job sites'), so an agent can tell it initiates a job search. It doesn't differentiate itself from siblings like list_jobs or job_details, which is where it falls short of a 5.

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

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

The parenthetical '(or check on a search already running)' implies two usage modes — trigger a new search or poll an in-flight one — but names no alternatives or selection criteria against siblings such as list_jobs or job_details.

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 behavioral burden. It usefully discloses that the call returns 'the prompt to follow' rather than completing an import, but says nothing about whether it writes files, what permissions are needed, or whether it is safe to re-run.

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

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

A single front-loaded sentence with the action first and the input clarification parenthetical immediately after. 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?

For a one-parameter tool with no output schema, the essentials are covered, but as the opening step of a prepare/submit pair the description omits the follow-up step and any indication of what the returned prompt expects. An agent can call it, but not confidently place it in the 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 coverage is 0% and the parameter name 'docx_path' is misleading, so the description earns real credit by stating it is the path to either a .docx or PDF file. It still omits path format (absolute/relative) and validation behavior.

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 ('Start a resume import from a Word (.docx) or PDF file') and clarifies the accepted input formats. It does not explicitly name the sibling it hands off to (import_resume_submit_tex), so sibling differentiation is only implied by the prepare/submit naming.

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 word 'Start' implies this is the first step of a flow, but the description never says when to use it versus import_resume_submit_tex or build_resume, nor what happens next. Usage must be inferred from the two-step naming convention.

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 behavioral burden, and it undersells the operation: 'Check' reads as a read-only comparison, yet the tool is named submit_tex and exposes an accept_if_ok flag that implies the check can commit or accept the imported resume. Nothing is said about side effects, what a mismatch does, or reversibility.

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

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

A single front-loaded sentence with no filler. It is appropriately short, though the brevity is achieved partly by omitting needed information rather than by tight writing.

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

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

With no annotations, no output schema, 0% schema coverage, and an undocumented side-effecting flag, the description leaves an agent unable to call this correctly or predict its effects. It should at minimum explain what a successful check returns and what accept_if_ok does.

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

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

Schema description coverage is 0% for both parameters. The description loosely implies the 'tex' input is the LaTeX file under test, but it never explains the required tex string's format or the accept_if_ok flag at all, which is the one parameter with real behavioral consequence.

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 concrete action (check/compare) on a specific resource: the LaTeX version of an imported resume against the source Word/PDF. This places it in the import_resume_* workflow and separates it from siblings like build_resume or import_resume_prepare, though it never names a sibling explicitly and the name's 'submit' verb is not reconciled with the description's 'check'.

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

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

No when-to-use guidance, no stated prerequisites (presumably a prior import_resume_prepare call), and no indication of what to do if the check fails. The agent must infer the whole position of this step in the workflow from the 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 behavioral burden and does not meet it. It never states that this is a read-only operation, what happens with an invalid or unknown job_id, or whether any authentication/configuration is required. It partly discloses returned content ('description and keyword match') but nothing about side effects or failure modes.

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 compact sentence with no filler, and the scope ('one job') is front-loaded before the content hint. It is efficiently sized, though brevity here edges into under-specification rather than crispness.

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 one-parameter lookup with no annotations and no output schema, the description minimally suffices: it says what the tool returns in broad terms. But with no output schema to fall back on, it should have enumerated the returned fields more concretely and explained the input identifier, so gaps remain.

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 single parameter (job_id, string) has no description. The tool description mentions 'one job' but never explains the identifier's format or where the agent should obtain it (presumably from find_jobs/list_jobs), so it does not compensate for the coverage gap.

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

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

The phrase 'Everything about one job' identifies the resource and its scope (a single job), implicitly distinguishing it from collection tools like find_jobs and list_jobs. However, it uses a vague catch-all ('everything') instead of a specific verb such as 'retrieve' or 'get', and it never names a sibling explicitly.

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

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

There is no statement of when to call this tool versus find_jobs, list_jobs, or mark_job, and no prerequisites (e.g. that a job_id must first come from find_jobs). The only usage signal is implicit: the singular resource suggests lookup after a search, but nothing in the text says so.

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 behavioral burden, but it only discloses the default ordering ('best match first'). It says nothing about pagination, whether hidden jobs are excluded by default, required auth, or what fields come back — notable gaps for a 6-parameter read tool.

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

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

A single front-loaded sentence with zero filler is structurally clean. However, the brevity comes at the cost of under-specification rather than efficiency, so it is only adequate.

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

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

For a 6-parameter tool with no annotations and no output schema, the description gives an agent almost nothing beyond the ordering default. Missing are the meanings of the filter/sort parameters, pagination behavior, and the distinction from find_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?

Schema description coverage is 0% across 6 parameters, so the description must compensate and largely fails. 'Best match first by default' weakly hints at the sort parameter's default, but search, status, min_match, limit, and show_hidden are left entirely undefined in both the schema and the description.

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

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

States a specific verb ('List') and resource ('saved jobs'), plus a scope hint that saved jobs are the domain. It does not differentiate from the sibling find_jobs, so an agent cannot tell from the description alone whether listing and finding are the same operation.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as find_jobs or job_details. The only implicit signal is the verb 'List' itself, which is the bare minimum.

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. 'Set status' implies a mutation, but it never states whether the change is idempotent, whether it can overwrite an existing status, what permissions are needed, or what happens on an invalid job_id — all material for a write tool.

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

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

A single terse line with no filler, and the enumerable values are placed immediately after the verb. It is efficient, though it borders on under-specification rather than deliberate brevity.

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 two-parameter mutation tool with no annotations, no output schema, and no schema descriptions, the definition leaves too much unspecified: the effect of the operation, idempotency, and failure behavior are all missing.

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

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

Schema coverage is 0%, so the description must compensate. It does add real value by enumerating the accepted status values, which the schema does not encode as an enum. However, job_id is left entirely unexplained, so coverage is only partial.

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

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

The description gives a specific verb (Set) and the resource being changed (a job's status), and the enumerated values make the intent unambiguous. It does not, however, distinguish itself from siblings like find_jobs or job_details beyond the implicit fact that it mutates rather than reads.

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

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

There is no statement of when to use this tool versus the sibling tools, no preconditions, and no exclusions. The only guidance is the list of accepted status values, which is parameter information rather than usage routing.

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

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

With no annotations, the description carries the full burden. It usefully discloses two behaviors beyond the schema: partial-update semantics (only passed fields change) and that the prior file is preserved as config.yaml.bak. However, it omits permissions required, whether relative or absolute path resolution, and whether filters affect already-recorded jobs.

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

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

Two short sentences, zero padding, and the core action and file target are front-loaded. Every clause carries information, including the backup behavior in the second sentence.

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

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

For an 8-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage, this is too thin. Key details an agent needs — value formats, matching semantics for include/exclude lists, units for max_age_days, and the effect of changes — are absent from both the description and the schema.

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

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

Schema description coverage is 0% across 8 parameters, so the description must compensate and does not: it never explains job_types, languages, locations, max_age_days, or the include/exclude list semantics. Nothing is added beyond the self-descriptive parameter names, and the numeric max_age_days unit and string-match rules are left undefined.

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

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

The description names a specific verb and resource: 'Change the job filters in config.yaml'. It is unambiguous about what is being modified, though it does not differentiate itself from siblings (which are mostly job/resume tools) or note relationships to diagnostic tools like doctor.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of when not to use it. The parenthetical '(only the fields you pass)' describes merge behavior rather than usage context, so an agent gets no routing help from this sentence.

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