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

No annotations are supplied, so the description bears the full behavioral burden. It discloses the input provenance and the analyzed attributes, but says nothing about whether this is read-only, what happens with a non-path target, or any failure/precondition behavior. With an output schema present, the return-shape gap is covered, but the safety/edge-case gap is not.

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 plus a compact two-item arg list, with the purpose front-loaded before the argument notes. Every element earns its place; only the lack of any note on non-path input keeps it from being exemplary.

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 a two-parameter analysis tool with an output schema, the description covers purpose, both inputs, and their provenance, which is nearly the full picture. The remaining gap is behavioral (read-only status, path-type precondition) rather than functional.

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: it explains that session_id is the session returned by open_layout and target_id is the id of a path shape returned by query_region. That origin/type constraint is real added meaning beyond the bare string types in 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+resource ('Analyze a path shape as a waveguide') and enumerates the derived quantities (width, length, orientation, bend estimate), so the agent knows exactly what it produces. It does not explicitly contrast itself with the nearby sibling measure_geometry, so it falls short of full sibling differentiation.

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 arg notes embed a workflow: session_id comes from open_layout and target_id must be a path shape from query_region, which implies the prerequisite call sequence and the accepted target type. There is no explicit statement of when to prefer this over measure_geometry or what to do if the target is not a path.

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 behavioral burden. It does disclose the key destructive trait (the artifact directory, renders and DRC output, are deleted), which is genuinely useful. However it omits irreversibility, whether the session id becomes invalid, and behavior when the session is unknown or already closed.

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 plus an Args block, with the destructive side effect front-loaded right after the verb. No filler, nothing repeated for padding.

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 described. Still, this is a destructive, unannotated, one-shot operation and the description leaves open whether closing is reversible, idempotent, or whether the session id remains usable — gaps that matter 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?

Schema description coverage is 0%, so the description must compensate. It does so by explaining the provenance of `session_id` ('Session returned by `open_layout`'), which tells the agent where a valid value comes from rather than merely restating the type.

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 ('Close a session') and immediately qualifies it with the side effect ('delete its artifact directory (renders, DRC output)'), which is more than a tautology. It is clearly the inverse of the sibling `open_layout`, though that differentiation is only implied by the parameter note rather than stated.

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 description never says when to call this versus leaving a session open, nor does it warn that closing is presumably terminal for that session. Usage is only inferable from the verb itself; no conditions, prerequisites, or alternatives are named.

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 present, so the description carries the full behavioral burden. It does disclose the returned content and the depth expansion behavior, which is useful, but says nothing about permissions, whether it mutates session state, cost limits, or error conditions for an unannotated tool.

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 a single sentence, followed by a compact Args block that maps one-to-one to parameters. No filler or redundant restatement.

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 detailed (though it summarizes them anyway), and all parameters are explained. The remaining gap is the absence of usage routing against siblings, which is minor given the low-complexity, read-oriented nature of the 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?

Schema description coverage is 0%, so the description must compensate, and it does: it documents all three parameters, including the meaning of depth (levels to expand, 0 = none) and the origin of session_id (returned by open_layout). This adds real meaning beyond the bare schema titles.

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 ('Describe one cell') and enumerates the outputs (bounding box, child instances, text labels, shapes per layer). This distinguishes it from sibling list_cells, though it never explicitly names that sibling to route the agent.

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 implies a prerequisite by noting session_id comes from open_layout, giving a basic workflow hint. However, it offers no explicit when-to-use/when-not guidance versus list_cells, query_region, or measure_geometry, leaving selection largely to inference.

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 the optional side effect that `include_crops` renders a PNG crop and gives the default crop window (20x20 um), which is real behavioral context beyond the schema. It does not state read-only/safety profile, permission requirements, or behavior on an unknown run_id.

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?

The purpose sentence is front-loaded and the parameter notes are terse and each earn their place. The Args block is slightly formulaic but contains 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 description is unnecessary, and the description covers purpose, all parameters, and the optional crop rendering. It would be fully complete with a note on what happens when the referenced run is missing or whether extraction is read-only.

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 documents all four parameters, gives the provenance of session_id (`open_layout`) and run_id (`run_drc_script`), and clarifies crop_size_um as an {x, y} micron window with a default. Only the exact units/format edge cases are left thin.

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 ('Return the violation markers') and scopes it to a run produced by the sibling `run_drc_script`. An agent can distinguish this from query_region, measure_geometry, or run_drc_script itself without opening 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?

The phrase 'from a `run_drc_script` run' implies the prerequisite that a DRC run must exist and that run_id/session_id come from `open_layout` and `run_drc_script`, which is useful. However, there is no explicit when-to-use/when-not guidance or named alternative among the many siblings.

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 behavioral burden. It discloses ordering (sorted by name), the per-entry payload, and the depth-scoping rule, but says nothing about result size limits, pagination, or performance on large layouts, which are the real risks for a hierarchy listing.

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 purpose and sort order, then the return payload, then Args, which is a sensible ordering. The return-field sentence overlaps with the existing output schema, but it is brief and not padded.

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?

