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

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is clear. The description adds that this is a zoom-history step ('zoom previous'), but it does not explain what happens when there is no previous view or how deep the history stack goes.

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 description is a single short sentence that is front-loaded and contains no unnecessary text. The parenthetical adds useful clarification without bloat.

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 simple no-parameter navigation tool with annotations covering safety and no output schema, the description is largely complete. It could mention edge-case behavior when no previous view exists, but that is a minor gap.

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 has zero parameters, so the baseline score is 4. The schema is empty and there are no parameter semantics to clarify.

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 action ('Return to the previous view') and clarifies it as 'zoom previous', so the resource is unambiguous. It doesn't explicitly name a sibling alternative, but the word 'previous' sufficiently distinguishes it from direct zoom/pan 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?

There is no explicit guidance on when to use this tool versus siblings like zoom, zoom_to, or pan. The agent must infer that it is for undoing a view change, and no prerequisites or exclusions are provided.

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 annotations already declaring readOnlyHint=false, destructiveHint=false, the description usefully clarifies why: mutations happen only in the viewer session and are never persisted, and save/export/open are blocked. That closes the apparent tension between 'changes things' and 'non-destructive'. It omits return format and error behavior for unknown command ids.

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 what it does, then when to use it, then the persistence constraint. No filler and nothing important buried.

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?

Safety and persistence semantics are fully covered, and both parameters are explained by the schema, so an agent can call this correctly. The one real gap is discovery: it advertises 400+ commands but offers no way to learn which ids exist or what `params` each expects.

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 100%: `command` is documented with eight concrete example ids and `params` is typed as a free-form JSON object. The description adds only the scale of the catalog and no guidance on how per-command parameter shapes relate to the `params` blob, so the baseline of 3 applies.

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 concrete verb and resource ('Run a CADCraft command directly') and quantifies the surface area (400+ AutoCAD-style commands), so the agent knows this is an arbitrary-command dispatcher. It signals itself as a catch-all fallback but never names a specific sibling (measure, find, layers) it supersedes, which keeps it short of a 5.

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?

'Use for inquiries the other tools do not cover' gives a clear selection rule: try the specialized siblings first, fall back here. It stops short of explicit exclusions or naming which sibling handles which category, leaving the agent to infer the mapping from sibling names alone.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description contributes the concrete scope of what is removed (selection, markers, boxes), but leaves open whether clearing is view-scoped or global and gives no hint about the odd idempotentHint=false.

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 eight-word sentence with the verb front-loaded and every word carrying scope information. Nothing extraneous.

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 no-argument, no-output tool, the description is nearly sufficient; the only gap is whether the clear applies to the current view or the whole document, which matters when layered content exists.

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 the schema imposes no semantic burden; baseline is 4. The description correctly does not invent 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?

States a specific verb (clear) with an enumerated resource list (selection, markers, boxes), so the agent knows exactly what state is reset. It is distinguishable from siblings like select/mark, though 'boxes' is undefined terminology that only makes sense with prior context.

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 guidance on when to call this versus alternatives such as select_window or back, and no stated preconditions. The only usage signal is the implicit 'clean up after selecting/marking', which the agent must infer.

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?

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=false, so the safety profile is covered. The description adds genuinely new behavior: the response reports full object identity and also enumerates nearby candidates, plus the follow-up path via `select`. It does not mention that the pick replaces the current selection unless `add` is set, which is the main reason idempotentHint is false.

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 tight sentences: the action and return content come first, the fallback path second. Every clause carries information an agent needs, and nothing is 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?

