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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful clarification — that this does not grant roles or approval authority — but says nothing about the destructive replace semantics (which fields are overwritten vs preserved), how version conflicts surface, or when to reuse idempotency_key on retry.

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?

Two tight sentences with the resource scope front-loaded and the boundary condition second; no filler or redundancy. It is arguably undersized for a nine-parameter destructive write, but that shortfall is penalized under contextual completeness rather than here.

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 destructive, non-idempotent mutation with six required parameters, a mandatory version for optimistic concurrency, and no output schema, the description leaves too much implicit. It never explains what happens on a version mismatch, whether omitting task_mode preserves the saved rule, or what the return value confirms — an agent could easily call this wrongly.

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 22% (task_mode and idempotency_key only), so the description must compensate and largely does not. The phrase 'new issues, plan reviews and human tasks' implicitly maps to issue_mode/review_mode/task_mode, but company, version, issue_members, review_members and task_members — including the 100-item cap on each array and the optimistic-concurrency meaning of 'expected version' — get no explanation.

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 ('Save') and resource ('automatic routing') and enumerates the three routing categories it governs: new issues, plan reviews, human tasks. It is clearly the write counterpart to summer_work_routing_read, though the sibling is never named explicitly.

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?

There is no guidance on when to call this versus summer_work_routing_read or the adjacent summer_cases_assignment_update / summer_human_tasks_update tools. The one constraint given ('Does not grant roles or approval authority') limits scope but does not tell the agent when this tool is the right choice or what prerequisite steps (reading current routing to obtain the version) are required.

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