RhinoMCP

by kbangaru-cyber

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.0
Disambiguation5/5
Each tool targets a specific action and geometry type, with clear descriptions that prevent confusion. Even closely related tools like duplicate_edge and duplicate_border are differentiated by their inputs and outputs, and broad escape-hatch tools (run_python, run_command) are clearly distinct in purpose.
Naming Consistency5/5
All tools follow a consistent rhino_verb_noun pattern, with verbs like create, get, set, delete, and list applied uniformly across categories. Even Grasshopper-specific tools (rhino_gh_set_slider, rhino_gh_get_outputs) maintain the pattern, and no mixed conventions like camelCase are present.
Tool Count1/5
With 105 tools, the server far exceeds the typical well-scoped range (3-15) and falls into the extreme mismatch category (50+). While Rhino is a complex CAD environment, many tools could be consolidated (e.g., create_point and create_points; multiple get_* analysis tools), making the surface unnecessarily large and potentially overwhelming for an agent.
Completeness5/5
The tool set covers the full lifecycle for Rhino geometry: creation of primitives and complex surfaces, transformation and boolean operations, querying/analysis, layer/material/block management, viewport control, import/export, and even Grasshopper integration. The inclusion of arbitrary code execution tools (run_python, run_command, gh_run_script) ensures no operation is impossible, so there are no obvious dead ends.
Average 3.3/5 across 89 of 105 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contains only 'Create a point object in Rhino.' It does not disclose any behavioral details beyond the creation itself, such as whether it affects the current document, units, coordinate system, or if it overwrites an existing object. Annotations are all false (readOnlyHint, destructiveHint, etc.), providing no safety profile. With no annotation support, the description carries the full burden and fails to provide any meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient in length, but it is under-specified. It does not front-load any distinguishing or actionable information beyond the basic purpose. While there is no bloat, the brevity comes at the expense of clarity and completeness, so it is not appropriately conciseness – it is minimalism without substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple point creation) and the presence of an output schema (which may describe the return), the description is somewhat minimal. However, the lack of distinction from rhino_create_points and the absence of any usage guidance make it incomplete for an agent to correctly select and invoke it among many similar create tools. The description fails to capture context such as coordinate system or units, which could be relevant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters at all. The schema itself documents each param (name, layer, point with x/y/z) with descriptions, but the schema description coverage signal is 0%, indicating the tool description explains none of the parameters. Since coverage is low, the description must compensate, but it does not add any meaning beyond what the schema already provides. This is a complete miss.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create') and resource ('point object'), and it identifies the resource as a single point. However, it does not distinguish this tool from the sibling rhino_create_points (plural), which likely creates multiple points, nor from other create tools like rhino_create_line. The phrasing 'a point' hints at singular, but without explicit differentiation, an agent could confuse it with the plural variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 such as rhino_create_points or other geometry creation tools. The description offers no conditions, exclusions, or references to sibling tools, leaving the agent to infer usage based solely on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations, which already indicate a mutation (readOnlyHint: false). It does not mention effects on the scene, permissions, reversibility, or return behavior, leaving a significant gap for a transform operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is structurally simple and front-loaded, but it is under-specified to the point of being minimally informative. Conciseness is not beneficial when critical details are omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (non-uniform scaling with a center point and three factors), an output schema exists but is not described, and no parameter semantics are provided, the description is inadequate for an agent to correctly invoke the tool without relying entirely on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description does not explain any of the parameters (guids, center, factor_x, factor_y, factor_z). Even though the schema itself contains per-parameter descriptions, the tool description should compensate for low coverage but fails to mention any parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Scale objects') with the key differentiator 'separate X, Y, Z factors', which distinguishes it from the sibling rhino_scale for uniform scaling. It is specific and immediately understandable, though it does not explicitly name the tool or contrast it with rhino_scale in the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 such as rhino_scale for uniform scaling. An agent must infer usage from the name and description alone, with no explicit exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, so the description doesn't contradict them. However, it adds no behavioral detail beyond the obvious 'creates' action. It doesn't disclose what happens on duplicate executions (idempotency is false), the coordinate system, units, or whether a new object is returned. Given the minimal annotations, the description should carry more burden and explain at least that a new line object is added to the model, which it does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is succinct and front-loaded with the core action. However, it is under-specified for a tool with multiple parameters and optional fields. It earns its place but does not provide the necessary detail to be genuinely helpful, so it falls short of a 4 or 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that creates a 3D line with start/end points and optional name/layer, the description is incomplete. It does not mention output object type, required vs. optional parameters, or any constraints. The presence of many sibling create tools increases the need for distinguishing context, which is absent. A complete description should at least note that it creates a straight line segment in the Rhino document and that coordinates are in the current model units.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the parameters (start, end, name, layer). The context signal indicates 0% schema description coverage, meaning the description must compensate for the lack of parameter documentation in the schema. It fails to do so, providing no information about how coordinates are specified, defaults, or the meaning of optional fields. The agent would have to rely on the schema itself, which is sparse regarding usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Create a line') and the key inputs (start to end point). It is specific enough for the resource type, but it doesn't differentiate from sibling tools like rhino_create_curve or rhino_create_polyline, which serve similar geometric creation purposes. The verb and resource are unambiguous, so a 4 is warranted, not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. There is no mention of conditions (e.g., straight vs. curved lines), no exclusions, and no reference to other create tools. An agent would have to infer from context that this is the tool for straight line segments, but without explicit routing, the description fails to aid tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimally informative (all hints false) and do not convey safety or idempotency. The description does not disclose whether the operation creates new curves, modifies existing ones, or what happens if the projection fails. It offers no behavioral detail beyond the core action, leaving the agent unaware of side effects or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, but excessively terse. It consists of a single sentence that is clear but lacks necessary context. While conciseness is maintained, the structure is too minimal to be considered well-rounded for a tool with multiple parameters and potential side effects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple inputs, a direction vector, and a projection operation), the description is incomplete. It does not mention the output format (e.g., new curve GUIDs), any error conditions, or typical use cases. Although an output schema exists, the description still fails to explain what the tool returns and how the result relates to the input geometry.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, yet the description adds no parameter-level meaning. It merely restates the general action without explaining the direction vector's role, the semantics of multiple curve GUIDs, or the required target. The description falls far short of compensating for the schema's lack of explanatory text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Project'), the object (curves), and the target (a brep/surface) along a direction. This clearly communicates the tool's core function and differentiates it from creation tools like rhino_create_curve or rhino_offset_curve. However, it does not explicitly distinguish it from similar projection-related tools like rhino_intersect or rhino_closest_point, so it falls short of full distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites, such as curves needing to be planar or the direction vector being non-zero, nor does it say anything about when a different projection method might be preferable. No exclusions or specific conditions for use are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no behavioral insights (readOnlyHint=false, destructiveHint=false) and only indicate this is a write operation. The description adds minimal behavioral context beyond stating 'Create', but does not disclose how layer handling works, what happens on invalid coordinates, or the return behavior. As a mutation tool with no annotation-based safety profile, the description should carry more detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is efficient and front-loaded, but it is under-specified for a batch creation tool with an optional layer parameter. It does not provide enough contextual structure to be considered appropriately sized; the brevity sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch creation with optional layer) and the presence of an output schema, the description is incomplete. It omits operational context such as how the layer parameter is used, what happens if points are invalid, and whether the operation is atomic. An agent would need to rely entirely on the schema and external knowledge to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has detailed descriptions for points, layer, and coordinate fields, so the schema itself is self-explanatory. However, schema description coverage is 0% because the tool description does not mention any parameters. The description does not compensate for this gap, offering no additional semantic meaning about how parameters behave or relate to each other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Create' and the resource 'point objects', with qualifiers 'multiple' and 'at once' that clearly distinguish it from the singular tool rhino_create_point. While it does not explicitly name the sibling, the purpose is clear and specific enough for an agent to understand its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit guidance on when to use this tool versus alternatives such as rhino_create_point. The phrase 'at once' implies batch use, but there is no explicit 'use this when' or 'do not use this when' guidance, leaving the agent to infer from naming conventions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so the tool mutates state, but the description adds no behavioral context beyond that. It does not mention side effects (e.g., adding an object to the model), output behavior, or any requirements (like having an open document). The description offers minimal value beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no superfluous words. It is front-loaded with the action and key attributes, making it appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description doesn't need to explain returns or safety, but it is still incomplete. It fails to mention the center point (a crucial parameter), how to specify a name or layer, or any orientation defaults. For a creation tool, an agent needs to know what parameters are essential and what the resulting object's placement depends on. The description leaves these gaps, making the tool harder to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 parameter meaning. It only mentions major and minor radii, omitting the 'center', 'name', and 'layer' parameters entirely. It provides no details on defaults, relationships, or how these parameters affect the result, leaving the agent without sufficient guidance on how to set them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a torus with major and minor radii, using a specific verb (create) and resource (torus). While it doesn't explicitly differentiate from sibling create tools, the name and content make the purpose unambiguous enough for an agent to select it correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 the many other create_* tools. It does not mention alternatives, prerequisites, or any context that would help an agent decide between creating a torus and another shape.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutation (readOnlyHint false) and not destructive (destructiveHint false). The description only says 'create', which aligns with the annotations. However, it does not disclose what happens to the original curves (e.g., whether they are trimmed), the role of the 'join' parameter, or that the operation may fail if curves do not intersect. With no annotation coverage for these nuances, the description carries the burden and fails to provide them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded with the core action ('Create a fillet arc') and gives just enough detail about location. However, it is so brief that it forgoes essential operational context, though from a pure conciseness standpoint it is efficient. A 4 is appropriate for being crisp, but it pays for brevity in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a creation operation with moderate complexity (requires two curve GUIDs and a radius). The description omits prerequisites (intersection), the effect on original geometry (trimming/joining), and potential error conditions (invalid radius, non-intersecting curves). While an output schema exists, it does not cover these execution conditions. The description is too thin for an agent to predict side effects or avoid failures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself provides descriptions for each parameter (e.g., 'GUID of the first curve', 'Fillet radius'), but the description adds no extra meaning. The context signal shows schema description coverage of 0%, indicating the tool description does not compensate for parameter understanding. Since there are several parameters (curve1_guid, curve2_guid, radius, join) and the description doesn't clarify their interplay (e.g., that join trims and joins results), the parameter semantics are insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('create') and resource ('fillet arc') and provides location context ('between two curves at their intersection'). This clearly differentiates it from sister tools like rhino_fillet_edge, which works on surfaces. However, it does not explicitly mention that it operates on curves in a way that could conflict with rhino_create_arc, though the context makes that clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. It does not mention prerequisites (curves must intersect), nor does it suggest specific conditions for using rhino_fillet_edge or other curve tools. The description is purely declarative with no 'when-to-use' or 'when-not-to-use' information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only false hints (readOnlyHint, destructiveHint, idempotentHint all false), so the description carries the full burden of behavioral disclosure. It merely states that a surface is created, without mentioning that it creates a new object, does not modify existing geometry, or any side effects. It does not contradict annotations, but offers minimal behavioral insight beyond the obvious creation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and resource. There is no wasted verbiage, and it is easy to scan. However, it lacks any structural elements like bullet points or a breakdown of prerequisites, and it is slightly under-specified given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters (points, u_count, v_count, degrees, name, layer) and an output schema, the description is far from complete. It does not explain the requirement that points.length equals u_count * v_count, the degree limits (1–11), or that the surface is added to the document. An agent would need to rely entirely on the schema to understand constraints, and even then, the description omits behavioral context like object creation semantics. The presence of an output schema helps, but the description still leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the tool description does not help explain any of the parameters. The description only mentions 'grid of control points', which partially aligns with the 'points' parameter, but it ignores u_count, v_count, degrees, name, and layer. Since the schema itself has decent descriptions (e.g., row-major, degrees), the description fails to compensate for the low coverage and adds no value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Create') and a specific resource ('NURBS surface') and includes a differentiator ('from a grid of control points'). This distinguishes it from sibling tools like rhino_create_planar_surface or rhino_create_patch, though it does not explicitly name alternatives. It is unambiguous and specific enough for an agent to understand the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other surface creation tools (e.g., loft, patch, planar_surface). It does not mention prerequisites, the necessity of a rectangular grid, or when an alternative would be more appropriate. The usage context is only implied by the phrase 'grid of control points' and the schema's u_count/v_count, but no explicit advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate that this is not read-only (readOnlyHint false) but not destructive (destructiveHint false). The description adds little beyond stating that edges are duplicated into curves, implying new objects are created without modifying the original. It doesn't disclose any side effects, limitations, or behavioral nuances such as how edge_indices affects the operation. Since the output schema exists, return format is covered, but behavioral details are sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets to the point immediately. It uses no filler words and is appropriately sized for the tool's simplicity. However, it could be slightly improved by including a tie to parameters or usage, but as a standalone statement it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient to understand the primary purpose but lacks information about how the edge_indices parameter works or how this tool relates to rhino_duplicate_border. With only two parameters and an output schema, the description could have explained the optional filtering behavior. It is minimal and leaves the agent to infer the full API contract from schema comments alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description provides no explanation of parameters. The description does not mention the 'guid' or 'edge_indices' fields, leaving the agent to rely solely on the schema property names and their minimal comments. Since the schema coverage is zero, the description was expected to compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (duplicate) and the resource (edges of a brep), with the outcome 'as individual curves'. It is specific and distinct from sibling operations like rhino_duplicate_border, though it doesn't explicitly differentiate between them. The verb is direct and the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 rhino_duplicate_border or when edge selection is needed. No context about typical use cases, prerequisites, or conditions is provided. The agent is left to infer usage from the tool 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'creating copies,' which implies non-destructive behavior consistent with destructiveHint=false. However, with all annotations false, the description carries the full burden of behavioral disclosure. It does not mention the need for a plane definition, whether multiple objects are handled in one call, or any 3D-specific details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant content. It is concise and front-loaded with the verb and object. While it is terse given the tool's complexity, it achieves efficiency without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with multiple inputs (guids, plane_normal, plane_origin) and an output schema, the description only states the basic action. It lacks usage context, behavioral expectations, and any note on the required plane definition. The output schema exists, but the description does not set expectations for the returned value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contains no parameter information whatsoever. It does not reference the guids input or the plane_normal and plane_origin parameters. Given the schema description coverage of 0%, the description was expected to compensate, but it fails to provide any guidance on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: it mirrors objects across a plane and creates copies. This is a specific verb+resource combination that distinguishes it from move or rotate, though it does not explicitly contrast with the sibling rhino_copy. The purpose is unambiguous and matchable to the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use mirror versus copy, move, or rotate, nor does it mention any prerequisites like the requirement of defining a plane. The agent is left to infer usage from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description's action of setting the current layer is consistent with these annotations and adds no contradiction. However, it does not go beyond the annotations to provide additional behavioral context such as what happens if the layer does not exist, whether the operation fails silently, or any side effects. Given the annotations cover the safety profile, a score of 3 reflects that the description adds minimal value but does not mislead.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous words, achieving high conciseness. It is appropriately front-loaded with the core action. However, it is so brief that it omits any additional structure or context that could aid usability, but since it is directly readable and not bloated, a score of 4 is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description is incomplete for confident invocation. It does not mention error behavior, whether the layer must already exist, or any return value (though an output schema exists, it is not shown). More importantly, it lacks any context about when this operation is appropriate relative to sibling tools. Given the existence of many related tools, the description fails to provide sufficient situational guidance for an agent to select and call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'name' with a description 'Layer name to make current', which already provides direct semantics. However, the tool description itself does not elaborate on this parameter at all. With schema description coverage at 0%, the description carries no burden to explain parameters, but the criterion states that low coverage (<50%) requires the description to compensate. Here it does not, so the description adds no value beyond the schema. The single parameter is self-documenting in the schema, but the tool description fails to provide any additional guidance on its usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Set the active/current layer.' This states a clear verb (set) and resource (current/active layer). It is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like rhino_set_layer, though the name itself conveys the distinction. The description adds a clarifying term 'active/current' that helps but is not accompanied by an explicit comparison to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. The description solely states what it does, with no mention of when it is appropriate, what prerequisites exist, or which sibling tools are better for other scenarios. With numerous layer-related tools (rhino_set_layer, rhino_create_layer, rhino_set_layer_visibility), the absence of any usage context leaves the agent to infer 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint: true and destructiveHint: false, and the description's 'Change' implies mutation consistent with readOnlyHint: false. However, the description adds no behavioral context beyond this, such as whether the layer must exist, what happens if it doesn't, or how the change affects existing objects. With low annotation coverage (only three hints), the description should have disclosed more.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no wasted words. However, it is under-specified, lacking any details that would aid an agent in understanding usage, edge cases, or relationships to other tools. While efficient in length, it sacrifices necessary substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with two parameters and an output schema, the description is too minimal. It does not mention prerequisites (e.g., layer existence), behavior on missing layers, or any error conditions. The annotations and schema carry some weight, but the description leaves significant gaps that could lead to incorrect usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description provides no parameter information. While the input schema itself includes descriptions for 'name' and 'color', the description fails to compensate for the missing coverage. It adds no meaning beyond what the schema already provides, and the agent must rely solely on the schema for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Change') and the resource ('color of a layer'). It distinguishes from siblings like rhino_set_color (which presumably targets objects) by specifying 'layer', and from rhino_set_layer_visibility by focusing on color. However, it doesn't explicitly contrast with these alternatives, leaving some room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as rhino_set_layer (for assigning objects to layers) or rhino_set_color (for object color). The description merely states what it does without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (all hints false), so the description carries the burden of behavioral disclosure. It does not explain what happens if the layer already exists, whether the new layer becomes current, if parent layers are auto-created, or any side effects. The nesting syntax is helpful but does not cover core behavioral expectations for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus an example, front-loading the purpose and the key syntax. It is appropriately short and has no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the existence of an output schema, some details may be inferred. However, the description omits critical context such as duplicate-name handling, whether parent layers are auto-created, and default behavior (e.g., color, current layer). For a creation tool with no annotation guidance, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only reiterates the name parameter's nesting syntax, which is already documented in the schema ('Layer name (use :: for nested...)'). It adds no value for the color or parent parameters, both of which are undefined beyond the schema, and schema description coverage is reported as 0%. The description fails to compensate for the lack of parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Create a new layer.' It is unambiguous about the action. However, it does not differentiate from sibling tools like rhino_set_layer (which modifies an existing layer) or rhino_delete_layer, though the verb alone largely disambiguates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives only the nesting syntax for the name parameter but provides no guidance on when to use this tool versus alternatives. It does not mention conditions like 'use this to create a new layer, use rhino_set_layer to modify an existing one.' This gap leaves the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it creates an offset copy, implying the original curve is preserved, which adds a small behavioral clue. However, it does not disclose what happens to the document (e.g., a new curve is added), any failure conditions (e.g., non-planar curves), or whether it returns a GUID. With all annotations set to false, the description carries the full burden of behavioral disclosure, which it does not adequately fulfill.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action. It has no redundancy or wasted words, making it structurally efficient. However, its brevity comes at the cost of missing essential details, so it scores slightly lower than a perfectly balanced description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters (guid, distance, and plane_normal), one of which is optional, and performs a mutation, the description is too sparse. It does not mention that a curve GUID is required, what the output contains (despite an output schema), or expected behavior on different curve types. The description under-specifies for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 by explaining the parameters. It only mentions 'given distance' without explaining the direction convention (positive=right, negative=left) or the optional plane_normal parameter. This is insufficient for an agent to correctly set the parameters, especially since the schema provides no descriptions according to the signal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an offset copy of a curve at a distance, with a specific verb ('create') and resource ('curve'). It implicitly differentiates from rhino_offset_surface (surface vs curve) and rhino_create_curve (new curve from scratch). However, it does not explicitly mention that it requires an existing curve GUID, which is only implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like rhino_offset_surface or rhino_create_curve. The description does not mention prerequisites (e.g., the curve must already exist), limitations, or context in which this tool is appropriate. It only states the action without any usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=false and destructiveHint=false, and the description adds no further context about side effects. Critically, the description does not disclose that the default behavior is to delete original objects (via delete_originals=true), which is a significant behavioral omission given the annotation claims non-destructive. The description does not contradict the annotations, but it adds no value 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with a clear opening statement of purpose. It is front-loaded with the primary action and follows with a rationale. However, it lacks any structured breakdown of usage, making it slightly less effective than it could be, though it earns a 4 for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters including a nested object and a destructive default, plus an existence of an output schema, the description is far from complete. It does not describe how to select objects (guids), the base point role, or the deletion behavior. An agent cannot reliably know what to pass or what to expect, making this inadequate for a non-trivial creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 the lack of parameter documentation. It does not explain any of the parameters (name, guids, base_point, delete_originals) or their purpose. An agent has to rely solely on the schema field names, which is insufficient for correct invocation, especially for the delete_originals side effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair: 'Create a block definition' and explicitly distinguishes it from inserting instances by saying 'reusable geometry instances' and mentioning batch updates. It clearly separates this from sibling tools like rhino_insert_block or rhino_list_blocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains why blocks are useful (save memory, batch updates) but gives no explicit when-to-use versus alternatives, no exclusions, and does not mention that this is for defining blocks rather than inserting them. An agent would have to infer the use case from the name and phrase 'block definition'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, destructiveHint=false, and idempotentHint=false, indicating mutation. The description adds the 'always-facing' characteristic, which is a useful behavioral detail for how the text appears in 3D. However, it does not disclose other traits such as the effect of the 'point' parameter (required? optional?) or any side effects. Given annotations cover safety, the description provides only marginal additional behavioral context beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, which is concise. However, it is under-specified for a tool with multiple parameters and no other explanation. Conciseness is achieved at the cost of completeness, but the structure is clear and front-loaded with the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has multiple parameters (text required, others optional) and a nested point structure, but the description gives no context about defaults, required fields, or how the point is used. An output schema exists but is not shown here; even so, the description should clarify the placement behavior and key inputs. The tool is relatively complex, yet the description provides minimal guidance, making it incomplete for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about any of the parameters (e.g., text, font, height, point, layer, name). The context signal indicates schema description coverage is 0%, meaning the schema also lacks parameter descriptions (though the actual schema shown includes descriptions, the signal indicates otherwise). Since the description does not compensate for the low schema coverage and fails to clarify the meaning or usage of parameters, this dimension is poorly handled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a 'text dot' that is 'always-facing' (a label) at a point. This specifies a distinct resource (text dot/label) and the action (create), and it is differentiated from sibling tools like rhino_create_point or rhino_create_line by mention of 'text'. It lacks explicit mention that it creates a text object as opposed to a geometric shape, but it is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no mention of prerequisites, and no exclusions. The description only states what it does, not when it should be chosen over other creation tools. For a tool among dozens of create operations, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds no behavioral context beyond what the name/title state – it does not mention units, failure conditions, whether the solid must be closed, or what happens if an invalid GUID is passed. With zero additional context, it fails to enrich the annotation-covered traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff or redundancy. It is short and to the point, which is appropriate for such a simple tool. However, it is slightly under-specified – a bit more detail on the input would be useful, but as a summary it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple – one required parameter and an output schema exists – but the description omits any mention of the GUID parameter, the requirement that the object be a closed solid (though implied), and any indication of the return value (e.g., volume in cubic units). Since the schema coverage is 0%, the description carries the burden of explaining how to use the tool, and it falls short. An agent would likely struggle to know it must pass a GUID of a solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate for undocumented parameters. The schema has one parameter, params (GuidInput), requiring a GUID, but the description never mentions that a GUID must be provided or that it should reference a closed solid. The description adds no meaning beyond what the sparse schema already states, so it fails to help the agent understand the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (calculate) and a specific resource (volume of a closed solid), which makes it clear this tool computes volume. It does not explicitly name sibling tools like rhino_get_area or rhino_get_length, so it does not fully distinguish from them, but the resource type is distinct enough that an agent can infer when to use it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the phrase 'closed solid' – an agent can infer this is for closed solids only. However, it gives no explicit guidance on when not to use it, no mention of alternatives, and no prerequisites (e.g., the object must be a valid Rhino solid).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is a non-read-only, idempotent, non-destructive operation, and the description merely restates the action without adding behavioral context. It does not disclose whether the target layer must already exist or if it will be created automatically, nor does it mention the effect on object properties—information that is not 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and object. There is no redundancy or extraneous information, making it efficiently sized for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a basic move-to-layer operation, the description is minimally adequate and the presence of an output schema reduces the need to explain return values. However, it lacks essential context about layer existence behavior and does not clarify how this differs from rhino_set_current_layer, which could lead to incorrect tool selection in an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 for parameter clarification. The tool description does not mention either parameter (guids or layer) or explain their expected format, meaning an agent receives no additional semantic guidance beyond the bare schema names. This is a significant gap for a two-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Move objects') and a resource ('layer'), making its purpose unambiguous. It does not explicitly differentiate from sibling layer tools like rhino_set_current_layer or rhino_set_layer_visibility, but the verb alone sufficiently distinguishes moving objects to a layer from other layer operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as rhino_set_current_layer, rhino_set_layer_color, or rhino_set_layer_visibility. The description gives no context about typical use cases, prerequisites (e.g., layer existence), or when the sibling tools 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds the constraint that the material must be an 'existing' one, which is not in the annotations. However, it does not explain what happens if the material name is invalid, whether the operation is reversible, or the effect on the objects. The added context is limited but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It front-loads the core action and is appropriately concise for the tool's complexity. It loses a point for being perhaps too sparse, but it is not overwrought.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so the description doesn't need to explain return values. However, the description omits critical operational context: whether the material must exist beforehand (implied but not explicitly stated), how to find valid material names, error handling if objects are invalid, and any prerequisites. For a simple tool this might be acceptable, but the lack of any examples or usage notes makes it incomplete for reliable autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 parameter documentation. The description does not mention guids or material_name at all, nor how to specify them. The schema itself only provides minimal phrasing ('GUIDs of objects', 'Material name to assign'), which is insufficient for the agent to construct correct input without further inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific: 'Assign an existing material to objects' names the verb, resource, and object. It clearly indicates that the material must already exist (as opposed to creating one). However, it does not explicitly distinguish itself from the sibling rhino_set_material, so it earns a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like rhino_set_material or rhino_create_material. There are no explicit conditions, exclusions, or references to other tools, leaving the agent to infer usage context on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose that the operation is destructive or that it modifies/deletes input objects by default. While annotations include destructiveHint=true, the description adds no extra behavioral context beyond the annotation, such as what happens to the original solids or failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, short sentence with zero filler. It is appropriately concise and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a destructive boolean operation. It lacks information about prerequisites (e.g., closed solids, intersection existence), error handling, or the effect of the delete_input parameter. While output schema exists, an agent invoking this tool would benefit from knowing that inputs are replaced and that operation may fail without intersecting geometry.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning about the parameters (guid_a, guid_b, delete_input) beyond what the schema already provides. With 0% schema description coverage in the description, it fails to compensate; the schema's basic GUID descriptions and the delete_input default are not expanded upon.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation (keep only the intersecting volume) and the resource (two solids). It unambiguously distinguishes from sibling boolean tools like rhino_boolean_union and rhino_boolean_difference, making the purpose immediately evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that this is the boolean intersection operation, nor does it contrast with union or difference. An agent must infer usage from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds little behavioral context beyond the implicit 'create' action. Annotations already indicate readOnlyHint=false, so mutation is expected. The description does not disclose return behavior, impact on existing objects, or any side effects. It only restates the creation intent with no additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence with no filler words. It front-loads the primary action and parameters, making it highly concise and easily parsed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool among many geometric creation siblings, the description lacks usage guidance and behavioral context. It does not explain when to prefer this over an arc, ellipse, or similar tool, nor what the tool returns or any special cases. Though the schema covers parameter details, the overall context remains incomplete for an agent aiming to select and invoke appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the context signal says schema description coverage is 0%, the input schema itself contains descriptive text for most parameters (e.g., 'Center point', 'Plane normal (default Z-up)', 'Circle radius'). The description mentions the key parameters (center, radius, optional plane normal) but omits name and layer. It adds minimal extra meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a circle' with given center, radius, and optional plane normal. It is clearly distinct from sibling tools like create_arc or create_ellipse based on the name, but it does not explicitly differentiate itself from those alternatives within the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as create_arc or create_ellipse. The description only states what the tool does, with no mention of suitable scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description simply says 'Create a cone' which indicates a mutation, but the annotations already declare readOnlyHint: false, so it adds no new behavioral context. It does not disclose the return value, side effects on the document, or any orientation/axis assumptions. Unlike the high example, there is no additional detail beyond the annotation defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently worded sentence with no redundancy or filler. It front-loads the core action and parameters. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple primitive creation with an output schema present, so the description does not need to explain return values. However, it lacks information about the cone's orientation (default along Z axis), the effect of the cap parameter (default true), and any behavioral notes about the creation process. For a basic create operation this is minimally viable, but an agent might under-specify a cone if it assumed no cap or a different axis.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'base center, radius, and height' which maps to three schema parameters, but the schema already provides descriptions for each ('Base center point', 'Cone height', 'Base radius'). Schema description coverage is 0% meaning the tool description adds no extra meaning. It also omits cap, name, and layer parameters entirely. The description does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (create) and resource (cone) and lists the three core geometric inputs (base center, radius, height). It clearly distinguishes from other creation tools like rhino_create_sphere or rhino_create_box. However, it does not differentiate the cone from rhino_create_cylinder, which shares the same base center/radius/height conceptual model, leaving mild ambiguity about what makes the cone unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of typical use cases, exclusions, or prerequisites (e.g., need for an active document, or that a capped cone is the default). An agent must infer usage purely from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide basic mutation indicators (readOnlyHint=false, destructiveHint=false) and the description confirms creation, but no extra behavior is disclosed. It does not state that a new object is added to the document or mention side effects, undoability, or interaction with existing objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero fluff. It front-loads the action and object type, making it easy to scan. It could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with five parameters and a nested point structure, the description leaves out essential context: when to choose this over other curve tools, what outputs to expect (though an output schema exists), and any prerequisites. Relying solely on the title and schema is insufficient for correct tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all parameters (e.g., degree as 'Curve degree (1=linear, 3=cubic)', points as 'Control points for interpolated curve'). The tool description adds no parameter-level meaning and does not compensate for the 0% schema description coverage metric, but the schema itself is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (Create) and resource (interpolated NURBS curve) and clarifies the method (through control points). It distinguishes from siblings like rhino_create_line or rhino_create_polyline by indicating an interpolation curve, 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.
Usage Guidelines2/5
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 other curve creation tools (e.g., line, polyline) or when not to use it. The description does not mention alternatives, prerequisites, or scenarios that favor this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations convey safety or behavior hints (all false), so the description carries the full burden. It only mentions creation, implying mutation, but does not disclose what happens with invalid radii, whether a plane is required, or how the object is added to the scene. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is easy to parse. However, it is too sparse, omitting important operational details that could be included in a similarly concise manner. It is brief but not optimally balanced with content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested object with six properties, and while an output schema exists, the description explains neither the creation context nor the behavior of optional parameters. For a creation tool with multiple coordinates and attributes, the description is inadequate for an agent to call it correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per context, so the description must compensate. It clarifies that the two radii are independent ('separate X and Y radii'), which adds meaning beyond the parameter names, but it completely ignores other parameters like center, normal, name, and layer. Insufficient compensation for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'create' and resource 'ellipse', and the phrase 'separate X and Y radii' clearly distinguishes it from rhino_create_circle and other curve creation tools. It fully conveys the core purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives (e.g., circle vs. ellipse, or other creation tools). The description is a bare statement of action with no context about prerequisites, coordinate system assumptions, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutating tool (readOnlyHint=false), and the description confirms it creates an object. However, the description adds no additional behavioral context—it doesn't mention side effects (e.g., whether the rail curve is modified), output properties, or default behaviors like capping. With annotations present, the bar is lower, but the description still fails to disclose anything beyond the immediate action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It front-loads the core action and is appropriately sized for a tool that creates a pipe. It doesn't waste space on unnecessary details, and the structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is minimally acceptable. It indicates the main prerequisite (existing rail curve) and the output is a pipe. However, it doesn't explain how the pipe is generated (e.g., from a profile or as a closed solid), doesn't mention the default capping behavior, and doesn't clarify that the radius is required. The provided schema and output schema fill some gaps, but the description leaves room for ambiguity in an agent's decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has descriptions for all parameters (curve_guid, radius, cap, name, layer), but the tool description provides virtually no parameter information—it only implies the need for a curve via 'along an existing rail curve.' Schema description coverage is 0%, meaning the description does not compensate. Since the required 'radius' is not mentioned, an agent might be unsure what to provide without opening the schema, though the schema itself is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create a pipe (tube) along an existing rail curve.' It specifies the resource (pipe along a curve) and implies the need for an existing curve. It distinguishes from other create tools like rhino_create_cylinder or rhino_create_sweep by focusing on the rail curve. However, it doesn't explicitly mention the required 'radius' parameter or how the pipe is constructed, so it falls short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description doesn't mention conditions like 'use when you have an existing curve' or contrast with similar tools like sweep. There are no exclusions or prerequisites stated beyond the implication of an existing rail curve. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint: false and destructiveHint: false, so the operation is not marked as safe or clearly destructive, but the description adds no behavioral context. It does not disclose what happens on error, whether the command runs synchronously, if it returns any output, or whether it may modify the scene. Since annotations are ambiguous, the burden falls on the description, which fails to clarify.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, unambiguous sentence that is front-loaded with the core action. There is no wasted text, and the brevity is appropriate for the tool's simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description provides no information about return values, potential errors, or limitations. For a generic command runner that could have wide-ranging effects, this is a significant gap. An agent cannot predict what outcome to expect or what precautions to take, making the description incomplete for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0% per context signals, meaning the description must explain the parameter. The description simply says 'command' and does not elaborate on format, syntax, or expectations. The schema does provide an example ('_Circle 0,0,0 5'), but the tool description itself adds no value beyond the parameter name, making it insufficient for an agent to know how to construct a valid command.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Execute') and a clear resource ('a Rhino command string as if typed in the command line'). This distinguishes it from other tools that perform specific operations, as it is a generic command executor. The purpose is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of the many specific sibling tools (e.g., rhino_create_circle, rhino_move). It does not mention that it is for arbitrary commands not covered by dedicated tools, nor does it warn about potential side effects. The agent is left to infer when this is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false and destructiveHint=false, so the description carries the burden of behavioral disclosure. It says 'Create' but does not explain whether the original objects are modified or copied, whether new objects are returned, or any side effects. No information is given about how existing geometry is affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It front-loads the core purpose. However, it is almost too terse—it conveys the high-level action but leaves all operational detail to the schema, which is acceptable but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (one nested parameters object with four properties) and a rich schema that explains each field, the description provides the essential idea but nothing more. It does not mention output behavior or any rules about count/include original, which an agent might need. The schema compensates partially, but the description alone is not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the tool description adds no parameter detail. While the schema itself provides descriptions for count, guids, spacing, and direction, the description does not compensate for the low coverage. It vaguely mentions 'direction' and 'even spacing' but omits required inputs like guids and count, and clarifies nothing about spacing defaults or count semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create'), names the resource ('linear array of objects'), and specifies the key traits ('along a direction with even spacing'). This is unambiguous and naturally distinguishes it from the sibling tool rhino_array_polar (polar array).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like rhino_array_polar or rhino_copy. It does not state any conditions, prerequisites, or exclusions. An agent is left to infer from the name alone when this is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating operation (readOnlyHint=false), and the description adds a basic summary but no additional behavioral context. It does not disclose that base_center is optional with default origin, nor does it mention cap behavior, placement layer, or side effects on existing geometry. For a creation tool, more transparency about defaults and scope would be valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence with no filler. It is appropriately brief and front-loads the core parameters, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a geometry creation tool with multiple parameters, defaults, and an output schema, the description is thin. It does not mention units, coordinate conventions, default cap behavior, or what the return value represents. An agent would need to consult the schema and possibly external documentation to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions base center, radius, and height, but implies all three are required, whereas the schema marks only radius and height as required. It omits cap, name, and layer parameters, which already have descriptions in the schema. Since schema coverage is high, the description adds little value and may mislead about requiredness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create) and the resource (cylinder), and specifies the key dimensions (base center, radius, height). This distinguishes it from sibling creation tools like rhino_create_sphere or rhino_create_box, which have different parameters and shapes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., extrusion or loft for complex shapes). It does not mention any prerequisites, exclusions, or when not to use it. The agent is left to infer usage from the name alone, which is minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety hints (all false), so the description must carry behavioral details. It only states the action (create) without elaborating on side effects, such as whether existing materials are affected, naming conflicts, or that the material is stored in the material library. This is minimal beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and resource. Every word is necessary; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with a detailed schema and an output schema (per context), the description is minimally adequate. However, it does not explain that a new material is created independently of objects, nor does it clarify the relationship to sibling tools like rhino_assign_material. Some contextual guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The nested schema already provides detailed descriptions for all parameters (name, diffuse_color, ior, reflectivity, transparency) with ranges and defaults. The tool description adds no additional parameter information, but the schema does the heavy lifting, so a baseline of 3 applies despite the context signal indicating 0% coverage (which appears to be miscalculated for the top-level 'params' only).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (create) and resource (render material) and lists key properties (color, transparency, reflectivity). It is clear and distinct from siblings like rhino_assign_material or rhino_set_material, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that this creates a material in the document as opposed to assigning an existing one or setting material properties on an object. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so it's a mutation. The description does not add any context about what happens to the scene, side effects, or object management. It merely restates the action. No additional behavioral disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with zero waste. It front-loads the action and the optional closing behavior. Every word earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with a detailed input schema and an output schema, the description covers the essential requirement (ordered vertices) and the optional closure. However, it lacks guidance on when to use this versus alternatives, and it doesn't mention the layer or name parameters, though those are in the schema. Overall it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description does not describe the parameters. The description only adds 'ordered vertices' which is similar to the schema's 'Ordered list of vertices'. It provides no extra meaning about the 'name', 'layer', or 'closed' parameters, which are documented in the schema. It fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Create), the resource (polyline), and the key requirement (through ordered vertices). It also communicates the optional closing behavior. While it doesn't explicitly differentiate from siblings like rhino_create_line or rhino_create_curve, the description is clear and unambiguous about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: create a polyline by providing ordered vertices, optionally closing it. It gives basic instructions but does not mention when to choose this vs other creation tools, nor any exclusions or prerequisites. There is no mention of when not to use it, so minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the word 'permanently', which clarifies that deletion is irreversible, complementing the destructiveHint annotation. However, it does not disclose other behavioral traits such as error handling, behavior on invalid GUIDs, or interaction with undo. Given that the annotation already signals destructiveness, the description adds minimal extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the core action and selection method. It is optimally concise and well-structured for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool, the description covers the essentials but lacks important context such as irreversibility warnings (beyond the word 'permanently'), the need for existing objects, and any undo behavior. While the destructiveHint annotation covers some of this, the description could still better prepare an agent for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by GUID' but does not explain the GUID format, whether multiple GUIDs are accepted, or how they relate to object selection. The schema's parameter description already states 'GUIDs of objects to delete', and with schema description coverage reported as 0%, the description should compensate but does not offer additional semantic value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (delete), a resource (objects), and a selection method (by GUID). It is clear enough to distinguish from layer-specific deletion (rhino_delete_layer), though it does not explicitly mention alternatives. The one-sentence description is sufficient for understanding the primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that layer deletion should use rhino_delete_layer, nor does it warn about the destructive nature or any prerequisites (e.g., object existence). The lack of explicit usage context makes it easy for an agent to misuse it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the full burden of behavioral disclosure. It only says 'Duplicate' without explaining side effects, whether new objects are created, or what happens to the originals. No mention of the return value or any other behavioral traits beyond the bare action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence that front-loads the action and clearly identifies the target. Every word contributes to the meaning, and there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits crucial context such as the distinction from the sibling rhino_duplicate_edge, whether the duplicate is a new independent object, and what the tool returns. Even though an output schema exists, the description fails to give the agent enough to fully understand the operation's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the lone parameter 'guid' as 'GUID of the surface/brep/mesh', and the description adds no further meaning or context. With schema description coverage reported as 0%, the description should compensate, but it remains silent on parameter usage or formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (duplicate) and the resource (border/naked edge curves) with specific object types (surface, brep, mesh). It distinguishes itself from the sibling rhino_duplicate_edge by focusing on border/naked edges, which is a more specific subset, so an agent can tell when to use this over that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like rhino_duplicate_edge or rhino_get_naked_edges. It does not state prerequisites, conditions, or when not to use it. The description leaves the choice to inference from the name and minimal text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true and readOnlyHint=false, indicating the operation modifies the curve. The description adds no further behavioral context—it does not clarify whether the curve is modified in place or if a new curve is created, nor does it mention any side effects on the original object. It adds nothing beyond what the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It packs the core action, parameter, and side options efficiently, making it easy to scan and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with four parameters and only one required, the description is incomplete. It does not mention the style parameter, any prerequisites (e.g., curve must be editable, length constraints), or whether the operation is reversible. Although an output schema exists, the input side is under-specified for an agent to reliably call the tool with correct expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'length' and 'side' (start/end/both), matching those properties, but it entirely omits the 'style' parameter (Line, Arc, Smooth), which critically affects the extension behavior. Given the low coverage, the description should cover all parameters; it only partially does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (extend), the resource (a curve), the parameter (given length), and the scope (from start, end, or both ends). It is specific and distinct from siblings like offset_curve or rebuild_curve, so an agent can understand the core function without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as offset_curve, fillet_curves, or rebuild_curve. The description gives no context about typical use cases, exclusions, or prerequisites, leaving the agent to infer when 'extending' is the right operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that this is not a read-only operation (readOnlyHint false) and not destructive (destructiveHint false). The description adds no additional behavioral context, such as whether grouping modifies objects, is reversible, or has side effects. It relies entirely on annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the core action and includes the optional name detail, which is directly relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple grouping tool with an output schema and supportive annotations, this minimal description is adequate. However, it could mention that grouping is distinct from joining objects or provide a note about how groups behave, but these are not critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides clear descriptions for both parameters (guids and group_name). The tool description adds no parameter information, but the schema coverage is sufficient, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (group objects) and the optional naming aspect. It's specific enough to distinguish from rhino_ungroup, though it doesn't explicitly differentiate from similar tools like rhino_join.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no information about when to use this tool versus alternatives, no prerequisites, and no context about grouping semantics. Sibling tools like rhino_ungroup or rhino_join exist but the description offers no guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the bare action. It does not state whether the move modifies objects in place, whether it creates copies, what happens to selection, or if undo is supported. Annotations are minimal (readOnlyHint=false, destructiveHint=false) and do not fill this gap, so the description falls short of providing useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It front-loads the core action and vector concept, making it easy to parse. Ideal length for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward move operation with a well-defined schema and an output schema present (return values not needed in description), the description is minimally sufficient. However, it omits any hint about coordinate systems, units, or whether the move is relative to the object's current position. These are not critical given the schema, but they would improve completeness for an agent without Rhino domain knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already includes descriptions for both parameters ('GUIDs of objects to move' and 'Translation vector'), so the schema carries the parameter meaning. The tool description adds no additional insight about how to construct the translation vector or interpret the GUIDs, but this is acceptable given the schema coverage. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move objects') and the mechanism ('by a translation vector'), making it obvious what the tool does and distinct from sibling transform tools like rhino_rotate or rhino_scale. It doesn't explicitly name a sibling, but the verb and vector qualifier are specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as rhino_rotate, rhino_scale, or rhino_copy. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer suitability 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already provide. With readOnlyHint=false and destructiveHint=false, the agent can infer it is a mutating but non-destructive operation, but the description does not disclose what happens if there is no operation to redo, whether it modifies the document state, or any side effects. Since annotations are sparse, the description carries the burden, and it fails to deliver.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. It is front-loaded and contains no fluff. While it is extremely brief, this is appropriate for a no-parameter operation, and the sentence earns its place by stating the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema, the description is minimally sufficient to convey the basic action. However, it is incomplete in that it does not address edge cases (e.g., behavior when there is no undo history), nor does it mention that the tool is part of an undo/redo pair. Given the simplicity of the tool, a score of 3 reflects that it is functional but leaves important context unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. The description does not need to explain parameter meaning. With 0 parameters, the baseline is 4, and the description does not detract from this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: redo the last undone operation. It uses a specific verb and resource, and it is not a tautology. However, it does not explicitly distinguish itself from its sibling rhino_undo beyond the name and the word 'redo', so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 rhino_undo or other editing operations. It does not mention prerequisites (e.g., that an undo must have occurred) or conditions that would make redo inappropriate. This is a significant gap for a tool whose sibling set is large.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the basic action and does not disclose any behavioral traits such as whether objects are modified in place, whether prerequisites like object existence are needed, or what the tool returns. Annotations only provide readOnlyHint=false, which is minimal, and the description adds no further context about side effects or operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the core operation. It is appropriately structured, front-loading the action and key spatial concepts, with no extraneous words. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no readOnlyHint, the description is inadequate. It lacks essential context such as prerequisites (e.g., whether objects must be selected), potential side effects on the scene, and expected output format. Given the presence of an output schema and the complexity of a 3D rotation, a more detailed description is necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage reported as 0%, the description must compensate for parameter understanding, but it only mentions 'axis' and 'center point' without explaining the meaning of guids, angle_degrees, or the relationship between parameters. It fails to clarify required fields, units, or default behavior, leaving agents to guess critical input semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Rotate objects') and the mechanism ('around an axis through a center point'), which unambiguously distinguishes it from sibling transformation tools like move, scale, or mirror. It is direct and leaves no doubt about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention rotation-specific scenarios or exclude cases where other transformations would be more appropriate. An agent must infer usage solely from the tool name, which is insufficient for effective selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide the core safety profile (idempotent, not destructive, not read-only). The description adds no additional behavioral context—such as whether the current selection is replaced or augmented, or how invalid GUIDs are handled. Since annotations carry most of the burden, the description's minimal contribution brings it to a 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the action and resource, making it immediately scannable. This is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and that an output schema exists, it need not detail return values. However, key behavioral context is missing: whether the selection replaces the current selection, what happens with invalid GUIDs, and whether objects must already exist. These details are essential for an agent to use the tool correctly and are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 the single parameter. It does not: it simply refers to 'GUIDs' without explaining what a GUID is, that they must be valid object identifiers, or any constraints. The schema already says 'List of GUIDs to select', so the description adds no value beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (select), the resource (objects in the Rhino viewport), and the mechanism (by their GUIDs). This distinguishes it from sibling tools like rhino_get_objects, which retrieve information, and rhino_check_objects, which validate. An agent can immediately understand what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention whether selection replaces the current selection, whether to use it before transformations, or any prerequisites. There are no exclusions or references to other tools, leaving the agent to infer usage context from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a mutation (readOnlyHint=false) and idempotency (idempotentHint=true). The description adds no additional behavioral context: it doesn't mention whether the material must already exist, whether it overwrites previous assignments, or how failures are handled. With annotations present, the bar is lower, but the description still provides no value beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the primary action and resource. For a simple tool, this is appropriately sized and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (two parameters, one action), but the description is missing key context: it doesn't clarify whether the material must exist beforehand, and it doesn't distinguish itself from the sibling rhino_assign_material. The output schema is marked as present, so return values may be covered there, but the description alone is minimally complete. It is adequate for a trivial operation but leaves the agent to infer usage conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters ('GUIDs of objects' and 'Material name to assign'). Since schema description coverage is high (both parameters have descriptions), the baseline is 3. The description adds no extra parameter semantics, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Assign a named material') on a specific resource ('objects'). However, it does not differentiate from the sibling tool rhino_assign_material, which appears to serve a similar purpose. The verb and resource are clear, but without distinguishing from the sibling, it cannot get a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like rhino_assign_material or rhino_create_material. The description only says to assign a material, but doesn't mention scenarios, prerequisites, or when another tool would be more appropriate. This leaves the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose key behaviors: whether the original curve is destroyed (though destructiveHint is true, the description doesn't confirm it), whether new objects are created, or what the output represents. It adds no behavioral detail beyond the annotation, lacking important context like side effects on the cutter or the result of a failed split.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words or repetition. It front-loads the primary action and object, making it efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a modification tool with destructive hints, the description is incomplete. It does not mention return values, whether the curve is modified in place or if new pieces are produced, or any error conditions (e.g., no intersection). Given the availability of an output schema (not shown), the description should still explain the operation's outcome and requirements, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter descriptions in the schema are minimal ('GUID of the curve to split' and 'GUID of the cutting object'), and the tool description only repeats the concept of a curve and cutting object without adding any extra meaning. No guidance on GUID format, valid object types, or how the parameters relate. With 0% schema coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Split' applied to 'a curve' at 'its intersection with a cutting object.' This is specific and distinguishes it from similar tools like rhino_trim or rhino_offset_curve in the sibling list. The resource and action are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_trim, rhino_boolean_difference, or rhino_split alternatives. There is no mention of prerequisites (e.g., the curve and cutter must already intersect) or exclusions. The agent receives no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the core mutation behavior is disclosed. However, the description adds nothing beyond that: it omits that a portion of the curve is permanently removed, that the side parameter determines which part is discarded, and that the original curve is modified in place. No side effects, failure conditions, or return behavior are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. It is appropriately terse. However, it omits critical context such as the destructive nature and the side parameter, so its brevity borders on under-specification. It earns a 4 for conciseness but not 5 because it sacrifices necessary information for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature, the existence of a side parameter, and the presence of an output schema, the description is incomplete. It does not explain what happens to the original curve, what the output contains, or that the cutter must intersect the curve. An agent may not understand that the tool mutates the geometry or that it discards a segment, making the description insufficient for correct invocation without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself provides descriptions for each parameter (curve_guid, cutter_guid, side), so the baseline is 3. The tool description adds no parameter information. The side parameter's semantics ('Which side to discard (0 = first segment)') are somewhat cryptic, but the schema covers it adequately. Overall, the description does not compensate for any missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('trim'), resource ('a curve'), and the mechanism ('at its intersection with a cutting object'). It clearly distinguishes from sibling tools like rhino_split (which likely splits without removing) and boolean operations. The intent is immediately unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as rhino_split, rhino_boolean_difference, or rhino_join. It does not mention prerequisites (e.g., the curve must intersect the cutter), nor any exclusions or typical workflows. An agent must infer when trimming is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, indicating a write operation, which aligns with 'Create'. However, the description adds little beyond the name—it doesn't clarify whether original objects are copied or moved, whether any objects are modified in place, or what the output contains. Since annotations already cover the safety profile (non-destructive), the description fails to provide meaningful behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically clear sentence that front-loads the core concept. It is efficient in wording, but it sacrifices critical detail for brevity, making it borderline under-specification rather than well-structured conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple parameters, nested schema, output schema, and many siblings), the description is grossly insufficient. It does not explain prerequisites (e.g., selecting objects), the meaning of 'angle' or 'axis', or expected return values. The presence of an output schema mitigates return-value explanation, but overall completeness for a tool like this is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%—the description mentions no parameters. Although the input schema itself has detailed descriptions for guids, count, center, axis, and total_angle, the tool description does not compensate for the low coverage. An agent must rely entirely on the schema, and the description adds no guidance on how to use these parameters together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Create') and the resource ('polar (circular) array of objects around a center point'), distinguishing it from linear arrays and other creation tools. The action and target are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for circular arrangements but does not explicitly state when to prefer this tool over alternatives like rhino_array_linear. It lacks any contrast or condition-driven selection guidance, leaving the agent to infer 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark destructiveHint=true, but the description does not elaborate on the destructive nature, the default deletion of input objects (delete_input defaults to true), or potential failure when solids do not intersect. It adds no behavioral information beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler words, front-loading the core action. It is concise and effectively structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits critical context: it does not mention that the operation is destructive by default (delete_input defaults to true), that the inputs may be deleted, or that the solids should be closed and overlapping for a meaningful result. Since the tool is destructive and has a mutable default, this lack of context makes it incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies that solid A is the base and solid B is subtracted, giving meaning to the parameter names that the schema only labels as 'first' and 'second'. However, it does not explain delete_input or provide constraints on the solid types, leaving the agent to infer from the schema's sparse descriptions (coverage 0% per signal).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Subtract solid B from solid A' uses a specific verb (subtract) with clear resources (solid A and solid B), making the operation immediately distinguishable from sibling boolean tools like union and intersection. It precisely states the action without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 boolean_union or boolean_intersection, nor does it mention any prerequisites or exclusions. It simply states the operation without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutation (readOnlyHint=false) but provide no further behavioral details. The description does not disclose that the tool creates a new object, that it requires existing curves, or any side effects. It carries little beyond the annotation, so it fails to add meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, with the core action front-loaded and the use cases in a second sentence. No fluff or repetitive details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives enough to select the tool but omits details about the output (though an output schema exists) and prerequisites such as having valid curves. It touches on parameters but not thoroughly. It is minimal but not entirely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the roles of the parameters by calling the rail a 'rail curve' and the sections 'cross-section curves', adding some semantic value beyond the schema's generic GUID descriptions. However, schema description coverage is 0%, so the description should compensate more, but it does not explain name, layer, or closed options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sweeps one or more cross-section curves along a single rail curve, specifying the verb and resource. It gives concrete examples (moldings, pipes). It implicitly distinguishes from sweep2 by mentioning 'single rail', but does not explicitly name that sibling though many creation tools exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers practical use cases ('moldings, pipes with varying cross-sections') providing some context for when to use it. However, it does not mention when not to use it or explicitly point to alternative tools like sweep2 or loft, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds the supported file formats and object scope, which is useful. However, it doesn't disclose behavioral details like overwrite behavior, error handling, or that the tool writes an external file, so it adds only moderate context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence stating the action and key formats. Every word earns its place; it is concise without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description and schema cover the essentials: what to export, where to export, and supported formats. An output schema exists, so return details are presumably handled. Minor gaps remain, such as overwrite behavior and error conditions, but these 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes descriptions for both parameters: filepath explains the output path with formats, and guids explains that None means entire scene. Since the schema fully documents them, the description doesn't need to compensate. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation (export), the resource (objects or entire scene), and the output formats, making the tool's purpose unmistakable. It doesn't explicitly contrast with sibling tools like rhino_import_file, but the verb 'export' and the file destination distinguish it well enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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, prerequisites, or context such as 'use when you need to save geometry to disk.' There is no mention of selection criteria or exclusions, leaving the agent to infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is covered. The description adds useful context by specifying that objects must be 'adjacent' (touching) to join. It does not disclose failure behavior (e.g., what happens when objects are not adjacent), but with annotations covering the safety profile, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It states the action and the input type compactly. It loses a point only because it fits so little information into its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the definition is largely adequate. However, it omits practical details an agent needs: that objects must share endpoints/tolerance, the result of non-adjacent inputs, and the relationship to the destructive hint (that originals are consumed). These are moderate gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself describes the sole parameter as 'GUIDs of curves/surfaces to join' and enforces minItems 2, so the schema carries most of the burden despite the 0% coverage signal. The tool description repeats the target types but adds no new syntax, format, or selection guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('join'), a resource ('curves or surfaces'), and the outcome ('into a single object'). It is clear on its face, and the phrase 'single object' helps differentiate it from grouping. However, it does not explicitly distinguish itself from rhino_group or the boolean operations, which produce similar aggregate results, 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.
Usage Guidelines2/5
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. An agent could reasonably confuse rhino_join with rhino_group, rhino_boolean_union, or rhino_explode (the inverse), and the description provides no routing information, prerequisites (e.g., objects must share endpoints), or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true, which already convey that this is a harmless, idempotent write operation. The description does not add behavioral context beyond the annotations—it does not mention any side effects, scope limitations, or that it only affects visual display rather than geometry or materials.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words, which is appropriate for a simple tool. It is efficient, though it could benefit from a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is straightforward, the description does not explicitly state that the color is the display color (as opposed to material color) or that multiple objects are targeted via GUIDs. The schema covers the GUID requirement and RGBA semantics, so the missing context is minor but still a gap for an agent that only reads the description first.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters, but the input schema provides comprehensive descriptions for the nested Color object (r, g, b, a each with range explanations) and the guids field ('GUIDs of objects'). The schema alone is sufficient for an agent to understand what values to supply, so the lack of parameter info in the description is compensated by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Set') and resource ('display color') on objects, making the primary purpose clear. However, it does not distinguish this tool from similar sibling tools like rhino_set_layer_color or rhino_set_material, so while the verb and resource are explicit, the differentiation is left to the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention any context, prerequisites, or exclusions, leaving the agent to infer that it is the right choice among the many 'rhino_set_*' siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, which cover the main behavioral aspects. The description adds no extra context beyond the literal action (e.g., effects on active viewport or camera state). It does not contradict the annotations, but it provides minimal added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the core action and lists example values. There is no fluff or redundancy; every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and an output schema exists so return values are already covered. The description is sufficient for an agent to call it correctly, though it omits details about invalid view names or whether it changes the active viewport. Given the simplicity, the overall coverage is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on the view_name parameter. The schema itself includes a description listing allowed values, but the tool description adds nothing beyond that. Since schema description coverage is reported as 0% (meaning the description ignores the parameter), the description fails to compensate for the semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (switch the viewport) and the target (a named view), with a list of common view names. It is specific enough to understand the tool's purpose, though it does not explicitly differentiate from sibling camera tools like rhino_zoom_extents or rhino_capture_view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 description only states what it does, without mentioning when to prefer it over rhino_zoom_extents, rhino_list_views, or other camera-related tools. There are no exclusions or contextual hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, consistent with the 'create' action. The description adds no behavioral details beyond the basic creation, such as effect on the scene, coordinate system assumptions, or failure conditions. It is consistent but provides minimal extra information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose (create arc) and key parameters (center, radius, angle range). It is efficient with zero wasted words, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema covers parameters and there is an output schema, the description lacks optional guidance such as the arc being a partial segment (though angle range implies it) or any typical pitfalls. It is sufficient for a basic understanding but not enriched for nuanced usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes each parameter (center, radius, angles, layer, etc.) with defaults. The description text adds no additional semantics beyond what the schema provides. With full schema coverage, the baseline is 3, and the description does not compensate or enhance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (arc) with key attributes (center, radius, angle range). It distinguishes from related tools like circle or ellipse by mentioning angle range, though it doesn't explicitly contrast with siblings. The verb and resource are specific and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like rhino_create_circle or rhino_create_ellipse. The description only states what it does without context on selection criteria or exclusions. Agents must infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, so the description being a mutation is consistent (no contradiction). The description adds some value with 'Caps closed curves' and the along-a-direction constraint. However, it does not disclose what happens to the source curve after extrusion, nor whether the result is a surface or solid — useful behavior beyond the annotations that is left unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with zero wasted words, and the primary action is front-loaded in the first sentence. Every clause earns its place — one defines the operation, the other a default cap behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value details are covered by structured data. For a mid-complexity geometric tool, the description is adequate but incomplete: it omits the behavior when 'direction' is not supplied (defaults to a specific axis or is required?), and whether the original curve is retained. These are the kind of details an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is reported at 0%, so the description bears the burden of explaining parameters. It partially compensates by implying the 'direction' parameter ('along a direction') and the 'cap' parameter ('Caps closed curves'), but it does not explain 'distance' or 'curve_guid'. The schema itself carries descriptions for these fields, so the description adds only marginal meaning over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Extrude') and resource ('existing curve') with a clear direction qualifier, which conveys the core operation unambiguously. The 'Caps closed curves' clause adds a specific behavioral detail. It distinguishes itself from siblings like loft/sweep/revolve by mechanism, though it does not name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose extrusion over the many adjacent creation tools in the sibling list (rhino_create_loft, rhino_create_sweep1, rhino_create_revolve, rhino_create_planar_surface, rhino_create_patch). The description also does not clarify the default behavior when the optional 'direction' parameter is omitted, which is material to correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description is not required to restate that the operation modifies the model. It adds minimal context beyond the annotation—mainly that the result is 'individual components.' It does not mention whether the original compound objects are deleted or retained, but this is not a contradiction and the annotation covers the destructive nature. Thus a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no superfluous words. It is front-loaded with the core action and outcome. This is appropriately concise for a straightforward tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter and an output schema (though not shown), so the description does not need to explain return values. However, it lacks any usage guidance regarding when to prefer this tool over siblings and does not note any side effects beyond the destructive annotation. Given the simplicity of the operation, this is acceptable but not complete—usage direction is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for the 'guids' parameter ('GUIDs of objects to explode'), so the tool description adds no additional meaning. With schema coverage effectively 100% for the single parameter, the baseline of 3 applies. The description does not provide extra syntax or format details beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Explode') and a clear resource ('compound objects') with the outcome ('into individual components'). It is unambiguous about what the tool does. However, it does not distinguish itself from closely related siblings such as rhino_explode_block or rhino_ungroup, so it scores slightly below the top.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like rhino_explode_block or rhino_ungroup. It does not mention any prerequisites, such as selection requirements or differences between exploding blocks versus other compound objects. An agent receives no direction on choosing among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readOnly, idempotent, and non-destructive, so the description need not repeat those. The description adds the object types it works on, which is useful context. However, it does not mention that the operation is non-mutating beyond what annotations provide, nor does it describe any edge cases or units. With annotations covering the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly states the action and the object types. It is front-loaded and contains no unnecessary words, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (so return values need not be described), the description lacks essential usage context. It does not explain that the guid parameter refers to an existing Rhino object previously obtained via get_objects or similar, nor does it clarify the selection of among surface, brep, or mesh. For a tool with a single parameter and no schema-level documentation, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter documentation exists in the schema. The description does not add any information about the 'guid' parameter, such as how to obtain it or what objects are valid. The agent is left without guidance on what to pass, making the parameter semantics very weak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Calculate' and the resource 'surface area', and specifies the object types (surface, brep, mesh). This distinguishes it from sibling tools like rhino_get_volume and rhino_get_length, which are for different measurements. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for area calculations on specific geometry types, but it does not explicitly state when to use this tool versus alternatives or mention any prerequisites. It does not reference rhino_get_volume or rhino_get_length as alternatives, leaving some inference to the agent. However, the scope is clear enough for a basic call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 clear. The description adds that it returns multiple values and handles both curves and surfaces, which is useful. However, it does not disclose behavior for invalid inputs (e.g., out-of-range parameters) or clarify whether both curve and surface parameters are accepted simultaneously. This is a moderate gap but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no filler. Every word contributes to understanding the tool's function and output, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool handles both curves and surfaces with different parameterization, the description omits essential usage details: how to specify the point for each type (parameter vs. u/v), and that the `guid` can be a curve or surface but only one set of parameters should be provided. An output schema exists, so return values are covered, but the input specification is incomplete and could lead to incorrect calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the tool description provides no explanation of parameters. The schema itself gives minimal labels ('U parameter on surface', 'V parameter on surface', 'Parameter on curve (None = midpoint)'), but the description does not clarify which parameters apply to curves versus surfaces—a critical distinction. The agent must infer from the schema that `parameter` is for curves and `u`/`v` for surfaces, but the description adds no guidance, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact action (get curvature), the target (a point on a curve or surface), and lists the outputs (curvature, radius, tangent, gaussian/mean for surfaces). It is specific and distinguishes from sibling query tools like rhino_get_area or rhino_get_length, which target different geometric properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives, nor are any exclusions stated. The description simply states what the tool does without contextual cues like 'use for curvature analysis' or 'prefer this over rhino_closest_point for derivative queries.' The agent must infer usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety hints (all false), so the description carries the full burden of disclosing side effects. It mentions access to all APIs, implying it can mutate the document, but does not explicitly warn that running arbitrary code can have destructive or irreversible effects, nor does it describe any environment constraints. This is a significant gap for a script execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The primary purpose is stated first, and the additional context about API access is front-loaded and relevant. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 omits crucial details: how to structure script code, how inputs are provided and accessed, and what side effects may occur. For a tool executing arbitrary code with only a 1-parameter nested object, the description is too thin. An agent cannot confidently call it without additional schema inspection and guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 parameter semantics. It does not explain what `code` should contain beyond the schema's minimal text, nor does it clarify how `inputs` are passed to the script or how to access them inside the script. The tool description adds zero value about parameters, leaving an agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Execute' and the resource 'GHPython script inside Grasshopper', which distinguishes it from sibling tools like `rhino_run_python` (which runs in Rhino, not Grasshopper) and the many geometry creation tools. It also adds context about full API access, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this runs scripts specifically in Grasshopper, which is enough to differentiate it from `rhino_run_python`. However, it does not explicitly state when *not* to use it or mention alternatives, so it lacks explicit exclusions or comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral context that geometry is added to the current document, which goes slightly beyond the raw verb. However, annotations already convey that this is a mutating (readOnlyHint=false) and non-destructive (destructiveHint=false) operation, so the description does not disclose additional traits like import position, error handling, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential action without wasted words. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description is minimally complete. However, it omits potential caveats like whether imports are placed at the world origin or whether existing geometry is affected, and it doesn't mention error conditions. These are minor for a basic import but could confuse an agent expecting more guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single parameter (filepath) including supported formats. The description adds no additional meaning about how the parameter should be used, so it meets the baseline but provides no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource ('Import geometry from a file') and specifies the target ('into the current document'), making the action unambiguous. However, it does not explicitly contrast with sibling tools like rhino_export or creation commands, though the intent is obvious from the name and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as creating geometry manually or using rhino_run_command. The description does not mention scenario-dependent choices or prerequisites (e.g., file existence, format support), leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=false and destructiveHint=false, so the description adds little behavioral context. It does not disclose that inserting a block instance modifies the document, that the block definition must exist, or what happens with invalid inputs. No extra behavioral traits are described beyond what 'insert' implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the core action and key options. There is no filler or unnecessary information. It is well-structured and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 that an output schema exists (so return values are covered), the description is adequate but not fully complete. It misses critical context such as the requirement that the block definition already exists, and it offers no guidance on error conditions or interaction with layers. For a modification tool, some behavioral prerequisites are expected but not provided, leaving gaps that could lead to misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes detailed descriptions for every parameter (e.g., name: 'Block definition name to insert', scale: 'Scale factor', rotation: 'Rotation angle in degrees', insertion_point: 'Insertion point'). Since schema description coverage is effectively high, the description does not need to repeat these details. The description mentions 'point', 'scale', and 'rotation' which aligns with schema parameters but adds no new semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Insert a block instance'), the resource (block instance), and key parameters (point, scale, rotation). It distinguishes from sibling tools like rhino_create_block (which defines a block) and rhino_explode_block (which breaks block instances). The verb and object are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites (e.g., the block definition must already exist), nor does it explain when to prefer rhino_insert_block over rhino_move or rhino_copy. The agent has to infer usage solely from the action name and parameter names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds that it 'Creates intersection curves' which gives some behavioral nuance, but it does not describe edge cases (e.g., when objects do not intersect, or behavior for non-surface/brep types). Given the annotation coverage, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and gets directly to the point. It avoids fluff and front-loads the core function. It could be slightly more detailed on usage, but as a concise statement it is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with only two parameters, the description lacks guidance on object type compatibility (e.g., curves, surfaces, breps) and what happens when no intersection exists. The existence of an output schema partially compensates for return-value documentation, but the lack of exclusions or error conditions leaves some gaps for an agent invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It only refers to 'two geometric objects' without clarifying which GUID corresponds to which object or whether order matters. The names 'guid_a' and 'guid_b' are self-explanatory to Rhino users, but the description adds no extra semantic value beyond a generic reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find intersection' and the resource 'two geometric objects', and specifies that it creates intersection curves for surfaces/breps. This distinguishes it from similar tools like rhino_boolean_intersection, which computes a boolean result rather than just intersection geometry. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as rhino_boolean_intersection, rhino_trim, or rhino_split, which also rely on intersections. The description does not mention scenarios where this tool is preferred or when another is more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the agent knows the operation is destructive. The description adds no behavioral context beyond that—it does not mention whether the original object is modified in place, whether the operation is reversible, or any side effects on the solid. With annotations covering the basic safety profile, the description still fails to add value about the actual behavioral consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero fluff. It front-loads the core action and then gives a practical usage tip. Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (three parameters) and the presence of an output schema, the description provides essential usage guidance via the get_object prerequisite. However, it lacks information about units for distance, edge_index bounds, or error handling. It is adequate for basic invocation but leaves gaps that the schema or annotations do not fill, particularly around output format and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%—the description contains no parameter details at all. While the input schema provides descriptions for each parameter (guid, distance, edge_indices), the description does not augment or clarify them. For a low-coverage situation, the description should compensate by explaining parameter relationships or format requirements, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Apply' and the resource 'chamfer (beveled edge)' on 'edges of a solid', which clearly distinguishes this from sibling fillet operations. It also directs the agent to use get_object first, reinforcing the precise scope. This is a clear, specific purpose with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to 'Use get_object first to see available edge indices', which is a useful prerequisite for correct invocation. However, it does not compare this tool to alternatives like rhino_fillet_edge or rhino_fillet_curves, nor does it state when not to use this tool. There is clear context for the workflow but no explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so it's known this is a mutation. The description adds no additional context about side effects (e.g., whether originals are preserved, what the return value is). It essentially restates the purpose without enriching behavioral understanding beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero fluff. It states the action and the one optional parameter. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (which likely describes the returned GUIDs), the description is minimally adequate. However, it does not mention what the tool returns or confirm that the original objects remain unchanged. These gaps are minor but indicate room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters. The description mentions 'optional translation offset' but does not explain that it is a Vector3d with x/y/z components, nor that 'guids' is required and accepts an array. The description does not compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Duplicate') and a resource ('objects'), plus a distinguishing parameter ('optional translation offset'). It differentiates this tool from siblings like rhino_move (which relocates objects) and rhino_array_linear (which creates multiple copies along an axis) without needing to list them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The intent is implied ('duplicate objects') but no exclusions or sibling comparisons are provided. For a simple operation, the implied usage is acceptable, but it lacks the explicit routing seen in higher-scoring definitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive write operation. The description adds minimal behavioral context: it mentions 'origin' but does not specify how the box is oriented (e.g., whether the origin is the base corner extending in positive X/Y/Z, or centered). It also does not disclose behavior about layer handling (e.g., if layer is null, uses current layer). Since annotations cover the safety profile, the description should add orientation and placement semantics, but it does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero filler. Key parameters are listed up front, and the word 'cuboid' clarifies the shape. It is perfectly sized for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create_* tool, the description is adequate but incomplete. There is no mention of the return value (output schema exists but is not explained), nor details about how coordinates relate to the Rhino document (e.g., world vs. construction plane). The absence of orientation and layer behavior leaves gaps. However, given the tool's simplicity and the presence of annotations, it is not severely under-specified. Ranked 3 for being minimally viable with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0% for the top-level params object, so the description must compensate. It lists origin, width, depth, and height but adds no new meaning beyond the schema's own property names (e.g., 'Width (X)'). It does not clarify units, orientation axes, or that origin is a corner point (which the schema does partially). Optional fields like name and layer are omitted from the description, leaving their role unclear. The description fails to enrich the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'box/cuboid', then lists the key parameters (origin, width, depth, height). This is specific enough to distinguish from siblings like rhino_create_sphere or rhino_create_cylinder, even though many create_* tools share the same verb. The naming convention and parameter list make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: if you need a box, use this tool. However, it does not explicitly state when to prefer this over alternatives, nor does it mention exclusions (e.g., 'for rectangular prisms with axis-aligned edges use this, otherwise use rhino_create_extrusion'). Context from sibling names (e.g., rhino_create_cylinder) suggests the distinction, but no explicit guidance is provided. This is adequate but not proactive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, aligning with the 'create' action. The description adds no behavioral nuance beyond stating the creation, such as side effects (e.g., returns object, modifies scene) or coordinate system implications. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, 'Create a rectangle from origin, width, and height,' is concise, front-loaded with the primary action, and contains no superfluous words. Everything stated earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple creation tool. It covers the core inputs and action. Missing details like the coordinate system or return value are less critical because the output schema exists and the operation is straightforward. Could mention orientation explicitly, but not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for width (Width (X direction)), height (Height (Y direction)), and origin (Corner origin point). The tool description mentions these but does not add new semantic meaning beyond what the schema describes. It reinforces the relationship but doesn't clarify anything missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it creates a rectangle using origin, width, and height, which is clear and specific. 'Create a rectangle' is a precise verb-resource pair. It does not explicitly differentiate itself from other shape creation tools, though the tool name already does so, hence not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives, such as when a rectangle is needed versus other primitives, or any prerequisites like active layer context. The description only states the action without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is fully covered. The description does not add behavioral nuance (e.g., units, object type support, or error behavior), but for a simple read-only distance calc the annotation coverage is adequate. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence delivers the complete operational essence with zero filler. Every word earns its place, and the structure is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-GUID read-only distance calculator, the description plus schema and annotations cover the essential calling contract. An output schema is present (though not shown), and the operation is trivial. The only gap is lack of usage context relative to sibling tools, but that is a usage-guidelines concern, not a completeness one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters ('First object GUID' and 'Second object GUID'), so schema coverage is effectively complete. The tool description adds no additional meaning about the parameters (e.g., what object types are valid, ordering importance, or coordinate systems), but the baseline of 3 is appropriate given the schema's own documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('calculate') and resource ('distance') with two objects as operands. It is specific enough to distinguish from direct geometric operations like rhino_intersect or rhino_closest_point, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 others (e.g., rhino_closest_point for proximity queries or rhino_get_length for curve length). The description gives no context about suitability or edge cases, leaving the agent to infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds no behavioral context beyond what annotations already state—it does not mention units, error conditions, or that the curve is not modified. It is not contradictory, but it adds no extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence with no filler. It is front-loaded with the core purpose and wastes no words. Perfect for a simple read-only measurement tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations that mark the operation as read-only, the description covers the essential information: the input type (curve) and the goal (length). It could mention units or edge cases (e.g., compound curves), but for a simple one-parameter tool, this is adequate. The only minor gap is not explicitly stating that the GUID must refer to a curve object, but that is already in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes the 'guid' as 'Object GUID', which is generic. The description specifies that the object must be a curve, adding meaningful semantic constraints beyond the schema. This is a useful clarification, though minimal given there is only one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Calculate the length of a curve' clearly states the action (calculate), the resource (curve), and the result (length). It is specific and distinct from sibling tools like rhino_get_area or rhino_get_volume, which target different geometric properties. The verb and object are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 rhino_distance (for distance between points) or rhino_get_area (for surfaces). There is no mention of prerequisites (e.g., the curve must be a closed loop or a single curve). It leaves the selection entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating operation (readOnlyHint=false) and not destructive. The description adds no further behavioral context, such as whether the original object is preserved, what happens to the input, or any side effects. It simply restates the operation without clarifying the impact of 'solid' or the creation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, one sentence, with the core action front-loaded. Every word contributes to the meaning, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are already documented. However, the description lacks important context about input requirements, such as whether the surface must be planar or whether a closed brep is needed for the solid option. It is minimally adequate but could be richer given the operation's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is reported as 0%, meaning the description does not discuss parameters. While the schema itself provides descriptions for guid, solid, and distance, the tool description only mentions 'by a distance' and 'Optionally create a solid', which partially covers two of three parameters but omits guid entirely. Given low coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (offset), the resource (surface or brep), and the key parameter (distance), plus an optional solid creation. It is specific enough to distinguish from sibling tools like rhino_offset_curve, which handles curves instead of surfaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for offsetting surfaces or breps, but provides no explicit guidance on when to choose this tool over alternatives, nor any prerequisites (e.g., closed brep for solid creation). There is no mention of exclusions or related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the agent knows this modifies objects. The description adds the uniform scaling and center point details, but does not disclose whether scaling occurs in-place, how invalid GUIDs are handled, or any side effects. Given that annotations are present, the description adds some but not rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler. It is front-loaded with the action and easily parsed, making it efficient for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple scaling operation, but it omits key details: it does not mention that 'center' is optional (not required in the schema), nor does it explain the default behavior when center is not provided. It also does not specify whether the operation modifies objects in place or returns new ones. With an output schema present, return details are not required, but these gaps make it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema's parameter descriptions are minimal and not helpful. The tool description adds no parameter information, so the agent must rely solely on the schema's basic field names and types. The description does not clarify the meaning of 'factor' or the behavior of the optional 'center' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (uniformly scale) and the resource (objects), and explicitly mentions the center point, which distinguishes it from rhino_scale_non_uniform. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any explicit guidance on when to use this tool versus alternatives like rhino_scale_non_uniform. It implies uniform scaling is intended, but does not state conditions, exclusions, or provide any decision context for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral context (e.g., that the layer must exist, or that other layer properties are unaffected). It does not contradict annotations, but it contributes nothing beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no waste. The essential information is front-loaded and perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple setter, and the output schema exists, so return type is not a gap. However, the description does not mention that the layer must exist or that the operation is idempotent (though annotations cover the latter). It lacks prerequisites but is otherwise sufficient for a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% from the tool description, which says nothing about the parameters 'name' and 'visible'. The schema descriptions ('Layer name', 'Visibility state') are minimal but self-explanatory. The description does not compensate for the low coverage, leaving the agent to infer parameter meaning from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show or hide a layer' clearly states the verb (show/hide) and the resource (layer). It distinguishes itself from sibling tools like rhino_set_layer_color or rhino_set_current_layer by focusing solely on visibility. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it note exclusions or prerequisites. The usage is implied by the name and description, but there is no guidance on configuring parameters or when it might be inappropriate. Minimal but not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds minimal behavioral context beyond stating it is a write-type set operation, which is consistent with readOnlyHint=false and destructiveHint=false. There is no conflict with annotations, but the description doesn't elaborate on overwrite behavior 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core verb+resource, and zero filler. The second sentence adds relevant use-case context rather than redundancy. Efficient for a simple tool, though not exceptional enough to warrant a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple 3-parameter set operation and the output schema is present, so return values need no explanation. With annotations covering idempotency and safety, the description is adequate. Missing context includes overwrite semantics and how set interacts with retrieval via rhino_get_user_text, which would strengthen completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameter meaning. The phrase 'key/value pair on objects' maps conceptually to the key, value, and guids parameters, providing some semantic glue. However, it doesn't explain the one-to-many relationship (multiple guids share the same key/value) or that setting an existing key overwrites the value, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — 'Set a user text key/value pair on objects' — which clearly communicates the tool's function. The follow-up sentence about storing metadata/BIM data/cost information adds concrete context. It doesn't explicitly name sibling tools for differentiation, but the set-vs-get distinction from rhino_get_user_text is implicit in the name and description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context ('Useful for storing metadata, BIM data, cost information, etc.'), which tells an agent when this tool applies. However, it names no alternatives and gives no explicit when-not-to-use guidance — for instance, it doesn't point to rhino_get_user_text for retrieval or rhino_set_name for the name attribute.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that it checks for bad geometry and naked edges, but that is more about function than behavior. It does not disclose return format or side effects, but the annotations reduce the burden. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no redundancy. The action is stated first, and the scope is front-loaded. It is efficient and focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description covers the essential usage: how to scope the check. It does not explain the return structure, but the output schema handles that. It is adequate without being exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the guids parameter: provide specific GUIDs or leave empty to check all objects. This directly compensates for the reported 0% schema description coverage. It clarifies optionality and scope, though it does not detail the format (e.g., array of strings), which is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks objects for validity, bad geometry, naked edges, and common problems, with an optional scope (specific GUIDs or whole scene). It uses a specific verb and resource, but does not differentiate from siblings like rhino_get_naked_edges or rhino_check_mesh, which overlap in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only explains how to scope the check (specific GUIDs or empty for all), but gives no guidance on when to use this tool versus alternatives like rhino_get_naked_edges or rhino_check_mesh. There is no mention of exclusions or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, indicating this is a mutating/creation operation. The description reinforces this by stating 'Loft a surface', which is consistent. However, it does not add extra behavioral context such as side effects, failure modes, or dependencies on existing objects. Since annotations cover the safety profile, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences with no fluff. The first sentence states the core action, and the second adds a brief usage hint. It is concise, front-loaded, and every word earns its place without redundancy. This is an example of efficient specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and relies heavily on the input schema for parameter requirements (e.g., minItems=2, ordered curves). It does not mention potential constraints like coplanarity or intersection issues, nor does it explain the output. However, given that an output schema exists (signal indicates yes) and the schema handles parameter details, the description is just adequate. It could be more complete for a complex operation like loft, but it is not severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description does not mention any parameters, and the schema description coverage signal is 0% (meaning the description provides no parameter details). However, the input schema itself has clear descriptions for each parameter (e.g., 'GUIDs of cross-section curves (ordered)', 'Loft type: Normal, Loose, Tight, Straight, Uniform'), so the schema carries the full burden. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Loft a surface') and the resource ('multiple cross-section curves'), making the purpose unambiguous. However, it does not explicitly differentiate from similar surface creation tools like rhino_create_sweep1 or rhino_create_patch, though the term 'loft' is specific enough that a knowledgeable agent would understand it. It is not a tautology and adds context about smooth transitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context ('Great for creating smooth transitions between different profile shapes') that hints at when to use this tool, but it does not mention alternatives, when not to use it, or any prerequisites (e.g., curve ordering, curve types). There is no explicit comparison to sibling tools like sweep or revolve, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
All annotations are false, so the description carries the full burden of behavioral disclosure. It states that it creates a mesh, which implies a mutation side effect, but does not disclose what happens with invalid indices, whether the mesh object is added to the Rhino scene, or any validation behavior. Minimal but adequate for a straightforward creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and input types with zero filler. The description is appropriately compact and immediately scannable, making it easy for an agent to grasp the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with thorough schema descriptions and an existing output schema, the description is sufficient. It need not explain return values (output schema exists) or enumerate edge cases since the schema covers formats. The only missing element is usage alternatives, which is already penalized under usage_guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'vertices and face indices', which aligns with the two required parameters, but adds no detail beyond what the schema already provides. The schema includes comprehensive descriptions for vertices, faces, and optional fields, including format hints. With schema description coverage at 0% (no parameter specifics in the description), it fails to compensate, though the schema covers all needed semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create' and the resource 'mesh', specifying inputs as 'vertices and face indices' and explicitly noting 'triangles or quads'. This distinguishes it from sibling creation tools like rhino_create_sphere or rhino_create_box, which target different geometry types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 rhino_create_surface_from_points or rhino_create_patch. It does not mention exclusions, prerequisites, or related mesh tools like rhino_check_mesh. The agent must infer usage from the name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating operation that is not destructive. The description adds no behavioral details beyond 'create'—no mention of side effects, permissions, or what happens to input objects. Since annotations cover the basic safety profile, a mid-score is appropriate, but the description could add context about document modification or object creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the purpose and then specifies inputs. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 6 parameters and a nested input object. The description provides only the basic purpose and two key inputs. It lacks guidance on how u_spans/v_spans affect the result, what the output object is (though an output schema exists), and any prerequisites or limitations. For a tool with this parameter count and no schema coverage, the description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 parameter meaning. It mentions 'boundary curves' (curve_guids) and 'interior points' (points), covering only 2 of the 6 parameters. It omits name, layer, u_spans, and v_spans, which are important for controlling the surface complexity and organization. This is a significant gap given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Create a patch surface') and specifies the input sources ('from boundary curves and/or interior points'). This distinguishes it from sibling tools like rhino_create_planar_surface (which creates from planar curves) and rhino_create_surface_from_points (points only). The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you have boundary curves and/or interior points) but does not explicitly contrast it with alternatives or state when NOT to use it. With many surface-creation siblings, clear routing would be valuable, but the input specification provides some context. No exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description does not need to repeat the destructive nature. It does add the behavioral outcome 'smoother result' and the notion of rebuilding for a new point count/degree. However, it does not disclose whether the original curve is replaced, whether a new curve object is created, or any side effects, leaving some transparency gaps beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that names the verb, resource, and key parameters without any filler. It is efficient and immediately informative, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive annotation and the presence of an output schema, the description is somewhat sufficient but lacks detail on the exact behavior (e.g., whether the curve is modified in place, whether a new curve is returned, or what constraints apply). With many curve-related siblings, more contextual guidance on how this differs from creation or offset tools would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (curve_guid, degree, point_count), so the baseline is 3. The tool description mentions 'point count and degree' and associates them with a smoother result, adding a small amount of semantic context beyond the schema. It does not fully compensate for the schema coverage, but it is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('rebuild'), a resource ('curve'), and the key parameters ('point count and degree') with a clear goal ('smoother result'). It is unambiguous about what the tool does, though it does not explicitly differentiate from sibling tools like offset or extend, which also modify curves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies a usage context (rebuilding a curve to achieve a smoother result), but there is no explicit guidance on when to choose this tool over alternatives, nor any mention of prerequisites or conditions. The agent must infer the appropriate scenario from the tool 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), so the description carries full responsibility for behavioral disclosure. It mentions available libraries (rhinoscriptsyntax, RhinoCommon, scriptcontext) but fails to mention that arbitrary code can mutate the scene, cause side effects, or that execution may raise exceptions or have no return value. For a code-execution tool, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: it leads with the core purpose, lists the available libraries, and closes with usage guidance. Every sentence earns its place, and the message is front-loaded for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 does not hint at return values, error behavior, or execution constraints (e.g., timeouts). For an arbitrary code execution tool, an agent needs to know what to expect on success or failure, but the description offers no such context. Given the complexity and power of the tool, this is a notable incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is reported as 0% (despite the param having a description, the signal indicates low coverage), so the description must compensate. The description only repeats the library access already stated in the schema's parameter description; it adds no new meaning about the 'code' parameter, such as expected format, common patterns, or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Execute arbitrary Python code') and the resource ('inside Rhino'), and explicitly differentiates from specialized tools by positioning it for 'advanced operations not covered by other tools.' This gives an agent a precise understanding of the tool's scope and distinguishes it from the numerous sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use: 'Use this for advanced operations not covered by other tools.' This directly tells an agent to fall back on this tool when specialized tools are insufficient. It doesn't mention when not to use it, but the positive guidance is clear enough to route – the alternative is implied to be every other tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint: true already signals the operation modifies state. The description adds no further context about side effects (e.g., input objects being deleted or replaced). However, the schema separately documents delete_input, which covers the deletion behavior. Since the annotation and schema already provide the relevant behavioral details, the description's silence is acceptable, but it adds no extra value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence that front-loads the core action and outcome. There is zero redundancy, and the parenthetical '(merge into one)' adds clarifying value without bloat. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return values need not be described) and the annotations/schema already cover destructive behavior and the delete_input parameter, the description covers the essential operation. It does not mention prerequisites like overlapping solids or potential failure modes, but these are not strictly necessary for a well-understood boolean operation. The tool is adequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all three parameters (guid_a, guid_b, delete_input), so schema coverage is effectively 100%. The description itself adds no parameter-specific meaning beyond what the schema already states. This meets the baseline of 3 for high schema coverage; no penalty or bonus applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Boolean union'), the resource ('two solids'), and the outcome ('merge into one'). It is precise and immediately distinguishes the operation from sibling tools like boolean_difference and boolean_intersection, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It simply states what the operation does, but does not explain scenarios (e.g., 'use when you need to combine overlapping solids into a single object') or contrast it with difference/intersection. Usage context is only implied by the operation name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so basic safety is covered. The description adds specific behavioral context by listing the quality checks performed, which is beyond the title. However, it does not describe the output format or any preconditions, though the output schema likely covers the return.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that front-loads the verb and lists the checks. There is no redundancy or filler, making it well-structured and immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and an output schema exists, so return format is not necessary. However, the lack of usage guidance and the ambiguous parameter semantics make the description incomplete for correct invocation. An agent might not know that the GUID must be a mesh or when to prefer this over sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is 'guid' with schema description 'Object GUID', and schema coverage is 0%. The tool description does not clarify that the GUID must reference a mesh object, nor does it explain the expected input semantics. With such low schema coverage, the description fails to compensate, leaving the agent uncertain about what to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('mesh quality'), and enumerates the exact checks performed (closed, normals, degenerate faces, naked edges). This clearly distinguishes it from the broader 'rhino_check_objects' and the more focused 'rhino_get_naked_edges', so an agent can differentiate without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like rhino_check_objects or rhino_get_naked_edges, nor any exclusions or prerequisites. The description only states what it does, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context beyond the basic purpose. It does not contradict annotations, and the bar is lower with annotations present, so a baseline 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. It contains no filler words, and all information is directly relevant. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with annotations covering safety and an output schema present, the description covers the essential purpose. It could mention supported object types or the return value format, but these are either implied or covered by the output schema. Overall, it is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes descriptions for both parameters ('Object GUID to query' and 'Test point'), so the schema itself provides high coverage. The tool description does not elaborate on parameters, but that is unnecessary given the schema's clarity. Baseline 3 applies because schema_description_coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Find') and resource ('the closest point on an object to a test point'). It clearly distinguishes from sibling tools like rhino_get_bounding_box or rhino_distance, which serve different geometric queries. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any exclusions or prerequisites. It only states the function. An agent would need to infer appropriate usage from context, which is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so no safety profile is hidden. The description adds no extra behavioral details (e.g., whether curves are consumed, error behavior on invalid input), but this is acceptable for a straightforward creation tool. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and the key input constraint. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 present, the description is mostly sufficient. It specifies the required input type, but could mention what happens if the curves are not planar or not closed. Given the simplicity and the presence of an output schema, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all parameters: name ('Object name'), layer ('Target layer name'), and curve_guids ('GUIDs of closed planar curves'), which gives reasonable coverage. The description adds no additional meaning beyond what the schema already conveys, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (planar surface), and specifies the input condition (one or more closed planar curves). This makes it distinct from sibling tools like rhino_create_surface_from_points or rhino_create_patch, which also create surfaces but via different inputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention exclusions (e.g., non-planar or open curves) beyond what is already in the description, nor does it reference other surface creation tools. An agent would have to infer usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the description correctly conveys a mutation (creation). It does not add further detail such as whether the sphere is added to the active layer or if it overrides existing geometry, but for a simple creation tool the description is sufficient and consistent 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It communicates the core purpose efficiently and front-loads the primary inputs. There is zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a create-sphere operation and the presence of an output schema (which explains return values), the description covers the essential information. However, it does not mention optional parameters or any side effects, which could be expected from a full description. It is acceptable but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 center and radius. It omits the optional parameters 'name' and 'layer' that exist in the schema, so an agent may not know about them. The description does not fully compensate for the lack of schema-level parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (a solid sphere) with the key inputs (center and radius). It is specific and distinct from sibling tools like create_circle or create_box, leaving no ambiguity about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a sphere, but it provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions (e.g., for creating a hollow sphere or a sphere mesh). It is not misleading, but situational context is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true and readOnlyHint=false, so the description does not need to repeat that. It adds minimal extra context about the actual operation but does not disclose side effects (e.g., whether the block definition is removed or other instances are affected). It is consistent with annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It states the verb, object, and result directly, which is optimal for a simple one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description covers the core intent. However, it leaves a gap by not differentiating from the generic rhino_explode tool, which could cause an agent to select the wrong tool. A short note on when to use this instead of rhino_explode would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description for the guid parameter ('GUID of the block instance to explode'), so the parameter is well-documented. The tool description adds a small amount of context by tying the guid to a block instance, but does not add formatting or usage details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Explode'), the resource ('a block instance'), and the outcome ('into its constituent objects'). It distinguishes itself from the sibling rhino_explode by specifying block instances, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives. There is a sibling named rhino_explode which likely handles exploding non-block objects, but the description does not mention this distinction or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=true), lowering the burden. The description adds what-data context via the returned field list, but discloses nothing about behavior on invalid/unknown GUIDs or duplicate matches. This is consistent with annotations and adds modest value, no more.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the action verb first, followed by a tightly packed list of returned data fields. No filler, no repetition of schema content, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with an output schema documenting the return structure and annotations covering the safety profile, the description is nearly complete. The only real gaps are explicit sibling differentiation and unknown-GUID behavior, which are minor at this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is reported as 0%, so the description must carry meaning for the single guid parameter — and it partially does, by stating the object is retrieved 'by GUID'. However, it adds no format or lookup-failure detail beyond the schema's own 'Object GUID (unique identifier in Rhino)' comment, so compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb-resource pair ('get detailed information about a specific object by GUID') and enumerates the returned data (geometry type, dimensions, area, volume, edge info, material, user data). The singular 'specific object by GUID' implies differentiation from the plural rhino_get_objects, but it does not name the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it — anytime a single object's full detail is needed — but gives no explicit guidance on alternatives such as the specialized rhino_get_area, rhino_get_volume, rhino_get_length, or rhino_get_user_text, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate these. It adds the requirement that the solid must be closed, which is useful. However, it does not disclose boundary behavior (e.g., whether a point on the surface counts as inside) or any tolerance considerations, which are relevant for a geometric containment check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence states the core functionality without any fluff. It front-loads the purpose immediately and contains no redundant information. The brevity is appropriate for a simple, read-only query tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward containment check, the description is mostly adequate, especially with a rich output schema available. However, it omits practical details such as how to interpret results for points on the boundary, whether the solid must be manifold, and any performance implications. It also does not clarify what happens if an invalid or open solid GUID is supplied. These gaps could lead to incorrect agent assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter-specific information; it only describes the operation abstractly. Schema description coverage is 0%, so the description should compensate, but it does not. While the input schema itself contains descriptive field names and help text for guid and point, the tool description adds no additional meaning. This is a gap given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Check') and resource ('point inside a closed solid'), clearly distinguishing it from similar tools like rhino_is_point_on_surface by specifying 'closed solid'. The name itself is also descriptive, reinforcing the purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for solids ('closed solid') but does not explicitly mention when to use this tool over alternatives such as rhino_is_point_on_surface or rhino_intersect. There is no guidance on when not to use it, though the context of 'closed solid' provides some implicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the notion of tolerance, which is relevant context but also present in the parameter schema. No additional behavioral side effects are disclosed, but none are expected for a read-only check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the action and key condition. Perfectly concise for the task.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with an output schema, the description covers the essential behavior (check point on surface) and key constraint (tolerance). It lacks explicit mentions of return type, but the output schema handles that. Minor gap: no guidance on when to use versus similar checks, but not critical for a simple read-only query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides detailed descriptions for each parameter ('Surface/brep GUID', 'Test point', 'Distance tolerance'). The description adds nothing beyond mentioning 'within tolerance', which slightly reinforces the purpose but does not provide new meaning beyond the schema. Since schema coverage is high, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and clearly identifies the resource 'if a point lies on a surface within tolerance'. It distinguishes from similar query tools like rhino_is_point_in_solid by specifying surface rather than solid, though it doesn't 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verifying point-on-surface coincidence but does not explicitly state when to use this tool over similar queries (e.g., rhino_closest_point or rhino_is_point_in_solid). No alternative tools are mentioned, leaving the agent to infer from the surface focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the change applies to the 'active viewport' and lists example modes. Annotations already convey idempotentHint=true and destructiveHint=false, so no contradiction exists. However, the description does not elaborate on side effects, reversibility, or how the change affects the scene, relying on annotations for safety semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with zero redundancy. It front-loads the action and object, then provides illustrative examples. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter operation with an output schema and safety annotations, the description is essentially complete. It states the scope ('active viewport') and the parameter is fully documented in the schema. No critical information for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema definition for the single parameter 'mode' provides a full list of allowed values with a clear description. The tool description mentions 'etc.' but adds no additional meaning beyond the schema. Since the schema already carries strong parameter semantics, the description does not need to compensate, but it also adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Set') and resource ('display mode of the active viewport') with concrete examples (Wireframe, Shaded, Rendered). It clearly distinguishes this from sibling tools like rhino_set_view, which deals with camera orientation, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It simply states what it does without mentioning exclusions (e.g., not for camera view) or recommending a different tool for other scenarios. Given the large sibling set, explicit routing would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool mutates (readOnlyHint=false), is idempotent (idempotentHint=true), and is non-destructive (destructiveHint=false). The description adds no additional behavioral context, such as what happens to an existing name or any side effects. It neither contradicts nor enriches beyond annotations, so a baseline 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. It states the action and resource clearly without any redundant details, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with an output schema present (so return values are defined elsewhere), and annotations cover safety and idempotency. However, the description lacks any guidance on prerequisites, error handling, or specific usage context that would help an agent invoke it correctly beyond the obvious action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per context signals, and the tool description does not explain the parameters 'guid' and 'name' at all. Although the parameter names are self-explanatory, the description fails to compensate for the lack of schema descriptions, leaving the agent to infer parameter purpose from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set or change the name') and the resource ('a Rhino object'). It distinguishes itself from sibling tools like rhino_set_color or rhino_set_layer by specifying the 'name' attribute, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one wants to set or rename an object's name, but it does not explicitly state when to prefer this over alternatives or mention any prerequisites (e.g., object must exist). Since the sibling tools are distinct properties, the usage is fairly obvious, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=false (mutation) and destructiveHint=false, but the description adds no behavioral details beyond the basic operation. It does not state that a new surface object is created, whether input curves are modified, or any side effects. Since annotations only carry minimal safety hints, the description should have provided more behavioral context but does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. The key information (sweep along two rails, comparison to single-rail) is front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a basic understanding but lacks important context for a complex surfacing tool. It does not mention that it creates a new surface object, prerequisites like valid rail curves, or how it differs from loft or other surfacing methods beyond sweep1. Given the output schema exists (likely describing the result), some burden is reduced, but the description still feels incomplete for agents that need to know when this is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (tool description has no parameter details), but the input schema itself provides descriptions for all parameters (e.g., rail1_guid, section_guids). The description adds no additional meaning beyond what the schema already documents, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'sweep' with resource 'cross-section curves along two rail curves'. Explicitly distinguishes from single-rail sweep, which is a sibling tool (rhino_create_sweep1). The agent can identify this tool's purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Gives more control over the shape of the resulting surface than single-rail sweep' provides a comparative advantage, implying this tool is preferred when more surface control is needed. However, it does not explicitly state when to avoid this tool or list prerequisites. It gives clear context but no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral context by stating that it returns either a specific key or all key/value pairs, clarifying the scope of the operation. There is no contradiction with annotations. It does not discuss error behavior or edge cases, but the annotation coverage lowers the required bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and includes the key behavioral detail (specific key or all). There is no filler or redundancy, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema, and annotations covering safety and idempotency, the description is largely sufficient. It clearly states the operation's scope. It does not cover possible error conditions (e.g., nonexistent key), but for a read-only retrieval tool these are minor gaps. Overall, it is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is reported as 0%, meaning the tool description does not describe parameters. The description only hints at the 'key' parameter via 'specific key or all', but does not explain 'guid' at all. The schema itself does provide descriptions for both parameters, but per the signal, the description must compensate for low coverage. It does not, so the score is low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'user text from an object', and explicitly mentions the return types (specific key or all key/value pairs). It is distinguishable from sibling tools like rhino_set_user_text (set operation) and rhino_get_objects (general object retrieval) because it targets user text specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. It does not mention that rhino_get_object retrieves general properties or that rhino_set_user_text writes user text. The context is clear from the name, but the description itself provides no when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by stating that setting the slider drives parametric updates, implying side effects such as triggering recomputation. Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. However, it does not disclose potential failure modes (e.g., missing slider, unmet prerequisites) or whether changes are immediately reflected, but this is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 the meaning, and it is exceptionally concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values need not be explained. However, the description omits practical context such as requiring a loaded Grasshopper definition, the need for the slider to exist, or what happens on failure. These details would help the agent use the tool reliably. For a basic setter, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for each parameter ('New slider value' and 'Grasshopper slider component name or nickname'), so the description does not need to add much. However, it adds no additional meaning beyond what the schema gives—it merely repeats the concept of setting a slider. No compensation is needed because schema coverage is sufficient, but there is no added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set the value), the target (a Grasshopper slider), and the purpose (drive parametric updates). This precisely distinguishes it from sibling tools like rhino_gh_get_outputs (which reads) and rhino_gh_run_script (which runs scripts), so an agent can immediately understand what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 you need to update a slider value) but provides no explicit guidance on when not to use it or which alternative to select (e.g., rhino_gh_get_outputs for reading values, or rhino_gh_run_script for more complex parametric changes). No exclusions or sibling comparisons are given, so it relies on the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that the operation makes the brep solid, which is a useful outcome. However, it does not clarify whether the original object is modified in place or a new object is returned. The description does not contradict annotations, but it adds little 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no redundant words. It front-loads the action and clearly states the goal. Every word is necessary and contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema present, the description is adequate. It explains what the tool does without needing to detail return values or edge cases. While it could mention limitations (e.g., non-planar openings), the minimal scope makes it largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, 'guid', which the schema already describes as 'GUID of the open brep to cap'. The tool description does not add any additional semantic context about the parameter. Since the schema fully covers the parameter, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Cap'), a precise resource ('all planar openings on an open brep'), and the intended outcome ('make it solid'). It clearly distinguishes this operation from sibling tools like rhino_boolean_union or rhino_join, which address different kinds of geometry transformations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have an open brep with planar openings and want to seal it. However, it provides no explicit guidance on when not to use it (e.g., non-planar openings) or alternatives. For a simple operation this is adequate, but it does not actively direct the agent toward or away from specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that the output is a PNG and explains how to get base64 data, but it repeats what the schema already states about include_base64. It does not mention that providing a filename writes the image to disk, nor any side effects (e.g., file overwrite), though the schema's filename default and description imply it. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first captures the core action, the second clarifies the optional parameter. Each sentence earns its place, with no filler. The essential information is 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, non-destructive capture tool with an output schema (not shown but indicated), the description is sufficient. It covers the main purpose and the key option (include_base64). Minor gaps exist: it doesn't mention what happens when filename is provided (file write) or the response format beyond base64. Given the simplicity and available schema, these are acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides clear descriptions for all four parameters (width, height, filename, include_base64), so the description doesn't need to explain them. However, it adds a single clarification about include_base64 that is slightly more direct than the schema's phrasing. Because the schema covers parameters well, a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Capture'), a concrete resource ('the active viewport'), and an output format (PNG). It clearly distinguishes this tool from geometry-editing siblings like rhino_move or rhino_boolean_union, and even from related view tools like rhino_zoom_extents or rhino_set_view, which alter the view rather than capture an image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need a PNG of the current view), but it does not explicitly state when to prefer this tool over alternatives such as rhino_export (which can save geometry) or rhino_gh_run_script for custom captures. No exclusions or comparison to siblings are given, so an agent gets no explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutation. The description adds the crucial detail that objects in the layer are also deleted, clarifying that the effect cascades to all contents. It does not mention whether the operation is reversible or what happens if the layer is empty, but the core destructive scope is transparent beyond the annotation hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the action and the target. There is zero waste, and it omits redundant filler. It is concise without losing the critical detail about object deletion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter), the destructive annotation already covering nature, and the presence of an output schema, the description is largely complete. It tells the agent what happens (layer and objects removed). The only minor gap is the lack of mention about error handling when the layer does not exist, but that is not essential for a one-line tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'name' is described in the schema ('Layer name to delete'), which provides the necessary semantics. The description text adds no additional meaning beyond the schema, so it does not enhance parameter understanding. Since schema coverage is effectively provided (though context signals show 0% description coverage, the schema itself has a descriptive string), a baseline of 3 is appropriate; no extra value is delivered from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and resource ('a layer'), and explicitly notes that it also deletes the layer's objects, which distinguishes it from tools like rhino_delete (deletes objects only) and rhino_create_layer. The purpose is unambiguous and immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when you want to remove a layer and all its geometry. However, it does not explicitly differentiate from related tools like rhino_delete (which might delete objects without the layer) or rhino_set_layer_visibility (which hides instead of deletes). No explicit 'when not to use' guidance is given, but the purpose is clear enough for straightforward selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows it modifies the object. The description adds no further behavioral context beyond the prerequisite, such as reversibility or failure conditions. It does not contradict the annotations, but it adds minimal value over them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core operation and then giving the essential prerequisite. No fluff or redundant details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential flow: apply fillet to edges, with prior step to find edge indices. It doesn't explain error handling or exact behavior on multiple edges, but the output schema (not shown) likely covers return values, and the annotations cover the destructive nature. For a modification tool, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (guid, radius, edge_indices), including the note to use get_object for edge indices. The description repeats that note but adds no new meaning for guid or radius. Since schema coverage is high (though the signal says 0%), the description is not required to compensate, and it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('apply a fillet') and resource ('edges of a solid'), clearly defining the operation. It distinguishes from sibling tools like chamfer_edge (different operation) and fillet_curves (curves vs. solid edges) without needing to name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear prerequisite ('Use get_object first to see available edge indices'), which is valuable. However, it does not explicitly state when to use this tool versus alternatives like rhino_chamfer_edge or rhino_fillet_curves, nor any exclusions. The context is implied but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=false and idempotentHint=true, covering safety and repeatability. The description adds the behavioral detail 'releasing its members', but it does not disclose what happens if the group does not exist, whether it affects nested groups, or any side effects. Given the annotation coverage, the description adds limited extra context beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the primary action and resource. It contains no filler or redundant phrases, making it efficient and clear for the agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema present, the description is nearly complete. It could mention behavior on missing group or error conditions, but these are secondary given the simplicity and the presence of an output schema describing return values. The description is adequate for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter 'group_name' as 'Name of the group to ungroup', which fully covers its semantics. The tool description's mention of 'named group' adds no new information about the parameter's format or constraints, so it provides marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Ungroup' and the resource 'a named group', and adds 'releasing its members' which clarifies the effect. It is easily distinguishable from siblings like rhino_group (which groups) and rhino_explode (which breaks curves/surfaces), so an agent can tell apart the intended operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool – when you want to ungroup a named group – but it does not explicitly state when not to use it or mention alternatives like rhino_explode or rhino_join. There is no exclusion or comparative guidance, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds value by explicitly stating the tool 'duplicates' edges and explaining the meaning of naked edges. This clarifies that it creates new geometry (not destructive) and serves an analysis purpose, complementing the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action ('Find and duplicate') and the resource, followed by a helpful explanatory clause. No wasted words, and the purpose is immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter analysis/duplication tool with an output schema available, the description covers the core function and its rationale. It lacks explicit notes on input constraints (e.g., brep required) or error behavior, but these are minor for a tool this simple. The presence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter (guid) has minimal schema description ('Object GUID'), and the tool description does not explicitly state that the guid must reference a brep. It is only implied by 'of a brep', leaving the agent to infer the required object type. Given 0% schema coverage, the description fails to fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find and duplicate') with a clear resource ('naked (unjoined) edges of a brep') and adds explanatory context about what these edges indicate. It distinguishes the tool's analytical purpose from creation/transformation siblings, making the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to identify gaps preventing a closed solid) but does not explicitly mention alternatives or exclusions. It lacks guidance on when not to use it or which sibling tools are more appropriate, so usage context is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral detail: lists specific repairs and notes it is an 'attempt', implying possible incompleteness or failure. No contradiction with destructive annotation; the destructive hint already covers modification, but the description provides useful nuance about expected repair scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no fluff. Key details (specific repairs and optional fill_holes) are front-loaded, and the sentence structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema and annotations, the description is largely sufficient. It covers purpose and parameters adequately. It does not explicitly state whether the mesh is modified in place or returned as a new mesh, but the destructive annotation implies modification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are tautological (e.g., 'Mesh GUID to repair') and coverage is 0%, meaning the schema provides no meaningful parameter info. The description mentions fill_holes but doesn't add meaningful parameter behavior beyond the schema's own minimal description, nor does it explain guid requirements or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'repair' with specific resource 'mesh'. Lists common issues (degenerate faces, duplicate vertices, unified normals, fill holes), making it obvious what it does. Distinct from rhino_check_mesh which is diagnostic only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives mentioned. The purpose implies usage for meshes with these issues, but no guidance on when not to use or how it compares to other mesh tools like rhino_cap_planar_holes or rhino_check_mesh.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only nature is covered. The description adds value by specifying the exact return fields (guid, name, type, layer, color, bounding box), which is not in the annotations and helps the agent understand the output shape. It does not introduce any contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The primary action 'List objects' is front-loaded, and the return format is compactly listed. Every word earns its place, making it easy to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema (not shown) and annotations covering safety, the description is fairly complete: it states what it returns and the filter capabilities. It does not mention the limit default or maximum, but that is present in the schema. The only minor gap is the absence of any note about pagination or sorting, but these are not critical for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents each parameter with clear descriptions ('Filter by object name (substring match)', 'Max objects to return', etc.). The tool description adds no new semantic meaning beyond echoing 'filters by type, layer, or name', which is already covered by the schema. With high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('List objects in the scene') and clearly mentions the filter dimensions (type, layer, name). It differentiates from the singular sibling rhino_get_object by implying a plural result, and from other creation tools. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the basic use case (listing objects) but does not explicitly mention when to prefer this over rhino_get_object or rhino_scene_info. No exclusions or alternative routing are provided beyond the implicit 'list all' context, so the agent must infer the appropriate choice from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds context that it reads 'current' values, implying dynamic state, and 'active' definition, which is useful. However, it does not disclose behavior when no definition is loaded or whether it returns all outputs, relying on the output schema. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. The verb and resource are front-loaded, and the context ('active Grasshopper definition') is included efficiently. Ideal for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0 parameters, simple read operation, and an existing output schema (which presumably specifies return values), the description covers the essential purpose. The only minor gap is error conditions (e.g., no active definition), but given the output schema and annotations, this is not a significant omission. Overall complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, so schema coverage is trivially 100%. The baseline for 0 params is 4, and the description need not add parameter details. It correctly focuses on behavior rather than params, so no deduction is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'read' with a specific resource 'current output values' and context 'active Grasshopper definition'. It distinguishes itself from GH siblings like rhino_gh_set_slider (which modifies) and rhino_gh_run_script (which executes), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is the tool for reading GH outputs, but does not explicitly state when to use it versus alternatives (e.g., set_slider, run_script) or when not to use it. It lacks explicit exclusions or prerequisites such as requiring an active GH definition, though 'active' hints at that. Guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false, indicating a safe, repeatable action. The description adds the specific behavior of adjusting the viewport camera. It does not contradict annotations, and it provides the essential behavior without unnecessary detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence that fully states the purpose. There is no filler or redundant information. The essential idea is front-loaded and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter, idempotent action, the description is complete. It specifies the active viewport and the result. One could argue for mentioning that it does not alter objects or selection, but the idempotentHint already covers safety. The existence of an output schema (likely void) further reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty (100% coverage). The description does not need to add parameter semantics. Per the rubric, baseline for 0 params is 4, and there is no missing information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Zoom'), the resource ('the active viewport'), and the result ('show the entire scene'). This is specific enough to distinguish from view-related siblings like rhino_set_view or rhino_capture_view, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. However, it is a self-contained viewport adjustment with no obvious competing tool, so the absence of explicit exclusions is acceptable. The context implies it is used when the user wants to see the whole scene.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds useful detail about the output components (min/max points, dimensions, center), which goes beyond the bare 'get bounding box' and helps the agent understand what to expect. It does not contradict annotations and adds enough context for a read-only query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the core action and result. Every word earns its place, and the information is front-loaded. There is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (context indicates 'has output schema: true'), the description does not need to explain return values in detail. The tool is simple (one required parameter), read-only, and the description conveys what it returns. Missing details like units or coordinate system are likely covered by the output schema or are not critical for invoking the tool. The definition is complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'guid', is described in the schema as 'Object GUID' with a required field. The tool description adds no additional meaning about the parameter. Since schema_description_coverage is 0% from the description's perspective, but the schema itself provides adequate documentation for this trivial parameter, the description does not need to compensate. It neither enhances nor detracts from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), the resource ('axis-aligned bounding box of an object'), and the specific returned data (min/max points, dimensions, center). This distinguishes it from other query tools like rhino_get_area or rhino_get_volume, and the tool name reinforces the intent without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used when an axis-aligned bounding box is needed, but it does not explicitly contrast it with sibling analysis tools (e.g., rhino_get_area, rhino_get_volume) or state when not to use it. An agent could infer the appropriate context, but there is no explicit guidance on selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the scope 'in the document', which clarifies that block definitions across the entire document are included, but it does not disclose potential limitations like whether nested block definitions are included or the exact return format. Since annotations cover the safety profile, the description adds limited but useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. The verb and resource are front-loaded, and every word contributes to the purpose. It is an excellent example of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with an output schema present, the description fully conveys the operation's intent. It does not need to explain return values because the output schema covers that. All information an agent needs to decide whether to call this tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete (100% coverage). The description does not need to elaborate on parameters. Per the rubric, a zero-parameter tool receives a baseline of 4, and there is nothing to deduct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a precise resource ('all block definitions in the document'). It clearly distinguishes itself from sibling list tools like rhino_list_layers and rhino_list_materials by naming the exact resource type. Even without a title, the description is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage by specifying what it lists, but it does not explicitly mention when to use this tool versus alternatives (e.g., other list tools) or provide any exclusions. Given the trivial nature of the tool and its clear name, the guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so mutation is known. The description adds that the tool creates a new surface by revolving a profile, which clarifies the effect. It does not mention side effects like whether the original curve is modified, but given annotations cover mutation, this added context is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the operation and then use cases. No wasted words. Every sentence adds valuable context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a creation tool with an output schema. It covers the purpose and typical uses. It does not state prerequisites like the profile curve must be planar or how the axis direction is determined, but these are inferable from the operation and schema. The agent can rely on the schema for parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself provides descriptions for all parameters (curve_guid, axis_start, axis_end, start_angle, end_angle, etc.), giving high coverage. The tool description adds no parameter-specific meaning beyond what the schema already explains, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('revolve'), the resource ('profile curve') and the output ('surface of revolution'). It adds typical use cases (vases, goblets, turned parts) which clearly differentiate it from sibling tools like rhino_create_loft or rhino_create_sweep1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use (creating surfaces of revolution) and provides examples of use cases. However, it does not explicitly mention alternatives or conditions when not to use, such as when a loft or sweep would be more appropriate. It lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, which aligns with the description. The description adds the scoping detail 'last operation', which is useful. However, it does not disclose potential failure modes (e.g., if there is no operation to undo) or whether the undo can be reversed via redo. It adds minimal behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, front-loaded sentence that states the action and scope without any wasted words. Every element earns its place; no extraneous details or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and a simple action, the description is sufficient to guide an agent. The output schema presumably documents the return value, so the description need not elaborate. It covers the core intent and scope adequately for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to describe. The schema coverage is vacuously 100%, and the baseline for a zero-parameter tool is 4. The description correctly avoids over-explaining parameters that don't exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Undo' and the resource 'last operation in Rhino', making the tool's purpose unmistakable. It distinguishes itself from siblings like rhino_redo (opposite action) and other commands that modify geometry. No ambiguity exists about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells the agent when to use the tool: after an undesired operation, to revert the most recent change. While it does not mention alternatives (like rhino_redo) or explicit exclusions, the context is clear enough for a tool this simple. The condition 'last operation' is a direct usage signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds useful behavioral context by enumerating the returned layer properties (colors, visibility, lock state, object counts), which is beyond what annotations provide. It does not describe pagination or performance, but that is not critical for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the action and the returned data. There is no wasted wording or redundancy, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema is provided, the description is complete. It names the resource (layers), the scope (all), and the attributes returned. There is no missing information an agent would need to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema provides no parameter information. The description does not need to explain parameters, but it does clarify that it lists 'all' layers without any filtering or arguments. With 0 params, the baseline of 4 applies, and the description adequately conveys that no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' with the resource 'all layers' and specifies the exact data included (colors, visibility, lock state, object counts). This distinguishes it from other list tools like rhino_list_blocks, rhino_list_views, etc., which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving layer information, but does not explicitly state when to use this tool over alternatives or when not to use it. For example, it does not mention that layer manipulation tools (create/delete/reset) are separate. The purpose makes the primary use case obvious, but there is no explicit guidance about exclusions or sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds no additional behavioral context (e.g., ordering, format, side effects), but it does not need to given the simplicity and the presence of an output schema. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler. It front-loads the action and the resource, and every word contributes to the meaning. This is optimal conciseness for a zero-parameter listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with no parameters and an output schema present, the description fully covers what an agent needs to invoke it correctly. The output schema handles return-value details, and annotations cover side effects. No additional context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (vacuously). There is nothing for the description to explain about parameters, so the baseline of 4 applies. No parameter information is needed beyond what the schema shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('all render materials in the document'), which is unambiguous and clearly differentiates it from other material-related tools in the sibling list (e.g., create_material, assign_material) since none of those list materials. The scope is explicit (all materials in the current document).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly name alternatives or give when-not-to-use guidance, but there is no competing list-material tool among siblings, so the usage context is clear from the tool's purpose. It implicitly states this is the tool for retrieving the full set of materials, which is sufficient for such a straightforward operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds specific behavioral detail (listing viewports and named views with display modes) without contradicting the annotations. The return format is not described, but an output schema exists, so that minor gap is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It states the verb and resource immediately, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no parameters, an output schema, and annotations covering safety, the description is complete. It states exactly what is listed, and an agent has all necessary information to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description doesn't need to explain parameter meaning, and the schema trivially covers everything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('list') and resource ('all viewports and named views'), and adds 'with their display modes', which clearly differentiates it from sibling listing tools like rhino_list_layers or rhino_list_blocks. An agent can immediately understand the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only listing operation for discovering available views, but it does not explicitly contrast with alternatives like rhino_set_view or rhino_capture_view. There is no when-to-use or when-not-to-use guidance, leaving the agent to infer the context from the name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds transparency about the specific data returned, which is useful for an agent setting expectations. No contradictions; the description aligns with the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action ('Get an overview'), followed by a concise list of the returned data. There is zero waste; every element adds value and is immediately scannable by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema already exists to define the return type, the description is complete for an agent to understand what the tool does and what to expect. It covers the essential information return aspects without needing to repeat the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, which warrants a baseline of 4 per the rubric. The description adds nothing about parameters because there are none, and the schema confirms this. It accurately reflects the no-input nature without superfluous detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get an overview') and a specific resource (current Rhino document), and enumerates the exact information it returns (filename, unit system, tolerances, object count by type, layers, active view). This distinguishes it from sibling tools like rhino_get_objects (specific object details) or rhino_list_layers (layer list only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys it is for a high-level summary of the entire document, which implies when an agent should use it (when needing overall context) versus more specialized tools. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for effective selection among the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Rhino-mcp MCP server](https://glama.ai/mcp/servers/kbangaru-cyber/Rhino-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kbangaru-cyber/Rhino-mcp)

Score Badge

Copy to your README.md:

[![Rhino-mcp MCP server](https://glama.ai/mcp/servers/kbangaru-cyber/Rhino-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kbangaru-cyber/Rhino-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kbangaru-cyber/Rhino-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server