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

With no annotations, the description carries the full burden of behavioral disclosure. It delivers thoroughly: explains the scoring formula (+2 tag overlap, +3 salary overlap, etc.), states the tool is free, reveals identity requirements ('without identity', 'verified key required only to save an approval-bound artifact'), and clarifies that the employer outcome pilot never affects matches. This goes far beyond a typical description.

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 three sentences long and front-loaded with the primary purpose. Each subsequent sentence adds relevant detail (scoring, costs, identity, follow-up tool). It wastes no words, though it is slightly longer than necessary and could be more succinct by trimming the secondary caveats.

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 8 parameters, no output schema, and no annotations, the description is quite complete: it covers purpose, scoring logic, cost, identity requirements, and a related follow-up action. The main gap is that it does not describe the return format or expected output structure, which would be useful for a ranking tool. Still, the behavioral and parameter context is unusually rich.

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 63%, leaving 37% of parameters without schema descriptions. The description compensates by mapping scoring components to parameter groups: 'tag overlap' refers to skills, 'salary overlap' to salary_min/max, and 'workplace/level/type/location matches' to those respective parameters. This adds meaningful context beyond the schema, though it does not explain individual parameter formats or limits beyond what the schema already 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: 'Rank active AI/ML jobs against a candidate profile for free.' This is a specific verb ('rank'), resource ('AI/ML jobs'), and target ('candidate profile'), and it distinguishes match_jobs from sibling tools like search_jobs and get_similar_jobs by emphasizing profile-based scoring.

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 some usage context by mentioning compile_job_specific_resume as a follow-up after selecting a role, but it does not explicitly state when to use match_jobs versus alternatives like search_jobs or analyze_application_readiness. The intended use is implied rather than explicit, so exclusions and alternatives are missing.

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