With no output schema, the description takes on the job of describing return values and does so explicitly. The remaining gap is the empty-pick case (what is reported when nothing is under the point) and the selection-replacement side effect, both of which an agent would want before calling.

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 60%: `add`, `coords`, and `tolerance_px` are documented in the schema, while `x`/`y` are bare. The description's 'under the point' implies the coordinates but does not clarify the pixel-vs-world interpretation or the tolerance behavior, so it adds little beyond the structured fields. Baseline 3 is appropriate.

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 concrete verb and resource ('click on the drawing: select the object under the point') and enumerates the reported attributes (type, layer, coordinates, text, block attributes, size), so the agent knows exactly what it gets back. It differentiates itself from the sibling `select` (handle-based selection) but leaves overlap with `inspect`/`find` unaddressed.

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 a clear operational context: the pick returns nearby alternatives and, if the wrong one was hit, the agent should call `select(handles=[...])`. That is an explicit alternative plus the condition that selects it. It does not say when to prefer this over point-free siblings like `inspect` or `find`.

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?

Annotations already establish readOnlyHint=true and openWorldHint=false, and the description adds useful context: it searches text/entity types and can optionally select, zoom, and highlight results. It does not explain the non-idempotent hint or return behavior, but it adds meaningful operational context beyond annotations.

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 definition is a single front-loaded sentence that states the primary search capability first and the optional follow-up behavior second. There is no wasted text.

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 six-parameter search tool with no output schema, the description should clarify return results, how limit affects results, and what layer filtering does. It covers the core search and show behavior but leaves notable gaps around result shape and omitted parameters.

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 67%, with descriptions present for show, text, type, and in_view. The description reinforces text/entity search and the show behavior, but it does not add meaning for layer or limit, leaving those parameters largely undocumented in both places.

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 and resource: search the drawing for text or entity types, with concrete examples such as labels, reference designators, notes, and entity types. It is clearly distinguishable from zoom/select siblings, though it does not explicitly name an alternative.

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 usage by describing searchable content and the optional jump/highlight behavior, but it does not state when to use this instead of select, inspect, or other navigation tools. No exclusions or prerequisites are given.

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?

Annotations already declare readOnlyHint, idempotentHint and closed-world behavior, so the safety profile is covered. The description adds that output is textual and enumerates the returned data, which is useful, but it does not say what happens when no handles are given (that lives only in the schema).

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 compact clauses with zero filler: the returned fields come first, followed by the output-medium constraint. Every word 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?

With no output schema, the description does the heavy lifting by enumerating return content, which is adequate for a read-only inspection tool. The only gap is behavior when handles is omitted, which is delegated to the schema.

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?

Only one optional parameter ('handles') with 100% schema description coverage including its default ('the selection'). The description adds nothing about handle format or selection fallback, so the schema carries the meaning entirely — baseline 3.

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 pairs the generic verb 'inspect' with a concrete resource ('entities') and enumerates exactly what is returned: DXF attributes, effective colour, bounding box, length/area, block content. 'Text only, no image' implicitly separates it from the visual 'look' sibling, though no sibling is named 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?

Usage is only implied: the tool is for pulling full attribute data on entities. There is no explicit when-to-use/when-not, and it never names alternatives like 'find' (locating entities) or 'measure' (dimensions), leaving the agent to infer the split.

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?

The description directly contradicts the annotation readOnlyHint: true by stating the tool can 'change which layers are shown', which implies write operations. No other behavioral context (e.g., reversibility, required permissions) is provided to resolve this conflict.

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 single sentence is front-loaded, wastes no words, and packs in the key capabilities. It could be slightly clearer about the two modes but is appropriately concise.

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 tool that can mutate layer visibility, the description is incomplete given the contradictory annotations. It fails to clarify side effects, reversibility, or how the readOnlyHint applies, leaving the agent with a misleading signal about safety.

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 100%, so the schema already fully documents the names and action parameters. The description adds no parameter-level meaning beyond what the schema provides.

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+resource: 'List layers' or 'change which layers are shown', with concrete details (visibility, colour, entity count). It clearly distinguishes listing from modifying, but does not reference any sibling tool or alternative.

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 implies two main usage modes (listing and changing visibility), but provides no explicit guidance on when to use this tool vs alternatives such as cad_command or screen_settings. The action enum in the schema suggests contexts but the description itself does not.

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?

