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

Goes well beyond the destructiveHint annotation: real applications are submitted in the person's name, the run counts against the plan, jobs already applied to are never reused, and `dry_run=true` does everything except submit. It also discloses prerequisites. No contradiction with the annotations.

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

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

The description is dense but every sentence earns its place: it packs the action, selection logic, tailoring, screening-answer source, submission, consequences, prerequisites, dry-run mode, and next step in a compact block. No filler or repetition of schema defaults.

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 complex, destructive, asynchronous-looking action with five parameters and no output schema, it is remarkably complete: it covers what happens to each job, what is needed before calling, what side effects occur, the safe testing path, and the follow-up endpoint. The only implicit piece is the exact return value, but the explicit 'Poll get_apply_run_status' instruction covers what the agent needs next.

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 only 60%, and the description compensates for the two undocumented parameters: it clarifies `limit` as the cap on how many jobs are taken and defines `dry_run` as 'everything except submit'. The `job_id` override behavior is already documented in the schema; the description's mention of 'same filters as list_matching_jobs' adds context for `fresh` and `match`.

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 action ('Start an application run') and a specific resource (matching jobs), then nails the scope: up to `limit`, best-fit-first, never already applied, with submission inside the employer's system. It separates itself from the sibling `list_matching_jobs` (same filters but actual submission) and names `get_apply_run_status` as the follow-up.

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

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

It clearly frames when to call it: to actually apply to matching jobs, and it gives the safety path `dry_run=true` to test without submitting. It also states prerequisites (confirmed email, active plan) and points to polling. It stops short of explicitly enumerating 'use list_matching_jobs to preview first' or 'use stop_apply_run to cancel', but the context makes the primary use unambiguous.

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