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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the description is free to add real value: results are paginated, the target API is the SmartShifts organization workforce API, and provider record text should be treated as untrusted data rather than instructions. That last line is a meaningful prompt-injection disclosure not present in annotations.

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 compact sentences, front-loaded with the core capability, followed by pagination and safety notes. Nearly every sentence earns its place, though the API/documentation references are somewhat boilerplate.

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?

Output schema exists, so return values need not be explained, and annotations cover the safety profile. However, with a required jobId that is nowhere described, an agent lacks enough information to invoke the tool correctly in non-obvious cases.

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 carry parameter meaning, but it only hints that 'results paginated' implies limit/offset. The required jobId is never explained—no format, no source, no example—leaving the most important parameter undocumented in both schema and description.

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: read saved workflow progress including rows/steps, errors, totals and receipts. This distinguishes it from generic siblings like system_read or system_audit, though it never names the closest alternative (system_operation_status) 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?

No explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The only pointers are documentation links (/mcp, smartshifts://policy), which are references rather than selection criteria. Usage is only implied by the word 'saved workflow progress'.

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