readOnlyHint=true and openWorldHint=false already tell the agent this is a safe, non-networked read/state operation, so the bar is lower. The gloss on title blocks, viewports, notes and parts lists adds genuine domain context, but nothing is said about whether switching persists, whether a drawing must be open, or what the list returns.

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 with the action first and the clarifying parenthetical after it. The parenthetical is long but it is the only elaboration and it carries real 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?

For a one-optional-parameter tool with full schema coverage and clear annotations, almost nothing an agent needs is missing. The only gap is that the description never says what the listing form yields (layout names), which matters slightly since there is no output schema.

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 100% and the single parameter already documents that it accepts 'Model' or a paper-space layout name and that omission lists layouts. The description adds no format, casing, or defaulting detail beyond the schema, so baseline 3 applies.

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 concrete verb pair ('switch between' / 'list') and the exact resource (model space and paper-space layouts), plus a useful gloss on what a paper-space layout contains. An agent knows what this does, though it doesn't explicitly distinguish itself from near-neighbors like 'layers' or 'open_drawing'.

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 'or list the layouts' branch implies two modes, and the schema makes the trigger explicit ('omit to list them'), but the description itself gives no when-to-use/when-not guidance relative to alternatives such as 'inspect' or 'open_drawing'. Usage is inferable rather than stated.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the call is a repeatable refresh, but says nothing about what is actually returned (an image? a textual screen dump?) or whether it reflects pending state changes. Note idempotentHint=false alongside a 'show again' read is mildly surprising and unexplained.

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 short sentence with the action front-loaded and the qualifying context in a compact parenthetical. No filler; only minor gain from a slightly cleaner phrasing.

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 and no parameters, the description carries the full burden of explaining the result, yet it never says what 'show' produces or how the agent should interpret it. For a screen-capture-style tool in a 20-sibling set, that is a meaningful gap.

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 the baseline is 4 and the description correctly implies there is nothing to configure. No parameter-level confusion is possible.

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?

"Show the current screen again" states a specific verb and resource, and the parenthetical clarifies it is a re-render/refresh action rather than a new navigation. It is distinguishable from navigation siblings like zoom or pan, though it does not explicitly separate itself from the similarly-named 'inspect' or 'screen_settings'.

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 parenthetical gives concrete triggering conditions — after changing options, or to refresh your view — which is real when-to-use guidance. It stops short of naming an alternative or stating when not to use it (e.g., first call after opening a drawing).

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?

Annotations already declare readOnlyHint=true, openWorldHint=false and idempotentHint=false, so the safety profile is covered. The description adds useful behavior the annotations don't: markers are orange, they can carry labels, and the call ends by showing the drawing (i.e. it returns a rendered image rather than data). It does not disclose that existing markers are discarded unless `add` is set, nor how the rendered output is returned.

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 short sentence with the action front-loaded and the render step trailing, plus a parenthetical example. Nothing is redundant and nothing needs trimming.

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 four parameters and no output schema, the description carries moderate burden. "then show it" gestures at the returned image but doesn't say what the agent gets back or whether prior markers/measurement lines persist — a meaningful gap given `add` defaults to false and the tool is non-idempotent.

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 75%, so the baseline is 3, and the description justifies a small bump by framing the core output as 'labelled orange markers', which anchors `points` and `labels`. It still does not explain how label strings map to point indices, or when to choose px vs world coordinates — both left to 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?

Specific verb + resource: "Put labelled orange markers on the drawing" plus the follow-up "then show it", which tells the agent the call also renders the result. It is distinguishable from siblings like `measure` (measurement lines) and `inspect`/`look`, though the description never names those alternatives 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?

"e.g. to point out findings" gives one motivating use case, which implies this is the annotation/pointing-out tool in the family. There is no guidance on when not to use it, no mention of `clear` for removing markers, and no statement of prerequisites (e.g. that a drawing must already be viewed).

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?

