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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral value beyond that: the derived-vs-stored 'overdue' status trap where a returned value is rejected by the status filter, default page size, and an inventory of returned job fields. This is exactly the kind of disclosure that prevents agent errors.

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?

Four sentences with the purpose front-loaded and the critical warning flagged with 'IMPORTANT' at the end. Every sentence earns its place, though the final sentence is slightly wordy ('ask for status scheduled and read each job's returned status').

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?

Despite having no output schema, the description inventories the returned job fields (printer, priority, scheduled date, task progress, assignees, linked problems), explains pagination behavior, and surfaces the one real footgun. Combined with the fully-covered schema and safety annotations, nothing an agent needs to call this correctly is missing.

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 100% and the schema itself is already rich — it documents the status filter rejecting 'overdue', page_size defaults to 10 with max 100, printer_id taking precedence over printer_ids, and search substring semantics. The description mostly re-states the page_size default, adding little beyond the schema, so the baseline 3 applies.

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 opening sentence names the verb (List), resource (maintenance jobs), scope (across the account), and capabilities (filters, paging, sorting). The use-case framing 'what maintenance is outstanding, and on which printer' clearly distinguishes it from get_maintenance_job (single job) and get_maintenance_dashboard (overview).

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?

Positions itself as 'the tool for' list-style maintenance queries and explicitly routes the overdue-count use case to the dashboard, naming an alternative. It doesn't enumerate when to prefer get_maintenance_job or list_maintenance_problems, but the niche is clearly implied.

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