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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantive behavior the annotations cannot convey: results are precomputed verified values from real engine runs, not live computation, and must be quoted verbatim without rounding. This anti-fabrication constraint materially changes how the agent should handle the output.

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?

Front-loaded with the capability, then the anti-fabrication rule, then the re-call rule — each sentence carries a distinct instruction. Slightly undercut by "All eight chapters" when the enum lists ten values including the two cmp-* entries, a small internal inconsistency that could confuse the agent.

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?

With one optional parameter, no output schema, and read-only annotations, the definition covers what the agent needs: what is computed, that results are canonical, and how to handle follow-ups. The only gap is the chapter-count mismatch, which is minor against the otherwise complete picture.

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 100% and the chapter enum is documented in detail (track meanings, defaults, format). The description adds nothing beyond the schema about the parameter, 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?

States a specific verb and resource ("Single Run bottleneck analysis for the selected chapter") and enumerates what is computed: worst-availability node, per-interrupt downtime split, throughput, OEE. The "Single Run" scoping implicitly separates it from compare_chapters, but no sibling is named outright.

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?

"For follow-ups about the same chapter, re-call this tool" is an explicit usage rule that prevents the agent from answering from memory. However, there is no guidance on when to prefer compare_chapters or get_chapter_facts instead, so the alternative-selection half of the guidance is missing.

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