Annotations declare readOnlyHint=true and idempotentHint=false; the description adds the non-obvious side effect that 'points are marked on screen', which explains the non-idempotency (visible markers accumulate). It stops short of saying how long markers persist or how results are reported.

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 dense sentence, front-loaded with the primary operation and listing modes/outputs without filler. Slightly compressed by the line wrap, but every clause carries 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?

No output schema exists, so the description compensates by enumerating returned quantities (lengths, dx/dy, angles, total, area, radius). It lacks detail on the coords parameter's effect on results and on the returned format, which leaves a small gap.

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 beyond the schema: it maps 'three or more points' to area calculation and associates handle with length/area/radius, whereas the schema only says 'Two or more points' generically.

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 distances... between points', 'an entity's length/area') with concrete outputs enumerated (segment lengths, dx/dy, angles, area). It is distinguishable from siblings like inspect/find/mark in intent, though it does not name them 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?

The three operating modes (2+ points → distance, 3+ points → area, handle → entity measurement) imply when each pathway applies, but there is no explicit statement of when to prefer this over inspect/find or what to do when both points and handle are omitted.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered externally. The description adds genuinely useful state info — that opening replaces the previously open drawing — which aligns with idempotentHint=false. It omits failure behavior (unsupported file, missing path) and whether view state like layers/marks is reset.

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 tersely worded sentences with the action front-loaded and no filler. Phrasing like 'the drawing open before' is slightly awkward but costs no comprehension.

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 one-parameter tool with no output schema and strong annotations, the core behavior is conveyed. Still missing are the post-open state (what the viewport shows, whether prior marks/layers persist) and error conditions, which an agent would want before calling it in a workflow.

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% and the single `path` parameter is fully documented with accepted formats (.dxf, .dwg, Gerber/Excellon, folders, zips). The description adds nothing about the path, so baseline 3 applies — the schema does all the work.

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 concrete verb and resource ('Open a drawing') plus the scope of the result ('show the whole of it'), which distinguishes it from sibling view-manipulation tools like zoom_window or zoom_extents. It stops short of naming an explicit sibling or exhaustion of alternatives, but the action 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?

The implication is that this is the entry point before inspecting or measuring a drawing, and 'Replaces the drawing open before' hints at session workflow. However, it never says when to prefer this over siblings (e.g. inspect, find, layers) or what happens if a drawing is already open.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description still earns some credit by stating the viewport offset does not alter zoom level. It says nothing about idempotence despite idempotentHint=false, nor about what happens when neither direction nor dx/dy is supplied.

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, front-loaded with the core behavior and no filler. It is efficient but so terse that the second sentence spends its budget on an illustration rather than on the missing invocation logic.

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?

Wait — rescored: for a zero-required, 5-parameter tool with no output schema and only 80% schema coverage, the description never explains what a call with no arguments does, which is a real gap an agent could hit. Combined with the unaddressed direction-vs-dx/dy interaction, it is short of complete.

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 80%, so the schema already explains amount, coords, and direction, making 3 the baseline. The description adds only the single 'right' example and does not clarify the mutual exclusivity between the direction/amount path and the dx/dy path — the one genuinely ambiguous part of a 5-parameter, zero-required 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 — 'Move the view' — and adds a scope qualifier, 'without changing zoom', that separates it from the zoom_* siblings. The only weakness is that the second sentence illustrates just one direction ('right') rather than characterizing the operation generally.

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?

'Without changing zoom' implicitly routes the agent to zoom_window/zoom_to/zoom_extents when zoom changes are wanted, but no alternative is ever named and no condition for choosing pan over back or look is given. Usage is inferable rather than stated.

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?

The description's verb 'Change the screen' describes a mutation while annotations declare readOnlyHint=true; that is an inconsistency. Beyond the field list, it says nothing about persistence, whether unspecified settings reset, defaults (all params default to null), or return 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?

