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?

The readOnlyHint=false annotation already flags this as a mutating operation, and the description's 'Add' is consistent. The description adds modest structural context (balloon vs boxed label) but does not disclose where the object is created, that it targets the active document by default, or any side effects. No contradiction with 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 single sentence is short, front-loaded, and contains no filler; the parenthetical adds genuinely useful structural detail. It is appropriately sized for a simple creation tool, though it could convey more without becoming verbose.

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 that an output schema exists and the tool is a creation operation, the description is still too thin. It omits the essential knowledge for correct invocation: how target_point and leader_origin relate geometrically, which is the core usage detail for a callout tool. An agent would likely need to infer this from the sibling names and 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?

With 0% schema description coverage claimed, the description carries the burden of explaining parameters, but it only hints at 'style' via 'balloon or boxed label'. It does not clarify the critical distinction between target_point and leader_origin, nor text, layer, or doc_id semantics.

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') and resource ('a callout') and clarifies the artifact's structure ('leader + balloon or boxed label'), which helps distinguish it from plain leader tools like rhino_leader. It is clear, though it does not explicitly name or differentiate from sibling annotation 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?

No guidance is given on when to use this tool versus alternatives such as rhino_leader, rhino_add_leader, rhino_text, or other rhino_annotation_* tools. There is no mention of when a callout is preferred over a plain leader or text label.

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 readOnlyHint=false, so the mutating nature is established. The description adds context beyond annotations: 'bridge only' clarifies it is not the native Rhino command, and 'Rhino DimStyle table' identifies the storage target. It does not disclose duplicate-name behavior or overwrite semantics, but with annotations covering the safety profile this is an acceptable 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 zero filler. Every clause earns its place, and the key qualifier ('bridge only') appears early. Slightly more substance would improve it, but as a concise statement it is 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?

For a mutating creation tool with a near-homonym sibling (rhino_dimension_style) and 0% schema description coverage, this is too thin. It does not clarify conflict behavior, prerequisites, or how this tool relates to the sibling. The output schema covers return values, but the missing usage and behavioral context leaves real 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?

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It mentions none of them — not even that 'name' is required, or what color, arrow_size, and text_height control. The agent is left to infer meaning from parameter names and default values in the schema.

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

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

States a specific verb ('Register') and a specific resource ('reusable dimension style'), and flags the bridge-only scope targeting the Rhino DimStyle table. This partially differentiates it from the closely named sibling rhino_dimension_style, though it never names that alternative or explains the exact relationship.

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 parenthetical '(bridge only)' hints at a scope distinction from the native Rhino tool, but the description never names the alternative (rhino_dimension_style) nor states the condition that selects this tool. An agent must infer when the bridge-specific registration path is 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?

The annotations already indicate this is a write operation (readOnlyHint: false), and the description adds useful behavioral detail: the arrow is centered on location, and angle_deg rotates it clockwise from world +Y, which is non-obvious and important for site-north adjustments. There is no contradiction with the 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 two compact sentences. The main action is front-loaded, and the only extra detail—the rotation convention—is directly relevant to correct invocation. No wasted words.

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 annotation-creation tool with an output schema and default values in the input schema, the description covers the core action and the key non-obvious behavior. It does not enumerate optional fields, but those are documented in the schema, so nothing critical is missing for an agent to call this 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 reported as 0%, so the description must compensate. It does explain the two semantically rich parameters: location is the center point, and angle_deg rotates clockwise from world +Y. However, it leaves size, layer, style, name, and doc_id to the schema/defaults, so it only partially carries the parameter-documentation burden.

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: 'Draw a north arrow centred on location.' This unambiguously identifies the tool's function and distinguishes it from sibling annotation tools like scale bars, callouts, and dimensions, which create different objects.

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 use case is implied: if an agent needs a north arrow annotation, this is the tool. However, the description does not explicitly state when to prefer this over other annotation tools, nor does it mention siblings such as rhino_annotation_scale_bar. There are no exclusions or alternative conditions 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 provide readOnlyHint=false, indicating a mutation. The description adds useful behavioral context by explaining what a revision cloud is ('bumpy polyline') and that it includes a revision label. The schema parameters (bump_count, bump_radius, revision_no) further disclose shaping behavior, so the description supplements the annotation without contradicting it.

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 states the tool's purpose and key visual characteristics. It's appropriately concise; though it could front-load the revision label aspect, it earns its place with the parenthetical clarification about the polyline appearance.

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 a simple creation tool with one nested object parameter, and the output schema exists. The description adequately conveys the purpose, but it doesn't mention whether the revision cloud is added to a drawing sheet or model space, how the label is rendered, or any layer/visibility defaults. This is acceptable for a drawing annotation tool but leaves some usage questions open.

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, but it only explains the overall concept. It doesn't explain what boundary_points means, what bump_count/bump_radius control visually, or what revision_no is for. The param names and schema defaults are self-explanatory to some degree, but the description adds no parameter-level 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 clearly states a specific verb ('Draw') and resource ('revision cloud (bumpy polyline) around a region of interest with a revision label'). This distinguishes it from general annotation tools like text, dimensions, and north arrows, though it doesn't explicitly name a sibling alternative.

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

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

