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

The annotations already signal that this is mutating (readOnlyHint=false), and the description's 'active canvas' phrasing adds a small amount of placement context. However, it does not disclose side effects, failure modes, or requirements such as the component needing to be installed or known, beyond what the annotation already implies.

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 clean, front-loaded sentence. Every word carries meaning and there is no redundant or generic 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 insert operation with a clear schema and output schema, the description is nearly complete: it names the action and target surface. It could additionally note behavior on invalid names or coordinate units, but these are minor for the tool's simplicity.

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 description itself adds no parameter meaning. The nested input schema does explain that x/y are canvas coordinates and name is the component nickname or full name, which covers most of the semantic burden. Since the computed schema description coverage is 0%, this is a partial gap, but the actual schema text prevents serious ambiguity.

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 uses a specific verb ('Drop') and identifies the resource ('a Grasshopper component') and destination ('the active canvas'), which clearly separates it from sibling tools that search, connect, or delete components. It does not explicitly name a contrasting sibling, so it misses the top tier.

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 gives no guidance about when to use this tool versus alternatives like gh_place_slider, gh_components_search, or gh_connect_components. No prerequisites, exclusions, or decision context are provided, so an agent must infer when this is the right tool.

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 annotation readOnlyHint=false already signals mutation, and the description adds that output is written into the active Rhino document. It does not disclose side effects such as whether existing baked objects are replaced or whether a GH definition must be running, but the core write behavior is clear.

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, front-loaded sentence with no filler. Every word contributes to identifying the action, object, and destination.

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 bake operation, the description plus schema is mostly sufficient, but it omits practical context about obtaining component IDs and ensuring the components have computed output before baking. The available output schema may cover return values, so that gap is minor.

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 description does not explain parameters, but the schema's nested properties define component_ids ('Components whose output to bake') and layer ('Target Rhino layer (created if absent)'), so the schema carries the semantic load. The description adds no additional parameter value beyond what the schema already 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 gives a clear verb ('bake'), resource ('output of one or more components'), and destination ('active Rhino document'), so an agent can tell what the tool does. It does not explicitly say 'Grasshopper' or distinguish this from sibling tools like gh_run or gh_data_tree_get, so it misses 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?

No guidance is provided about when to use this tool versus alternatives, nor are prerequisites mentioned, such as having a Grasshopper definition open or needing component IDs from gh_component_list. Usage is only implied by the word 'bake'.

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 aligns with the readOnlyHint=false annotation by indicating a mutation ('Set'), but it does not disclose additional behavioral details such as side effects on the template or immediate application.

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 clear, concise sentence that directly states the tool's function without extraneous detail.

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 set operation with an output schema inferred, the description is sufficient to understand the primary action, though it lacks details on success/failure output or error cases.

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 description clarifies that the parameter refers to a slider, panel, or toggle, and implies the template must already be loaded, but it does not explain the value parameter's types or the exact meaning of template_id beyond the schema field names.

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 'Set' and a clear resource 'single named parameter on a loaded template', and specifies the types (slider/panel/toggle) that distinguish it from related tools like gh_set_slider or gh_set_parameter.

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 mention of when to use this tool versus alternatives such as gh_set_parameter or gh_set_slider; it only describes the action without indicating conditions or alternatives.

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: false already signals mutation, and the description's action (grouping components into a cluster) is consistent with that annotation, so there is no contradiction. However, the description adds little beyond the annotation: it does not disclose side effects on the original components, whether it operates on the active GH definition, or reversibility via gh_cluster_expand.

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 7-word sentence with zero filler and the verb front-loaded, making it very economical. It borders on under-specification given the 0% schema coverage, but unlike a tautology it conveys real semantic content.

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 an output schema present and the mutation annotation covering safety, the description does not need to explain return values or read-only status. Still missing are operational context such as prerequisites (an open GH canvas), how to obtain valid component_ids, and the tool's relationship to gh_cluster_expand, leaving the definition at minimum viable for a simple 2-parameter 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 for documenting the parameters. It only implicitly maps 'components' to component_ids and 'named' to name; it does not explain what format component_ids take, how to source them (e.g., from gh_component_list), or that both parameters are required. The compensation is minimal.

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 (Group), resource (components), and outcome (a named cluster), so an agent can tell this creates a Grasshopper cluster. However, it does not explicitly differentiate from the inverse sibling gh_cluster_expand or from Rhino grouping tools like rhino_group and rhino_group_selected.

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 is given on when to use this tool versus alternatives, no prerequisites are mentioned (e.g., active GH document), and no reference is made to the inverse operation gh_cluster_expand. The only implied usage is what the tool name itself suggests, so the description provides effectively no routing help.

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 annotation readOnlyHint=false signals that the tool modifies the document, and the description implies this without detail. It does not disclose side effects (e.g., whether the cluster itself is deleted or kept) or any other behavioral characteristics beyond the basic action.

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, concise sentence with no unnecessary words. It directly states the purpose in a clear and efficient manner.

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?

The description is minimally sufficient for a simple tool with one parameter, but it does not clarify what 'expand' entails (e.g., whether the cluster is replaced by its components, how the output is structured). The existence of an output schema mitigates this slightly, but the description alone is incomplete.

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 schema provides no description for the only parameter (cluster_id), and the tool description does not mention it at all. Since schema coverage is 0%, the description fails to compensate, leaving the parameter's role entirely implicit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('expand') and the object ('a cluster'), making the purpose understandable. It does not explicitly distinguish itself from sibling tools like gh_cluster_create, but the verb 'expand' is specific enough to avoid confusion.

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 gives no indication of when to use this tool over alternatives, such as gh_cluster_create or gh_component_list. It lacks any context about the appropriate scenario for expanding a cluster.

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 and idempotentHint, and 'List' is consistent with those. The description adds valuable context beyond annotations: the operation is scoped to the active canvas and can be narrowed by a filter. No side effects or hidden behaviors are suggested.

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, front-loaded sentence that states the operation, the scope, and the optional parameter. Every word earns its place; there is no redundancy.

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 list operation with an output schema present, the description covers the core needs: what is listed, where, and the availability of filtering. The annotations cover safety and idempotency, and the output schema handles return-value details. Nothing critical 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?

The description mentions 'optionally filtered' but does not explain what the filter operates on. While the input schema's 'filter' property does contain a description ('Substring to filter component nicknames by.'), at the top level the args parameter has no description and the context signal reports 0% schema description coverage. The description adds only minimal value over the nested schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and resource ('components on the active canvas'), immediately distinguishing this from siblings like gh_components_search (library search) or rhino_list_objects (Rhino document objects). The optional-filter note adds specificity without ambiguity.

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 'currently on the active canvas' clearly establishes the context in which this tool is appropriate. However, it does not explicitly name alternatives or state when not to use it, though the scope alone is strong enough guidance for an agent.

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 mark readOnlyHint and idempotentHint; the description aligns and adds detail about return shape (rows fields, summary block) and catalog scope. No mention of pagination or exact match semantics, but the safety profile is covered by 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?