A single compact sentence with the resource front-loaded and zero filler. It is lean, though terse enough to border on under-specification for a 5-parameter tool.

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, five optional params, and a readOnly/change ambiguity, the description should clarify persistence and return behavior but does not. Completeness is inadequate for a settings tool whose defaults are all null.

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 60%; width_px/height_px ranges and the cjk enum meanings are documented in-schema. The description usefully groups the settings (size, grid, minimap, CJK) so each maps to a parameter, but grid/minimap booleans remain undocumented and the description adds no format detail beyond naming them.

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 (Change) and resource (the screen) and enumerates the four configurable groups (drawing area size, grid, minimap, CJK glyphs). This distinguishes it from view-navigation siblings like zoom/pan, though it doesn't name an alternative 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?

No guidance on when to use this versus zoom/zoom_window/pan or other view tools, no prerequisites, and no exclusions. The agent must infer that this configures view settings rather than navigating.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description usefully adds that entities are highlighted as a visible side effect. However, it omits the key behavioral fact stated only in the schema — that the call replaces the existing selection — and says nothing about what happens with invalid or unknown handles.

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 with no filler and the effect stated immediately. It is arguably too terse given the missing selection-replacement semantics, 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?

A one-parameter tool with annotations and a fully covered schema needs little, but the description leaves out the selection-replacement behavior and any indication of what the call returns (e.g., new selection set or confirmation). Sibling interaction (select_window, clear) is also 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 100% and the single parameter is fully documented in the schema, so baseline 3 applies. The description confirms the handle-based addressing but adds no format detail (handle syntax, batching) 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 ("Select entities by handle") plus the visible effect (highlighting), so the action is unambiguous. It does not distinguish itself from siblings like select_window or clear, which an agent must infer from names alone.

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 guidance on when to use this versus select_window (window/region selection) or click, and no mention of how it relates to clear. The agent must guess the selection workflow from sibling names.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by stating the return shape (counts by type and layer) and the 'visible objects' scope, but says nothing about whether the selection persists, how visibility/viewport affects results, or what happens with an empty box.

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 that names the action, the scope, and the return content with zero filler. Nothing to trim.

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 8 parameters, 4 required and undocumented in the schema, no output schema, and a coordinate-mode ambiguity (px vs world) that materially changes results, the description is too thin. It never clarifies bbox ordering, whether coordinates are in image pixels by default, or the effect of the 'visible' constraint on returned counts.

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 only 38%; the four required bbox coordinates have no descriptions at all, and the description does not explain them either. It hints at type/layer filtering via 'counts by type and layer' but leaves coords (px vs world) and crossing semantics entirely to the schema's own field descriptions.

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: 'Box-select visible objects' plus what it returns (counts by type and layer). It is clear what the tool does, but it never distinguishes itself from close siblings like 'select' or 'find', which an agent could easily confuse it with.

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 when-to-use guidance, no exclusions, and no mention of the alternatives ('select', 'find', 'inspect') among the siblings. The only hint is the word 'visible', which implies a viewport dependency but is not explained.

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?

Annotations already cover safety (readOnlyHint=true, openWorldHint=false) and non-idempotence; the description's contribution is the wheel analogy, which usefully signals relative zoom compounding across calls and consistent with idempotentHint=false. It says nothing about what the call returns or whether view state persists, which are relevant for a view-mutating 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?

A single sentence, front-loaded with the action and backed by a compact analogy; there is no filler and nothing that could be cut without losing meaning.

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?