The description implies the tool is for marking changed regions on drawings with a revision label, which is a standard drafting use case. However, it doesn't explicitly state when to choose this over other annotation tools (e.g., rhino_text_dot, rhino_hatch, rhino_leader) or mention prerequisites like needing a drawing sheet or active 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 establish readOnlyHint=false and title 'Add Scale Bar', so the creation behavior is expected. The description adds beyond annotations by clarifying that the bar geometry uses document units while the label displays real-world distance derived from scale_denominator. It does not disclose details such as label formatting or how the object is inserted into the 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?

Two concise sentences with the action first and the key unit-conversion detail second. No filler 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 creation tool with an output schema and annotations, the description plus schema is nearly complete: it clarifies the crucial scale-bar unit semantics and leaves parameters to self-explanatory names and constraints. Minor gaps such as exact label text or layer behavior are not critical for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description is the main source of semantic meaning, and it explains the important relationship between document units, real-world distance, and scale_denominator. However, it leaves location, divisions, label_height, and total_length to be inferred from their names and schema defaults, so it only partially compensates.

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 ('Draw') and a concrete resource ('a divided scale bar with a label'), which clearly identifies the tool's function. This distinguishes it from sibling annotation tools like north arrows, revision clouds, and callouts because a divided scale bar is a unique object.

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 choose this tool over alternatives such as rhino_annotation_callout or dimension tools. It explains unit behavior but does not state prerequisites, exclusions, or typical scenarios like adding a scale bar to a plan.

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's 'Add' action is consistent with that. However, the description adds no behavioral context beyond the mutation hint, such as active document behavior, layer creation, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence with the action and core inputs front-loaded. Every word earns its place; no repetition of the title or schema noise.

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 with an output schema and a mutation annotation, the description is minimally viable: an agent can construct the required args. It is incomplete for selection among many sibling creation tools, especially rhino_cmd_arc, but the schema fills most invocation 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 description names the three core parameters (centre, radius, sweep angle) and clarifies degrees, which partially compensates for the 0% top-level schema description coverage. It adds no constraint details and omits the optional name, layer, and doc_id parameters, though the nested schema documents 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 verb ('Add'), a resource ('an arc'), and the defining construction inputs (centre, radius, sweep angle in degrees). It is clear, but it does not differentiate from sibling tools such as rhino_cmd_arc, so it misses the top distinction criterion.

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 choose this tool over alternatives like rhino_cmd_arc, rhino_circle, or the many other curve-creation tools. The construction method is implied by the parameter list, but there is no explicit context, prerequisite, or exclusion.

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 a meaningful behavioral constraint beyond annotations: the tool computes area for meshes only, and Brep area requires a bridge—this tells the agent that passing a Brep object_id will not work as expected. No contradiction with annotations; the description complements 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?

A single short sentence with a parenthetical note—every word earns its place and the main action is front-loaded. No redundancy or 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 read-only query tool with an output schema present, the description covers the essential domain constraint (mesh-only) and the annotations cover safety and idempotency. The main gaps are not naming a concrete alternative for Brep area and not mentioning units of the returned area, but these are minor given the annotations and output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is reported at 0%, though doc_id actually has an inline description; object_id is only labeled 'Object Id.' The description's 'of a mesh' adds the crucial semantic that object_id should reference a mesh object, which is genuinely useful. However, it doesn't clarify doc_id semantics or the expected output, so it only partially compensates for the coverage gap.

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

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