Three short sentences, no redundancy, front-loaded with verb and resource. Efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only search tool with a rich parameter schema and output format described, the description is sufficient; the workflow hint to gh_add_component completes the picture.

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 nested schema fully describes limit, query, plugin, and category, so the description doesn't need to repeat them. It adds only the workflow tie to gh_add_component. While the reported coverage is 0% at the top level, the visible schema provides complete parameter documentation; description doesn't add further meaning, so 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 identifies the verb 'Search', the resource 'Grasshopper component catalog', and scopes it as 'built-in + plugin-supplied'. It names the sibling gh_add_component and clarifies the catalog’s purpose, distinguishing it from sibling tools like gh_component_list and gh_plugin_list.

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 states the intended workflow: use to find the GUID needed by gh_add_component before dropping a component. It lacks exclusion criteria or alternative routing, but the use case is unambiguous.

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 implies a modification but does not disclose any side effects, failure conditions, or requirements such as the existence of the components or parameter types. It adds little beyond the readOnlyHint annotation.

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, clear sentence that immediately states the purpose without any extraneous 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?

The description is minimal and lacks context about the Grasshopper environment, the requirement that the components and parameters exist, and the effect on the definition. It is complete enough for an expert but not for a general user.

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 description does not explain the parameters, but the schema's property descriptions (e.g., 'Input name or zero-based index.') cover their meanings. Since the schema handles this, the description's lack of parameter detail is acceptable, but it adds no additional value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action and object, 'Create a wire from one component output to another component input,' which specifically distinguishes it from other tools like adding or deleting components.

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 provides no guidance on when to use this tool versus alternatives such as gh_connect_many or gh_add_component. There is no mention of prerequisites, use cases, or when not to use this tool.

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?

Beyond the minimal readOnlyHint=false annotation, the description discloses meaningful behavior: it returns a per-row results array, surfaces partial failures, and defines the status/error fields on each row. This clarifies the non-atomic failure mode, which is the critical behavioral trait for an agent invoking a batch write. It doesn't describe side effects on the GH document, but the core failure semantics are well 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?

Two short sentences that front-load the purpose and add only the essential failure-semantics detail. There is slight internal redundancy ('per-row results array' followed by 'each row carries status and error'), but overall every sentence earns its place and the structure is clean.

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?

The rich input schema covers the connections array and stop_on_error structure, and the output schema covers the return shape, so the description rightly focuses on the missing piece: partial-failure behavior. For a batch tool this is nearly complete, though it omits any hint of prerequisites such as needing an open GH document or guidance on batching limits.

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?

With 0% schema description coverage at the top level, the description should compensate by explaining the connections batch and stop_on_error parameters, but it mentions neither. The nested $defs do carry individual property descriptions, which partially mitigates the gap, yet the description itself adds no parameter-level value.

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 uses a specific verb ('Add') with a clear resource ('multiple wires') and adds the 'single round-trip' batching context, which inherently distinguishes it from single-connection tools like gh_connect_components. However, it never names the sibling explicitly, so the differentiation is implied 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 implies a batch use-case through 'multiple wires' and 'single round-trip', giving an agent a reasonable sense of when to call it. But it provides no explicit guidance about when not to use it, no prerequisites, and no named alternative such as gh_connect_components.

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 the description's 'Read' matches that safety profile without contradiction. The description adds a useful detail by explaining that the result is a list of branches, but it does not disclose edge cases like missing component IDs, invalid outputs, or how the optional 'output' parameter 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?

The description is a single, focused sentence with no filler. It communicates the core action and result format immediately, making it easy for an agent to parse.

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 tool with an output schema and readOnlyHint annotation, the description is nearly complete: it identifies what to read and what format to expect. It only falls short by not addressing the relationship to the batch or set variants, but that is more of a usage-guidance gap than a completeness 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 description coverage is 0%, so the description carries the burden of explaining parameters, but it does not explain 'component_id' or 'output' beyond what the schema shows. 'component_id' and the default of 0 for 'output' are present in the schema, yet the description provides no additional guidance about their meaning or valid values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the operation ('Read'), the resource ('component output'), and the expected return format ('DataTree (list of branches)'). It does not explicitly distinguish from the related sibling tools 'gh_data_tree_get_batch' or the set variants, so it loses the top score.

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 gives no guidance on when to prefer this tool over alternatives such as 'gh_data_tree_get_batch' or 'gh_data_tree_set'. There are no explicit context cues, conditions, or exclusions to help an agent choose among the related sibling tools.

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

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

The readOnlyHint annotation already signals the safe read-only nature. The description adds meaningful behavioral context by explaining that multiple reads are batched into a single bridge round-trip, which is not evident from the schema or annotation alone. It does not contradict any 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 description is appropriately concise: one sentence, front-loaded with the action, and every word adds signal. It avoids restating the name or 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?

The output schema and annotations cover return values and safety, and the description covers the batching behavior. However, the lack of parameter semantics and the absence of guidance on how to construct queries leaves meaningful gaps for an agent selecting and invoking this tool, especially given the nested 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 0%, so the description needs to compensate for parameter meaning, but it does not explain what 'component_id' refers to, what 'output' selects, or how the 'queries' array maps to results. The schema provides structure but not semantic 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 ('Read'), a specific resource ('multiple component outputs'), and a distinguishing mechanism ('in a single bridge round-trip'). This clearly separates it from single-output reads like gh_data_tree_get and from write operations like gh_data_tree_set_batch.

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 when to use this tool: when multiple component outputs need to be read and batching into one round-trip is desired. However, it does not explicitly name alternatives or state when NOT to use it, such as recommending the single-read variant for one output.

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 only readOnlyHint=false provided by annotations, the description must disclose more behavioral context, but it only says 'Push' without explaining effects such as overwriting existing input, triggering recomputation, or failure behavior. There is no contradiction with annotations, but the description adds little beyond signaling a write operation.

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, fluff-free sentence with no wasted words. However, it is under-specified for a tool with a complex nested schema, so the brevity is closer to incompleteness than to effective conciseness.

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 pushes structured data-tree branches into a component input, the one-sentence description is inadequate. It omits how branches/paths/values are structured, which component fields are needed, and how this relates to sibling set/get batch tools. The output schema exists but does not compensate for missing operational context.

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 should compensate, but it does not explain component_id, branches, or input parameters. The term 'DataTree' and 'component input' map only loosely to the nested schema fields, leaving the agent to infer the exact required structure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Push') and resource ('a DataTree') into a component input, so an agent can understand what the tool does. It does not explicitly distinguish from sibling tools like gh_data_tree_set_batch or gh_data_tree_get, but the write direction and component-input target are clear.

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 is given about when to use this tool versus alternatives such as gh_data_tree_set_batch, gh_data_tree_get, or gh_set_parameter. The description provides no context about prerequisites, single-component scope, or cases where another tool would be more appropriate.

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 only declare readOnlyHint=false, so the description carries the burden of explaining side effects. It discloses that the GH document is paused during assignment and recomputed exactly once, which is genuinely useful behavioral context for a mutation tool. A small gap remains around mid-batch failure behavior, but the core side effect is well 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?