Both parameters are documented and an output schema already covers return values, so the agent has what it needs to call this correctly. The only gap is the absence of any session/permission or scale caveats that a no-annotation read tool might benefit from.

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 define both parameters, and it does: session_id is tied to `open_layout`, and max_depth is explained with concrete edge semantics ('0 = top cells only, 1 = top cells and their direct children') plus the omit-to-list-all default. That is genuine added meaning.

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 ('List cells in the layout hierarchy') plus the sort order, which is materially more informative than the bare name. It does not name or distinguish itself from siblings like describe_cell or query_region, but the purpose itself is unambiguous.

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 is implied rather than stated: an agent infers this is the enumeration step after `open_layout`, which the session_id arg indirectly confirms. There is no explicit when-to-use, when-not-to-use, or comparison against describe_cell/query_region, so guidance remains minimal.

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. It discloses the returned content and the filter usage, but says nothing about scope (whole layout vs. current view), ordering, pagination/limits, or what happens with an invalid/expired session_id.

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 action, then the output usage hint, then the argument note. No filler; every sentence adds information.

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, and the description covers purpose, argument provenance, and downstream use. It could still note scope/ordering for a listing tool, but nothing essential to 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 0% and the single parameter has no schema description, so the description must compensate — it does by naming session_id's origin ('Session returned by `open_layout`'), giving the agent a concrete way to obtain it. No format or validation detail beyond that.

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 ('List every layer in the layout') plus the exact returned fields (layer/datatype, name, shape count). This clearly distinguishes it from siblings like list_cells and describe_cell, which operate on cells rather than layers.

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 explains downstream usage ('use the returned {layer, datatype} pairs as layer filters in other tools') and implies this is the enumeration step, but never states when to prefer it over alternatives such as query_region or describe_cell, nor any preconditions beyond having a session.

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 must carry the behavioral burden; it discloses output units (microns and database units) and that measurements are bounding-box based for some modes, which are real behavioral facts. It does not state whether the call is read-only, whether shapes must all come from the same query_region invocation, or how invalid target_ids are handled.

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, then modes, then args — a sensible order with no filler prose. The trailing Args block partially restates session_id/mode/target_ids already introduced above, a small redundancy that keeps it from a 5.

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 formatting needn't be described, and the description adds the unit convention anyway. Mode arities, prerequisite tools, and parameter provenance are all covered; only edge cases (mismatched sessions, invalid ids, mixed-source shapes) are unaddressed.

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% and even the `mode` string has no enum, so the description is the only documentation — and it fully compensates, enumerating all seven modes with their required target_ids arity and defining the two bounding-box semantics. Each of the three parameters is given provenance and meaning.

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 ('Measure a value from shapes') and names the producing sibling (`query_region`), which cleanly separates it from listing/analysis tools like list_cells or analyze_waveguide. The mode list further pins down exactly what kind of measurement is produced.

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 ties usage to a prior `query_region` call and requires target_ids sourced from it, plus session_id from `open_layout`, giving a clear call chain. It does not, however, exclude or compare against alternatives such as analyze_waveguide or run_drc_script for related geometry questions.

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: read-only access, session expiry on inactivity, the requirement to close sessions, and the cross-cutting fact that the returned session_id is mandatory for all other tools. It doesn't cover permission failures or error conditions, keeping it out of 5 territory.

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 critical 'Call this first' instruction, then lifecycle, then a compact Args block. Every sentence adds operational value with 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?

For a session-creating entry-point tool, the description covers purpose, ordering, lifecycle, cleanup, and all three parameters. An output schema exists, so return-value detail is unnecessary, and the one key return field (session_id) is already called out.

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 fully: path is an absolute path restricted to .gds/.oas, top_cell specifies the default with a stated fallback (alphabetically first top cell), and format resolves ambiguity when the extension is unclear. Each parameter gains meaning absent from 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?

States a specific verb (open), resource (GDS/OASIS layout), and mode (read-only), plus the side effect of starting a session. 'Call this first' immediately distinguishes it from every sibling tool, which all depend on the session it creates.

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 clear ordering guidance ('Call this first'), the lifecycle rule (sessions expire after inactivity), and names close_session as the terminating counterpart. It stops short of describing when-not to use it or how it pairs with specific downstream tools, so it falls just below the top.

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 full behavioral burden and handles it well: it discloses session-stable id semantics, deterministic result ordering, and that truncation reports how many items the caps dropped. It stops short of confirming read-only safety or performance characteristics of recursive queries, but the substantive behaviors are covered.

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?

