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

Despite annotations only carrying generic CRUD hints, the description discloses the full behavioral profile: it creates a NEW vacancy, runs asynchronously and returns an analysis_id immediately, is polled via get_vacancy_detail (~10s), returns cached 'completed' results without spending quota unless resume/self-description changed, and emits 'not_found'/'limit_exceeded' errors. It also states it consumes one vacancy analysis against the plan — a cost/rate detail annotations do not capture.

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

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

Front-loaded with the core action and its routing constraint in the first sentence, then layers dedup, async, storage, and error semantics. Dense but every clause carries a distinct, actionable fact 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?

For an async mutating tool with a nested schema and an output schema, this covers the lifecycle (trigger → poll → result), cost, dedup/force, persistence of inputs, and failure codes. An agent has everything needed to invoke, poll, and handle errors 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 nested input schema documents each field, but the description adds meaning beyond it: company/location/url are persisted on the vacancy and make it findable via search_vacancies(location=...), resume_id defaults to the active resume, and force controls re-execution. This is genuine semantic value on top of the schema's field-level docs, though the individual param mechanics are largely already covered.

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+resource ('Analyze the text of a job posting... against a resume') and immediately scopes it to postings 'not in ResumeQuick yet'. It explicitly names the two sibling tools that handle the adjacent cases (analyze_tracked_vacancy, analyze_radar_match), so an agent can route correctly without opening any 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?

Gives explicit when-to-use (posting text not yet tracked), when-not (already tracked → analyze_tracked_vacancy; radar match → analyze_radar_match), and the dedup rule with the force=true escape hatch. Nothing about selection is left to inference.

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