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

Annotations already declare mutability, idempotency, and non-destructiveness, but the description adds behavior annotations cannot express: it consumes application credits, is capped at 50 jobs per call, and — critically — that 'queued' or 'waiting_credit' status does not mean the application was actually submitted. That async-outcome warning is high-value disclosure. It still doesn't say how to detect the true final state or what happens on credit exhaustion.

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?

Three short, front-loaded sentences with no filler. The scope/cost constraint comes first, the retry rule second, and the status caveat last — a sensible ordering with nothing wasted.

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?

An output schema exists, so return structure needn't be explained, and the status vocabulary (queued, waiting_credit) is at least named. But for a credit-spending mutation, the description omits the credit cost per job, insufficient-credit behavior, and how to follow up on pending submissions, leaving meaningful 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?

Schema description coverage is 0%, so the description must compensate. It clarifies the 50-item cap on jobs and the retry semantics of idempotency_key, which map directly to the two required parameters. However, allow_repeat_companies receives no explanation at all, and the format of jobs (hex job IDs from search_jobs) is left implicit.

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 action (queue up to 50 job applications) and resource (jobs, using application credits), and the final sentence disambiguates the confusing name by clarifying that submission is asynchronous. It doesn't explicitly contrast with siblings like list_applications or get_application, but the verb+resource pair is specific enough to distinguish it.

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 gives one concrete operational rule — reuse the same idempotency_key on retries — which is genuine usage guidance beyond the schema. However, it never says when to prefer this over alternatives (e.g. use find_matches/search_jobs first to obtain valid job IDs) or what to do when credits run out, so usage is only implied.

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