All four parameters are optional with defaults and no output schema exists, so the bar is modest, but with three similarly named zoom siblings the definition should still say what this one does that they don't and whether the view change is visible/persistent. Those gaps keep it at minimum-viable.

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 75% and the schema documents each parameter thoroughly, including factor semantics ('2 = twice as close') and the px/world enum. The description's 'around a point' loosely reinforces the anchor parameter but adds no format or default information beyond the schema, so the baseline 3 applies.

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 (zoom in or out) and the anchor concept (around a point), with a concrete analogy ('like the mouse wheel over that spot') that makes the relative-scaling behavior clear. It does not distinguish itself from the siblings zoom_window, zoom_extents, or zoom_to, so an agent cannot tell from the description alone which zoom variant applies.

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 statement of when to use this tool versus the three zoom siblings or pan. The mouse-wheel analogy implies interactive, incremental zooming, but the agent must infer that rather than being told.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds only the scope notion ('whole drawing'), which mildly extends beyond the annotations by implying the framing includes all entities rather than a selection. No mention of what happens to current view state or whether zoom can be undone, which is relevant for a viewport mutation.

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 short, front-loaded sentence with zero filler. Its terseness is more an under-specification issue than a structure problem, so it earns high marks here but not the top score.

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 no-param, read-only viewport action with annotations covering safety, this is minimally sufficient. However, with four sibling zoom/pan tools in the namespace, an agent needs at least a phrase clarifying that this frames the entire drawing rather than a selection or a specified target.

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 and the schema is trivially complete, so there is nothing for the description to compensate for. Baseline 4 applies.

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 phrase 'Show the whole drawing' conveys a fit-to-view operation, and the tool name zoom_extents supports that reading. But the description never uses the verb 'zoom' or names the viewport/extents concept, and it does nothing to distinguish this from the many viewport siblings (zoom, zoom_to, zoom_window, pan, back).

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 guidance on when to use this versus zoom_to, zoom_window, zoom, or back. The agent must infer that 'whole drawing' means 'fit all geometry in view' rather than a zoom level or a specific target.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is clear. The description adds that this frames a view around entities, but does not add further behavioral details such as what happens with invalid handles or how the framing margin behaves.

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 concise sentence that is front-loaded with the action and immediately followed by concrete examples. There is 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 simple two-parameter read-only viewport tool with full schema coverage and no output schema, the description is nearly complete. It could be slightly stronger by explicitly contrasting with zoom_extents or zoom_window, but 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?

Schema description coverage is 100%, so both margin and handles are fully documented in the schema. The description adds the useful implication that handles default to the current selection, but does not provide additional syntax or meaning 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?

The description gives a specific verb and resource: frame specific entities, with examples of which entities (find results or the selection). This distinguishes it from siblings like zoom_extents and zoom_window, though it does not name those alternatives 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?

It provides clear usage context by saying to use it for specific entities such as find results or the current selection. It does not explicitly state when not to use it or name the alternative zoom tools, but the intended scenario is clear.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only 'fills the screen' – it says nothing about aspect-ratio handling, whether the view persists, or what happens when the rectangle falls outside the last image, and notably does not reconcile the idempotentHint=false annotation with an operation that looks repeatable.

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 short sentence with the resource and the effect front-loaded; nothing is padded. It is terse to the point of omitting parameter detail, but no sentence 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?

For a simple read-only view operation with no output schema, the description is minimally sufficient to invoke it. It falls short on the five-parameter surface and on disambiguating among the several zoom/pan siblings, so an agent still needs to open the schema.

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 only 20% – x0/y0/x1/y1 have no descriptions – but the phrase 'two opposite corners' usefully establishes that the four numbers pair into (x0,y0) and (x1,y1). It does not say whether ordering matters (x0<x1) or how units are interpreted, leaving the undocumented params partly compensated.

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 (zoom) and the exact geometric target (a rectangle defined by two opposite corners that fills the screen), with an analogy to a zoom-window drag. An agent can tell this apart from pan/back/zoom_extents, though it never explicitly names which sibling to prefer.

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 analogy 'like a zoom-window drag', but there is no explicit when-to-use vs zoom_extents, zoom_to, look, or pan, and no guidance on when to pick 'world' over 'px'. The agent must infer the situation from the sibling list.

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