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

Adds real value beyond the annotations: concurrent and repeated requests coalesce, request_id must be reused on retry, and the existing schedule is unaffected. Note that idempotentHint=false combined with coalescing is complementary rather than contradictory (idempotency through request_id, not intrinsic). But it never explains why destructiveHint=true or what side effects a run has, so the destructive profile is left to the annotation alone.

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 sentences, each carrying new information: what the tool does, the coalescing/retry semantics, and the schedule invariant. The action is front-loaded with zero 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 a 6-parameter destructive mutation with no output schema and near-zero schema documentation, the description covers retry/coalescing well but leaves the agent without guidance on expected_revision (likely a conflict check) or on what a successful response returns. Adequate, with clear gaps an agent could trip over.

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 only 17%, so the description should compensate, but it explains only request_id (reuse on retry) and implies 'job' is a job identifier. expected_revision — a required concurrency-control parameter with an exclusiveMinimum constraint and no schema description — is completely unaddressed, as are company and environment.

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 and resource: 'Request one run of an enabled scheduled job'. An agent can distinguish this from siblings like summer_scheduled_jobs_runs (read run history) and summer_scheduled_jobs_save (create/edit a job). It doesn't name any sibling explicitly, so it stops short of a 5.

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?

'Enabled scheduled job' implies the single precondition, and 'reuse request_id on retry' is a concrete usage instruction. However, it never says when to reach for this tool instead of summer_scheduled_jobs_runs or summer_scheduled_jobs_history, nor what to do if the job is disabled or the expected_revision is stale.

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