The purpose sentence and id-routing note are front-loaded, then the Args block. The block is long, but with 0% schema coverage each line is load-bearing; the phrasing is compact and free of repetition.

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 nested-schema query tool, everything an agent needs is present: required params, formats, enum-like values, defaults, coordinate system, and truncation reporting. An output schema exists, yet the description still usefully explains the id contract that downstream tools depend on.

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% and there are 8 parameters, so the description must compensate, and it does: every argument gets meaning, including box as microns with an explicit key layout, the layers filter shape, hierarchy_mode's top/recursive/flattened semantics, defaults, and the three truncation caps.

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 opening sentence names a concrete verb (return) and three specific resources (shapes, text labels, child instances) scoped by an overlap box. The mention of handing ids to measure_geometry/analyze_waveguide/render_view makes clear this is the discovery step, not a measurement or rendering tool, distinguishing it from those 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?

It establishes the workflow context: session_id comes from open_layout, and returned ids feed measure_geometry, analyze_waveguide, or render_view. It does not state when to use this versus a narrower sibling query or any exclusion conditions, but the downstream routing is explicit and useful.

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 the PNG side effect, the non-obvious state mutation ('Arguments given here also update the session's default view'), and a hard prerequisite constraint ('Targets must come from query_region on the rendered cell'). It stops short of discussing cost, latency, or failure modes, but the non-obvious behaviors are surfaced.

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 action and return value in sentence one, followed by the state-effect caveat, then a clean per-argument list. Every line earns its place; nothing is repeated from the schema.

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 a 7-parameter rendering tool with an output schema, the description covers all parameters, the state side effect, the annotation prerequisite, and return semantics. An agent has everything needed to invoke it correctly.

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 fully, and it does: every one of the 7 parameters is documented with format, defaults, and provenance (session_id from `open_layout`, layers as `[{"layer": int, "datatype": int}]`, image_size default 1200x800, style enum values). This adds substantial 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?

The first sentence gives a specific verb ('Render'), resource ('layout geometry'), output ('to a PNG') and return value ('absolute path'). It also positions itself relative to the sibling `set_view` by noting the shared session-state effect, so an agent can distinguish it from that tool 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?

Usage is implied by the rendering workflow (open_layout -> query_region -> render_view) and by the reference to `set_view`, but there is no explicit when-to-use / when-not-to-use statement or named alternative. The agent must infer that this is the visual-output step.

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 documents the deck contract ($input_path/$report_path variables, must write to $report_path), a hard environment prerequisite (klayout executable on PATH or KLAYOUT_BIN), and the return payload (run_id + marker counts). It omits failure/timeout behavior and whether the run mutates session state.

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 action, then the deck contract, then follow-up and prerequisites, with an Args list at the end. Efficient and well-organized, though the contract paragraph could be tightened slightly.

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?

Output schema exists, yet the description still usefully names run_id and marker counts, and it covers the environment prerequisite and downstream handoff. Complete enough to invoke correctly; only error-handling behavior is unaddressed.

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: session_id is tied to open_layout, script_path is specified as an absolute path, script_type is constrained to ruby only, and params is explained with the -rd name=value forwarding syntax. This is meaningful added 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?

States a specific verb+resource+mode: 'Run a KLayout DRC deck in batch mode against the session layout.' It is clearly distinguishable from siblings like extract_markers, which it explicitly names as a downstream step rather than a competing choice.

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?

Establishes context (batch DRC against an open session) and routes the agent to extract_markers via run_id for marker locations. It lacks explicit when-not guidance (e.g., when to prefer interactive/geometry queries over a full deck run), so it stops short of a 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, the description carries the full burden and does reasonably well: it discloses partial-update semantics ('Omitted arguments keep their current value'), an auto-fit side effect, and that the setting persists for later render_view calls. It omits error/permission behavior and what happens if session_id is stale, which a mutation tool ideally covers.

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, followed by concise behavioral notes and a tidy Args list. Every sentence carries information, though the Args block is somewhat verbose relative to the schema.

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 explained, and the description covers the mutation semantics and parameter formats adequately for a 4-parameter stateful tool. Remaining gaps (persistence scope, failure modes) are minor against the schema and output schema already provided.

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 largely does: it documents all four parameters, gives box's key set and micron units, and specifies the layers shape [{layer, datatype}]. Minor gaps remain, such as whether box requires all four keys and the null/default meaning.

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 ('Set the session's default render view') and ties it to the sibling tool render_view, so an agent can distinguish configuring the view from actually rendering it. It is clear, though it does not explicitly say 'use set_view rather than render_view when configuring'.

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 establishes clear context via its relationship to later render_view calls and gives conditional rules: omitted arguments keep current values, and changing cell without a box auto-fits. It stops short of stating when not to use this tool, so it lacks explicit exclusions.

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