Two sentences, front-loaded with the purpose statement, with no filler. The defer_solve explanation earns its place by pairing the mechanism with the motivating use case.

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 complex nested-schema write tool, the description plus annotations and output schema cover the essential call requirements: what to write, the batching mechanism, and the read-only/write posture. It doesn't spell out that a GH document must exist or how component_id maps to an added component, but sibling tools (gh_add_component, gh_data_tree_get) establish that context.

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?

Top-level schema coverage is 0%, so the description must compensate; it thoroughly explains defer_solve's behavioral meaning and why its True default matters. The remaining parameters (assignments, component_id, branch path/value structures) are structurally clear and partially documented inside the nested schema defs, so the description doesn't need to re-explain 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?

The description states a specific action ('Apply many DataTree assignments') on a concrete resource, and the 'many ... at once with a single GH solve' phrasing encodes the batch semantics that distinguish it from the single-assignment sibling gh_data_tree_set. The annotation title 'GH: Write DataTree (batch)' reinforces the write direction.

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 explicitly contrasts the tool with N independent 'set' calls and identifies the exact scenario (parameter sweeps) where batching is critical. It also explains the default defer_solve=True behavior as the mechanism that makes the batch path preferable, giving an agent a clear decision rule.

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=false and destructiveHint=true, so the destructive nature is covered. The description's 'Remove' is consistent with those annotations and adds the canvas scope, but it does not disclose side effects like whether connected wires are removed or whether the action is reversible.

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, front-loaded sentence with no filler or repetition. It is concise without being a tautology, though the brevity leaves out useful supporting details.

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 one-parameter destructive tool, the description covers the basic action, and annotations plus output schema provide safety and return information. However, it is still missing parameter semantics and any guidance on side effects, making it minimally viable rather than 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?

The input schema defines component_id as a plain string, and the description gives no detail about what this ID refers to, how to find it, or what format is expected. With 0% schema description coverage, the description should compensate but does not, offering only the weak hint that a 'component' is being removed.

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 ('Remove') and resource ('a component from the canvas'), which gives the agent a clear sense of what the tool does. It is essentially a paraphrase of the tool name, but the 'canvas' context helps distinguish it from Rhino object deletion tools and Grasshopper creation 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 guidance on when to use this tool versus alternatives such as gh_add_component, gh_component_list, or rhino_object_delete. No prerequisites are mentioned, such as how to obtain a component_id or whether the component must exist before deletion.

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 is consistent with the readOnlyHint annotation and does not contradict it. It adds only the context that a 'current value' is being read; no additional behavioral details such as source document, staleness, or side-effect-free guarantees are disclosed, but the annotation already covers the safety profile.

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 focused sentence with no filler. The core action and resource are front-loaded, making it easy to parse quickly.

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 operation with readOnlyHint and an output schema, this is mostly adequate. However, the missing parameter semantics and lack of routing to the paired write tool leave an agent with some ambiguity about how to identify the component/parameter and when to prefer this over related gh_* tools.

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 the description does not explain component_id or the output parameter beyond what the schema's terse 'Output name or zero-based index' already states. The agent must infer that component_id selects a Grasshopper component and that output selects the specific parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Read') and the resource ('current value of a component parameter'), and the readOnlyHint annotation aligns with this. It does not explicitly differentiate from siblings like gh_set_parameter or gh_data_tree_get, but the read-vs-set contrast is strongly implied.

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 gives no guidance on when to use this tool versus alternatives such as gh_set_parameter, gh_data_tree_get, or gh_component_list. The read-only use case is implied but no explicit when/when-not guidance or alternative routing is 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?

The annotations only indicate readOnlyHint=false, so the agent knows this is not a pure read operation but gets no destructiveHint coverage. The description says 'Open a bundled template on the canvas' but does not disclose whether it replaces existing canvas content, preserves it, or otherwise mutates the canvas beyond loading. The mutation scope is left to inference.

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 sentence with no filler, front-loading the action and then stating the return payload. It is appropriately concise and structured, though the missing usage/alternative context is a substantive omission.

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?

The presence of an output schema means return values do not need further elaboration, but the description does not clarify how this tool relates to the near-sibling 'gh_run_template,' nor does it explain the effect of loading on the current canvas. For a mutating tool with only readOnlyHint=false and no other behavioral annotations, this is an important 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 description adds no parameter-level detail for 'name' or 'canvas_target,' but the input schema already provides useful descriptions for both: name is sourced from gh_template_list, and canvas_target accepts 'active' or 'new.' Since the schema carries the parameter semantics, the description does not need to repeat them, though a brief pointer would have been helpful.

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: 'Open a bundled template on the canvas' and clarifies the return value as 'template_id + parameter map.' This is clear and not a tautology. It stops short of a 5 because it does not explicitly distinguish itself from the closely related sibling 'gh_run_template.'

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 about when to use this tool versus alternatives such as 'gh_run_template' or 'gh_template_list.' The name parameter in the schema points to gh_template_list for valid names, but the description itself does not explain the selection context or say when loading is preferred over running a template.

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 annotations only provide readOnlyHint=false, indicating a mutation but not detailing side effects. The description adds minimal context beyond the purpose: it does not disclose whether the current canvas is closed without saving, how the optional name is applied, or what happens to unsaved work. For a document-creation tool, this is a significant behavioral transparency gap.

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 with no redundant words. It delivers the core purpose immediately, and every word contributes 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?

For a simple creation tool, the description is not fully complete: it omits the optional name parameter and any side effects on the current canvas. The output schema may document return values, but behavioral context around creating/replacing a document is missing, which an agent needs to make safe calls.

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 sole parameter 'name' (default 'untitled') is described in the schema as 'Document name,' but the tool description makes no mention of it or its effect. With schema description coverage reported at 0%, the description does not compensate, so an agent reading the description alone would not know the new canvas can be named.

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 clear action ('Create') and a specific resource ('fresh empty Grasshopper canvas'). It clearly distinguishes from siblings like gh_open_file and gh_load_template, making the tool's role unambiguous. The qualifiers 'fresh empty' further clarify that this starts a blank canvas rather than loading content.

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 usage for starting a new blank canvas but does not explicitly state when to prefer it over alternatives such as gh_open_file or gh_load_template. No exclusions, conditions, or prerequisite steps are provided, leaving the agent to infer the appropriate context.

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=false already signals a state-changing operation, and the description adds no behavioral context beyond that. Critically, it does not disclose what happens to the currently open Grasshopper definition when a file is opened (e.g., replacement, risk of losing unsaved work). No contradiction exists, but the description contributes none of the behavioral disclosure an opening-file action warrants.

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, complete sentence with no filler and the verb front-loaded. It is appropriately sized for a one-parameter tool, though the brevity borders on under-specification.

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 with a near-identical sibling (rhino_open_file) and a mutation annotation, the description omits the key context an agent needs: which file types it targets versus Rhino documents, and what happens to the current definition on open. The schema documenting 'path' and the existence of an output schema do not compensate for these gaps.

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 description mentions no parameter at all, and the top-level 'args' schema node lacks a description (0% coverage per context signals). Only the nested 'path' property is documented ('Absolute path to a .gh / .ghx file.'), so the description fails to compensate for the coverage gap at the parameter level.

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 uses a specific verb ('Open') and a domain-specific resource ('Grasshopper definition'), which maps cleanly to .gh/.ghx files per the schema. The term 'Grasshopper definition' implicitly distinguishes this from the near-identical sibling rhino_open_file (which opens Rhino documents). However, it relies on domain knowledge rather than naming the alternative, so it stops 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?