The description uses a specific verb and resource: 'Compute the surface area of a mesh,' which is clear and unambiguous. The parenthetical '(Brep area requires bridge)' adds scope and hints at a limitation, distinguishing it from Brep-related area tools like rhino_cmd_area and rhino_area_centroid. However, it does not explicitly name a sibling tool, so differentiation is implicit rather than explicit.

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

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

The parenthetical implies the tool is intended for meshes and that Brep inputs are out of scope ('Brep area requires bridge'), which gives the agent a condition for when not to use it. But it stops at implication—it doesn't explicitly name an alternative tool or state 'use X for Brep area.' No explicit when-to-use or when-not-to-use guidance is given.

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

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

The description is minimal and does not disclose behavioral details beyond what the annotations provide. The annotations include readOnlyHint=false, indicating this is a mutating operation, but the description does not explain effects such as whether the original objects are retained or replaced, whether the array is created in the active document, or any limitations such as maximum count or spacing constraints. The schema does provide some constraints (e.g., count max 1024), but those are structured data, not behavioral transparency in the description.

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 that efficiently states the core operation. It is appropriately short and front-loaded, but it may be too terse given the lack of parameter and usage details. It earns a 4 because it is concise and not bloated, but it leaves out important 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?

Given the tool's complexity (one input object with 5 fields), the description is incomplete. It lacks information about the direction vector format, the meaning of spacing, count limits, and how it relates to sibling array tools. The annotations indicate mutation but not the effect on the original objects. The output schema exists but is not described; however, the description need not explain return values. Still, the missing usage and parameter semantics make the tool hard to invoke correctly without inspecting the schema deeply.

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 mention any parameters. The schema itself defines parameters with titles but only a couple have descriptions (e.g., doc_id, direction's z component). The description adds no semantic meaning about what 'direction', 'spacing', 'count', or 'object_ids' mean in the context of a linear array. Because the description lacks parameter explanations and the schema has poor coverage, the tool definition provides insufficient guidance.

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 'Array objects along a vector with constant spacing' clearly states the verb ('Array') and the resource ('objects'), and identifies the operation as a linear array along a vector. It does not explicitly distinguish from sibling tools like rhino_array_polar or rhino_array_rectangular, but the phrase 'linear' and 'vector' in the tool name and description make the purpose 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?

The description implies the tool is used for creating linear arrays, but it does not provide explicit guidance on when to use this tool versus alternatives such as rhino_array_polar or rhino_array_rectangular. The description mentions 'constant spacing' which is a useful context, but no exclusions or alternative tool names are given.

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

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

Annotations only indicate mutation via readOnlyHint=false. The description does not add behavioral context such as whether the original objects are copied or moved, whether new objects are created in the document, or how count and total angle affect the result.

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 is concise, though it could be expanded with additional guidance without becoming bloated.

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 six parameters and no property descriptions, this description is far too thin. It does not explain polar-array semantics like rotation around a center point, angle coverage, or axis specification, leaving the agent under-informed for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides no parameter meaning. An agent cannot infer the roles of object_ids, center, count, total_angle_degrees, axis, or doc_id from the text, so the description fails to compensate for the schema gap.

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

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

The description states a specific action ('Array objects') and a specific pattern ('polar'), which is enough to distinguish it from linear and rectangular array siblings. However, it does not differentiate from the similarly named rhino_cmd_array_polar sibling.

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 like rhino_array_linear, rhino_array_rectangular, or rhino_replicate_along_curve. There is also no mention of prerequisites such as needing an active document or existing object IDs.

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 this is a mutation, and the description aligns with that, so there is no contradiction. However, the description adds no behavioral detail beyond the annotation: it doesn't say whether originals are retained or copied, whether objects are created or replaced, or what the tool returns. No destructive or side-effect context is disclosed.

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 zero wasted words; '3D rectangular grid' earns its place by adding the dimensionality not present in the tool name. It is appropriately lean, though terse enough that it edges toward under-specification rather than ideal 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 mutation tool with 7 parameters, an existing output schema, and sibling alternatives, the 8-word description is inadequate on its own. It omits whether the original objects are preserved, what the tool returns, prerequisites like existing objects in the document, and how this differs from array_linear/array_polar. The schema covers ranges and defaults, but behavioral and selection context is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% — only doc_id has a schema description — and the tool description does not compensate. The phrase '3D rectangular grid' loosely implies count_x/y/z and spacing_x/y/z semantics, but no parameter is explicitly explained. The parameter names are partially self-explanatory, but the description adds almost no meaning beyond the schema.

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

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

The description states a specific verb ('Array'), resource ('objects'), and geometry ('3D rectangular grid'), which is clear and recognizable. It implicitly differentiates from sibling tools like rhino_array_linear and rhino_array_polar through the word 'rectangular', though it doesn't explicitly contrast them.

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. The sibling list includes rhino_array_linear, rhino_array_polar, rhino_array_on_curve, and rhino_distribute, but the description never mentions them or any selection criteria, leaving the agent to infer when a rectangular array is 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?

The description explicitly discloses the destructive side effect: 'the originals are deleted; this is a form-finding move, not a duplicating one.' Annotations only carry readOnlyHint=false, so this deletion warning and the promise of new IDs add essential behavioral context beyond the structured data.

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 tightly structured: a clear first-sentence overview, then parameter behavior, then return/destructive consequence. Every sentence earns its place and there is no filler or repetition of schema noise.

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 mutating deformation tool, the description covers operation, attractor modes, strength direction, return value, and the critical deletion side effect. Combined with the schema's documentation of doc_id, falloff, max_distance, and point filtering, the agent has enough context to invoke 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?

The description adds meaningful parameter relationships: positive strength pulls and negative pushes, the attractor can be a point or curve, and curves use the closest sample on the curve. It also clarifies that the returned IDs are new objects. The schema already documents falloff, max_distance, and doc_id, so the description compensates well for the key semantic gaps.

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 verb and resource: 'Displace each input point along the vector to an attractor with a falloff.' It clearly distinguishes this as an attractor-based point-deformation operation, unlike the many sibling move/soft-edit/bend/twist 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 description implies use for attractor-driven form-finding and warns that it is 'not a duplicating one,' but it does not explicitly name alternative tools or state when to prefer this over sibling deformation operations. Context is conveyed through the operation's semantics rather than direct routing guidance.

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 readOnlyHint=false by indicating a generative/write operation, and it adds the bridge-only compatibility constraint. However, it does not disclose whether the source object is modified, whether new objects are created on a specific layer, or other side effects beyond generation.

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 efficient sentence that front-loads the core action and then packs the two most valuable qualifiers ('waffle-style fabrication', 'bridge only') into a short parenthetical. There is no wasted or redundant wording.

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 that an output schema exists and the input schema provides descriptions for the key parameters, the short description is mostly sufficient. It clearly communicates the high-level operation and restrictive context, though it could be slightly stronger about what exactly is produced or how the source object is treated.

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 documents object_id, axis_a, axis_b, and doc_id, and count_a/count_b are self-describing through names and min/max constraints. The description's mention of 'two orthogonal sets' adds high-level intent for axes and counts, but it does not explain parameter defaults or the layer parameter, leaving that responsibility to the schema.

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

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

The description names a specific action ('Generate'), a specific resource ('two orthogonal sets of section ribs'), and adds a clear fabrication context ('waffle-style'). It distinguishes this tool from generic sectioning or single-rib tools by emphasizing the orthogonal two-set output and bridge-only scope.

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

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

The parenthetical 'waffle-style fabrication, bridge only' gives a clear usage context and an explicit restriction about where the tool applies. It does not name alternative tools or explicitly state when not to use them, but the intended use case is reasonably well communicated.

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 are minimal (only readOnlyHint: false), so the description carries the behavioral disclosure burden and succeeds. It discloses failure modes (wrong route returns an 'error' row with HandlerError), abort semantics tied to on_error='stop', the exact return shape ({summary, results} with index/method/status/result|error), and the performance profile — all context beyond what annotations provide.

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?

Longer than typical but justified: the route-naming convention, error semantics, performance data, and return format are each non-obvious and earn their place. Content is front-loaded (purpose first, then the critical gotcha, then performance rationale, then return shape). The benchmark detail could be tighter by a sentence, but its presence directly supports the usage decision.

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 batching tool with nested args, a route-naming trap, per-step error semantics, and an output schema, the description is remarkably complete. It covers why to use it, when to use it, what cannot be batched, how to name methods correctly, what happens on failure, and what the response looks like. The on_error parameter and batch size limits are already covered by the schema, so no required detail is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% at the top level, so the description must compensate, and it does so strongly for the critical 'method' parameter with mapping examples and a counterexample ('rhino.query.document_summary' NOT 'rhino.document.summary'). It also explains on_error's behavioral effect. However, the 'params' object semantics are only addressed via the schema's nested $defs ('JSON object passed verbatim'), not in the description itself.

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?

Opening sentence states a specific verb+resource+mechanism: 'Dispatch multiple bridge methods in a single round-trip.' It goes beyond the title by explaining what 'bridge methods' are and how they relate to MCP tool names (e.g., 'rhino_layer_create' maps to 'rhino.layer.create'), which separates it from the hundreds of individual rhino_* sibling 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?

Provides explicit, quantified when-to-use guidance: 'Effective for any workflow that issues >5 bridge calls back-to-back' with measured performance evidence (~580ms sequential vs ~340ms batched). It also states when-not: 'Standalone-only tools (rhino_set_user_text etc. that have no bridge_call path) cannot be batched,' giving the agent actionable exclusion criteria.

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 provide a title, so the description carries the behavioral burden. It discloses that all changes are wrapped in one undo record and that apply_to_all applies the first spec to every object. This goes well beyond the structured annotation data, though it does not mention potential overwrite semantics or failure 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 compact and front-loaded with the core purpose. Every sentence adds useful information: what it does, what fields are allowed, undo behavior, and apply_to_all semantics. 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 batch modification tool, the description covers the main operational aspects: supported modifications, undo grouping, and apply_to_all. Combined with the rich input schema and output schema, most necessary context is present. It lacks explicit alternative routing, but this is not a critical gap for this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds combination semantics by listing the modifiable fields and explains the apply_to_all flag's effect. However, schema description coverage is low, and the description does not fully compensate by detailing all nested parameters such as rotation center/axis, scale center/factor, or the required id field.

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: 'Modify many objects in a single call.' It clearly enumerates the supported modification types and explains the apply_to_all mode, which distinguishes it from single-object tools like rhino_move, rhino_rotate, or rhino_scale.

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 clearly implies when to use this tool: for batch modification of many objects in one call, with an explicit explanation of the apply_to_all behavior. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full exclusion guidance.

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 no read-only or destructive hints, so the description must carry the behavioral burden. It does not disclose whether the operation modifies objects in place, whether make_copy defaults to false and creates a copy, what happens to the original geometry, or what the tool returns. The word 'bend' implies mutation but leaves key behavioral details unstated.

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 is concise and immediately states the operation, though it is perhaps too terse to fully support a complex geometric transformation 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 requires object_ids, two axis endpoints, a bend point, and an optional make_copy flag, the one-sentence description is not enough context for an agent to call it correctly. An output schema exists, but it does not replace missing guidance about selection, in-place versus copy behavior, or interaction with sibling transformation 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 reported as 0%, and the tool description does not compensate by explaining object_ids, the start/end axis points, or make_copy. It mentions 'axis' and 'specified point,' which loosely maps to the start/end/point parameters, but it adds little semantic value over the raw schema and omits the copy behavior entirely.

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 'Bend objects along an axis through a specified point' uses a specific verb and resource, and conveys the core geometric operation clearly. It does not explicitly distinguish itself from similar siblings like rhino_cmd_bend or rhino_twist, but the bend semantics are sufficiently 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 rhino_cmd_bend, rhino_twist, rhino_taper, or rhino_flow_along_curve. There are no prerequisites, selection requirements, or exclusions stated, so the agent must infer usage from the name and description 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?

Beyond the readOnlyHint=false annotation, it discloses what is written (Pset_RhinoMcp::<key> user_text), where (each object; additionally Rhino's IFC property-set table in bridge mode), and the downstream effect (IFC export). It doesn't state whether existing metadata is overwritten or whether the operation is reversible, but the core mutation 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?

Two short paragraphs with the main action front-loaded and a technical mechanism in backticks; no filler or redundant restatement 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 mode-dependent behavior and export relevance, but with no schema descriptions counted and no guidance on required args, overwrite behavior, or relationship to rhino_bim_pset_* tools, an agent could select it yet still struggle to populate args correctly. The output schema reduces the need to explain return values, so the remaining gap is invocation semantics.

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?

Context indicates 0% schema description coverage, and the description does not name required parameters like object_ids or entity_type nor explain doc_id, pset_name, or properties mechanics. It offers only conceptual grounding ('IFC entity + property-set metadata') and the default Pset_RhinoMcp key prefix, which is not enough to invoke the nested args confidently.

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?

Opening sentence names a specific action ('Tag objects') and a specific resource ('IFC entity + property-set metadata'), and the rest details the write mechanism (user_text keyed as Pset_RhinoMcp::<key>) plus bridge-mode behavior, which separates it from generic BIM pset tools in the sibling 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?

The description implies the main use case—attaching BIM metadata before an IFC export—and explains standalone vs bridge behavior, but it never explicitly states when to choose this over rhino_bim_pset_set/get/delete or rhino_export_ifc. There are no exclusions or alternative tool names.

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

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

Annotations indicate destructiveHint=true and readOnlyHint=false, so the description doesn't need to restate destructiveness. However, the description adds no behavioral context beyond what annotations provide: it doesn't clarify that the operation is irreversible, whether it affects nested properties, or what happens if the pset does not exist. The description does not contradict the 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?

One concise sentence that front-loads the action ('Remove every property'). It is efficient and avoids fluff, though it could add a brief note about doc_id or irreversibility without becoming bloated.

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 has destructive annotations and a small schema, but the description is too thin for a delete operation. It doesn't specify which document context applies, any prerequisites (e.g., object must exist, pset must exist), or what the return/confirmation looks like. An agent could call it incorrectly without knowing whether to target the active document or another one.

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 mentions 'a named PropertySet' and 'an object', which maps to pset_name and object_id but doesn't explain them further. doc_id is not mentioned at all in the description. The schema's own parameter descriptions are minimal, so the description compensates partially but not fully.

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 'Remove every property under a named PropertySet from an object.' states a specific verb (remove), resource (property set), and scope (from an object). It clearly distinguishes itself from sibling tools like rhino_bim_pset_get and rhino_bim_pset_set, but it doesn't explicitly mention the destructive/irreversible nature.

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: when you want to delete an entire property set from a BIM object. However, it doesn't explicitly state when NOT to use it or mention alternatives like rhino_bim_pset_set could modify instead of delete. No prerequisites or context for when deletion is appropriate are given.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable behavioral detail: the mode-dependent data source difference and the result grouping by PropertySet name in a 'psets' field.

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 with the core purpose, followed by mode behavior and result grouping. Every sentence earns its place without 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 tool with only one required parameter, output schema present, and annotations covering idempotence and read-only behavior, the description is complete. It explains mode differences and result structure sufficiently.

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 already documents object_id, doc_id, and pset_name with descriptions and defaults, so the description does not need to repeat parameter details. It adds only the grouping context, not additional parameter semantics.

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: 'Read PropertySet entries off an object.' This clearly identifies the tool's function and differentiates it from sibling tools like rhino_bim_pset_set and rhino_bim_pset_delete.

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 clear context by explaining bridge mode versus standalone mode and which data source each reads. It does not explicitly compare against alternatives such as rhino_bim_pset_set, but the read-only nature and mode guidance are sufficient for an agent to understand 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?

Annotations already signal a write via readOnlyHint=false, and 'Persist' largely restates that without adding new behavioral context. The description does not mention overwrite semantics, implications for existing property sets, user_text storage, permissions, or failure modes.

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 efficient, though slightly terse considering the BIM-specific subject matter.

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 combination of tool name, title, and rich input schema makes the call reasonably clear, and an output schema is present. However, the description alone does not explain what a PropertySet block means in the IFC context or how this differs from metadata_set and user_text setters, so the agent must rely on sibling names and schema details.

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-level information, but the nested schema thoroughly documents doc_id, object_id, pset_name, properties, and replace_existing. Although the wrapper-level coverage signal is 0%, the actual field descriptions compensate, making this a baseline 3 rather than a failure.

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 ('Persist') with a clear resource ('PropertySet block') and target ('on an object'), and the action clearly differs from sibling pset_get/pset_delete tools. It does not explicitly name sibling alternatives, but the set/get/delete family is still decipherable from the description and 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?

The description gives no guidance on when to use this tool versus alternatives such as rhino_bim_pset_get, rhino_bim_pset_delete, rhino_bim_metadata_set, or rhino_set_user_text. It implies a write operation but never states conditions, prerequisites, or exclusions.

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