solve_timer

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

Beyond the annotations (readOnly=false), it discloses that the tool injects results into the plan (a mutation), how it handles exact/inexact/unrepresentable targets, and that unknown timers are surfaced rather than guessed. This is rich, non-obvious behavioral context that the structured fields do not provide.

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 core purpose, then workflow and behavior. Mostly earns its space, though minor jargon ('Pillar D Tier 3') adds little. Slightly dense but well-organized.

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 no output schema, the description carries the return-value burden and does so: it explains the result shape (zero-error PSC/ARR, closest pair with achieved frequency and ppm error) and the downstream effect on render_framework. Nothing essential for correct invocation 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%, so parameters are already documented (baseline 3). The description adds the relationship between parameters, describing timer_clock_hz as a what-if bypass of clock derivation and target_hz as an override path, which sharpens usage beyond the schema text.

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 ('Solve a timer's Prescaler/Period'), names the exact intent-to-registers transformation, and clearly distinguishes itself from siblings solve_clock_tree and design_framework. An agent can tell immediately what this produces.

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?

Gives explicit sequencing: record a target via design_framework, run solve_clock_tree first, or pass timer_clock_hz directly for a what-if. This routes the agent between prerequisites and an alternative path with no inference required.

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