No guidance is given for when to use this tool versus rhino_open_file or other gh_* siblings. The description neither states prerequisites (e.g., file existence, an active Grasshopper session) nor exclusions. An agent must infer the use case from the tool name 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?

The annotation only declares readOnlyHint:false, and the description confirms a mutating create action while adding a useful behavioral contract: it returns the new component_id for chaining. This goes beyond the annotation by telling the agent how the output will be consumed in later steps. It does not disclose potential side effects like coordinate validation or canvas state requirements, but the core behavior is transparent.

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 two sentences with no filler: the first sentence states the primary purpose, and the second explains the return value and its follow-up use. This is well front-loaded and every sentence 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?

Given the tool's write nature and creation role, the description adequately explains the primary purpose and the return contract. It mentions the relevant follow-up tools, which helps an agent plan a multi-step workflow. It could additionally note that a valid Grasshopper canvas is required, but the output schema and existing annotations reduce the need for extensive detail.

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 description maps 'bounds and initial value' to the min/max/value parameters, and the schema itself provides detailed descriptions for all properties inside args. However, schema coverage is reported as 0% at the top-level args parameter, and the description does not mention x, y, name, or decimals. The partial compensation plus the schema's embedded property descriptions make this adequate but not fully self-sufficient.

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 and resource: 'Create a Number Slider on the canvas with bounds and initial value.' This clearly distinguishes it from generic component creation tools like gh_add_component and from modification tools like gh_set_slider. The mention of bounds and initial value uniquely identifies the slider-specific purpose.

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 provides a clear usage sequence by noting the returned component_id enables subsequent gh_connect_components or gh_set_slider calls. However, it does not explicitly state when to choose this tool over alternatives such as gh_add_component or gh_set_slider, nor does it mention exclusions/preconditions like needing an open Grasshopper canvas.

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 idempotentHint=true, so the safety profile is covered. The description adds useful behavioral detail by stating it returns one entry per GH_AssemblyInfo library and emphasizing 'currently loaded,' which clarifies that only plugins loaded in the live session are listed, not merely installed ones.

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 concise and front-loaded: it states the action first, then the output shape, then the motivating use case. Every sentence adds value, with no filler or redundancy.

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 read-only, zero-parameter listing tool with an output schema, the description covers all essential aspects: what is enumerated, what each entry contains, and when an agent should call it. No missing prerequisites, side-effect warnings, or return-value explanations are needed.

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 input schema contains no real parameters—only an empty 'args' object—so there is little for the description to explain. A baseline of 4 applies for zero-parameter tools. The description does not explicitly say 'takes no arguments,' but the schema itself already makes that evident.

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 opens with a specific verb and resource: 'Enumerate Grasshopper plugin libraries currently loaded.' It clearly differentiates from sibling component-oriented tools like gh_component_list and gh_components_search by targeting plugin assemblies rather than canvas components, and it lists the returned fields (id, name, author, version, description, path).

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 gives a concrete use case: discover whether the user has LunchBox, Ladybug, Kangaroo, etc. installed before attempting to drop in a custom component. It does not explicitly name alternatives or state when not to use this tool, but the provided context makes the intended invocation scenario 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?

The readOnlyHint=false annotation already signals mutation, and the description adds that preview state changes for selected components or all. However, it does not explain whether 'toggle' means flip current state or set it according to the 'enabled' parameter, nor does it describe any side effects or requirements such as needing an open Grasshopper document.

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, front-loaded sentence with no filler. Every word contributes meaning: the action, the target resource, the optional scope, and the 'all' case are all conveyed efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity and existing output schema, the description is mostly adequate, but it leaves ambiguity around the enabled parameter's role and the exact way to target all components. It also does not clarify that this is Grasshopper-specific preview behavior, which could matter given the large sibling toolset.

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 carries the burden. It does add meaning by linking 'on/off' to the enabled boolean and 'a list of components (or all)' to component_ids. However, it does not explicitly explain that null component_ids means all, or that enabled determines the target state rather than toggling based on current state.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Toggle preview on/off') applied to a specific resource ('a list of components (or all)'). This distinguishes it from sibling tools like rhino_render_preview or gh_bake_to_rhino because it focuses on Grasshopper component preview state.

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 is given about when to use this tool rather than alternatives. There is no mention of prerequisites, exclusions, or comparison with similar preview/visibility tools like rhino_viewport_preview or gh_component_list. The intended context is only implied by the name and the word 'components.'

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 flag this as destructive, and the description adds the specific behavior that the cached solution gets cleared. This goes beyond a generic 'reset' by naming what is affected, though it does not clarify whether the definition or canvas contents themselves are also cleared.

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 one short, front-loaded sentence with no filler. Every word contributes to explaining the action and its main effect.

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 zero-argument tool with an output schema and annotations already marking it destructive, the description is nearly sufficient. It clearly names the action and target, though it could have clarified that it only clears the cached solution and does not delete the Grasshopper definition.

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 confirms this, so there is no parameter documentation burden on the description. The baseline of 4 applies because no parameter-level clarification is needed.

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 names a specific action ('Reset') and a target ('the canvas'), with a clarifying parenthetical ('clear cached solution') that tells the agent what the reset actually does. It is distinguishable from siblings like gh_new_canvas or gh_run, though it does not explicitly contrast itself with those 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?

The phrase 'clear cached solution' implies the tool is for situations where a stale or cached Grasshopper solution must be discarded. However, there is no explicit guidance about when to prefer gh_reset over related alternatives such as gh_new_canvas, gh_run, or gh_open_file.

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 readOnlyHint=false, the description only adds that the action applies to the current solution. It does not disclose that running a Grasshopper solution recomputes the graph, may update geometry or baked data, or could be time-consuming. The description does not contradict the annotations, but it adds little beyond them.

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 extremely compact and front-loaded with the action verb. However, it is under-specified rather than efficiently detailed: it avoids all useful elaboration, making it minimally adequate but not a model of concise clarity.

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 execution-style tool, the description omits prerequisites such as having an active Grasshopper document, side effects of running a solution, and the role of the new_solution parameter. The output schema may describe return values, but the decision context and behavioral impact are not covered.

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 description never mentions the new_solution parameter or explains the difference between running the current solution and forcing a fresh one. The schema contains only a bare 'Force a fresh solution' description, so the tool description adds no compensating parameter semantics given the low schema coverage signal.

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 names a specific action ('Run') and a specific resource ('current solution'), and the title confirms the Grasshopper context. It is not a tautology and is distinguishable from most sibling creation tools, though it does not explicitly differentiate itself from gh_run_template.

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 is given about when to use this tool instead of gh_run_template, gh_reset, or Rhino run commands. There are no conditions, prerequisites, or exclusions, so the agent must infer the intended context from the name 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?

The description adds useful behavioral context beyond the readOnlyHint=false annotation: it signals that the tool forces a fresh solution rather than reusing a cached one, and that baking outputs into Rhino is optional. However, it does not disclose potential document mutation implications, what happens to prior solution state, or failure/timeout 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?

