start_jobs

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

The description adds meaningful behavioral context beyond the annotations: atomicity of validation, queueing semantics (jobs are not executed synchronously), and that only metadata is returned immediately (implying results must be fetched later). This aligns with readOnlyHint=false/destructiveHint=false and helps the agent set follow-up expectations.

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?

One dense 11-word sentence that front-loads the core action (atomic validate, queue) and the key consequence (immediate metadata return). No filler words or redundant restatements of the name.

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?

The description adequately covers the tool's headline behavior and the output schema presumably documents the return metadata, so return format is not a gap. However, for a tool with a complex nested JobRequest (six sub-fields, including worker_profile that a sibling lists) and asynchronous queue semantics, the description leaves out what happens on validation failure and how to follow up on results, which the agent must infer.

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 for undocumented parameters, but it only restates 'multiple jobs' and says nothing about the JobRequest sub-fields (task, worker_profile, timeout, scope_paths, output_schema, evidence_budget). The schema's titles and defaults carry the entire semantic burden, and the description adds no meaning to them.

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 uses a specific verb ('queue') and resource ('multiple jobs') and adds behavioral detail — 'atomically validate' and 'immediately return metadata' — that goes well beyond a generic verb+noun phrase. The plural form implicitly distinguishes this from the sibling start_job without opening either 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?

The phrase 'multiple jobs' implies a batch use case and suggests preferring this over start_job for bulk operations, but the description never explicitly says when to choose this tool versus start_job, gets, or cancels. There is no when-not guidance or mention of alternatives.

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