get_manual_reference

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

The annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds the useful fact that this is a static reference lookup, but it does not explain how 'edition differences' are surfaced despite zero parameters, nor how complete or current the manual content is. Adequate, not rich.

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?

A single front-loaded sentence with no filler; every element of the noun list maps to real returned content. It borders on a dense enumeration rather than a structured statement, but nothing is wasted.

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 an output schema present, return values need no explanation, and zero-parameter, read-only annotations mean little else is required. Remaining gap: whether the content is static manual excerpts versus generated, and how edition scope is determined.

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?

The tool takes no parameters, so per the baseline rule the schema carries no semantic burden the description must offset. The only residual gap is that the description doesn't clarify why an edition-agnostic, parameterless call can report 'edition differences'.

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 verb 'Get' plus the resource 'manual reference' is specific, and the description enumerates the three content areas (operand maxima, edition differences, RTC register/control procedures). It is distinguishable from data-generating siblings like generate_ldr or simulate_ladder, though it never contrasts itself with the closely related get_design_guide.

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?

The listed content areas imply when the tool is relevant (looking up manual limits or RTC register procedures), but there is no explicit when-to-use, no exclusions, and no pointer to get_design_guide or get_instruction_capabilities as the alternative for adjacent lookups. Usage is left to inference.

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