get_timing_paths

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

With no annotations, the description carries the full behavioral burden. It does disclose the default output shape (structured summary) and that higher detail levels add raw text, which is genuinely useful. It omits prerequisites (timing paths only exist after synthesis/implementation), the read-only nature is only implied by 'Get', and it doesn't warn that detail_level=full returns large raw text.

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?

Two short sentences, zero filler, with the core purpose front-loaded and the output-shape note immediately after. Every clause earns its place.

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?

For an 8-parameter, zero-required tool with no annotations and no output schema, the description covers purpose and the detail_level axis but leaves the agent without prerequisites, expected return structure, or volume expectations. Adequate to invoke, not adequate to invoke confidently.

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 baseline is 3, but the description adds meaning the schema lacks: it explains what detail_level actually changes in the response ('the raw text too'), whereas the schema only enumerates the values. It still says nothing about clock/from_pin/to_pin/through filter interaction or num_paths/slack_threshold behavior beyond the schema.

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 (get failing/critical timing paths), which is concretely distinguishable from the sibling get_timing_summary in scope. However, it never names or contrasts with that sibling explicitly, so an agent must infer the boundary itself.

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 second sentence gives useful guidance on the detail_level axis (default summary, escalate to standard|full for raw text), which is real usage direction. But there is no guidance on when to pick this over get_timing_summary, get_clocks, or report_qor_assessment, and no stated prerequisites such as requiring a synthesized/implemented design.

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