The description is a single tight sentence with no filler or repetition. It is front-loaded with the primary action, though it errs on the side of being terse given the tool's parameter and workflow complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the surrounding sibling tools and the required template_id workflow, the description is too thin. It does not explain that the template must first be loaded via gh_load_template, how this differs from running the active definition with gh_run, or what 'declared outputs' refers to operationally.

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 effectively 0% for the top-level parameter, so the description should compensate by explaining parameters. It only hints at the 'bake' behavior and says nothing about template_id, layer, or timeout_seconds, leaving the agent to rely on the nested schema descriptions for those important details.

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 names a clear action ('Force a fresh solution') and a concrete optional outcome ('bake the declared outputs'), which maps well to running a Grasshopper template. It is understandable in context, but it does not explicitly differentiate gh_run_template from the closely related gh_run or gh_bake_to_rhino 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 guidance about when to use this tool versus alternatives such as gh_run, gh_load_template, or gh_bake_to_rhino. The workflow dependency on gh_load_template is only implied by the parameter name, and there are no exclusions or conditions for choosing this tool.

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 signal write behavior (readOnlyHint: false), and the description's 'Save' matches that. It does not go beyond the annotation to disclose overwrite semantics, failure modes if no default path exists, or whether any confirmation is given, but for a save operation the basic behavior is clear and consistent.

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, front-loaded sentence with no filler. It communicates the core operation immediately and leaves details 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?

For a simple save operation with one optional path parameter, an output schema, and an annotation marking it as a write, the description is largely sufficient. It could mention the default-path behavior or when no active definition exists, but the schema already covers the path default, so the main gap is only the usage guidance captured above.

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 description adds no parameter-specific detail, but the input schema's path property already explains that it defaults to the open file. Because the schema provides the essential semantics, the lack of extra description is acceptable, though the tool description itself does not guide parameter choice.

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 clear action ('Save') and a specific resource ('the active Grasshopper definition'), which immediately distinguishes this from Rhino document save tools like rhino_save / rhino_save_as and from gh_open_file. No ambiguity remains about what the tool operates on.

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 about when to use gh_save_file versus alternatives such as gh_bake_to_rhino, gh_open_file, or rhino_save. The context is implied by the name, but the description does not state prerequisites (an open definition) or exclusions.

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 provide readOnlyHint=false, and the description explicitly indicates a mutating operation on a Panel's text, which is consistent. However, it adds little behavioral depth beyond the basic 'set' action—it does not say whether text is overwritten wholesale, whether the component must already exist, or what side effects occur.

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 one front-loaded sentence with no filler. It is appropriately concise for a simple tool, though it could have used the saved space to add parameter or usage context.

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?

The tool is simple and an output schema exists, so return-value documentation is not required. Still, the description omits how to identify the target Panel beyond the schema field name and lacks any guidance on how component_id relates to the broader Grasshopper document, making it minimally viable rather than 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 0%, and the description only sheds light on 'text' ('text contents'); it does not explain component_id's role or how to obtain/format it. The parameter names and titles are self-explanatory at a basic level, but the description does not compensate for the lack of schema documentation.

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 ('set'), a precise resource ('text contents of a Panel component'), and this distinguishes it from sibling gh_set_slider/gh_set_toggle/gh_set_parameter tools. The GH context is reinforced by the title, so there is no ambiguity about which component type is targeted.

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 is given on when to choose this tool over alternatives such as gh_set_parameter or gh_set_toggle, nor does it mention prerequisites like obtaining a component_id from gh_component_list. The description only states what the tool does, not when to use it.

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 only restates that a value is pushed into a parameter, which aligns with readOnlyHint=false but adds little. It does not disclose whether the parameter is replaced or appended, whether recomputation is triggered, or what happens on invalid typed input.

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 focused sentence with no filler. The action verb is front-loaded and the resource is clearly stated, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description is too thin for an agent to safely invoke this tool. It omits how to identify the component, how to name/select the parameter input, and how the typed value maps to Grasshopper data.

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% at the top level, and the description does not compensate. It does not explain the role of component_id, how input selects a parameter, or how the GhParameterValue discriminated union should be constructed.

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 uses a specific verb ('Push') and a specific resource ('a component parameter'), making the core action clear. It broadly distinguishes itself from getter siblings like gh_get_parameter, though it does not explicitly name alternatives.

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 tool versus alternatives such as gh_connect_components, gh_set_slider, or gh_get_parameter. An agent gets no explicit context about prerequisites or conditions that would route it to this tool.

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 only set readOnlyHint to false, so the description must carry the behavioral burden. It does not disclose potential side effects, whether the value must be within an existing slider range, or what happens if an invalid component_id is provided. The description adds no behavioral context beyond the mutation implied by 'Set'.

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 front-loaded sentence with no filler or redundant phrasing. It is efficiently structured, though it carries so little detail that the conciseness borders on under-specification.

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 setter operation, this is minimally viable: it states the target component and the value to set, and an output schema exists so return-value documentation is not required. However, it omits context about slider domain constraints and how component_id is resolved, leaving notable gaps for an agent invoking the tool 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 should compensate for missing parameter documentation. It clarifies that the value is numeric, matching the schema type, but it does not explain component_id semantics, such as the expected identifier format or that it must reference an existing slider component.

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 uses a specific verb ('Set') with a clear resource ('Number Slider component') and target ('numeric value'), making the operation unambiguous. It does not explicitly distinguish from siblings like gh_place_slider or gh_set_parameter, but the component type is specific enough to avoid most confusion.

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 provides no guidance on when to use this tool versus alternatives such as gh_set_parameter, gh_set_toggle, or gh_place_slider. It also does not mention prerequisites like the slider needing to already exist in the Grasshopper document.

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 provide readOnlyHint=false, and the description's 'Set' matches that mutating behavior. However, the description adds no additional behavioral context such as whether the change persists, whether it triggers recomputation, or what happens if the component_id is invalid.

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 clear sentence with no filler. The core action is front-loaded and 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?

For a simple setter with an output schema, the action is clear, but the description omits how to identify the target component and any operational context. It is adequate but minimal.

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 phrase 'to true or false' explains the value parameter, but the required component_id parameter is not described at all. With 0% schema description coverage, the description must compensate but only partially does.

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 uses the specific verb 'Set' and names the resource 'Boolean Toggle component' with the target values 'true or false'. This clearly distinguishes it from sibling setters like gh_set_slider and gh_set_panel, which target different component types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use or when-not-to-use guidance is given. The description does not mention alternatives such as gh_set_slider, gh_set_panel, or gh_set_parameter, nor does it state prerequisites like the component needing to exist in the Grasshopper document.

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 the description adds meaningful behavioral context by defining the available=False state and explaining that loading will fail until the .gh binary is shipped. This helps the agent interpret list results without attempting doomed loads.

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 short, front-loaded with the core purpose, and every sentence adds value. The available=False caveat earns its place by preventing incorrect assumptions about template readiness.

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 an output schema present and a readOnly annotation, the description covers the key behavioral nuance that could cause failures. It is slightly incomplete only because it does not mention the relationship to load/run template tools, but this is a minor gap for a simple listing operation.

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 schema has only an empty args wrapper with no meaningful properties, so there are effectively no parameters to document. The description does not need to add parameter details; the baseline for an effectively zero-parameter tool 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?

