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

With no annotations, the description carries the load, and it does well: it discloses that only names are returned ('Returns names only'), not descriptions or options, and points to the remedy. It does not state read-only semantics explicitly, but the read-only nature is strongly implied by the query-style behavior.

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 short sentences, front-loaded with the return value and followed by usage and follow-up guidance. No filler.

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?

An output schema exists, so return-value detail is not required, yet the description still clarifies that only names come back. Combined with usage triggers and glob examples, nothing an agent needs to call this correctly 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 0% for the single pattern parameter, so the description must compensate; it does so with concrete glob examples ('*power*', 'report_*'). It stops short of describing the default or pattern syntax rules, but the examples convey the intended format.

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 precise verb+resource: returns OpenSTA command names matching a glob pattern. It is clearly distinguishable from siblings like run_tcl and report_timing, and the glob examples make the scope immediately concrete.

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 two explicit trigger conditions ('you do not know a command's name' or 'run_tcl answered "invalid command name"') and a named follow-up action (run_tcl "help <name>"). The agent knows both when to call this and what to do next.

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

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

With no annotations, the description carries the full burden and does well: it discloses that answers come from the session journal, so earlier states remain readable even after sta died. That persistence/source detail is genuinely useful behavioral context. It does not mention permissions, cost, or error behavior, so a 4 rather than 5.

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?

Four sentences, front-loaded with what the tool returns and followed by the actionable usage rule and the persistence caveat; little waste. The enumeration is dense and the line-break artifact mid-sentence slightly hurts flow, but overall it is efficient.

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?

An output schema exists, so return-value explanation is not strictly required, yet the description still conveys the content shape and the crucial `state` usage rule plus journal-backed persistence. For a one-parameter read tool this is close to complete, with only edge details (valid state range, post-restart behavior) 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 description coverage is 0% for the single `state` parameter, so the description must compensate and largely does: it explains to pass the n from "[conditions #n]" or 0 for current state. It does not state the default or the range of valid n values, leaving a small gap.

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 description gives a specific verb (retrieve/see) and a well-defined resource: the analysis conditions behind a result, enumerated as Liberty, netlist, SDC, SPEF files, run_tcl constraint changes, switching-activity source, and scenes. It does not explicitly contrast itself with siblings like get_summary or get_status, so it stops short of a 5, but an agent can tell what this returns.

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?

It gives concrete when-to-use instructions tied to output: results end with "[conditions #n]", pass that n as `state`, or 0 for the current state. This is a clear trigger condition, though it does not name an alternative tool or state when not to use it, so it falls short of 5.

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

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

With no annotations present, the description carries the full behavioral burden and does disclose the key trait that it is concurrency-safe while another tool is blocking. It also enumerates what state is exposed (running command, elapsed time, computing/idle, design state number, run_tcl constraint changes, log directory). It stops short of edge cases such as behavior when no design is loaded.

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?

It is front-loaded with a one-line purpose, then a single sentence listing returned state, which is efficient. Some enumerated return items arguably duplicate the available output schema, making it slightly longer than strictly necessary.

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?

Given zero parameters, an output schema for the return shape, and no annotations, the description covers what an agent needs: what it reports and that it is safe to call concurrently with a blocking tool. Nothing essential is missing for correct invocation.

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 zero parameters, so there is nothing to document and the schema baseline of 4 applies. The description appropriately avoids inventing parameters.

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 description clearly states the resource — the status of the OpenSTA session ('What the OpenSTA session is doing') — so the agent knows this returns session state rather than timing or power data. However, it never distinguishes itself from the overlapping sibling get_summary or get_conditions, leaving the agent to guess which status-like tool to pick.

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?

It gives a concrete usage context: 'Safe to call at any time, including while another tool is waiting,' which tells the agent it can be invoked concurrently with other calls. It does not, however, name an alternative or state when a sibling like get_summary would be preferred instead.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only describes output content. It does not state that this is a read-only query, nor that a design must be loaded first (a real prerequisite in EDA sessions), nor any unit conventions. The risk is low for a summary getter, but the disclosure gap is real.

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?

One front-loaded sentence followed by a compact metric list; every item earns its place and there is no filler or restatement of the name.

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?

An output schema exists, so the description need not explain return values, yet it does so anyway (harmless). The missing piece is the operational context: whether a design must be loaded and what units the numbers use, which matters in a session-based EDA tool.

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 zero parameters, so there is nothing to document; baseline for a no-param tool is 4. The description correctly avoids inventing arguments.

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 description states a specific verb and resource ('Timing and size summary as numbers') and enumerates the exact metrics returned (slack, TNS, WNS, clock period, fmax, DRC counts, cell/net counts). It distinguishes itself from report_timing/report_power by framing itself as a numeric summary, though it never names those siblings 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?

There is no explicit statement of when to use this versus the sibling report_timing or report_power tools. Usage is only implied by the content enumeration ('summary as numbers'), which suggests a quick overview rather than a detailed report, but the agent must infer this.

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

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

With no annotations, the description carries the full burden and delivers: it discloses that loading is additive on top of a running session, that it starts a new analysis state, that warnings (unmatched SPEF nets, missing cells, unconstrained ports) propagate to all later results, and that it returns per-step timings plus a warning digest.

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 purpose sentence, then a tight parameter glossary, then behavioral caveats — every line carries information the agent cannot get from the schema, and the caveats are ordered by importance.

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?

Despite an output schema existing, it still summarizes the return payload and, more importantly, supplies the state model, sequencing, and warning-propagation context that structured fields cannot express for a setup tool of this complexity.

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 compensate and does: it documents all five parameters in-line, including liberty's string-or-list form, the optional-but-consequential nature of sdc ("required for meaningful timing") and spef ("without it delays use wire-load / no parasitics").

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 ("Load a design into the OpenSTA session") and immediately scopes its role in the workflow ("Call this once before any analysis"), which distinguishes it cleanly from sibling reporting/tcl tools.

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?

Explicitly gives the invocation point (once, before any analysis) and routes the agent to the correct alternative: restart_session is named as required first when earlier constraints must be dropped, and get_conditions is cross-referenced for the new analysis state.

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

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

With no annotations, the description carries the full burden. It does disclose valuable behavior: output is in watts, and the switching-activity provenance (VCD/SAIF read through run_tcl vs OpenSTA default, in which case values are estimates). However, it says nothing about permissions, that this is purely read-only, or any side effects/rate characteristics.

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-loads the purpose, then per-parameter notes, then a provenance caveat. Every sentence carries information, though the embedded parameter notes read like schema comments rather than prose and the final paragraph is slightly disjointed from the opening.

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?

An output schema exists, so return values need not be re-explained, and the description still adds the key interpretive note about where switching activity came from. Given two optional params and no annotations, it is nearly complete, missing only explicit read-only/safety framing.

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 compensate and largely does: top_instances is defined as 'list this many highest-power instances (0 = none)' and format as a 'text' table or 'json', adding the non-obvious caveat that the instance list is always text. Only minor gaps remain (defaults, interaction with hierarchy).

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 (report power) and enumerates the exact breakdown dimensions (sequential, combinational, clock, macro, pad groups; internal, switching, leakage components) plus units (watts). This is clearly distinct from report_timing and get_summary by domain, though the description never explicitly routes against siblings.

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 when-to-use or when-not-to-use guidance. It never says to prefer this over get_summary or report_timing, nor what prerequisites (e.g., a loaded design, prior run_tcl activity read) are needed. The usage context is only inferable from the tool name.

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

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

With no annotations, the description carries the full load and does disclose real behaviors: bus bits are auto-quoted, timeout_s=0 means wait indefinitely with stall detection, and json format may be unsupported. It does not state that this is a non-destructive read, nor that a design/session must already be loaded, which are meaningful gaps for a stateless-looking call.

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?

Purpose is front-loaded in one line followed by a tight per-parameter list with no filler prose. Only weakness is that the two default formats, 'full' and 'full_clock_expanded', are never explained, so the list is slightly asymmetrical.

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 tool with 0% schema coverage and no annotations, the description supplies nearly all parameter meaning, and the existing output schema removes the need to document return values. The remaining gaps are the missing design-loaded prerequisite and unexplained 'full'/'full_clock_expanded' formats.

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 compensate, and it does: it defines path_delay, path_count, scope enum values, from_pin/to_pin targeting rules, fields, format, and timeout_s semantics. Seven of the eight parameters get explicit meaning beyond the bare 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?

Opens with a specific verb+resource ('Report timing paths') and names the underlying command (OpenSTA report_checks), which pins down exactly what executes. It is clearly distinct from siblings like report_power or get_summary without needing to open any schema.

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?

Usage context (static timing analysis) is implied by the parameter glossary, and there is one routing hint ('check with run_tcl "help report_checks"' before using json format). However there is no explicit when-to-use vs when-not, and no guidance on required preconditions such as a loaded design relative to siblings like load_design or get_status.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses the destructive side effect ('The loaded design and any constraint changes are lost') and the necessary follow-up ('call load_design again'). It does not mention whether the restart requires specific permissions or how long it takes, so it falls just short of a 5.

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 sentences, each earning its place: one states the action, one states the consequence and required follow-up, one states the trigger condition. Front-loaded with the core action; no filler.

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?

Given no annotations, zero parameters, and complexity from the destructive nature of the operation, the description covers all an agent needs: what it does, what is lost, what to call afterward, and when to use it. An output schema exists, so no return-value details are required.

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?

Zero parameters, so the baseline is 4. The description appropriately adds nothing about parameters because there are none, and the schema is trivially complete. No parameter-related content is needed or missing.

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+resource: 'Stop the sta process and start a fresh one.' The agent knows exactly what this does, and it is clearly distinguishable from siblings like get_status (read state), load_design (load design), and run_tcl (execute commands).

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 an explicit when-to-use condition: 'Use this after get_status reports sta as exited, stalled, or holding an unfinished command.' It names the sibling tool to check first and enumerates the trigger states, leaving no ambiguity about when to invoke restart_session rather than other tools.

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

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

With no annotations, the description carries the full burden and does so well: it lists the disabled commands (exec, exit, socket, source, cd, load), the file-write sandbox tied to the session directory, state persistence and how it surfaces via get_conditions, output truncation behavior, and timeout semantics. This is exactly the safety and side-effect context a raw eval tool needs.

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-loads the core action, then uses a tight bulleted rule list where each entry carries distinct information (syntax, sandboxing, state, return value, truncation, timeout). Dense but no sentence is filler; slightly long for the payoff.

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?

Covers sandboxing, disabled commands, state side-effects, output limits and timeout for a high-power arbitrary-execution tool. An output schema exists, yet the description still usefully clarifies that the Tcl return value is returned and that puts is unnecessary, so nothing an agent needs 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 0%, so the description must compensate, and it does: it documents OpenSTA syntax expectations, the brace-wrapping rule for bus bit names with a concrete example, and clarifies timeout_s (0 = no limit) and the default. It adds real meaning beyond the bare 'command' string, though not exhaustively.

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 ('Run any OpenSTA Tcl command(s) in the live session'), immediately distinguishing it from siblings like find_commands (discovery) and get_status (read-only introspection). An agent can tell what this tool does without opening the schema.

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 conditional routing: use find_commands when unsure of a command name and `help <command>` when unsure of options, and covers the timeout semantics. It does not, however, tell the agent when to prefer the dedicated siblings (report_timing, report_power, get_summary) over hand-written Tcl, which is the main routing decision for this tool.

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