The description states a specific verb and resource: 'List bundled Grasshopper templates with their parameter contracts.' This clearly identifies what the tool does and distinguishes it from generic listing tools like gh_component_list or gh_plugin_list by focusing on templates and their parameter contracts.

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 gives no guidance on when to use this tool versus alternatives such as gh_load_template or gh_run_template. There is no mention of prerequisites, exclusions, or a recommended workflow for discovering templates before loading them.

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 clearly states that the operation maximizes the active viewport and is view-related rather than a model-editing action. It does not mention whether the action toggles back to a multi-viewport layout, but for a simple no-argument viewport command this is a minor gap.

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, focused sentence that front-loads the action and then specifies the target and result. There is no filler, redundancy, or repetition of schema 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 parameterless viewport command with an output schema present, the description provides the essential info an agent needs to invoke it correctly. It is only missing a brief statement about when to choose this over rhino_3view or rhino_4view, so it is strong but not maximal.

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 and an empty input schema, so there is no parameter meaning for the description to add. The baseline 4 applies here because no parameter documentation is required.

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 uses a concrete verb ('Maximize') with an identifiable resource ('active viewport') and a clear outcome ('fill the entire viewport area'). It is unambiguous, though it does not explicitly contrast itself with siblings like rhino_3view or rhino_4view, so differentiation relies on name and 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?

The intended use is reasonably implied: use it when the active viewport should be enlarged to fill the screen. However, there is no explicit when-to-use guidance, no mention of alternatives, and no exclusions, leaving the agent to infer selection among the many viewport-related tools.

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

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

With no annotations provided, the description must carry behavioral context. 'Switch to the three-viewport layout' conveys a viewport configuration change and implies a non-geometric UI action, but it does not mention side effects such as preservation of camera positions, undoability, or behavior if already in that layout.

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, front-loaded sentence with no filler. Every word contributes to meaning, making it an ideal concise definition for a simple 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?

Given the tool's trivially simple nature, zero parameters, and existence of an output schema, the description is sufficiently complete for an agent to invoke it correctly. It lacks only deeper behavioral context, but none is essential for a layout switch.

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 is 4. The empty input schema fully describes the lack of arguments, and the description does not need to add parameter-level detail.

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 ('Switch to') and a specific resource ('three-viewport layout'). It is clear and distinguishes itself from siblings like rhino_1view and rhino_4view by explicitly naming the three-viewport layout, though it does not explicitly reference those alternatives.

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 usage is implied: call this tool when you want the three-viewport layout. However, it provides no explicit guidance about when to choose it over rhino_1view or rhino_4view, nor any exclusions or prerequisites. The purpose effectively carries the usage context.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It transparently describes the visible result—switching to the four named viewports—which is the core behavioral effect of the tool. It does not mention subtler side effects such as preserving or resetting zoom or the active viewport, but for a simple viewport-layout command this is a minor gap.

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, front-loaded sentence with no filler or repetition. Every word contributes to identifying the action and the exact resulting viewport configuration.

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 zero-parameter viewport-switching command, the description provides the essential information: the action and the resulting layout. An output schema exists to define return values, so the description does not need to cover those. The only missing context is explicit handling of the current viewport state, but this is a low-complexity tool and the description is otherwise 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?

The tool has zero parameters, so there is nothing for the description to document beyond implying a no-argument call. The baseline of 4 for parameterless tools applies, and the description adds no conflicting or redundant parameter details.

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 clear action ('Switch to') and a specific resource (the standard four-viewport layout), and names the exact viewports (Top, Front, Right, Perspective). This makes the tool unambiguous and distinguishes it from viewport-related siblings like rhino_1view and rhino_3view.

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 intended use case is inferable: call this when the user wants the standard four-viewport arrangement. However, the description does not explicitly mention when not to use it or name alternatives such as single-view or three-view layouts, leaving the comparison to sibling tools implicit.

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 burden of behavioral disclosure, and 'enter creation mode' discloses almost nothing. It does not say whether the tool blocks waiting for interactive canvas input, requires a prior selection, produces an object, or what side effects it has. The mode-based language strongly implies a non-deterministic, interactive behavior that is left entirely unspecified.

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 brief, but this is under-specification rather than disciplined conciseness - the single sentence is vague and does not earn its place because it conveys almost no operational information beyond the tool name itself.

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?

Although the empty parameter list reduces the documentation burden, the description still fails to explain the interactive mode behavior, what the output represents, or how it relates to the overlapping sibling 'rhino_clipping_plane.' The existence of an output schema helps, but the mode semantics and the distinction from the sibling remain significant gaps.

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 and an empty input schema, so there is no parameter documentation burden for the description to carry. Per the baseline for 0-parameter tools, a score of 4 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?

The description 'Enter clipping plane creation mode' is nearly a tautology of the tool name 'rhino_add_clipping_plane' - both convey the same idea of creating/adding a clipping plane. It adds only the word 'mode,' which hints at an interactive workflow, but it never states what a clipping plane is, what creating one entails, or how this differs from the sibling 'rhino_clipping_plane.'

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 zero guidance on when to use this tool versus alternatives. Notably, a sibling tool 'rhino_clipping_plane' exists and no distinction is made between the two - an agent cannot determine whether this mode-entry tool or the sibling performs the actual clipping plane operation. No context, 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 no annotations, the description carries the behavioral burden. It states the core side effect (adds a control point to the end) and the prerequisite (a selected NURBS curve), but does not disclose whether the curve is modified in place, how the selection is resolved, or any failure conditions. The primary mutation is clear, though.

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 with no filler. Every word contributes either the target, the position, or the prerequisite, making it easy for an agent to parse quickly.

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 zero-parameter tool with an output schema, this is nearly complete: it identifies the object type, selection state, and insertion location. It would be stronger with an explicit note about modifying the original object or requiring an active selection, but the simplicity of the tool and presence of the output schema cover most gaps.

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 input schema has zero properties, so there are no parameter descriptions to supplement. The description adds the essential implicit parameter: the operation applies to a selected NURBS curve at its U-direction endpoint, which is exactly the guidance an agent needs when no explicit arguments are accepted.

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?

Description uses a precise verb ('Add') and names the specific resource ('control point'), the target ('selected NURBS curve'), the position ('to the end'), and the direction ('U direction'). This clearly distinguishes it from siblings like rhino_remove_control_point and rhino_set_control_points.

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 only usage cue is the operation itself — an agent can infer it should be used when a control point needs to be appended to a NURBS curve. It does not explicitly state when to prefer it over rhino_set_control_points or rhino_edit_points_on, nor does it mention exclusions or prerequisites beyond selection.

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 of behavioral disclosure. It indicates a modal interaction ('placement mode') but does not explain whether an object is created, whether user input is required, what happens after placement, or whether the command is destructive or reversible.

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, well-structured sentence with no filler. It front-loads the action and is appropriately sized for a zero-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?

For a zero-parameter tool with an output schema, the description does not need to document return values, so the main gap is behavioral context. The phrase 'placement mode' is ambiguous about whether the tool requires interactive user input or simply creates an angular dimension, making the description minimally viable but not fully 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?

The tool has zero parameters, so the baseline is 4. There are no parameter semantics for the description to clarify, and the empty input schema already conveys that the tool takes no arguments.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Enter') and identifies the resource ('angular dimension placement mode'), which distinguishes it from linear, aligned, ordinate, and radial dimension siblings. It stops short of a 5 because it does not state the resulting outcome or how the mode affects the document.

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 about when to use this tool versus alternatives such as rhino_dimension_angular or other dimension-placement tools. No prerequisites, selection requirements, or exclusions are mentioned, leaving the agent to infer appropriate use from the name 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?

With no annotations, the description must disclose behavior itself, but it only states that a placement mode is entered. It does not say what happens next, whether a dimension is immediately created, whether the command blocks awaiting user clicks, or what state changes occur.

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 entire description is one short sentence and is front-loaded with the essential action and resource. There is no redundant wording or structured fluff.

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 zero-argument mode-entry tool, the description gives the bare minimum needed to know what command to invoke. However, it lacks context about the interactive nature of placement mode and does not mention how this relates to other dimension tools, leaving the agent to guess about the resulting behavior.

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 and the schema covers them completely, so the description does not need to add parameter documentation. The baseline for a no-parameter tool is therefore 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?

The description identifies a specific action ('enter placement mode') and resource ('linear dimension'), so an agent can tell it is not adding an angular, aligned, or radial dimension. It remains slightly ambiguous whether this creates a dimension or starts an interactive mode, and it does not distinguish itself from the similarly named rhino_dimension_linear.

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 gives no explicit guidance about when to choose this tool over alternatives such as rhino_dimension_aligned or rhino_dimension_linear. There is no mention of prerequisites, workflow context, or whether the user must interact with the Rhino viewport after the mode starts.

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 to indicate safety or side effects, the description carries full burden. It only mentions entering a mode, without disclosing whether this creates objects, modifies the document, or requires user interaction. No behavioral implications are explained.

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, focused sentence with no unnecessary words. It is exceptionally concise and well-structured.

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?

The description provides only a minimal phrase without context about the mode's purpose, duration, or what happens after entering it. It lacks crucial operational details that a user or agent would need to understand the tool's function fully.

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 of 4 applies. The description does not need to explain parameters because they do not exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (enter placement mode) and the object (ordinate dimension), which is specific enough. However, it lacks the additional clarity of naming the resource type explicitly (e.g., 'dimension') and could be more explicit about what 'mode' entails, so it is not a perfect 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?

No guidance is provided on when to use this tool versus alternatives like rhino_add_dimension_linear or rhino_add_dimension_angular. The agent is left without context to choose this tool appropriately.

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 burden of explaining behavior. It indicates the tool enters a placement mode, but it does not disclose that this is likely an interactive operation requiring user input, whether it creates an object, or what the tool returns. The behavioral surface is therefore largely unspecified.

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, front-loaded sentence with no filler or repetition. It communicates the core action efficiently and is appropriately sized for a tool with no parameters.

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 parameterless tool, the description covers the basic purpose adequately. However, it omits important context about the interactive nature of dimension placement mode, what the user or agent should expect after entering the mode, and whether any geometry selection is required first. The output schema exists, but behavioral context is still thin.

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 and the input schema is empty, so there is nothing for the description to add about parameter semantics. The baseline for zero-parameter tools is 4, and no deduction is warranted.

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 uses a specific verb and resource: it enters radial/radius dimension placement mode. This clearly distinguishes it from sibling dimension tools like linear, aligned, angular, and ordinate dimensions. It stops short of a 5 because it does not explicitly name those alternatives, but the purpose 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?

There is no guidance about when to use this tool versus other dimension tools such as rhino_add_dimension_linear or rhino_add_dimension_angular. The description only states what the mode is, leaving the agent to infer when it should be invoked. No exclusions, prerequisites, or alternatives are mentioned.

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 of behavioral disclosure, but it only restates the mutation ('Add a directional light to the scene'). It says nothing about coordinate system, default orientation, side effects, or whether existing lights are affected. No contradiction with annotations exists, but almost no behavioral context beyond the action is provided.

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 short, front-loaded, and contains no filler: a one-sentence purpose followed by a parameter line. It is easy to scan, though the parameter section is thinner than ideal.

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?

Although an output schema exists, this is a mutation tool with no annotations and no direction-convention guidance. It also lacks differentiation from the many other lighting-related sibling tools, so an agent lacks enough context to invoke it correctly in all situations.

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. The line 'direction_x, direction_y, direction_z: Light direction vector' is the only parameter documentation and at least groups the three values into a meaningful vector concept. However, it omits the coordinate system, normalization expectations, and how the default (0,0,-1) relates to scene orientation, so it only partially compensates for the missing schema 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?

The description uses a specific verb+resource ('Add a directional light to the scene'), clearly stating what the tool does. The noun 'directional light' inherently separates it from point and spot light siblings, though it never explicitly names an alternative, so it stops 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?

No guidance is provided on when to use this tool versus rhino_add_point_light, rhino_add_spotlight, or rhino_light_add. There are no exclusions, prerequisites, or context cues; an agent must infer the intended use from the name 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It discloses the creation side effect ('Add'), but does not mention coordinate system, units, layer behavior, visibility, or whether an object is actually created in the document. This is a thin description for a mutation tool with no annotation safety signals.

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 very short and front-loaded: the core purpose appears in the first sentence, followed by a compact parameter list. Every sentence earns its place and 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 four-parameter tool with an output schema, the basics are present. However, with no annotations and no differentiation from sibling text/dot/point tools, the agent lacks important context about coordinate conventions and when this specific operation is appropriate.

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 only paraphrases the parameter names: 'Dot label text' and 'Location coordinates.' This adds little beyond the schema titles and provides no detail about units, coordinate space, integer semantics, or behavior when text is empty.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action: 'Add a small text dot annotation at a 3D location.' It identifies the verb (add), the resource (text dot annotation), and the location context. However, it does not distinguish this tool from closely named siblings like rhino_text_dot or rhino_add_text, so it misses the differentiation needed for 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?

No guidance is given about when to use this tool versus alternatives such as rhino_text_dot, rhino_add_text, or rhino_add_point. The usage context is only implied by the name and description, with no exclusions or alternative routing.

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 must carry the behavioral disclosure burden. It only states the basic mutation without explaining what happens if no curve is selected, whether the curve must be planar, how pattern names are validated, or what side effects occur in the Rhino document.

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 compact, front-loads the core action and prerequisite, and uses a short Args list for the two parameters. There is no filler or redundant restating of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the basic action and prerequisites, and the presence of an output schema reduces the need to document return values. However, important operational context is missing, such as failure behavior for invalid selections, pattern availability, and relationship to the similar rhino_hatch sibling.

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 is the only source of parameter meaning. It gives a brief definition for each parameter and useful examples for hatch_pattern, but it leaves out valid pattern enumeration, scale constraints, and what values are appropriate beyond the defaults.

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 clear action ('Add'), a specific resource ('hatch fill'), and a target ('selected closed curve'). It does not explicitly differentiate itself from the sibling rhino_hatch tool, but the intended operation is otherwise 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?

It implies usage by requiring a selected closed curve, but gives no explicit when-to-use guidance, exclusions, or alternatives. With sibling rhino_hatch available, an agent gets no help deciding between them.

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 of explaining behavior. It does reveal that the tool enters an interactive 'mode,' which is useful, but it does not explain what happens after entering the mode, whether user interaction is required, how the mode is exited, or what side effects occur.

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, efficient sentence with no filler. The core action and object are front-loaded, and every word contributes 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?

For a tool with no annotations and no parameters, the description is minimal but leaves an important gap: it is unclear whether this is a blocking interactive mode, a toggle, or a command that simply starts a placement workflow. The presence of sibling tools like rhino_leader makes the lack of disambiguation more consequential.

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 there is no parameter ambiguity for the agent. The description does not need to add parameter-level semantics because the schema already fully covers an empty input contract.

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 names a specific action ('Enter ... placement mode') and a specific resource ('leader annotation'), so an agent can tell this is about placing leader annotations. However, it does not distinguish this tool from the sibling rhino_leader, which likely refers to the same concept.

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 about when to use this tool versus alternatives such as rhino_leader, rhino_annotation_callout, or the various dimension tools. It also does not mention prerequisites or expected workflow context.

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 burden of behavioral disclosure. It does not mention side effects such as whether selected objects are removed from the model, whether block instances are updated, or whether the operation is reversible. This is a meaningful gap for a 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?

The description is short and front-loaded with the primary action. It contains no filler and every sentence contributes to understanding what the tool does.

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?

The tool is simple and has an output schema, so return values need no explanation. However, because there are no annotations and the tool mutates a block definition, the description should provide more context about selection requirements, side effects, and failure behavior to be fully 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 0%, but the description compensates by explaining the only parameter: 'name: Block definition name to add objects into.' This adds meaningful context beyond the raw schema, though it omits any constraints like case sensitivity or name format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Add currently selected objects to an existing block definition.' This clearly distinguishes the tool from sibling block operations like block creation, insertion, or redefinition.

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 the intended use: when you have selected objects and an existing block definition. However, it does not explicitly state when to prefer this over alternatives such as rhino_block_redefine or rhino_block_define, nor does it mention prerequisites like having a current selection.

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 full burden of behavioral disclosure. It only states the action and coordinates; it does not mention side effects (e.g., adding to the document), return values, coordinate system, units, or error conditions. This is limited transparency for a creation 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?

The description is a single clear sentence with no unnecessary words. It is concise and directly conveys the essential information without redundancy or ambiguity.

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 creation tool, the description provides the core information, but it omits context such as the returned object (since an output schema exists), the coordinate system (world vs. local), and units. This leaves some gaps for an agent needing full contextual understanding, but the simplicity of the operation mitigates the impact.

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 schema already defines x, y, z as integer coordinates with defaults. The description adds 'Point coordinates' which reinforces but does not significantly expand on the schema. Since all parameters are covered by the schema, the addition is useful but minimal, meriting a baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the operation: 'Add a single point object at the given coordinates.' It uses a specific verb and identifies the resource (a point object), distinguishing it from related tools like rhino_add_control_point and rhino_add_point_cloud even though alternatives are not named.

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 explains what the tool does but does not provide explicit guidance on when to use it versus similar point-creation tools. No alternative tools are mentioned, and no context is given for choosing this over others, leaving some ambiguity for the agent.

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 burden. It only says a point cloud is added; it does not disclose coordinate system, units, document requirements, replacement behavior, or any side effects beyond creating the object.

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 brief, direct, and front-loaded with the action. The Args block is useful and there is no filler, though the brevity leaves behavioral and usage context to other dimensions.

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 annotations and only a one-line action, this is close to minimally documented. It does not explain when the tool applies, how coordinates are interpreted, or what result to expect. For a creation tool, this leaves important call context to guesswork.

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 description documents that points is a list of (x, y, z) tuples, giving structure beyond the bare schema. However, the schema declares points as type string, so the actual wire encoding is ambiguous and the description does not resolve that mismatch.

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 ('Add'), a resource ('point cloud object'), and the input source ('list of 3D coordinates'). It is distinguishable from siblings like rhino_add_point by the point cloud resource, though it does not explicitly name alternatives.

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 is given for when to use this tool vs rhino_add_point/rhino_point or other creation tools. There are no prerequisites, exclusions, or alternative routing, so usage must be inferred.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the additive action and the location, but it does not mention whether a document must be open, coordinate system/units, side effects, or whether the created light is returned, which is a significant gap for a mutation 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?

The description is a single front-loaded sentence followed by a compact parameter list. There is no redundancy or filler; every word contributes to understanding the tool's purpose and parameters.

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 additive tool with an output schema, the description is minimally adequate but misses contextual details such as needing an active Rhino document and the units/coordinate system for the position. It also does not mention how it relates to the other light-creation sibling tools beyond the implicit type.

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 schema has 0% description coverage, so the description must compensate. It does add meaning by explaining 'x, y, z: Light position,' which connects the parameters to spatial placement. However, it does not clarify units, coordinate frame, or any constraints beyond the schema's integer type and defaults.

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 uses a specific verb-resource pair: 'Add an omnidirectional point light at the specified location.' The qualifier 'omnidirectional point light' clearly distinguishes it from sibling light tools like rhino_add_directional_light and rhino_add_spotlight, so an agent can tell exactly what this tool 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?

The description implies usage through the phrase 'omnidirectional point light' but does not explicitly state when to prefer this over sibling light tools. It provides no exclusions or alternative guidance, though the type of light is self-identifying.

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?

There are no annotations, so the description carries the full burden of disclosing behavior. It only says 'Add a spotlight' and lists parameters; it does not mention coordinate system, document requirements, units or semantics of radius, whether a document must be open, or potential side effects. For a mutation tool with no annotation coverage, this is a significant gap.

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 brief, front-loaded with the core action, and uses a clean argument list. Every sentence contributes useful information, with no fluff or repetition of the schema's default values.

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?

The description covers what the tool does and what each parameter means, and an output schema exists, so return values need not be explained. However, it lacks usage guidance and clear specification of radius semantics and coordinate conventions, leaving an agent to make assumptions about how to properly configure the spotlight.

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?

With 0% schema description coverage, the description compensates by assigning meaning to every parameter: x/y/z as position, target_x/y/z as the aim point, and radius as the cone radius. This is valuable semantic information the schema alone lacks, though 'cone radius' remains somewhat ambiguous regarding units or angle.

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 and resource: 'Add a spotlight to the scene.' This clearly distinguishes it from sibling light tools like rhino_add_point_light and rhino_add_directional_light. The verb-resource pair is unambiguous and directly tied to the tool name.

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 is given about when to use a spotlight versus point or directional lights, nor any exclusions or prerequisites. An agent must infer the choice from the tool name alone. The description provides no context for selecting this tool over its nearby siblings.

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