rhino-mcp

Server Quality Checklist

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

Latest release: v0.6.0
Disambiguation5/5
Each tool has a distinct purpose, even with 244 tools. Overlaps are minimal and descriptions clearly differentiate them. For example, multiple boolean tools are well-separated, and viewport capture tools have specific use cases.
Naming Consistency4/5
All tools start with 'rhino_' (or 'gh_' for Grasshopper), but the verb-noun ordering is inconsistent: some use verb_noun (e.g., rhino_list_objects) while others use noun_verb (e.g., rhino_object_info). This could cause minor confusion for an LLM.
Tool Count4/5
244 tools is large, but the server covers an extremely broad domain (3D modeling, analysis, BIM, rendering, Grasshopper, etc.). Each tool has a defined role, so the count is justified, though a more focused scope might be easier to navigate.
Completeness5/5
The tool set is remarkably complete, covering creation, modification, analysis, annotation, rendering, BIM, Grasshopper integration, and utilities. It supports a full modeling workflow with few obvious gaps.
Average 3.3/5 across 244 of 244 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal and does not disclose behavioral traits beyond the basic action. Annotations only provide readOnlyHint=false, so the description should compensate with details about side effects, such as document modification or viewport changes, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, but underspecified for the complexity of the tool. The single sentence omits crucial details about parameters and behavior, making it less helpful.
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 complex input schema with nested objects and the presence of an output schema, the description is grossly incomplete. It fails to explain the plane definition, result, or how the tool integrates with the Rhino environment.
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 information about the input parameters. The schema has 0% description coverage, meaning the schema descriptions are insufficient, and the tool description does not clarify the meaning of parameters like plane, name, layer, or doc_id.
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 ('Add a clipping plane') and the scope ('to all viewports'). It is specific enough to distinguish from other tools, but could be more precise about the effect on viewports.
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. The description does not provide context for appropriate usage scenarios or prerequisites.
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 uses 'Generate' which could imply creating geometry, conflicting with the readOnlyHint annotation. It does not clarify whether the tool modifies the document or only computes and returns. Annotations provide readOnlyHint, but the description contradicts by implying creation.
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 very short but misses critical information. It is under-specified rather than concisely complete. Every sentence should earn its place, but this single sentence leaves major gaps.
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 (5 parameters, output schema, nested structure), the description is grossly incomplete. It does not explain what the frames are, how parameters affect the result, or what the output represents.
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 to any parameter. It does not explain the roles of object_id, u_count, v_count, offset, or layer. Schema coverage is 0%, so the burden is entirely on the description, which fails.
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 verb 'Generate' and the resource 'oriented frames (planes) at panel centres' with the context 'for construction'. It distinguishes from siblings like rhino_uv_grid_panels or rhino_panelize_surface by specifying 'panel centres' and 'frames'.
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 when-to-use, prerequisites, or exclusions. It does not guide the agent on when to use this tool versus alternatives like rhino_uv_grid_panels or rhino_panel_planarity.
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, and the description confirms a write operation. No additional behavioral context is provided, such as overwrite behavior, required permissions, 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?
The description is a single sentence, very concise. However, it may be too short to provide adequate information. No structural issues.
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 the complexity of a save operation with multiple parameters, the description is incomplete. It does not explain return values, error handling, or default behaviors.
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 mention parameters at all, and the schema has descriptions but the context reports 0% schema description coverage. The description adds no value beyond the schema for understanding parameters.
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 'Write the document to disk' which is a clear verb+resource, but it does not specify the file format (3DM) or that it saves the active document, making it somewhat vague. It is not distinguished from siblings like rhino_open or gh_save_file.
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 on when to use this tool versus alternatives, no prerequisites or exclusions mentioned. The description lacks context for appropriate 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 indicate readOnlyHint=false, so the description does not need to repeat that it mutates state. However, it lacks details on side effects (e.g., closing the current definition, handling missing files), which would add value beyond the annotation.
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, but it lacks critical information, making it under-specified. Proper conciseness would front-load essential details, yet here it omits parameter and usage context.
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 one parameter and an output schema, but the description does not mention what the output is or any prerequisites (e.g., an active Grasshopper session). It is not complete enough for an agent to use without additional context.
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, despite the input schema having a required 'path' parameter with its own description. With schema description coverage at 0%, the tool description should compensate by explaining the parameter, but it fails to do so.
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 verb 'Open' and resource 'a Grasshopper definition', which is specific to the tool's function. It distinguishes from sibling tools like 'gh_new_canvas' or 'gh_run', but does not explicitly contrast them, preventing 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 provided on when to use this tool versus alternatives like 'gh_new_canvas' or 'gh_save_file'. There is no mention of prerequisites or context for opening a definition.
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 'draw'. However, the description adds no further behavioral context beyond that. It does not disclose side effects (e.g., object creation, layer modifications), permission needs, or limitations. For a mutation tool with no annotation coverage of behavior, more transparency is expected.
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 that is concise but lacks structure. It includes the term 'bumpy polyline' which adds mild color, but does not front-load the most critical information (e.g., boundary input). The sentence earns its place but misses opportunities to convey more in a compact way.
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 (multiple parameters, nested schema, output schema) and the presence of many sibling annotation tools, the description is woefully incomplete. It does not explain what a revision cloud is, how boundary points define the region, the significance of bump_count/radius, or what the output represents. The agent cannot fully understand the tool's behavior or constraints from this description 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?
The description does not mention any of the tool's parameters (e.g., boundary_points, bump_count, revision_no). With schema description coverage at 0%, the description should compensate by explaining key parameters and how they affect the output. It fails to do so, leaving the agent without guidance on how to populate the input schema effectively.
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 ('draw'), resource ('revision cloud'), and a distinctive feature ('with a revision label'). It distinguishes the tool from sibling annotation tools like rhino_text or rhino_annotation_callout, which serve different purposes. However, it could be more precise about the coordinate system or that it operates in document units.
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 (e.g., active document) or conditions (e.g., requiring a viewport). The agent is left to infer usage from the name and siblings without explicit when-to-use or when-not-to-use statements.
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 says 'Create,' which confirms mutation (as per readOnlyHint: false), but it does not disclose any additional behavioral traits such as whether it modifies existing objects, creates new geometry, or has limitations. No destructive hint is provided; info on constraints like edge continuity is missing.
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, front-loaded with the core action. However, it is too brief to be fully effective, sacrificing necessary detail for brevity.
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?
Despite an output schema existing, the description itself is severely incomplete. It fails to explain the concept of a blend surface, the effect of bulge, or the role of optional parameters, leaving significant gaps for a complex geometry operation.
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%, yet the tool description adds no meaning beyond the parameter names. The 'edge_a_id' and 'edge_b_id' are referenced indirectly ('two edges'), but parameters like bulge, name, layer, and doc_id are entirely unexplained, leaving the agent uninformed.
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 'Create a blend surface between two edges,' specifying the action and resource. However, among numerous sibling surface tools (e.g., rhino_loft, rhino_fillet_surface), it does not differentiate what makes a blend surface 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 provided on when to use this tool versus alternatives like loft, sweep, or fillet. There is no mention of prerequisites, edge compatibility, or when not to use 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?
The description indicates it modifies geometry ('Cap'), consistent with the readOnlyHint=false annotation. However, it does not disclose whether the operation is destructive, whether it creates new geometry or alters the input, or any other behavioral details beyond the verb.
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, making it extremely concise. However, it omits crucial information such as parameter semantics and behavioral details, trading off completeness 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?
Despite having an output schema (not shown), the description does not mention output or return values. It lacks explanation of input parameters and usage context, leaving significant gaps for a tool with one required parameter.
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 input schema has 0% description coverage, and the description does not explain any parameters (object_id, name, layer, doc_id). The user must infer meaning from schema alone, which is 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 clearly states the verb 'Cap' and the resource 'all open holes of a Brep'. It conveys the core function distinctly from other tools, though it does not explicitly differentiate from siblings.
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 (e.g., other hole-filling or closing operations). There is no mention of prerequisites or context for use.
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 indicates the tool generates new geometry, which aligns with the annotation 'readOnlyHint: false'. However, it does not disclose additional behavioral traits such as whether it modifies existing objects, requires specific document state, or side effects. The 'bridge required' hint is a constraint but not fully explained.
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 very short (one sentence) and front-loaded, but it omits crucial details that would justify its conciseness. Under-specification for a tool with multiple parameters and a nested schema.
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 mention what the tool returns. The input schema is complex with nested objects, but the description offers no guidance. The tool's purpose is stated, but the overall context is insufficient for correct invocation.
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 input schema has multiple parameters (doc_id, interval, direction, base_point, object_ids) with no documentation in the description. With schema description coverage at 0%, the description adds no meaning beyond the schema's basic types and titles.
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 ('Generate') and the object ('equally spaced section curves'). It adds specificity with 'bridge required', which hints at a precondition. While it distinguishes from some sibling tools like rhino_section, the meaning of 'bridge required' is ambiguous without additional 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 like rhino_section or rhino_section_at_axis. The description does not suggest any context, 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 indicates a write operation (cutting), consistent with readOnlyHint=false. However, no additional behavioral details are provided, such as whether the cut is destructive, or any prerequisites.
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, but it includes the essential action. However, it could be expanded to include more context without becoming verbose.
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 does not mention return values or expected outcomes. Given the lack of parameter documentation, the description is insufficient for an agent to use the tool effectively.
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?
With 0% schema description coverage, the description does not explain any parameters. Key fields like sheet_id, object_ids, plane_origin, etc., are undocumented, leaving the agent with no guidance.
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 (cut), the resource (objects via a plane), and the output (trace on a sheet). It distinguishes from similar tools like rhino_section and rhino_drawing_view_place.
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 on when to use or when not to use this tool. The phrase 'bridge only' is vague and does not explain the context or provide alternatives.
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 mutation (readOnlyHint=false). The description adds only the 'bridge required' prerequisite, which is a behavioral constraint. However, it fails to disclose other important behaviors like file overwrite behavior, supported IGES versions, or required permissions, leaving significant gaps.
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 short (one phrase), which is concise but at the expense of valuable information. It is not structured to convey multiple aspects (purpose, parameters, usage) and reads more like a label than a helpful 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's complexity (simple export) and the presence of an output schema, the description is severely incomplete. It fails to explain what IGES is, when to use it, or how parameters work. With many sibling export tools and 0% schema coverage, much more detail is needed for effective selection and invocation.
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 schema provides no parameter descriptions. The tool description does not mention any parameter (path, doc_id, object_ids) or their meanings. The agent is left with no guidance on how to fill these parameters correctly, making this dimension critically lacking.
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 verb 'Export' and the target format 'IGES', making the core action obvious. However, it does not elaborate on what IGES is or differentiate it from sibling export tools like rhino_export_step or rhino_export_obj, missing an opportunity to clarify unique value.
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 IGES versus other export formats. The only extra information is 'bridge required', which is a prerequisite but not a usage guideline. No alternatives or contextual hints 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 have readOnlyHint=false, consistent with an export (write) operation. However, the description adds minimal behavioral context beyond the annotation: it does not mention file creation behavior (overwrite, create new), path handling, or any side effects. It also doesn't clarify whether the export applies to the entire document or only selected objects, though parameters hint at it.
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, which is concise but at the expense of completeness. It is front-loaded with the key action and format. However, it lacks detail that would make it earn its single sentence; it could be expanded to cover key parameters and behavioral expectations without being verbose.
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 (1 required parameter, output schema present), the description is insufficient. It does not explain which meshes are exported (all, selected, or filtered by object_ids), whether the path must be new or existing, or any error/overwrite behavior. Although output schema exists, the description should still provide context about the export scope and constraints.
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 0% description coverage (no descriptions in the schema for the parameters). The tool description adds no meaning beyond the schema field titles. For example, 'path', 'doc_id', and 'object_ids' are not explained in the description, leaving the agent to infer their purpose from names alone.
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 (Export), resource (meshes), and output format (ASCII STL file). It distinguishes from sibling export tools like rhino_export_obj and rhino_export_step by specifying 'STL'. However, it could be more precise about whether it exports all meshes or a subset, though the presence of an 'object_ids' parameter implies filtering.
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 like rhino_export_obj or rhino_export_step. There is no mention of prerequisites, limitations, or trade-offs. The usage context is only implied by the tool's name and description.
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 the mutation is clear. The description adds no additional behavioral context—e.g., whether objects are copied or moved, what 'bridge only' entails, or any side effects like layer changes. It fails to add value beyond the annotation.
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 waste. However, it is too brief and could be expanded to include essential context without becoming verbose. It is appropriately front-loaded but lacks 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?
Despite having an output schema (unknown content) and annotations, the description fails to provide a complete picture. It does not explain 'bridge only,' the relationship to the sibling, or the outcome of the flow operation. Given the complexity of the input schema (4 parameters), the description is inadequate.
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 explain parameter meanings. It mentions 'one curve' and 'another,' which correspond to base_curve_id and target_curve_id, but it does not clarify object_ids or doc_id. No parameter details are provided, leaving the agent to guess.
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 'Flow objects from one curve onto another (bridge only).' This clearly identifies the action (flow) and resources (objects, curves), and hints at a specific variant ('bridge only'). However, it does not distinguish from the sibling tool 'rhino_flow_along_curve', which likely performs a similar operation.
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. There is no mention of prerequisites, limitations, or when not to use it. The description lacks any context for the agent to decide between this and the similar 'rhino_flow_along_curve'.
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 a write operation (readOnlyHint=false). The description adds no behavioral context beyond 'change', such as side effects, permission requirements, or reversibility. No value is added 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but underspecified. It lacks necessary detail about parameters and behavior, making it borderline inadequate for an agent.
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 fails to explain the input parameters or the mutation behavior. For a tool that changes an object's property, more contextual completeness is needed to ensure correct invocation.
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 description provides no parameter information. The required 'name' and nested 'color' object are undocumented, leaving the agent without any guidance on how to specify the layer or color 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 uses a specific verb 'Change' and resource 'layer's display colour', clearly stating the tool's function. However, it does not differentiate from sibling tools like rhino_layer_set_material, which is a minor gap.
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. No exclusions, prerequisites, or context are given; 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 already indicate readOnlyHint=false, so the description's mention of creating a surface is consistent. However, it adds no extra behavioral context such as whether the operation is destructive, requires specific curve types, or how errors are handled. The description is minimal and redundant with the title.
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, which is concise, but it lacks structure and depth. It is not a tautology but is too brief to be informative. Every word earns its place, but more substance is needed.
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 has multiple parameters, no schema descriptions, and an output schema (not shown), the description is severely lacking. It does not cover the loft operation's nuances, parameter roles, or output nature. The context is incomplete for effective use.
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 input parameters (profile_ids, closed, loft_type, etc.). Schema description coverage is 0%, so the description should compensate but fails to do so. The agent cannot infer parameter semantics from this description alone.
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 'loft' and resource 'profile curves' with output 'surface', clearly indicating the operation. However, it does not explicitly differentiate this tool from sibling surface creation tools like sweep1, sweep2, or network surface, which are similar in 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 lacks explicit when-not conditions, prerequisites, or comparisons to sibling tools. The user is left to 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?
The description only indicates a merge operation but does not disclose whether it modifies original surfaces or creates new ones, what happens with the tolerance parameter, or any side effects. Annotations provide no behavioral hints (no readOnlyHint/destructiveHint), so the description carries full burden but 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but lacks necessary detail. It could be expanded to include behavioral notes or usage constraints without becoming verbose. The structure is front-loaded but under-informative.
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 a complex operation (merging surfaces) and an output schema, the description should explain what the output represents (e.g., a new merged surface) and whether it affects the original objects. It fails to provide this context, making it incomplete.
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 schema itself lacks descriptions (though the input schema shows descriptions, the context signal indicates coverage is 0%). The tool description adds no meaning beyond what the schema provides; it merely repeats the concept of merging surfaces. The description does not explain the tolerance parameter or surface_ids beyond their names.
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 ('merge') and the resource ('multiple surfaces into a single surface'). However, it does not differentiate from similar sibling tools like boolean union or blend, which could confuse an agent.
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 boolean union or blend. No prerequisites, exclusions, or context for usage are mentioned.
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 reveals minimal behavioral traits beyond the annotation readOnlyHint=false. It confirms a write operation ('Mesh') but does not describe side effects like whether the mesh replaces the Brep or creates a new object, nor details about mesh quality or coordinate system. The 'bridge only' restriction is vague.
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 concise but to the point of being insufficient. It lacks structure or front-loading of important information; every word is necessary but the overall content is too sparse for effective tool use.
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 has 5 parameters with no schema descriptions and an output schema, the description is extremely incomplete. It does not mention required vs optional parameters, return values, or how the quality parameter affects results. The 'bridge only' constraint raises more questions than it answers.
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 input schema has 0% description coverage (params like 'object_id', 'quality', 'doc_id' lack definitions in the schema), and the description provides no explanation of any parameter. The agent receives no semantic help for filling in the required 'object_id' or optional 'quality' 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 the verb 'Mesh' and resource 'Brep', clearly indicating the tool converts a Brep to a mesh. The phrase '(bridge only)' adds a constraint but lacks clarity about what 'bridge' means. It distinguishes from similar sibling tools like 'rhino_mesh_from_surface' by specifying the source type, though 'bridge' remains ambiguous.
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 explicit guidance on when to use this tool versus other mesh-creation tools. It only mentions 'bridge only', which suggests a specific context but does not explain when that context applies or exclude alternatives. No criteria for selection 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 only provide readOnlyHint=false, so the description carries the burden. It does not mention that scaling modifies objects in place, whether a copy can be made (despite make_copy parameter), or that object IDs are required. The single sentence lacks behavioral depth.
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 very short (one sentence), which is concise, but it omits necessary details that could be included without significant length. It is front-loaded with purpose, but under-specification reduces effectiveness.
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 (non-uniform scaling with center, factors, copy option) and the presence of an output schema (not shown), the description fails to provide enough context for proper invocation. It does not explain how to specify the geometry or behavior, leaving the agent under-informed.
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?
With schema description coverage 0%, the description adds no parameter information. It does not explain 'centre', the scaling factors, or the make_copy option. The agent must rely solely on the schema, which has limited descriptions for non-nested 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 verb 'scale' and resource 'objects', and specifies 'non-uniformly about a centre', distinguishing it from uniform scaling or other transforms. However, it could be more explicit about what non-uniform scaling means (different factors per axis).
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 vs alternatives like rotate, move, or cage edit. No prerequisites or exclusion conditions provided. The description is purely functional without contextual advice.
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 non-read-only (write). The description adds no further behavioral context: no side effects, auth needs, or limitations. It only implies creation.
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?
Extremely concise (one sentence), but too terse for a tool with complex nested parameters. Lacks structure: no bullet points or parameter overview. Front-loading is good, but content is insufficient.
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?
With many parameters (center, radii, pitch, turns, etc.) and a nested input schema, the description fails to cover key aspects. Output schema exists but not shown. Incomplete for an agent 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%, meaning the tool description does not explain any parameters. The schema itself has descriptions, but the tool description fails to add value or clarify parameter meaning. Agent must rely solely on 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 verb 'Add' and the resource 'tapered spiral', and specifies the output type 'NURBS curve'. It distinguishes from sibling tools like rhino_helix by using 'tapered', but could be more precise about the 'sampled into' process.
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 (e.g., rhino_helix for non-tapered spirals). No mention of prerequisites, use cases, 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 already declare readOnlyHint=false, indicating mutation. The description 'Run' adds no behavioral details beyond what annotations provide. It doesn't mention what side effects occur (e.g., recomputation, Rhino document changes).
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, concise but under-specified. It front-loads the purpose, but the sentence could be more informative without adding length. It is not wasteful, but does not fully earn 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?
Given the tool's simplicity (one parameter, output schema exists), the description lacks critical context: what 'current solution' refers to, whether a file must be open, what the output implies, and how it relates to the Grasshopper environment. Incomplete for an agent to use effectively.
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 a description for the 'new_solution' parameter ('Force a fresh solution'), so schema coverage is effectively 100%. The tool description does not add any additional semantic meaning for the parameter; baseline of 3 applies.
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 'Run the current solution' states a verb and resource, but is vague. It does not distinguish from sibling tools like 'gh_run_template' or 'gh_run_template' (note: 'gh_run_template' exists), which also involve running. The title 'GH: Run Solution' adds slight specificity, but the description fails to differentiate.
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 like 'gh_run_template' or other Grasshopper execution tools. The description provides no context about prerequisites or typical use cases.
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 (mutation). The description adds no behavioral details beyond that – no mention of side effects, permission requirements, or error conditions. Minimal extra context.
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 (one sentence), but it sacrifices completeness. It does not waste words, but the brevity leaves out critical information.
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?
For such a complex tool (nested objects, discriminated type, output schema), the description is grossly inadequate. It omits the value type structure, required fields, output behavior, and any usage context. Complete absence of detail beyond the minimal 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%, so the description must clarify parameter meaning. It fails to explain 'component_id', 'value' with its discriminated type, or the optional 'input' field. No additional semantics provided.
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 'Push a value into a component parameter' clearly states the action (push) and target (component parameter), distinguishing it from sibling tools like gh_get_parameter (pull) or gh_set_slider (set a slider). However, it lacks specificity about which component or parameter context, so 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?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no when-not-to conditions. It solely states the action without usage 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?
Annotations already indicate write operation (readOnlyHint=false). The description adds only the verb 'Add' without clarifying whether it creates a new object or modifies an existing one. No information about side effects, authorization needs, or return value beyond the vague phrase 'sampled into a NURBS curve'.
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 one sentence, but it is under-specified and does not earn its place. Conciseness should not come at the cost of completeness; here it sacrifices clarity.
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 no output schema visible and a 0% schema coverage context, the description should clarify output type and usage context relative to siblings. It fails to do so, leaving the tool functionally incomplete for an AI agent.
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?
Despite schema properties having descriptions, the context signals 'Schema description coverage: 0%', suggesting the descriptions are either missing or not counted. The single-sentence description adds no meaning to any parameter, leaving the agent to rely entirely 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 'Add a helix sampled into a NURBS curve' clearly states the verb (Add) and object (helix), and implies the output is a NURBS curve. It distinguishes from siblings like rhino_spiral, but the phrase 'sampled into' is slightly ambiguous about whether it creates a new curve or samples an existing one.
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 on when to use this tool versus alternatives like rhino_spiral or other curve creation tools. No prerequisites or exclusions mentioned, leaving the agent to infer from the 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 only states 'expand' without detailing side effects (e.g., whether the cluster is deleted, how inputs/outputs are handled). Annotations provide readOnlyHint=false, but the description adds minimal behavioral context beyond the action.
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?
Extremely concise but under-specified; lacks necessary details about the expansion process. A single sentence fails to convey critical information, making it insufficient despite 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 output schema exists but is not detailed here, the description still leaves gaps: no explanation of the expansion mechanism, effect on the cluster definition, or how it integrates with other Grasshopper components.
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 sole parameter 'cluster_id' has no description in the schema (0% coverage) and the tool description does not explain its format (e.g., GUID, name) or how to obtain it. No value added 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 uses a specific verb 'expand' and resource 'cluster' to clearly state the tool's action. It distinguishes itself from sibling 'gh_cluster_create' by implying the reverse operation.
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 like 'rhino_block_explode' or prerequisites such as whether the cluster must be selected or exist in the current document.
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, but the description does not elaborate on behavioral traits such as whether the original objects are modified or copied, or any other side effects. It adds no context beyond the annotation.
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 but lacks necessary detail. It is not front-loaded with key information, and each word is not sufficiently informative.
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 has multiple parameters, siblings, and an output schema, the description is woefully incomplete. It does not explain return values, parameter usage, or how it fits in the workflow.
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 description does not mention any parameters or add meaning beyond the schema structure. Parameters like object_ids, center, count, etc., are left undocumented.
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 'Array objects in a polar pattern' clearly states the verb (array) and resource (objects) and specifies 'polar pattern', which distinguishes it from sibling tools like rhino_array_linear and rhino_array_rectangular.
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 vs alternatives (e.g., linear or rectangular array). There are no exclusions or context for 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 indicate destructiveHint=true, so the description adds little beyond mentioning 'Bridge required'. It does not disclose what happens to input objects (e.g., deletion, creation of new output), rate limits, or authorization needs. For a destructive operation, more transparency is expected.
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 very concise with one sentence and a note about bridge. However, the term 'Bridge required' is jargon and not explained, and the brevity sacrifices clarity.
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 complexity of a boolean union operation and the low schema coverage, the description is incomplete. It does not explain the concept of Brep groups, the role of the bridge, the output shape, or side effects on inputs. The output schema exists but its contents are unknown, and the description should provide sufficient context on its own.
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 mention any parameters; the schema provides descriptions for a_ids and b_ids, but the overall parameter object 'args' lacks description. Since schema coverage is 0% for the top-level parameter, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a boolean union on Brep groups, distinguishing it from siblings like boolean difference and intersection. However, it does not explain what 'Brep groups' means or the significance of 'Bridge required', which slightly reduces clarity.
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 on when to use this tool versus alternatives such as rhino_boolean_difference or rhino_boolean_intersection. The agent is left to infer from the name and description, which is insufficient for nuanced 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 readOnlyHint=false, so the description's 'deform' adds no new safety information. It does not disclose behavioral traits like whether original objects are preserved, undo behavior, or required permissions.
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 8 words, front-loading the key action. However, the extreme brevity may sacrifice 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?
Even with an output schema, the description fails to mention preconditions, effects on objects, or the meaning of 'bridge only'. A deformation tool needs more context for proper use.
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?
With 0% schema description coverage, the description must compensate but does not explain any parameters (doc_id, object_ids, cage_object_id). The agent has no clues about what each parameter means 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 clearly states the tool deforms objects using a control cage and specifies 'bridge only', which distinguishes it from other deformation tools like bend or twist. However, it could be more explicit about the resource being modified.
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_bend, rhino_twist, or rhino_taper. The agent is given no context for selecting this tool over sibling deformation tools.
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 says 'Export', implying a write operation. Annotations already set readOnlyHint=false, so no new behavioral information is added. There is no mention of file creation behavior, overwriting, or required permissions.
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, which is concise. However, it sacrifices necessary detail for brevity. It is front-loaded with the key action and format.
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 multiple optional parameters and an output schema (though not described), the description is insufficient. It omits context about object selection ('object_ids') and zone naming ('zone_user_text_key'). An agent would need to infer usage from parameter names 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?
The description adds no information about parameters. Context indicates 0% schema description coverage, yet the description does not explain the purpose of path, doc_id, object_ids, or zone_user_text_key. The agent would have no additional guidance beyond the schema names.
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 specific output format (gbXML) and scope ('thermal/structural BIM payload'), differentiating it from other export tools like rhino_export_obj or rhino_export_ifc. The qualifier 'bridge only' adds specificity but is jargon that may confuse some agents.
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 (e.g., rhino_export_ifc for IFC, rhino_export_obj for OBJ). The 'bridge only' hint is insufficient. The description does not mention 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?
Annotations already indicate readOnlyHint=false, so the description's 'Add' verb aligns but adds no further behavioral details such as side effects, document modification behavior, or required states.
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, front-loaded sentence but is under-specified for a tool with many parameters. It achieves conciseness at the expense of completeness.
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 complexity of the tool (multiple light types, 10+ parameters) and the absence of contextual information in the schema or annotations, the description is far from complete. No output schema details or return value information is provided.
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?
With 0% schema description coverage, the description fails to explain the majority of parameters (color, location, intensity, etc.). It only mentions the 'kind' parameter implicitly through the list of light types, leaving all other parameters semantically opaque.
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 ('Add') and resource ('light') and lists five distinct light types, making it clear what the tool does. Among sibling tools, there is no other 'add light' tool, so it is well-differentiated.
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 does it mention any prerequisites, limitations, or context for 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, so the agent knows it modifies data. The description adds no additional behavioral context, such as mesh integrity expectations or document modifications. Given the annotations, the description's incremental value is low.
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?
At three words, the description is extremely concise but severely under-specified. It lacks key operational details, making it insufficient for tool selection.
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 destructive boolean operation on meshes with multiple parameters and optional output schema, the description omits essential context such as ownership of the result, object creation behavior, and parameter roles. It is not complete enough for an agent to use effectively.
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 description fails to explain any parameters (e.g., a_ids, b_ids). It does not add meaning beyond the schema's field names and types, which are insufficient for correct 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 'Boolean-union meshes' clearly states the verb and resource. It distinguishes from sibling tools like rhino_boolean_union (which likely operates on breps) via the name 'rhino_mesh_boolean_union', but the description itself provides no 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?
No guidance is provided on when to use this tool versus alternatives like rhino_boolean_union or rhino_mesh_boolean_difference. The description is minimal, with no contextual usage hints.
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 behavioral traits beyond the action. Annotations indicate readOnlyHint=false, but the description adds no information about side effects, required permissions, or whether the original surface is modified.
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 very concise (one sentence), but it omits necessary context and is not front-loaded with critical information. It is not structured effectively.
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 moderate complexity (multiple parameters, siblings), the description is incomplete. It does not explain 'bridge only', parameter usage, or output. The output schema exists, so return values are covered, but usage context is lacking.
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 adds no meaning to parameters. The schema itself provides descriptions for doc_id and quality, but the tool's description does not explain the required object_id or optional name/layer. Given the context of 0% schema description coverage at the top level, the description should compensate but fails.
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 'Mesh a surface (bridge only)' clearly states the action (mesh) and target (surface), with a qualification ('bridge only') that helps distinguish from other mesh tools. However, the term 'bridge only' is ambiguous without explanation.
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_mesh_from_brep or rhino_mesh_box. The description lacks prerequisites, 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?
The description barely adds beyond the annotation's readOnlyHint=false. It does not disclose whether the boundary curves are modified, the nature of the patch surface (planar/curved, NURBS/mesh), or any 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It sacrifices completeness for brevity; a bit more detail would improve it.
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, sibling surface tools), the description is incomplete. It lacks return value info, parameter constraints, and usage context. The output schema exists but description should still provide high-level context.
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 0% schema description coverage, the description should explain parameters. It only hints at boundary_curve_ids but omits span_count, doc_id, layername, and name. The agent cannot infer their meaning from the description alone.
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 'Patch a region defined by boundary curves' clearly states the tool creates a patch surface from boundary curves, distinguishing it from tools like rhino_loft or rhino_plane_surface. However, it could be slightly more specific about the type of surface created.
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_loft or rhino_sweep1. There is no mention of prerequisites (e.g., closed curves), limitations, or when not to use 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 already indicate readOnlyHint=true. Description confirms read operation but adds no extra behavioral context (e.g., coordinate system, units, or effect on selections).
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?
One sentence, no unnecessary words. However, brevity sacrifices clarity about the scope (selection vs all objects).
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?
Output schema exists, so return format is defined elsewhere. Missing context about units, coordinate system, and discrepancy with tool name. Adequate for a simple read tool but leaves questions.
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 coverage is 0%; description does not mention the 'doc_id' parameter or its default 'active'. Schema itself provides parameter description, but the tool description adds no value.
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 it returns the union bounding box of all objects, but the tool name suggests selection ('selection_bbox'), creating ambiguity. It does not differentiate from sibling 'rhino_bounding_box'.
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 like 'rhino_bounding_box' or how selection vs all objects is determined.
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?
With readOnlyHint=false, the agent knows it's a mutation, but the description adds no details about side effects, permissions, or what object is created beyond 'torus primitive (mesh approximation)'. Behavioral traits are insufficiently disclosed.
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 wasted words, but it could benefit from slightly more detail; conciseness is good but not at the expense of completeness.
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 multiple parameters and an output schema, the description is too brief. It does not explain return values or parameter usage, leading to incomplete context for the 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?
The description does not mention any parameters. Schema coverage is 0%, so the description fails to compensate for the lack of parameter documentation in the schema, leaving the agent without guidance on required inputs like center, major_radius, and minor_radius.
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 adds a torus primitive and specifies it's a mesh approximation in standalone mode, which distinguishes it from other primitives like spheres or cylinders, though not explicitly compared to siblings.
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 alternative primitives or when mesh approximation is appropriate, leaving the agent 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 readOnlyHint=false, confirming it is a write operation. The description states 'Weld,' implying modification, which is consistent. However, it does not disclose how the welding affects the mesh topology, what happens if no coincident vertices exist, or any 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words), but it omits important details. While it is front-loaded, it does not earn its place by providing sufficient context for tool selection and use.
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?
With 0% schema coverage, no parameter descriptions, and no mention of return values (despite an output schema existing), the description is severely incomplete for a tool that modifies 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 input schema has 0% description coverage—none of the parameters (object_id, name, layer, doc_id) have descriptions in the schema. The description adds no parameter information, leaving the agent without guidance on required or optional inputs.
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 'Weld coincident vertices in a mesh' uses a specific verb ('weld') and clearly identifies the resource ('coincident vertices in a mesh'). It distinguishes itself from siblings like rhino_unweld_mesh (which does the opposite) and rhino_reduce_mesh (which reduces polygon count).
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_unweld_mesh or rhino_reduce_mesh. The description does not mention prerequisites or conditions (e.g., mesh must be closed).
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 provide readOnlyHint=true, so the safety profile is clear. The description adds that the output is a DataTree (list of branches), which clarifies the return format. However, it does not disclose any other behavioral traits beyond what annotations already convey, and the added value is modest.
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 at one sentence. However, it sacrifices essential detail; it could be more informative while remaining compact. The structure is simple but not optimized for quick understanding of key points.
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 that there is an output schema (present but not shown), the description does not need to detail return values. However, it lacks critical contextual information: parameter explanations, error conditions, and how to identify the component. For a tool with low schema coverage, the description should compensate, but it does not.
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 schema provides no descriptions for the parameters. The tool description does not explain what 'component_id' or 'output' mean, nor how they map to component outputs. An agent would have to infer from names alone, which is 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 clearly states the verb 'Read' and the resource 'component output', indicating a read operation on a Grasshopper component. It specifies the output format as DataTree (list of branches). While it distinguishes from write tools like gh_data_tree_set by emphasizing reading, it does not explicitly differentiate from the batch variant gh_data_tree_get_batch, though the name partly conveys that it is for a single component.
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 gh_data_tree_get_batch. The description does not mention prerequisites (e.g., component must exist) or context for use. An agent would not know if this tool is appropriate for a given scenario.
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 matches the annotation (readOnlyHint=false) indicating a write operation. However, it provides no additional behavioral details such as whether the current canvas is closed, if unsaved data is preserved, or any side effects. With annotations already signaling non-read-only, the description adds minimal value.
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 concise but under-specified. It lacks critical details about parameters, return values, and usage context. It is not front-loaded with the most important information beyond the basic 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?
Given that there is an output schema (not shown) and one parameter, the description should explain what happens upon successful creation (e.g., returns something, becomes active canvas). It does not address return values, error conditions, or state changes, leaving the agent with incomplete context for invocation.
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 should compensate by explaining the 'name' parameter. It does not mention parameters at all. The schema's own description ('Document name.') is minimal, and the tool description fails to add any meaning beyond what the schema already provides.
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 a fresh empty Grasshopper canvas.' It uses a specific verb ('Create') and resource ('Grasshopper canvas'), differentiating it from sibling tools like gh_open_file or gh_save_file.
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 on when to use this tool versus alternatives. For instance, it doesn't mention that this should be used to start a new project, nor does it clarify when to use gh_open_file instead. The description lacks context for decision-making.
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?
Description implies mutation but adds no behavioral detail beyond annotations (readOnlyHint=false). No disclosure about object creation, performance, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short sentence, but lacks structure. It is concise but does not prioritize key 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?
Given the nested input schema and 0% description coverage, the description fails to explain tool usage or parameter roles. Output schema exists but is not referenced.
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?
0% schema description coverage and description adds no meaning to parameters like count_x or spacing_y.
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 (array), target (objects), and arrangement (3D rectangular grid). It distinguishes from linear and polar array tools among siblings.
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. No context, prerequisites, or scenarios 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?
With no annotations beyond title, the description bears full burden for behavioral disclosure. It states the tool creates a point grid, implying object creation, but provides no details on side effects, data modification, or error conditions.
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?
Extremely concise (11 words, one sentence). Information is front-loaded but lacks structure. Could benefit from expanding parameter details while staying 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?
Given no annotations, high parameter count (4), and an output schema (not shown), the description is insufficient. It does not describe return values, preconditions, or errors, leaving the agent uninformed.
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 coverage is 0% with two parameters (u_count, v_count) undocumented in schema. The description hints at their meaning via 'even UV intervals', but fails to explain 'object_id' (GUID of surface) or 'layer'. Minimal added value 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 clearly states the verb 'Create' and the resource 'point grid on a surface', with the method 'at even UV intervals'. While specific, it does not explicitly distinguish from sibling tools like 'rhino_place_grid' or 'rhino_uv_grid_panels', but 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 on when to use this tool versus alternatives. It does not mention prerequisites (e.g., a surface must be selected) or when not to use it. The description lacks any usage 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?
Annotations are minimal (only readOnlyHint=false and title). The description adds no behavioral details beyond stating it adds a dimension. No mention of side effects, permissions, or any constraints. Lack of transparency for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence — not verbose, but under-specified. It could afford a bit more detail 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 tool with complex nested parameters and no schema descriptions, the description should provide more context about how to use the parameters (e.g., plane, layer, name). It also does not mention the output, though an output schema exists.
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 coverage is 0% (no parameter descriptions in schema). The description does not explain any of the nested parameters (e.g., point_a, point_b, plane, etc.). The agent would have no guidance on what each parameter means.
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 'Add a linear dimension between two points' clearly specifies the verb ('Add') and resource ('linear dimension'), and distinguishes it from sibling tools like rhino_dimension_aligned by stating 'between two points'.
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 (e.g., rhino_dimension_aligned) or when not to use it. The description lacks context on prerequisites or common use cases.
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 readOnlyHint or destructiveHint. Description implies non-destructive extraction but does not explicitly state behavioral traits like safety, permissions, 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?
Single sentence, 7 words, front-loaded with verb and object. Concise but slightly under-specified.
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?
With output schema present, return value details are not needed, but the description lacks explanation of border_type options (given in schema) and does not clarify input scope. Low schema coverage (0% per context) places burden on description, which fails to compensate.
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?
Despite schema having descriptions for 2 of 3 parameters (object_id, border_type), context signals indicate 0% schema description coverage. The description adds no parameter-level detail beyond the tool's overall function.
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 verb 'extract' and resource 'border curves' from a surface or mesh. It implies a read operation that distinguishes from sibling tools like rhino_dup_edge (which extracts edges) but does not explicitly differentiate.
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 vs alternatives. Siblings like rhino_dup_edge and rhino_mesh_from_surface exist, but no conditions or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the write nature is known. The description adds the 'bridge required' prerequisite, which is a useful behavioral constraint. However, no details on side effects, file overwriting, or output behavior are provided.
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 short (one sentence), but it omits crucial information like parameter details and usage context. While concise, it sacrifices completeness, so it is not well-structured for an agent.
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 large number of sibling export tools and the presence of three parameters (one required) with no schema descriptions, the description is incomplete. It fails to distinguish the tool or provide enough context for correct invocation.
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 description does not mention any parameters. The required parameter 'path' is left entirely unexplained, forcing the agent to guess its meaning (presumably an output file path).
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 verb 'Export' and the resource 'DXF', making the purpose immediately clear. However, it does not differentiate from other export siblings beyond the format name, which is minimal 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?
No guidance on when to use this tool over other export options like rhino_export_obj or rhino_export_stl. The only hint is 'bridge required', but it does not explain when that bridge is applicable or alternatives.
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 is consistent. However, the description adds minimal behavioral context—only a prerequisite mention—and does not disclose side effects, permissions, or error conditions. Given no destructiveHint annotation, more disclosure would be helpful.
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 short (6 words), which is concise but lacks important details. It is front-loaded with the action, but omits parameter context. While brevity is valued, here it comes at the cost of completeness.
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 multiple parameters and an output schema (not described), the description is too sparse. It does not cover return values, prerequisites beyond 'bridge', or parameter usage. Among many sibling tools, it provides only minimal differentiation.
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?
With schema description coverage at 0%, the description provides no parameter information at all. It does not add meaning beyond the schema, which already has descriptions for doc_id and object_ids. This is a significant gap for a tool with three 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 action (export) and target format (STEP), and mentions a prerequisite (bridge required). It differentiates from sibling export tools like rhino_export_obj by specifying STEP, though it doesn't explain what a bridge is.
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 STEP export is needed and mentions a prerequisite (bridge required), but does not explicitly compare to alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so the description's 'Create' aligns with mutation. However, beyond stating constant-radius, no additional behavioral traits are disclosed (e.g., destructive nature, result type, edge cases). The bar is lower due to annotations, but the description adds minimal value.
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 10-word sentence, concise but overly brief for a tool with 6 parameters and geometric complexity. It lacks necessary detail while being efficient, earning an average score.
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 (constant-radius fillet with multiple parameters) and the presence of an output schema, the description should provide more context about preconditions, output, or limitations. It only covers the basic purpose, leaving significant gaps for agent understanding.
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% per context, and the description does not mention any parameters or their roles. The parameter names (surface_a_id, surface_b_id, radius) are self-explanatory, but the tool's single args object structure is not clarified. The description fails to compensate for the lack of schema 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 clearly states the tool creates a constant-radius fillet between two surfaces, specifying the verb (Create), resource (fillet), and scope (between two surfaces). This distinctly separates it from siblings like rhino_blend_surface.
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, when not to use it, or prerequisites (e.g., surface intersection). The description lacks any usage context despite many related sibling tools.
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, implying mutation. However, the description does not clarify whether the original objects are modified or if copies are made, nor does it mention the default behavior of the 'make_copy' parameter.
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, which is concise but overly terse. It lacks critical details and could be expanded without losing clarity.
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 complexity of the transform (PlaneToPlane) and the presence of many sibling tools, the description is insufficient. It does not mention return values (output schema exists) or side effects, leaving the agent uncertain about behavior.
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 coverage is 0% and the description adds no meaning to any parameters. The schema itself is detailed, but the description does not explain the roles of 'from_plane', 'to_plane', or 'make_copy'.
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 'Orient', the resource 'objects', and the specific transform type 'PlaneToPlane'. This distinguishes it from other transform tools like move, rotate, scale.
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 like rhino_move or rhino_rotate. The description does not mention prerequisites or typical use cases.
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 modifies state. However, the description adds no additional context about side effects, required permissions, or behavior (e.g., whether it overwrites files, uses current viewport settings). The description's minimal content does not build on the annotation.
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, effectively concise without extraneous information. It could be more informative, but it is not verbose and front-loads the core 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?
Given the tool's complexity (5 parameters, an output schema, and a rendering task), the description is far too brief. It lacks details about rendering configuration, output format, error handling, and interaction with the viewport or scene. The presence of an output schema is not leveraged.
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 0% schema description coverage (and only output_path having a description in the schema), the tool description should compensate by explaining the meaning and usage of the parameters. It only mentions output_path, leaving width, height, samples, and transparent_background unexplained. This is 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 the tool 'Execute the configured render and write the result to output_path', clearly indicating it performs a render and saves the output. However, it does not differentiate from sibling tools like rhino_render_viewport or rhino_turntable_render, and does not specify what 'configured render' refers to.
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, or any prerequisites. The description does not mention exclusions or conditions that would help an agent decide between this and similar rendering tools.
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?
Description mentions 'bridge required' and 'render' but does not disclose side effects, performance implications, or prerequisites beyond the bridge. Annotations only provide readOnlyHint=false, which is consistent but incomplete.
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?
One concise sentence that front-loads key information. No wasted words, though it omits some details.
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 nested input schema with 4 parameters and an output schema, the description is too minimal. It does not explain output format, resolution defaults, or error conditions when bridge is 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?
No parameter details in description. Schema has some description on 'doc_id' but schema coverage is 0% per context. Description adds no value 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?
Description clearly states action 'render', target 'active viewport', and output 'image file'. The '(bridge required)' adds a constraint. It distinguishes from some siblings like 'rhino_screenshot' but not from 'rhino_render_to_file'.
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 guidelines provided. Does not specify when to use this tool versus alternatives like 'rhino_viewport_image' or 'rhino_render_to_file'. Implies usage for rendering to file but lacks 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 no behavioral context beyond the annotations. Annotations indicate readOnlyHint=false, implying mutation, but nothing is said about side effects, permissions, or what happens on failure. With annotations present, the description should still add value but fails to do so.
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 very concise at one sentence, but it lacks structure and does not front-load important details beyond the basic purpose. It could be improved by adding parameter explanations or usage notes.
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 required parameters) and 0% schema coverage, the description is incomplete. It does not explain how to use the tool effectively, nor does it leverage the existing output schema (which is present but not described).
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. It provides no information about any of the parameters (profile_id, axis_start, axis_end, angle_degrees, etc.), leaving the agent to rely solely on schemas without additional context.
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 'Revolve a profile curve about an axis' uses a specific verb and resource, clearly indicating the operation. It distinguishes this tool from siblings like rhino_extrude or rhino_loft, which involve different surface creation methods.
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. There is no mention of prerequisites such as needing a valid closed profile or when not to use it (e.g., for non-planar curves).
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 it's known that this tool produces output. The description adds that it generates image files to a directory, but doesn't disclose whether it modifies the Rhino document, side effects, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Could be slightly more structured (e.g., listing key parameters) but is appropriate for a tool with a clear primary 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?
Given the complexity (7 parameters, no schema descriptions) and the presence of an output schema (not shown), the description is too sparse. It omits return value, error conditions, and usage context like required model setup, making it hard for an agent 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?
With 0% schema description coverage, the description only mentions 'target' and 'output_dir' in the context, but provides no additional meaning for the other 5 parameters (width, height, radius, samples, frame_count, render_height). The tool relies entirely on parameter names and defaults, which is insufficient for correct invocation.
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 ('Render a turntable sequence') and resource ('camera orbits around target to output_dir'). It distinguishes from sibling render tools by specifying this is for turntable animation, though it doesn't explicitly differentiate from the related 'rhino_turntable' tool.
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 like standard rendering or other turntable-related commands. No mention of prerequisites, required model state, or comparison to siblings.
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, implying mutation, but description adds no further behavioral context. For a creation tool, it doesn't mention whether original objects are retained, what new objects are created, or any side effects. This is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, but brevity sacrifices important details. Every word earns its place, but more information could be added 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?
Output schema exists but description does not explain return values or what the tool produces. For a creation tool, missing details about created object IDs or document changes leaves the agent uncertain about tool outcomes.
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 description adds no parameter-specific semantics. Parameters like direction, spacing, and count lack explanation of units, coordinate system, or constraints. The description does not compensate for the missing schema 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?
Description clearly states 'Array objects along a vector with constant spacing', specifying the verb (array), resource (objects), and key parameters (vector, constant spacing). It distinguishes from sibling tools like rhino_array_polar and rhino_array_rectangular by implying linear arrangement.
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 (e.g., rhino_array_polar, rhino_array_rectangular). The description does not provide context for selection, leaving the agent without criteria to choose the appropriate array 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?
The description implies a state change (positioning camera), which aligns with readOnlyHint=false. However, it does not disclose any behavioral nuances such as whether the change is permanent, how existing camera settings are affected, or if the viewport must be in a specific mode (e.g., perspective). With no annotations providing additional safety hints, the description falls short.
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 of 12 words. It efficiently conveys the core action and parameters with no extraneous 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?
Given the tool's simplicity and the presence of an output schema, the description lacks important context such as coordinate system, presence of error conditions, or prerequisites (e.g., a viewport must exist). It does not mention the optional view_name parameter or how the lens length relates to camera behavior. A mutation tool like this would benefit from more thorough context.
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 restates parameter names from the schema ('location', 'target', 'lens length') but adds no new meaning. The schema itself has some descriptions for nested Point3dModel fields and bounds for lens_length_mm, but the description does not explain the significance of these parameters (e.g., coordinate system, units, behavior of view_name). Overall added value is minimal.
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 ('Position') and resource ('active viewport's camera'), listing the three components (location, target, lens length). It is specific and unambiguous, but does not explicitly distinguish itself from sibling tools like 'rhino_view_set' or 'rhino_zoom_extent', which also adjust the 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. Siblings such as 'rhino_view_set' or 'rhino_zoom_object' could serve similar purposes, but the description offers no context for choosing this tool over them.
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 lack readOnlyHint or destructiveHint. Description does not mention default behavior (e.g., make_copy default true), side effects, or what happens to input objects. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 11 words is concise and front-loaded. However, it may be too minimal; a bit more detail could be added without harming 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?
Description is insufficient given the tool has an output schema and 4 parameters (nested). Lacks details on return values, behavior of 'reposition', and prerequisites. Incomplete for effective use.
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%. Description does not explain parameter meanings beyond the schema's minimal descriptions of base_curve_id and target_curve_id. No added value for parameters.
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 'Reposition objects from a base curve onto a target curve' clearly states the action (reposition) and the resources (objects, base curve, target curve). It distinguishes the tool from siblings like rhino_move or rhino_orient by specifying the transformation along curves.
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 such as rhino_flow or rhino_orient. No prerequisites, implicit usage, or exclusion criteria provided.
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, so mutation is expected. Description adds that by default it creates copies, but does not clarify what happens when make_copy is false (e.g., moving objects) or any permissions needed.
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?
Very short and to the point, but could include more useful information without being verbose. Current length is acceptable but incomplete.
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?
Tool has multiple parameters, nested objects (PlaneModel), and an output schema not shown. Description does not explain how to specify the plane, document context, or object selection. Lacks completeness for a transformation 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?
Description only mentions 'plane' and 'copies by default', ignoring parameters like object_ids, doc_id, and make_copy. Schema description coverage is 0%, so description should compensate but fails to cover most 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?
Description clearly states the tool mirrors objects across a plane, with default behavior of copying. It provides a specific verb and resource, but does not explicitly differentiate from siblings like rhino_move or rhino_rotate.
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 (e.g., rhino_move, rhino_scale). No prerequisites or conditions mentioned.
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. It does not disclose side effects like overwriting existing views, permanence, or any required view state. Annotations indicate readOnlyHint=false which aligns with 'save', but no additional behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff. It is front-loaded and efficient, though it could be slightly expanded to include parameter hints without losing 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?
For a simple save operation with two parameters, the description is minimally adequate but lacks mention of optional doc_id, overwrite behavior, or prerequisites. Given annotations and output schema presence, more detail would improve completeness.
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 explain any parameters. The input schema provides some info (name required, doc_id optional with a description), but the tool description adds zero value beyond that. With 0% schema description coverage (as per context), the burden on the description is higher, and it fails to compensate.
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: save current camera as a named view. It uses a specific verb and resource, but does not explicitly distinguish from sibling view tools like rhino_view_set or rhino_zoom_extent, though the distinct purpose is 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?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use 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?
While the description implies a write operation (consistent with readOnlyHint: false), it does not disclose whether it overwrites existing keys, requires specific permissions, or triggers side effects. Additional behavioral context is missing.
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 single sentence is concise and front-loaded with the action, but could include more detail without becoming verbose. It is technically efficient but under-informative.
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 lacks information about return values or side effects. For a simple write tool, it fails to cover what the agent should expect after execution.
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?
With 0% schema description coverage, the description adds no meaning to parameters beyond their names. Key, value, object_id, and doc_id are not explained, leaving the agent to infer their roles.
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 'Attach' and the resource 'key-value user text entry to an object', making the tool's purpose unambiguous. It also distinguishes itself from the sibling 'rhino_get_user_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 like 'rhino_get_user_text' or other metadata tools. The description does not mention prerequisites or typical use cases.
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 a title, so the description must disclose behavioral traits. It states 'Twist objects' but does not mention whether original objects are modified or if a copy is made (despite the make_copy parameter). The description lacks details on destructive nature, permissions, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded with the action. It contains no unnecessary words and is efficiently structured for quick comprehension.
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 required parameters, optional make_copy, output schema), the description is too minimal. It does not explain the axis definition via two points, object selection, or the effect of make_copy. The presence of an output schema does not excuse the lack of behavioral context.
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 explain parameters. It hints at angle and axis but does not clarify that object_ids, axis_start, and axis_end are required, nor does it mention the optional make_copy parameter. The schema itself has some descriptions, but the overall description fails to compensate.
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 'Twist objects around an axis by a specified angle' clearly states the action and resource. It provides a specific verb and mentions key parameters (angle, axis). However, it does not explicitly differentiate from similar tools like rhino_rotate or rhino_bend, so it misses the highest mark.
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_rotate or rhino_helix. No context about prerequisites, typical use cases, or exclusions 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 show readOnlyHint=false, confirming mutation, but description adds no additional behavioral details such as side effects, requirements, or undo behavior.
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?
Description is a single, concise sentence with the verb front-loaded. It is efficient but could include more detail without sacrificing 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?
With a required object_id and 0% parameter coverage, the description is too minimal. It does not explain expected input, output, or prerequisites, despite having an output 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 documentation coverage is 0%, and the description provides no information about the required object_id parameter or optional parameters like name, layer, or doc_id.
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 'unweld' and the resource 'vertices' with the effect 'to break mesh smoothing', distinguishing it from siblings like weld_mesh.
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 vs alternatives like weld_mesh or reduce_mesh. The description lacks usage context or exclusion 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?
Annotations indicate writeHint=true (readOnlyHint: false), so the mutation aspect is clear. However, the description adds no behavioral details beyond 'Group', such as whether existing clusters with the same name are overwritten, or if components must already exist. Minimal value 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it may be too brief given the tool's 2 required parameters; a slightly longer, structured description could improve clarity 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?
The description lacks sufficient detail for the tool's complexity. Despite having an output schema, it fails to differentiate from siblings, explain parameter purpose, or provide usage context. The tool is simple but the description 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?
Schema description coverage is 0% and the description does not explain the 'name' or 'component_ids' parameters. While 'named cluster' hints at the name parameter, the mapping to input schema is weak. The description should at least state that 'name' is the cluster name and 'component_ids' are the IDs of components to include.
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 'Group' and identifies the resource 'components into a named cluster', clearly distinguishing it from related tools like gh_cluster_expand. It directly conveys the tool's 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 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., gh_group or gh_cluster_expand). No context about prerequisites, expected behavior, or exclusions is given, 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?
The description adds minimal behavioral context beyond the information already provided by annotations (readOnlyHint: false). It does not disclose potential side effects, prerequisites, or what happens on failure. The description is consistent with annotations (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, concise sentence that efficiently conveys the core purpose. Every word serves a purpose with no 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?
Given the tool's complexity (1 parameter containing 3 sub-parameters) and the presence of an output schema, the description is too sparse. It lacks details about return values, data tree structure requirements, or component type limitations, leaving ambiguity for the 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?
With 0% schema description coverage, the description does nothing to explain the parameters (component_id, input, branches). The schema provides some descriptions within sub-schemas, but the tool description itself adds no semantic value for parameter usage.
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 'Push a DataTree into a component input' uses a specific verb and resource, clearly distinguishing from sibling tools like gh_data_tree_get and gh_data_tree_set_batch. It immediately conveys the action and target.
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. No mention of not-to-use scenarios or comparisons with gh_data_tree_set_batch for batch operations. This leaves the agent to infer usage from 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?
Annotations are minimal (readOnlyHint=false only). The description adds no behavioral details beyond stating the toggle action. It does not disclose side effects, persistence, or interaction with the canvas state.
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 fluff. Every word adds meaning.
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 one parameter and minimal annotations, the description is too brief. It lacks context like whether the toggle is persistent, whether it affects all canvases, or if there are confirmation dialogs.
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?
Despite 0% schema coverage, the description hints that 'component_ids' can be a list or omitted for 'all'. However, it does not explicitly explain the 'enabled' boolean or the expected format of component IDs.
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 clear verb ('Toggle') and resource ('preview for components'), and mentions the optional scope of 'all components'. It differentiates from other gh_ tools that toggle different settings.
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 like gh_set_toggle or other gh_ toggles. The context signals show many sibling tools but no usage 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?
Annotations already indicate non-readonly (readOnlyHint=false). The description adds that the tool sets a value, but does not disclose side effects, permissions, or error behavior. Adequate but not enhanced 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded, but it omits critical parameter detail. Conciseness is good, but at the expense of completeness for parameter understanding.
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 no parameter descriptions and no output schema explained, the description is incomplete. It does not specify what happens after setting (success/error), nor does it cover the required component identification or value formatting.
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%, yet the description does not explain the parameters (component_id and value) or their meaning. It only mentions the high-level operation, failing to compensate for the lack of schema 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 clearly states the action (Set) and the target resource (Number Slider component) with its purpose (to a numeric value). It distinguishes from sibling tools like gh_set_toggle or gh_set_panel.
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, no prerequisites, and no exclusions. For a simple setter, context about slider existence or value constraints would help.
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 uses the word 'explode' which implies destruction, but it does not disclose that the operation can optionally keep the instance (via 'keep_instance' parameter in the schema). Annotations already indicate readOnlyHint=false, so the mutation is clear, but the description adds no further behavioral context beyond that.
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. It is front-loaded and to the point. However, it is slightly under-specified, lacking details that could be added 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?
Given the tool's simplicity and the presence of an output schema, the description still falls short: it does not mention the optional keep_instance behavior or the doc_id parameter. The agent needs more context to use the tool correctly in all cases.
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 three parameters (doc_id, instance_id, keep_instance), so schema coverage is effectively 100%. The description adds no additional parameter information, so baseline score 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 verb 'explode' and the resource 'block instance', and specifies the outcome 'into individual objects'. It also includes a scope limitation '(bridge only)', which helps differentiate from other block operations like insert or define. However, the meaning of 'bridge' is not explained.
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_block_redefine' or other block manipulation tools. The '(bridge only)' hint is a constraint but does not serve as usage guidance for the agent.
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 description adds the clarification that the box is axis-aligned and standalone. However, it does not disclose that the tool creates a solid Brep, permissions required, or side effects. The output schema exists but the description adds minimal behavioral 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it very concise. However, it is almost too brief, sacrificing clarity for brevity. Every word serves a purpose but omits important details.
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 complexity of the input schema (nested Point3d, multiple parameters) and many sibling tools, the description is insufficiently complete. It does not mention that sizes must be positive, that corner is lower-left-front, or that the tool creates a solid. The output schema provides some return info, but the description lacks essential context for effective use.
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 adds no meaning to parameters like corner, size_x/y/z, or doc_id. With 0% schema description coverage on the main schema, the description should compensate but fails to do so. The schema itself provides some descriptions (e.g., corner), but the tool description is silent on 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 'Add a rectangular box' and specifies it is 'axis-aligned in standalone mode', which differentiates it from rotated boxes or mesh boxes like rhino_mesh_box. However, it does not explicitly distinguish it from other solid primitives (sphere, cylinder) in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 phrase 'standalone mode' implies a constraint but does not explicitly state exclusions (e.g., for axis-aligned boxes only) or mention alternative tools like rhino_mesh_box for mesh boxes.
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 indicates a creation action but does not disclose behavioral traits such as destructive impact, required permissions, or document modifications. With minimal annotations, this gap is significant.
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, front-loading the core purpose. No extraneous content.
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 creation tool, the description is minimal. It states the output but does not explain document-level effects or common usage patterns. However, an output schema is present, reducing the need for return value details.
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% (though actual schema has some descriptions). The description adds no information about parameters, leaving the agent with only the schema's minimal hints.
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 action: 'Create a SubD object from an existing mesh.' It uses a specific verb and resource, distinguishing it from siblings like rhino_mesh_from_surface or rhino_subd_to_nurbs.
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. There is no mention of prerequisites, limitations, or comparison with other creation tools.
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 is a write operation. The description adds a behavioral note about the axis constraint in standalone mode. However, it does not disclose other important traits such as whether existing geometry is modified, if the operation is undoable, or any prerequisites. The description carries the burden since annotations only cover read-only hint.
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, concise and to the point. It wastes no words, but its brevity may omit useful information. It could be slightly expanded to improve clarity without becoming verbose.
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 complexity of the input schema (nested objects, multiple parameters) and the presence of sibling tools, the description is too brief. It does not mention the output, document requirements, or any side effects. The existence of an output schema partially compensates, but the description still lacks completeness for an AI to use effectively.
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?
Despite the schema having descriptions for parameters like axis, base_center, and height, the context signal indicates 0% schema description coverage, meaning the tool description does not add parameter information. The description only mentions the axis constraint but does not explain other required parameters like radius and height. For a tool with many parameters, the description should compensate.
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 ('Add a cylinder') and the resource. It goes beyond the name by specifying a constraint for standalone mode, which helps differentiate from other primitive shapes like sphere or box. However, it could be more explicit about what makes a cylinder unique among 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance: it mentions that in standalone mode the axis must be world Z. This is helpful but does not specify when to use this tool instead of alternatives like rhino_cone or rhino_box. No when-not-to-use or alternative references 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?
The description does not disclose behavioral traits beyond exporting a PDF. Annotations show readOnlyHint=false, indicating side effects, but the description lacks details such as file overwriting behavior, required permissions, or any limitations. The 'bridge only' note is a usage constraint, not behavior.
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. It contains no unnecessary words, making it efficient. However, the brevity may sacrifice completeness.
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 multiple parameters (dpi, doc_id, path) and a non-read-only action, the description is insufficient. It does not explain the bridge context, output behavior, or parameter nuances. While an output schema exists (per context signals), its absence from the description leaves 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 description provides no information about parameters. The input schema has descriptions for 'path' and 'doc_id' but not for 'sheet_id.' With 0% schema description coverage overall, the agent has minimal guidance beyond parameter names. The description should clarify parameter roles, especially 'sheet_id' and 'doc_id.'
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 exports a sheet to PDF and specifies 'bridge only,' distinguishing it from other export tools. The verb 'export' and resource 'sheet' provide a specific, actionable purpose.
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 phrase 'bridge only' gives some context on when to use this tool, implying it is intended for use when connected via a bridge. However, it does not explicitly state when not to use it or mention alternative tools like other export functions.
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 indicates a write operation ('Add'), which aligns with readOnlyHint=false. It omits details about side effects, permissions, or whether the title block replaces an existing one, adding little beyond the annotation.
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 fluff. It is front-loaded with the action and lists the components efficiently, earning 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?
Given the tool's complexity (many parameters, combined operation), the description is too brief. It ignores the output schema, leaves prerequisites unstated, and fails to contextualize the return value, resulting in 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?
The description provides no information about the input parameters, despite a complex schema with many required fields. With 0% schema description coverage, the description fails to compensate, leaving the agent uninformed about required arguments like sheet_id, project, title, and date_iso.
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 adds a bottom-right title block, north arrow, and scale bar to a sheet. It uses specific verbs and resources, distinguishing itself from sibling tools that handle these elements individually.
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 adding the components separately or prerequisites like an existing sheet. The description leaves the user to infer usage from 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?
Annotations already indicate readOnlyHint=false, so the description adds no behavioral context beyond that. It does not disclose side effects (e.g., overwriting existing environment, viewport changes) or any irreversible actions. With annotations present, the description should still add value, but it falls short.
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 wasted words. It is front-loaded with the action and resource. However, it could benefit from slightly more structure (e.g., listing key parameters or usage notes).
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 (single required parameter, defaults) and existence of an output schema, the description does not explain what the tool returns or any prerequisites (e.g., Rhino must be running, bridge must be active). The 'bridge only' hint is helpful but insufficient for full context.
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, so the baseline is 3. The description reinforces the purpose of use_for_lighting and use_for_background booleans but adds no new meaning beyond the schema. Schema description coverage appears high despite context signal claiming 0%.
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 ('Attach') and the resource ('HDRI/EXR environment'), specifying its purpose for lighting and background. It also notes 'bridge only', which helps distinguish from other environment-related tools, though it could explicitly differentiate from siblings like rhino_light_add.
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 mentions 'bridge only' as a usage constraint but provides no explicit guidance on when to use this tool versus alternatives (e.g., rhino_light_add or render settings). There is no mention of prerequisites or when not to use 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?
While annotations indicate a write operation, the description does not disclose behavioral traits like file overwriting, disk space requirements, or what happens if objects are not meshes. The 'mesh-only' hint is mentioned but not elaborated.
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 that conveys the essential purpose without extraneous information. It is front-loaded and 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?
Despite the existence of an output schema, the description lacks completeness for a file export tool. It does not mention side effects (file creation), constraints (mesh-only), or error conditions, leaving gaps for an AI agent.
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 'doc_id' and 'object_ids', reducing the burden on the tool description. The description adds minimal value beyond implying the path should point to a .obj file. With partial schema coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports objects to Wavefront OBJ format and specifies 'mesh-only', which distinguishes it from generic export tools. However, it does not explicitly differentiate from sibling OBJ-like exports such as rhino_export_stl, so a slight deduction.
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_export_stl or rhino_export_step. It lacks context on prerequisites (e.g., objects must be meshes) or scenarios where OBJ is preferred.
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, so the description correctly implies a write operation. However, it does not disclose potential side effects, limits (e.g., max group size), or behavior with existing groups. Given the presence of annotations, the description provides minimal added context beyond the title.
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 that conveys the core purpose without redundancy. It is 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 tool's moderate complexity (3 parameters, required array) and lack of detailed parameter descriptions, the description fails to provide sufficient context for correct usage. It does not explain how groups interact with the document or other Rhino concepts.
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 low (0% except for doc_id). The description does not explain the meaning of 'name' or 'object_ids' beyond what the schema already states. It adds no parameter-level 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 clearly states the action (group objects) and the result (under a named group). It distinguishes from sibling tools like rhino_move or rhino_object_delete, though it could be more explicit about what grouping entails.
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, nor any conditions or exclusions. The description does not help the agent decide between this and other object manipulation tools.
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 'Add an interpolated NURBS curve' which aligns with the readOnlyHint=false annotation, but adds no further behavioral context (e.g., degree range, effect of collinear points, handling of invalid input). Annotations already indicate mutation, so the description offers little 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, which is very concise and to the point. However, extreme brevity at the cost of more informative content prevents a higher score.
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 multiple optional parameters (degree, name, layer) and an output schema, the description is too minimal. It does not explain the default degree, output format, or usage context among many sibling tools. Even with an output schema, more context would be helpful for effective tool 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?
The schema has 0% description coverage, meaning the tool description adds no information about parameters like points, degree, name, etc. Although the schema itself has some property descriptions, the tool description does not compensate for the missing coverage, leaving parameter semantics entirely to 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 (add), the object (interpolated NURBS curve), and how it works (passing through given points). It distinguishes from sibling tools like rhino_nurbs_curve which creates a NURBS curve from control points rather than interpolating through points.
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_nurbs_curve or other curve creation tools. There is no mention of when not to use it or prerequisites (e.g., minimum 2 points).
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 minimal (only title) and provide no behavioral hints. The description does not disclose whether the isocurve is created as a new document object, what the output represents, or any side effects. For a tool that likely creates geometry, this is lacking.
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 11 words, which is concise but missing important details about usage and output. It is front-loaded but under-specifies for a non-trivial 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 that an output schema exists (as per context), the description is minimally adequate for a simple extraction tool. However, it lacks information about the nature of the output (e.g., a new curve object) and parameter constraints (e.g., valid range of parameter), limiting its completeness.
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 input schema already describes three of four parameters (object_id, parameter, direction) with clear descriptions. The description adds no additional meaning or context beyond the schema, so it provides 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 (Extract), the resource (isocurve), and the context (from a surface at a specific U or V parameter). This is highly specific and distinguishes it from sibling tools like rhino_evaluate_surface or rhino_surface_curvature_at.
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, no prerequisites (e.g., surface must exist, valid parameter range), and no mention of direction choice implications. The description is purely functional without usage 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?
Annotations are minimal (title only), so the description carries full burden. It does not disclose behavioral traits like whether the tool modifies the model, required permissions, or side effects. No added context beyond the name.
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 of 8 words, very concise and front-loaded. However, it sacrifices necessary detail 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?
For a CAD projection tool, the description lacks completeness: no mention of projection direction, object selection, or return values. Output schema exists but description is silent. Inadequate given complexity and 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?
Schema coverage is 0% in the description, though the input schema itself has some parameter descriptions. The tool description adds no meaning to parameters, failing to compensate for 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 clearly states the verb 'Generate' and the resource '2D drawing projection of 3D objects'. It is specific and distinguishes this tool from siblings like rhino_drawing_view_place.
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 other drawing or projection tools. No context or exclusions 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?
The description does not disclose behavioral traits such as whether the surface is modified in place, what happens on failure, or any side effects. Annotations are minimal (only a title) and do not compensate.
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, efficient and to the point. It could be slightly expanded without losing conciseness, but it is not verbose or cluttered.
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 complexity of matching surface continuity, the description is too brief. It does not explain the operation's effect, edge cases, or how the continuity parameter interacts with the surfaces. The presence of an output schema reduces the need to describe return values, but overall context is 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 input schema provides descriptions for all three nested parameters (surface_id, target_id, continuity). The description adds no additional meaning to these parameters beyond what the schema already offers, 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 verb 'adjust', the resource 'surface edge', and the objective 'to match the continuity of a target surface'. It is specific and distinguishes from general surface creation tools, though it could more explicitly differentiate from blending or filleting tools.
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_blend_surface or rhino_fillet_surface. There is no mention of prerequisites (e.g., surfaces must be adjacent) or conditions for use.
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 mentions 'Assign', which implies mutation. Annotations already indicate readOnlyHint=false. No additional behavioral context (e.g., side effects, permissions, or response behavior) is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is concise and front-loaded. However, it could include more useful information without losing 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 description covers the basic purpose but lacks important context such as the need for the material to already exist, object selection constraints, or error conditions. Given the output schema exists and annotations are present, it is minimally adequate.
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%, yet the description does not explain any parameters. It fails to add meaning beyond the schema, leaving the agent without key information about required inputs like object_ids and material_name.
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 ('Assign') and the resource ('existing material to one or more objects'), distinguishing it from related tools like 'rhino_material_create' and 'rhino_material_preset_list'.
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, no prerequisites (e.g., material must exist, objects must be selectable), and no 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 mentions translation and optional copying, but does not explain whether the original objects are replaced when copying (make_copy parameter). Annotations already indicate readOnlyHint=false, so the description adds little beyond that.
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 10 words, which is very concise. It is front-loaded with the core action, but could benefit from slightly more detail without becoming verbose.
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 complexity of a move tool with a vector input and an output schema, the description is too brief. It does not explain the vector format, the effect of the make_copy parameter, or what the tool returns (e.g., moved object IDs).
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% because the tool description does not mention parameters. However, the input schema itself provides descriptions for all parameters, so the baseline is 3. The description adds no extra meaning 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 clearly states it translates or copies objects by a vector, which is a specific verb and resource. However, it does not differentiate from sibling transform tools like rhino_rotate, but the verb 'translate' is distinct 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 vs alternatives such as rhino_rotate or rhino_mirror. The presence of many sibling tools for various transformations makes this 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?
The description only says 'build a surface', which aligns with the readOnlyHint=false annotation (it creates something). No additional behavioral details such as failure cases, temporary effects, or permissions are given.
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 that immediately conveys the core function. It is efficiently front-loaded and contains no fluff.
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 complexity of creating a surface from a curve network, the description lacks critical context: expected curve configuration, handling of non-network curves, output details, or error conditions. The output schema exists but the description does not compensate for the missing guidance.
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% for the main args parameter, and the description does not explain what the parameters are or how to structure the network. It adds no meaning 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 specifies the verb 'Build' and the resource 'surface from a network of crossing curves', making it clear and distinct from sibling surface creation tools like loft, sweep, or extrude.
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, no prerequisites, no scenario exclusions. It simply states the operation.
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 minimal context ('from the document') beyond confirming deletion. Does not disclose undo behavior, batch effects, or impact on dependencies.
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?
Extremely concise (8 words, one sentence). No wasted words, but could be more informative without losing conciseness. Good for brevity, though depth is sacrificed.
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 destructive tool with many siblings, the description is insufficient. It does not clarify what 'objects' refers to (geometry, blocks, etc.), whether undo is supported, or the scope of deletion. The output schema exists but is not used to compensate.
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 provides no parameter information. The agent must rely solely on the schema, which has titles and types but lacks descriptions for object_ids. doc_id has a schema description, but overall the description adds no value for 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 action 'Delete' and the resource 'objects' in context 'from the document'. It is distinct from sibling tools like rhino_layer_delete or rhino_object_select, though it does not specify what types of objects are included.
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 (e.g., rhino_boolean_difference, rhino_object_move_to_layer). No mention of prerequisites, irreversibility, or context where deletion 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 the description says 'add' implying mutation. No further behavioral details such as side effects, permissions, or document modifications are provided.
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, 13 words, front-loaded with the core purpose. Every word earns its place with no repetition or fluff.
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 a nested input schema with required subfields (plane, width, height) and an output schema, the description provides no details about these requirements or the return value. Users must infer the plane structure from the schema 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?
The input schema has 0% description coverage for parameters (only doc_id has a brief description). The tool description adds no meaning to the parameters; it only restates the plane argument implicitly.
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 (add), the resource (finite plane), and the key constraint (rectangular trim on given plane). It distinguishes this tool from sibling surface creation tools like rhino_patch, rhino_box, etc.
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 (e.g., rhino_rectangle for curves, rhino_surface_from_points for custom surfaces). The description does not mention prerequisites or 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?
Annotations are minimal (only title), leaving the description to disclose behavioral traits. The description does not specify whether the tool modifies the original surface or creates a new one, nor does it mention any effects, permissions, or side effects. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise but lacking structure. It omits important context such as default values, behavior, and prerequisites. While not verbose, it is too sparse to be fully helpful.
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 moderate complexity of rebuilding a NURBS surface, the description is incomplete. It fails to cover whether the original is replaced, how to specify the object_id, or any constraints on point counts and degrees. The presence of an output schema (unseen) does not mitigate the missing context.
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?
Although the input schema contains descriptions for most parameters, the context indicates schema description coverage is 0%. The tool description adds minimal value beyond stating 'new point counts and degrees', failing to explain the object_id parameter or how parameters interplay. It does not adequately compensate for 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 clearly states the verb ('Rebuild'), the resource ('surface'), and the specific modifications ('new point counts and degrees in U/V'). It distinguishes itself from sibling tools like rhino_rebuild_curve (for curves) and other surface creation tools.
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, when to choose rebuild over other surface editing tools, or any limitations.
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 the tool modifies state (readOnlyHint: false), but the description adds minimal behavioral context. It does not disclose requirements like an existing render context, side effects, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise but lacks structure. It lists settings without grouping or emphasis, which is adequate but not optimally organized.
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?
With an output schema present, return values are covered, but the description omits important context such as the need for an active render context to exist beforehand. The tool's behavior regarding existing settings or defaults is unspecified.
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 lists parameter categories (resolution, samples, engine, transparency) but adds no meaning beyond the input schema's own descriptions. Schema description coverage is low, yet the description fails to explain parameter constraints like pixel ranges or sample quality impact.
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 'Set render resolution / samples / engine / transparency on the active render context', specifying the verb and resource, and effectively distinguishes this tool from sibling tools that perform other render-related actions.
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_render_viewport or rhino_render_to_file. No prerequisites, exclusions, or context are mentioned.
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 modifies objects. The description only says 'rotate objects' without disclosing side effects, permanence, or prerequisites. Minimal behavioral context beyond the annotation.
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 concise but lacks detail. It earns its place but could be more informative without becoming verbose.
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 complexity of the tool (nested args with required coordinates) and 0% schema coverage, the description is too minimal. It does not explain rotation mechanics or prerequisites. Output schema exists but does not compensate for the lacking description.
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 input schema has 0% description coverage, meaning no parameter descriptions. The tool description does not add any meaning beyond the schema, such as explaining the role of center, axis, or angle_degrees. Critical missing context.
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 'rotate' and the resource 'objects', with specific details about rotation about an axis through a center point. This distinguishes it from sibling tools like rhino_move or rhino_scale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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., rhino_move, rhino_mirror). There are no explicit when-to-use or when-not-to-use instructions.
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 aligns with annotations (readOnlyHint=false) by indicating a write operation. However, it adds no additional behavioral context beyond what the annotations convey.
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 short and to the point, but it lacks essential information about parameters and usage, making it under-specification rather than efficient 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?
Despite an output schema being present, the description omits parameter semantics entirely. For a tool with a nested input schema, this is insufficient for an agent to use 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?
Schema description coverage is 0%, and the description fails to explain any of the input parameters (center, radius, name, layer, doc_id). This is a critical gap for tool usability.
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 'Add a sphere primitive' uses a clear verb and specific resource, distinguishing it from sibling tools that add other primitives like boxes or cylinders.
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 sibling list includes many geometry creation tools, but the description gives no context on 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?
Annotations lack readOnlyHint or destructiveHint, so the description must disclose behavioral traits. It only states 'Create', implying mutation, but does not explain side effects, error handling, or undo behavior. The description is insufficiently transparent.
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 extraneous words. It is highly concise and well-structured.
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 a point count of 4 and an output schema, the description omits crucial context: it does not mention the optional degree parameters, name/layer, or what the tool returns. For a surface creation tool, this is insufficient for effective use.
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 decent parameter descriptions (e.g., '2D grid of points (rows x cols)') and defaults for degrees. The tool description adds no additional meaning beyond what is in the schema, achieving a baseline score.
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), resource (NURBS surface), and input (2D grid of control points). However, it does not distinguish this tool from siblings like rhino_patch or rhino_network_surface that also create surfaces from points.
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. There is no mention of prerequisites, limitations, or comparison to similar surface creation tools among the extensive 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?
The annotations indicate readOnlyHint=false, so the description is consistent but adds no detail about side effects, permissions, or what objects are created/modified. The behavior is minimally implied by 'sweep'.
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 extremely concise (one sentence) and front-loaded with the primary action. However, it sacrifices necessary detail for brevity.
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 complexity (sweep operation with multiple parameters and no output schema shown), the description is severely lacking. It fails to cover what the tool actually does beyond the most basic definition.
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% (only doc_id has a description). The description does not explain parameters like rail_id, profile_ids, name, or layer beyond the basic sweep concept, leaving the agent to infer meaning.
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 'Sweep profiles along a single rail' clearly states the verb (sweep) and resource (profiles and a single rail), and it distinguishes from the sibling tool 'rhino_sweep2' which uses two rails.
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_loft, rhino_revolve, or rhino_extrude. No prerequisites or exclusions are mentioned.
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 what the annotation (readOnlyHint=false) already indicates. It does not mention that this operation creates a new surface, any error conditions, input requirements (e.g., rail curves must be non-intersecting), 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?
The description is extremely concise at six words, which is front-loaded but may be too terse. While every word earns its place, the brevity sacrifices necessary context. It is efficient but could include a bit more detail without becoming verbose.
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 complex surface creation tool with six parameters and no schema descriptions, the description is severely incomplete. It does not explain the type of profiles or rails required, any constraints, or the result of the operation. Although an output schema exists, the description fails to provide essential context for correct 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 adds no meaning beyond the input schema parameter names. With schema description coverage at 0%, the description should compensate by explaining parameters like rail1_id, rail2_id, profile_ids, but it does not. The parameter names are somewhat self-explanatory, but the description provides no additional clarity.
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 'Sweep profiles along two rails' clearly states the action (sweep), the resources (profiles), and the specific number of rails (two), which distinguishes this tool from its sibling rhino_sweep1. The annotation title 'Sweep2 (two rails)' reinforces this specificity.
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 rhino_sweep2 versus alternatives like rhino_sweep1 or rhino_loft. The description lacks any context about prerequisites, typical use cases, or conditions under which this tool is preferred.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the surface must be developable but does not state whether the tool modifies the original, how it handles non-developable surfaces, or details about the output (though an output schema exists). Critical behavioral traits are missing.
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 that efficiently communicates the tool's action without waste. It is front-loaded and earns its place, though it could be slightly expanded without losing 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 description covers the basic purpose but lacks details about prerequisites, error conditions, and behavioral nuances. Given the tool has an output schema, some missing context is acceptable, but overall it is not fully complete for an agent.
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 both parameters ('object_id' as a GUID and 'explode' as a boolean with default false). The tool description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate given high schema description 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 specifies the action 'unroll' and the resource 'developable surface or polysurface', providing a clear purpose. However, it does not differentiate from sibling tools like rhino_rebuild_surface or rhino_patch, so it cannot achieve 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, such as checking developability with rhino_surface_developable_score. There is no mention of prerequisites or context, making it difficult for an agent to decide when to invoke 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?
Description provides minimal behavioral context beyond repeating the tool's purpose. With readOnlyHint=false (mutation), the description should disclose side effects (e.g., overwrites existing file), file format assumptions, and whether a path is required if no active file. These are absent.
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?
Extremely concise single sentence. For a simple tool this is efficient, but it sacrifices detail. Could be improved with a brief note on behavior (e.g., overwrite warning).
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 the tool's simplicity, the description omits important context: what happens if no active definition, whether it overwrites without confirmation, file format, and the return value (output schema exists but is not described). Incomplete for reliable automated use.
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 input schema includes a description for the 'path' parameter that clarifies it defaults to the open file. This adds meaning beyond the schema's type definition. Schema coverage is reported as 0% but the parameter description exists and is helpful.
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?
Clear verb ('Save') and resource ('active Grasshopper definition') are stated. Distinguishes from sibling gh_open_file by focusing on saving rather than opening. However, 'active' could be ambiguous—does it mean the currently open file?—and no differentiation from other potential save tools.
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 like gh_open_file or rhino_save. The description does not specify prerequisites (e.g., a Grasshopper document must be open) or cases where saving might fail.
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, confirming this is a write operation. The description's 'Set' verb aligns with this. However, no additional behavioral traits or side effects are disclosed beyond what annotations already provide.
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 wasted words. However, it is excessively brief, missing critical details that could aid the agent.
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 two required parameters and zero schema descriptions, the description fails to provide enough context for correct invocation. The existence of an output schema is noted but not elaborated, leaving the agent underinformed.
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 description provides no information about the 'component_id' and 'text' parameters. The agent must infer their meaning from parameter names alone, which is insufficient.
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 'Set' and the specific resource 'text contents of a Panel component'. It effectively distinguishes this tool from sibling tools like gh_set_parameter and gh_set_slider by specifying the component type.
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 when to use gh_set_parameter instead. No context is provided about prerequisites or situations where this tool is 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?
The description confirms the tool is a write operation (reassigning objects) and adds the layer-creation behavior beyond the annotations. However, it does not disclose potential side effects like changing object visibility or performance implications for large selections, which would be useful given the mutation nature.
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 that conveys the core purpose efficiently. It is front-loaded and contains no superfluous words. However, it could be slightly expanded to cover parameters 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?
Given the tool's complexity (three parameters, no schema descriptions, and a wide array of sibling tools), the description is too sparse. While an output schema exists, the lack of parameter details and usage context undermines the agent's ability to use the tool 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?
With 0% schema description coverage, the description should explain the parameters, but it only mentions 'objects' and 'layer' generically. The schema has three properties (layer, doc_id, object_ids) with constraints (e.g., max 500 items, default doc_id), none of which are described. The description adds no semantic value beyond the schema's structure.
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 'reassign one or more objects to a different layer' with the notable feature of creating the layer if absent. It distinguishes the tool from siblings like rhino_layer_create (which only creates layers) and rhino_object_delete (which removes objects).
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_layer_create or modifying layers directly. There are no usage constraints, prerequisites, or scenarios described, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is clear. Description adds the tabular output structure but does not disclose other behavioral traits like error handling or performance. Adequate but not enhanced 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence. It is front-loaded and gets to the point. However, 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?
Despite having an output schema, the description is too minimal. It does not explain the purpose of the input parameters or the structure of the output. For a tool with required object_ids and optional fields, this is incomplete.
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?
Input schema has 0% description coverage of parameters. The description does not explain any parameters, leaving the agent without semantic meaning for fields, object_ids, or doc_id. This is a critical 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?
Description clearly states it returns a per-object measurement table with one row per object_id and requested fields. It is specific and distinguishes from sibling tools like rhino_object_info which provide different object data.
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. For example, it doesn't mention that this is for quantitative measurements versus property queries, leaving the agent without usage 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?
No annotations beyond title; description does not disclose whether the original surface is modified or new objects are created, or what happens to the surface. It does not mention potential side effects like new objects being added to the document.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, 11 words, no fluff. However, it lacks structure like bullet points or examples, and the brevity sacrifices completeness.
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 is too brief. It doesn't explain that panels are created as separate objects, the effect on the original surface, or how the panel type affects output geometry. For a tool with four parameters, more context is needed.
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 100% (all four parameters have descriptions). The description adds no extra meaning beyond the schema, 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 clearly states the action (subdivide a surface) and the resource (surface) with specific panel types (quad, triangle, diamond). It distinguishes from sibling tools like rhino_mesh_from_surface or rhino_uv_grid_panels.
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 vs alternatives like rhino_mesh_from_surface, rhino_panel_frames, or rhino_uv_grid_panels. No mention of prerequisites (e.g., surface must exist and be untrimmed) or when not to use.
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=true, so the description does not need to re-state that. The description adds that it reports specific health metrics, but does not disclose any other behavioral traits (e.g., error handling, performance). Adequate but not exemplary.
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 extremely concise (one line), which is good for conciseness. However, it sacrifices completeness. Still, it is well-structured with a clear focus on the tool's output.
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 a required parameter with no schema description, the description should explain the parameter semantics. It also does not clarify the return value format, though an output schema exists (not shown). The description covers the output content but misses input context, making it incomplete for a production 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%, meaning the schema provides no parameter descriptions. The tool's description does not describe the parameters at all, leaving ambiguity about what object_id expects (a GUID? name?) and the doc_id default. This is a significant 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?
Description explicitly states the tool reports on mesh health, listing specific checks: closed, manifold, vertex/face counts, validity log. This clearly identifies the tool's resource and action, and distinguishes it from siblings like rhino_validate_brep which validates breps.
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 context, prerequisites, or exclusions. The description simply states what the tool does 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 already indicate a write operation (readOnlyHint=false). The description adds useful behavioral details: boundary interpreted in XY, Z taken from boundary_min.z, optional rotation jitter about world Z, and deterministic seed usage. However, it omits details on object type constraints, whether source is modified or copied, and error handling.
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 — just three lines with no superfluous information. It front-loads the core action and efficiently conveys key points.
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 (6 parameters) and availability of an output schema (not shown), the description is insufficient. It misses critical details like source_object_id, doc_id, and conflicts with the schema on boundary_min's Z behavior. The context among siblings (various array/scatter tools) is not leveraged to clarify differentiation.
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 adds some meaning beyond the schema, such as explaining Z is taken from boundary_min.z and rotation jitter is about world Z. However, it contradicts the schema description for boundary_min (which states 'Z is preserved from the source'), creating confusion. It also does not cover all parameters (e.g., doc_id, source_object_id). Schema coverage is 0%, so the description should compensate, but it falls short and introduces inconsistency.
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 it scatters copies inside a 2-D AABB with optional Z-rotation jitter. The verb 'scatter' and the specification of the boundary as an AABB distinguish it from array tools that create regular patterns. However, it does not explicitly contrast with sibling array tools like rhino_array_linear.
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 on when to use this tool versus alternatives. The description implies usage for random placement within a rectangle, but does not mention exclusions or provide context for choosing it over other scatter or array 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?
The description indicates a mutation ('Slice') consistent with readOnlyHint=false, but provides no additional behavioral details such as whether objects are altered or new objects are created.
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 with a single sentence and a parenthetical note. Every word serves a purpose with no 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?
Despite the output schema being present, the description lacks coverage of all parameters (e.g., doc_id) and does not explain the tool's behavior in sufficient depth for a nested 4-parameter 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% and the description adds no parameter-level guidance. It mentions 'listed objects' and 'plane' but omits doc_id and does not clarify the role of plane_origin and plane_normal 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 clearly states the tool slices objects with a plane using a specific verb and resource. However, it does not specify the output (e.g., section curves) or distinguish from similar tools like rhino_section_at_axis.
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 mentions 'bridge required' as a dependency but offers no guidance on when to use this tool versus alternatives like rhino_contour or rhino_section_at_axis.
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 'Set', aligning with the readOnlyHint=false annotation, but adds no additional behavioral details. It does not disclose potential side effects, required template state, or the return 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 sentence with no redundant information. It is concise and front-loads 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?
Given the tool's complexity (1 required param containing 3 sub-params) and the presence of an output schema, the description lacks completeness. It omits preconditions, error handling, and the nature of the return value, leaving gaps for the agent.
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%, yet the description does not elaborate on the parameters beyond calling them 'single named parameter'. The schema's own descriptions are minimal but present. The description 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'single named parameter on a loaded template'. It specifies the template types (slider/panel/toggle), which distinguishes it from sibling tools like gh_set_slider, gh_set_panel, and gh_set_toggle that operate on components directly.
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 after gh_load_template or in place of direct parameter setters. The agent is left to infer the usage 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?
Description is minimal; annotations only provide readOnlyHint=false. No details on side effects (e.g., overwriting existing wires, validation errors) 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no unnecessary words. Efficiently conveys the core 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?
Lacks information about return value or success indication, despite an output schema being present (not shown). Does not explain what happens after creation.
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 tool description adds no meaning beyond the input schema, which already describes each parameter (e.g., 'Input name or zero-based index'). Schema coverage is effectively high from schema 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 clearly states the action ('Create a wire') and the resources ('from one component output to another component input'), distinguishing it from siblings like 'gh_connect_many' which handles multiple connections.
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 (e.g., gh_connect_many). No mention of prerequisites or context like component existence.
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 non-read-only, and the description adds that it forces a fresh solution and optionally bakes outputs. However, it does not disclose potential side effects like modifying the active document or clamping timeout, nor does it explain what 'declared outputs' refers to.
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 redundancy. Immediately states the core action and optional behavior, making it front-loaded 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?
Given the tool's complexity (runs a template, bakes geometry) and the existence of an output schema, the description covers the main intent but omits important context like input requirements, failure modes, and default behaviors (e.g., default bake).
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 information. Though the schema itself includes descriptions, the description fails to compensate for low coverage by explaining key parameters like template_id or bake behavior.
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 (force a fresh solution) and optional behavior (bake outputs). It distinguishes this tool from generic run tools like 'gh_run' by specifying 'template' context, though it could be more explicit about running a loaded template.
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 vs alternatives (e.g., gh_run, gh_load_template). No prerequisites or exclusions are mentioned, leaving the agent to infer context from sibling tool 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 declare readOnlyHint=false, indicating a write operation, and the description's 'Set' aligns with this. However, beyond stating the action, the description does not disclose additional behavioral traits (e.g., whether it modifies the document, what happens if the component does not exist, or undo capabilities). The annotations already provide the core safety profile, so the description adds limited 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 consists of a single, clear sentence with no extraneous information. It is optimally concise for the purpose stated.
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 lacks crucial context. It does not explain how to identify the toggle, what the value parameter accepts, or any behavioral nuances. For a tool with two required parameters and no schema descriptions, this is insufficient.
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%, placing the burden on the description to explain parameters. The description fails to mention either required parameter (component_id and value), leaving the agent to infer meaning from names alone. This is a significant 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 'Set a Boolean Toggle component to true or false' uses a specific verb ('Set') and clearly identifies the resource ('Boolean Toggle component') and the action (setting to true or false). It distinguishes itself from sibling tools like gh_set_slider and gh_set_parameter, which target different component types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 gh_set_slider or gh_set_parameter. It lacks explicit context for usage scenarios, prerequisites, or exclusions, leaving the agent without direction for tool 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?
The description aligns with annotations (readOnlyHint=false) by stating 'Add a callout', indicating a write operation. However, it does not add behavioral context beyond that, such as the fact that it creates an annotation object in the active document or that it requires an open 3D model. With annotations already signaling mutation, the description is adequate but minimal.
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 one short sentence, which is concise but too brief for adequate information. It front-loads the purpose but sacrifices completeness. It could benefit from a second sentence to cover parameters or usage context without becoming verbose.
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 mention of required parameters (target_point, leader_origin, text), optional parameters (name, layer, style), and the return value (output schema exists but is not referenced). For a tool with nested objects and multiple parameters, the description is insufficiently complete for an AI agent to use correctly without additional information from the schema.
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 does not describe any parameters. Although the JSON schema itself includes some parameter descriptions (like style and doc_id), the tool description adds no semantic value. For a tool with multiple required and optional parameters, the description should provide at least a brief overview of what parameters are needed.
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 'Add' and the resource 'callout', and explains what it produces ('leader + balloon or boxed label'). This distinguishes it from sibling annotation tools like rhino_leader or rhino_text_dot.
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 vs alternatives. It does not mention prerequisites, document state requirements, or typical use cases. An agent would need prior domain knowledge to decide between this and similar tools like rhino_annotation_leader.
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 readOnly or destructive hints, and the description does not disclose behavioral traits like whether the operation is destructive, reversible, or requires specific permissions. It only says 'Bend objects', leaving the agent uncertain about 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?
The description is a single, front-loaded sentence of 8 words, which is efficient. It could be slightly expanded to include the optional copy parameter without losing conciseness, but it remains concise and focused.
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 3D parameters, object IDs, optional copy) and minimal annotations, the description is too brief. It lacks context on how the bend works, what the 'through point' does, and any relationships to sibling tools, making it incomplete for an agent to fully understand its behavior.
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 adds no meaning beyond the input schema, which already documents parameters like start, end, point, object_ids, and make_copy with descriptions. However, the schema coverage signal is 0%, yet actual schema includes descriptions, 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 'Bend objects along an axis through a specified point' clearly states the action (bend) and the mechanism (axis and point), making it specific and distinguishable from sibling deformation tools like rhino_twist or rhino_taper, though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs. alternatives, such as rhino_twist or rhino_flow, nor any mention of prerequisites or limitations. The description only states what it does 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false). Description adds the bridge requirement but does not explain other behaviors like what the tool returns or needs authorization.
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, front-loaded with clear action and resource. Every word earns its place with no unnecessary repetition.
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 output schema existing, the description omits explaining the meaning of required parameters and optional ones. The bridge comment is specific but incomplete for an agent to fully understand usage without schema knowledge.
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%, yet the description adds no information about parameters (base_center, radius, height, name, layer). The parenthetical only hints at orientation but does not clarify parameter roles.
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 'Add a cone primitive' which is a specific verb+resource. The parenthetical about bridge distinguishes it from other primitives like sphere or box, though it's somewhat cryptic.
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 bridge tool as a prerequisite for non-Z axes, but does not provide explicit guidance on when to use this tool versus alternatives like rhino_cylinder or rhino_sphere.
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 'Add' aligns with readOnlyHint=false (mutation). However, it adds no additional context beyond the annotation; no mention of side effects, document requirement, or return behavior. Minimal but consistent.
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, no wasted words, information is front-loaded. Appropriate for a simple concept, though overly minimal for the 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?
Despite output schema existing, the description is too terse given the nested input schema and many sibling dimension tools. Fails to explain the coordinate system, plane requirement, or return value, leaving 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?
With 0% schema description coverage, the description must compensate. It only hints at 'two points' but ignores other parameters (name, layer, plane, doc_id). Does not explain the role of the plane or how coordinates are interpreted.
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?
Description uses specific verb 'Add' and resource 'aligned dimension', and mentions 'between two points', which clearly indicates the tool's function and distinguishes it from sibling tools like rhino_dimension_linear (horizontal/vertical) and rhino_dimension_angular.
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 vs alternatives (e.g., rhino_dimension_linear, rhino_dimension_angular). No mention of prerequisites or context where aligned dimension 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 already indicate readOnlyHint=false (write operation). Description adds no extra behavioral context (e.g., error handling, pattern validation, effect on original curves). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no filler. However, it could include more useful information without being 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?
Given the output schema exists, return value explanation is not needed. But the description lacks details like whether it works on multiple curves, pattern options, or error conditions. Adequate for a simple tool but not exemplary.
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 does not explain any parameter meanings (e.g., pattern, layer, name). The schema defines them but the description provides no aid.
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 ('Add') and resource ('hatch') and specifies the target ('given closed curves'). It differentiates from sibling tools like rhino_line or rhino_circle which create basic geometry, not hatches.
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 information on when to use this tool versus alternatives (e.g., rhino_patch for surface filling). No prerequisites (e.g., curves must be closed, planar) or exclusions 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 declare readOnlyHint=false, indicating a write operation. The description confirms 'Add,' but adds no further behavioral context (e.g., whether it modifies existing objects, requires specific permissions, or has side effects). The description 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, front-loaded sentence with no unnecessary words. It is maximally concise and structured well for quick comprehension.
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 complexity of the input schema (multiple parameters, nested objects) and zero schema description coverage, the description is too minimal. It does not cover parameter roles, default behaviors, or output, leaving the agent with significant ambiguity.
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 mentions 'optional text,' but does not explain other critical parameters like name, layer, doc_id, or the required points array. The agent gains little insight beyond the schema structure.
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 'Add a multi-point leader (with optional text).' This clearly specifies the action (add), the resource (leader), and the type (multi-point), distinguishing it from sibling annotation tools like rhino_text_dot or rhino_annotation_callout.
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 other annotation or dimension tools. There is no mention of prerequisites, 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 only indicate readOnlyHint=false. Description adds no behavioral traits like side effects, document requirements, or object relationship beyond 'add'.
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, concise, front-loaded. No unnecessary words.
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?
Tool has many parameters (8) with no schema descriptions and minimal description. Lacks details on required inputs, defaults, and output. Incomplete for effective use.
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 has 0% description coverage. Description only mentions 'subdivisions', ignoring critical parameters like corner, size, name, layer. Does not add meaning beyond schema structure.
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 'Add' and resource 'quad mesh box' with 'given subdivisions'. It distinguishes from sibling tools like rhino_mesh_from_surface which create meshes from surfaces.
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. No prerequisites or context provided for effective use.
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 'Add', consistent with readOnlyHint=false, but adds no behavioral details beyond what annotations already imply. It does not disclose side effects, permission requirements, or creation behavior (e.g., auto-layer creation is in schema, not description).
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 zero waste. It is efficiently structured and front-loaded with the key action and resource.
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 multiple parameters and an assumed output schema, the description lacks sufficient context. It does not explain what a NURBS curve is, why control polygon method is used, or how it differs from similar tools like rhino_interpolate_curve.
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 tool description does not mention any parameters. Although the input schema provides thorough descriptions for all sub-parameters (name, layer, degree, doc_id, control_points), the description itself adds no semantic value to help the agent understand parameter usage.
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 'Add a NURBS curve from a control polygon' uses a specific verb ('Add'), resource ('NURBS curve'), and source ('control polygon'). This clearly distinguishes it from sibling curve creation tools like rhino_interpolate_curve or rhino_line.
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. There is no mention of prerequisites, exclusions, or typical use cases, leaving the agent without context to choose correctly among related tools.
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, but the description adds no further context about what gets destroyed (original mesh?) or side effects. It doesn't explain if the operation is reversible or requires specific permissions.
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 and contains no superfluous information. 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 fails to specify what the tool returns (e.g., new mesh object modification) or prerequisites (e.g., input must be a mesh). Significant gaps remain for correct invocation.
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?
With 0% schema coverage, the description should explain key parameters like object_id and target_face_count, but it only mentions 'target face count' without details on valid ranges or behavior. No parameter semantics are provided.
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 verb 'reduce' and resource 'mesh' with a target face count, distinguishing it from sibling mesh tools like weld, unweld, or boolean operations.
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 guidance on when to use this tool versus alternatives like rhino_weld_mesh or rhino_mesh_from_surface. The context is implied but not stated.
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 hints. Description says 'Replace' implying mutation, but does not disclose side effects, undo behavior, or whether the original object is modified in place. With no annotations, description should offer more 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?
Single sentence that is concise and to the point. No unnecessary words, but could be expanded with additional context without becoming verbose.
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?
Description lacks information about return value, constraints (e.g., point count must match), and whether the operation modifies the object or returns a new one. Output schema exists but description does not complement it.
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 provides good descriptions for all parameters (points, weights, object_id). The description adds no extra meaning beyond the schema. Baseline 3 applies due to high schema description 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?
Description clearly states the action 'Replace control points' and the target 'NURBS curve or surface'. The name 'set_control_points' aligns with the purpose and distinguishes from sibling 'rhino_get_control_points'.
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 on when to use this vs. alternatives like 'rhino_rebuild_curve' or 'rhino_match_surface'. No mention of prerequisites or when not to use. Usage is only implied by the description.
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 show readOnlyHint=false, indicating a write operation, which aligns with the description. The description adds context about two modes and their output quality but does not disclose other behavioral traits such as performance, authorization needs, 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?
The description is concise with two sentences, front-loading the main action. However, the mention of 'bridges mode' could be clearer for users unfamiliar with the term.
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 covers the two modes and their outputs adequately for a moderate-complexity tool, but lacks parameter documentation. Given the presence of an output schema, the omission of return value details is acceptable.
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 description does not explain any parameters such as object_ids, sun_vector, ground_z, layer, or doc_id. This is a significant gap for a tool with multiple parameters.
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 ('project objects' bounding-box corners along sun_vector to the ground plane') and distinguishes between two modes (standalone and bridge), making the purpose specific and differentiating it from 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives, nor are there any conditions or exclusions mentioned. The description only implies usage by describing the output of two modes.
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 a title; no readOnlyHint or destructiveHint. Description does not disclose whether the original SubD is modified, if a new object is created, or other 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?
Single sentence is efficient and front-loaded, but could benefit from slight expansion to include parameter hints or usage context.
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 conversion tool, basic context is present. However, missing behavioral details and lack of guidance relative to sibling tools leaves gaps for new users.
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 includes descriptions for 'packed' and 'object_id' but not for 'name' and 'layer'. The tool description adds no parameter context, leaving users to infer meaning from 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?
Description states 'Convert a SubD object to a NURBS polysurface (Brep)', which clearly specifies the action and output. This distinguishes it from sibling tools like mesh conversion or surface creation.
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 (e.g., rhino_mesh_from_surface, rhino_create_subd). No prerequisites or disclaimers provided.
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, so the description's 'Remove' is consistent. No additional behavioral context (e.g., reversibility, permissions) is provided beyond what annotations state.
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 that is concise and front-loaded. No unnecessary words.
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?
Adequate for a simple delete operation, but lacking details about return value (output schema exists but not described) and context like whether the component must be selected or on an active canvas.
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?
With 0% schema description coverage, the description should clarify what 'component_id' is or how to obtain it. The description mentions no parameter details, leaving the agent without guidance on the parameter's format or origin.
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?
Description clearly states the tool removes a component from a canvas, using a precise verb and resource. It distinguishes from siblings like gh_add_component (adds) and gh_component_list (lists).
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 vs alternatives (e.g., gh_component_list for checking existence, or gh_bake_to_rhino for baking). Missing exclusions or prerequisites.
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 description adds minimal behavioral context. It does not disclose side effects, authorization needs, or what happens to existing properties. With a write operation, more detail expected.
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, no redundancy, front-loaded with action verb. 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?
Despite output schema existing, description is too sparse for a multi-parameter tool. Does not explain what a PropertySet block is, typical use cases, or relationship to other BIM tools.
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?
Description does not mention parameters, but the input schema provides detailed descriptions for all parameters (despite context signal claiming 0% coverage). Therefore baseline of 3 applies as schema carries the burden.
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?
Description clearly states the tool persists a PropertySet block on an object. It uses a specific verb and resource, distinguishing it from siblings like rhino_bim_pset_delete and rhino_bim_pset_get.
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?
Description provides no guidance on when to use this tool versus alternatives. No mention of prerequisites, context, 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 declare readOnlyHint=true, and the description aligns by implying a read operation. The description adds minimal behavioral context beyond the annotation, such as what happens on invalid doc_id or the format of the output.
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 that conveys the core function efficiently. It could benefit from a slightly more structured format, but it is not verbose.
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 (not shown but indicated), the description provides sufficient high-level context. It names the three components of the output. The tool is simple, and the annotations fill in read-only nature.
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 a good description for doc_id. The tool description does not add any additional parameter guidance. With schema coverage high for the only parameter, the description adds 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 "Bundled units / tolerances / base point in one call" specifies the three aspects it retrieves, distinguishing it from sibling tools like rhino_document_units_get or rhino_tolerance_get. The verb is implied but clear, indicating a retrieval operation.
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 on when to use this tool versus alternatives. It hints at bundling, but does not mention the existence of separate getters or provide criteria for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (only title), so the description bears full burden. It states 'Extract' which implies a read operation (copying edges), but does not confirm non-destructive behavior, error handling for invalid indices, or whether the original Brep is modified. This lack of detail reduces transparency.
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 wasted words. It is appropriately front-loaded but could benefit from slightly more context without becoming overly verbose.
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 (object_id, layer, edge_indices) and an output schema, the description lacks details on prerequisites (e.g., Brep must exist), error states, and parameter interplay. The minimal description is insufficient for a complete understanding.
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 adds 'all or specific indices', which is already covered by the edge_indices schema description. It does not mention the required object_id or optional layer parameters, and schema description coverage is 0%. Thus the description adds minimal value 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 verb 'Extract', the resource 'edge curves from a Brep', and the scope 'all or specific indices'. This is specific and distinguishes from siblings like rhino_dup_border (which extracts borders) or rhino_isocurve (which extracts isocurves).
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 provide explicit guidance on when to use this tool versus alternatives, such as rhino_dup_border or rhino_curve_split. Usage is implied but not clarified with when-not or alternative recommendations.
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 set readOnlyHint=false, consistent with a creation tool. The description adds the NURBS approximation detail, which is useful, but does not disclose other behavioral traits such as auth needs, side effects, or how the ellipse is added to the document.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that efficiently conveys the core purpose and a technical note. No unnecessary words, but could be slightly more 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?
For a simple creation tool with an output schema, the description covers the basic purpose and a key detail (NURBS approximation). However, it lacks information about constraints (e.g., only XY plane) and document context, making it adequate but not fully 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 provides descriptions for all parameters (high coverage), so the description does not need to add much. The tool description adds no further parameter semantics, but the baseline is 3 due to high schema 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 clearly states the action ('Add') and resource ('ellipse'), and adds context about the plane ('world XY plane') and representation ('NURBS approximation'). However, it does not differentiate from sibling creation tools like rhino_circle or rhino_rectangle.
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, nor any mention of prerequisites or when not to use it. The description only states what the tool does without contextual usage advice.
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, confirming a write operation. The description adds no additional behavioral traits beyond what annotations already provide. It does not disclose side effects, permissions, or other relevant behaviors.
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 that front-loads the key action and parameters. No redundant information is present.
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 5 parameters and an output schema, but the description only covers three appearance properties. Missing details about required name, doc_id, return values, and creation behavior (e.g., where materials are stored) leave significant 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?
With 0% schema description coverage, the description partially compensates by naming 'diffuse colour, transparency, and glossiness', which correspond to parameters. However, it omits the required 'name' parameter and optional 'doc_id', leaving some parameters unexplained.
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 'Create a material with diffuse colour, transparency, and glossiness' clearly specifies the verb (create) and resource (material with specific properties). Among sibling tools like rhino_material_assign and rhino_material_preset_create, this tool is distinct as it creates a new material rather than assigning or using presets.
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_material_preset_create or rhino_material_assign. There are no prerequisites, context, or exclusions mentioned.
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?
Description adds minimal behavioral context beyond annotations. Annotations already indicate destructiveHint=true and readOnlyHint=false, but description does not clarify whether inputs are modified or new objects created.
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 very concise (one sentence) with no wasted words, but could be better structured by listing parameters or behavior.
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 performs a boolean operation with multiple parameters and an output schema, the description is too sparse. It lacks explanation of output, input object handling, and parameter roles.
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 description does not elaborate on parameters. The phrase 'a - b' hints that a_ids and b_ids are mesh IDs, but no details on name, layer, or doc_id purposes.
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?
Description clearly states 'Boolean-difference meshes (a - b)', specifying verb (Boolean-difference) and resource (meshes), and distinguishes from sibling tools like rhino_boolean_difference (likely for breps) and rhino_mesh_boolean_union.
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 mesh objects but does not explicitly state when to use this tool vs. alternatives like rhino_boolean_difference or rhino_mesh_boolean_union. No guidance on prerequisites or 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 state readOnlyHint=true; description adds that standalone uses a heuristic (no full Gaussian K) and bridge reports true curvature, providing useful behavioral 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with main action front-loaded. Modes are presented in a separate line. Efficient but could integrate mode descriptions more smoothly.
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?
Description covers main action and modes but omits parameter details and return value structure. For a tool with output schema and 0% schema coverage, the description is incomplete.
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% (top-level args property undocumented). Description does not explain any of the six nested parameters (doc_id, count_u, count_v, etc.), leaving the agent without guidance on their meaning or expected values.
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 verb 'Classify' and resource 'UxV panel by curvature class' with explicit class names. Does not differentiate among sibling tools like rhino_panel_planarity.
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?
Distinguishes between standalone and bridge modes, implying when each is appropriate, but no explicit when-not-to-use or comparison with alternatives.
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 (mutates) and destructiveHint=false. The description adds that it adds 'a single point', which is minimal. It does not disclose important details like whether it checks for duplicates, requires an active document, or how it interacts with layers.
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, concise and front-loaded. However, it omits important usage and parameter guidance, so while efficient, it is not complete enough to earn a 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?
Given the tool's simplicity and rich sibling set, the description is too minimal. It does not explain what the output is (though an output schema exists), nor does it provide any contextual hints about when to choose this tool over others like rhino_search_rhinoscript_functions or rhino_get_control_points. The description covers only the most basic purpose.
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 parameters. Although the schema documents nested fields (point, name, layer, doc_id) with descriptions, the tool description itself adds no value. With 0% schema coverage for the top-level 'args' parameter, 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 'Add' and the resource 'single point to the document', making the tool's function unambiguous. It distinguishes from siblings like rhino_line (adds line) or rhino_helix (adds helix) by specifying a point.
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. For example, it does not compare with rhino_text_dot (adds text dot) or rhino_attractor_displace_points (modifies points). The description provides no context for selection or exclusion.
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 detail about what the status includes (progress, completed frames), which goes beyond the readOnlyHint and idempotentHint annotations. No contradictions or undisclosed behavioral traits.
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, clear sentence that efficiently conveys the tool's purpose with no wasted words.
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, combined with annotations and output schema, provides sufficient context for a simple inspect operation. It covers key aspects (status, progress, frames) without over-explaining.
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 single parameter (job_id) is described in the schema as 'GUID returned by rhino_render_queue_submit,' but the tool description itself adds no additional meaning or context for 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 it inspects a queued render job's status, progress, and completed frames. However, it does not differentiate from sibling tool rhino_render_queue_list which might also show status for multiple jobs.
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 explicit guidance on when to use this tool versus alternatives like rhino_render_queue_list or rhino_render_queue_cancel. Usage is implied but not clarified.
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 lacks disclosure of side effects (e.g., whether original objects are modified or new curves created) and does not add behavioral context beyond the annotation's readOnlyHint=false. The annotation already hints at mutation, but the description fails to clarify the nature of the mutation.
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 paragraphs) with front-loaded action, using backticks for clarity. No unnecessary words, though the second line could be merged.
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 has an output schema, the description adequately covers mode distinctions but omits information about return values, error conditions, or prerequisites beyond bridge versus standalone.
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 adds the constraint that standalone mode only supports 'u' and 'v' axes, while the schema already describes this. This adds some value but is partially redundant with the schema descriptions.
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 slices surfaces (or Breps/meshes in bridge) into section curves, specifying the count. However, it does not differentiate this tool from similar siblings like rhino_section or rhino_contour.
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 explains when to use standalone vs bridge mode and which axes are supported, but it does not provide guidance on when not to use the tool or mention alternatives.
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 a title; no readOnlyHint or destructiveHint. The description does not disclose whether the operation is destructive, if it modifies objects in place, or any permissions needed. The 'make_copy' parameter suggests optionality, but this is not explained.
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 superfluous words. However, it lacks structure (e.g., bullet points or sections) that could improve readability, but it is appropriately sized for 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?
Given the complexity of the input schema (with nested objects and multiple parameters) and the presence of an output schema, the description is too brief. It does not explain what the tool returns, how axes are expected, or any important constraints (e.g., object types that work with 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%: the parameter descriptions in the schema are minimal (e.g., 'Taper axis start.'). The description adds no extra meaning beyond the parameter names, and it does not clarify the role of each parameter, such as how axis direction affects the taper.
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 (taper), the resource (objects along an axis), and the key parameters (start/end radii). This distinguishes it from other transformation tools like rhino_bend or rhino_twist.
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 or when not to, nor does it mention alternatives. The usage is implied by the name and description, but no guidance is provided for 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?
The description does not disclose behavioral traits beyond the verb 'Set'. With readOnlyHint=false annotation already indicating a write operation, the description adds no extra context about side effects, permission requirements, or impact on 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action. Every word earns its place with 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?
For a setter tool with an output schema, the description is sparse. It lacks important context such as error handling, confirmation of success, or that it modifies the current document's tolerances globally. Given the presence of an output schema, more detail on what to expect would be beneficial.
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 mentions absolute, angle, and optional relative tolerances, which maps to the schema parameters. However, the schema already contains detailed descriptions for each parameter (doc_id, absolute, relative, angle_degrees), so the description adds limited additional semantic 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 resource (tolerances), and the scope (on the document). It distinguishes itself from sibling tools like rhino_tolerance_get by focusing on setting rather than getting tolerances.
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., rhino_tolerance_get for reading tolerances, or other document settings tools). It offers no context about prerequisites, default behavior, or when not to use 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 indicate readOnlyHint=false, so the tool is mutating. The description only says 'activate', omitting details like prerequisites (view must exist), side effects (changes active viewport), or error cases. Minimal transparency beyond the annotation.
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. It is not verbose, but could be slightly expanded to include the optional doc_id parameter for completeness without losing 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 presence of an output schema and adequate parameter descriptions in the schema, the description is minimally complete for a simple activation action. However, it lacks context about error handling or prerequisites.
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 both parameters (name and doc_id). The description adds no extra semantic value beyond the schema, so 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 clearly states the verb 'Activate' and the resource 'a saved named view'. It is specific and distinguishable from sibling tools like rhino_named_view_save and rhino_viewport_image.
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 vs alternatives. Siblings include many view-related tools (save, image, etc.), but no explicit when/when-not context 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?
Description confirms mutation (adding a component), consistent with readOnlyHint=false, but lacks disclosure of error cases, coordinate bounds, or effect on existing components.
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 concise sentence with key action and context. No wasted words.
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?
Adequate for a simple add operation, but could mention behavior when component name is invalid or canvas is not ready. Output schema exists but not referenced.
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?
Input schema already describes parameters (x, y, name) with basic descriptions; the tool description adds no additional meaning. Schema_description_coverage is 0% but schema itself is informative.
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?
Description uses specific verb 'Drop' and resource 'component' with location 'onto the active canvas', clearly distinguishing it from sibling tools like gh_delete_component or gh_connect_components.
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 such as gh_place_slider or gh_components_search. No prerequisites or context 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?
The description briefly indicates the tool writes (bakes) to the Rhino document, consistent with readOnlyHint=false. However, it lacks details on side effects (e.g., overwriting, layering behavior) or required document state.
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 accurately captures the tool's purpose with no wasted words. Front-loaded and 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?
With schema covering parameters and an output schema present, the description is minimally adequate. However, it omits context about what 'bake' entails (e.g., geometry conversion, layer handling) and does not warn about potential irreversible changes.
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 descriptions already clearly define both parameters: component_ids (required) and layer (optional with layer creation hint). The tool description adds no additional semantics 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?
Description clearly states the verb 'bake' and the resource 'output of one or more components into the active Rhino document.' It uniquely identifies the tool among siblings, as no other bake tool exists in the list.
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. The description does not mention prerequisites, excluded scenarios, or when not to use 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 only set readOnlyHint=false. Description says 'Open' which implies canvas modification but does not discuss side effects (e.g., overwriting existing content) beyond the canvas_target parameter, which is already in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no unnecessary words. Front-loaded with the core action.
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 explains the return value adequately given that an output schema exists. However, it omits error conditions (e.g., invalid template name) and prerequisites (e.g., listing templates 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 input schema provides full descriptions for both parameters. The tool description adds no additional parameter information, so 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 clearly states the verb ('Open'), resource ('bundled template'), and output ('template_id + parameter map'). It is distinct from sibling tools like gh_template_list, gh_bind_template_parameter, and gh_run_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Lacks prerequisites or 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 indicate readOnlyHint=false, consistent with the write operation described. The description adds some behavioral context (bridge-only, targets DimStyle table) but does not disclose side effects like overwriting existing styles, permissions, or response 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 a single, front-loaded sentence with no wasted words. It conveys the essential action and context efficiently.
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 any mention of return values. It also lacks details on parameter effects, prerequisites (e.g., open document), or when to use this tool among siblings. The tool is moderately complex with 5 parameters, yet the description is minimal.
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 0% schema description coverage, the description should compensate by explaining parameters. It does not mention any parameters or their purposes. The schema property names are somewhat self-explanatory, but the agent lacks guidance on required vs. optional fields and their impact.
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 registers a reusable dimension style, using a specific verb ('Register') and resource ('reusable dimension style'). It differentiates from sibling annotation tools like rhino_dimension_linear by focusing on style creation rather than placing dimension objects.
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, no prerequisites, and no examples. The agent receives no context about appropriate scenarios for registering a dimension style.
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 readOnlyHint or destructiveHint, so the description must carry the transparency burden. However, it only states the positive action (create) without disclosing whether it modifies original edges, requires any special conditions, or what happens on failure. This is insufficient for a tool creating new geometry.
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 of 9 words, straight to the point without any redundancy. It is front-loaded with the action and specific inputs, making it easy 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 moderate complexity of surface creation and the existence of an output schema (which covers return values), the description is quite minimal. It does not mention prerequisites (e.g., that edges must belong to surfaces, be adjacent) or error conditions. While sufficient for the core function, it lacks completeness for a reliable agent 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 mentions 'connecting two surface edges' which clarifies the purpose of edge_id_1 and edge_id_2, and 'continuity control' explains the continuity parameter. However, it omits any explanation for the optional 'name' and 'layer' parameters, and with schema description coverage at 0%, the description partially compensates but not fully.
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 action ('Create a blend surface'), the specific inputs ('two surface edges'), and a key feature ('continuity control'). This distinguishes it from the sibling 'rhino_blend_surface' which likely handles more general blend scenarios, though not explicitly stated.
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_loft' or 'rhino_sweep2'. It lacks explicit when-to-use, when-not-to-use, or prerequisite information, leaving the agent to infer from the name and 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 indicate mutation (readOnlyHint=false). Description adds context about replacing source objects in bridge mode, which is useful. However, lacks details on potential side effects like overwriting existing block definitions.
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. Every sentence adds value, and the structure is front-loaded with the primary 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?
Despite having an output schema, the description does not explain return values or prerequisites (e.g., objects must exist in the document). The tool has two modes with distinct behaviors but lacks full context for an agent to use it effectively.
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 only implicitly references 'name' and 'replace_objects' but does not explain other parameters like base_point, object_ids, doc_id, or description. The schema is the sole source of parameter meaning.
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 'Create a block definition' and distinguishes between standalone and bridge modes, providing specific verb and resource. It differentiates from siblings like rhino_block_insert and rhino_block_explode.
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 on when to use this tool versus alternatives. The description mentions two modes but does not provide criteria for choosing between them or when to use other block-related tools.
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. The description adds no behavioral details beyond that (e.g., what gets destroyed, if original objects are modified, or any side effects). The 'bridge required' note is a prerequisite, not a 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: two sentences with no wasted words. Every sentence provides essential information about the operation and a key requirement.
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 presence of an output schema and annotations, the description covers the core operation but lacks details on the result (e.g., whether a new object is created or existing objects modified). As a boolean operation with destructive hint, more context about the outcome would be helpful.
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 relationship between a_ids and b_ids ('Subtract b_ids from a_ids'), adding meaning beyond the schema's minimal descriptions. However, it does not address other parameters (name, layer, doc_id), so compensation for 0% schema coverage is partial.
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 ('Subtract') and the resources ('b_ids from a_ids'), specifying the exact boolean operation. It distinguishes from sibling tools like boolean_union and boolean_intersection by the subtractive nature.
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 mentions that a bridge is required, but provides no guidance on when to use this tool versus alternatives (e.g., intersection, union). No context on prerequisites or typical use cases.
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`, but the description adds no context about what gets destroyed, whether objects are modified or new ones created, or any prerequisites beyond the bridge. The brief text does not disclose behavioral traits such as object creation, selection changes, or error conditions.
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 very short (two sentences) and front-loaded with the core purpose. It is efficient but could be more structured without wasting space.
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 complexity (7 sub-parameters in the input schema), the description only covers two parameters. Despite the existence of an output schema, it omits optional parameters like `name`, `layer`, and `doc_id`. The 'Bridge required' note adds essential context, but overall the description leaves important 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 description repeats the parameter names `a_ids` and `b_ids` without adding meaning beyond what the schema's descriptions provide ('First operand brep GUIDs.', 'Second operand brep GUIDs.'). With schema description coverage at 0% (according to context), the description fails to compensate for the lack of 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 verb 'Intersect' and the two resource parameters `a_ids` and `b_ids`. It distinguishes this tool from sibling boolean tools like `rhino_boolean_union` and `rhino_boolean_difference` by naming the specific 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 mentions 'Bridge required', which provides a condition for use. However, it does not explain when to choose intersection over union or difference, nor does it provide exclusions or alternatives.
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=true, so the agent knows the tool is non-destructive. The description adds 'bridge required' as crucial behavioral context beyond annotations. However, it does not disclose details about the sampling process, output format, or any 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the core purpose and a key prerequisite. Every word serves a purpose without extraneous 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?
Despite having an output schema, the description is too minimal for the complexity of the tool. It does not explain what 'sample' entails, whether multiple curvature types are computed, or how results are presented. Parameter semantics are missing, leaving significant gaps for 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 0%, and the description provides no explanation of parameters. The required parameter 'object_id' is not clarified as a surface identifier, and optional 'doc_id' is ignored. The description fails to add value beyond the bare schema structure.
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 (sample) and resource (Gaussian/mean curvature of a surface). It distinguishes from sibling tools like rhino_surface_curvature_at, which performs point evaluation, by using 'sample' implying broader assessment. The prerequisite 'bridge required' adds specificity.
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 curvature analysis but does not explicitly state when to use this tool versus alternatives such as rhino_surface_curvature_at or rhino_zebra. No when-not or alternative guidance is provided.
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 description does not need to repeat safety. It adds value by specifying the output includes parametric domain and approximate length, which is beyond the annotations. However, no additional behavioral traits (e.g., regarding precision or performance) are disclosed.
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 efficiently conveys the core purpose without any unnecessary words. It is front-loaded with the action and result.
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 simplicity of the tool (one parameter, read-only query) and the presence of an output schema, the description covers the essential output. It mentions both aspects of the result (parametric domain and length). However, it could be slightly more complete by noting that the tool does not modify the curve, but annotations already imply that.
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 provides no information about the required parameter (curve reference). Schema description coverage is 0% (per context signal), meaning the tool description does not explain what the 'args' parameter expects. The schema itself has descriptions for doc_id and object_id, but the tool description fails to clarify how to provide the curve or its meaning.
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 it returns the curve's parametric domain and approximate length, using a specific verb ('Return') and resource ('curve's parametric domain and approximate length'). This distinguishes it from sibling curve tools that do other operations like point at parameter or split.
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 specify when it is appropriate or inappropriate, nor mentions any preconditions or alternatives among the many sibling curve 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 provide readOnlyHint, and description aligns ('Read'). However, description adds no additional behavioral context beyond that (e.g., how output is structured or if a document must be open). Since annotations cover safety, score is adequate but not enhanced.
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?
Single sentence, front-loaded with the verb. Efficient but 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple read tool with output schema, so description is minimally adequate. Lacks mention of the default active document and return format, but these are covered by schema and annotations.
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%, yet the description does not mention the single parameter (doc_id) or its behavior. The schema does describe it, but the description must compensate for low coverage and fails to add 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 'Read the current document unit system' uses a specific verb (Read) and resource (document unit system), clearly distinguishing it from write siblings like rhino_document_units_set.
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 guidance on when to use this tool versus alternatives (e.g., rhino_document_units_set or other read tools). The purpose implies usage for reading units, but no when-not or context 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 only indicate readOnlyHint=false, and the description adds the scaling behavior but does not disclose other behavioral traits like whether changes are undoable, affect existing objects beyond geometry scaling, or require special permissions.
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 of 12 words, conveying the core functionality and an optional behavior. No unnecessary words or details.
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 simplicity of the tool (set units, optional scaling), the description is mostly complete. An output schema exists, so return values are handled. However, it lacks context on error conditions or the impact of changing units on future operations.
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% in the tool description, so the description must compensate for parameter meaning. It does not describe any parameters, relying entirely on the input schema. While the schema descriptions are thorough, the tool description adds no value beyond what the schema provides.
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 'Set' and specifies the resource 'document unit system' with an optional additional action 'scaling existing geometry'. This distinguishes it from the sibling tool 'rhino_document_units_get' by implication of the set/get naming convention.
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 on when to use this tool versus alternatives (e.g., when to scale vs not scale, prerequisites, or side effects). The sibling 'rhino_document_units_get' is not mentioned as a complementary 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?
Annotations already indicate readOnlyHint=false (write operation). The description adds no further behavioral details such as document mutation, permissions required, or impact on 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no redundant information. It achieves 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?
For a simple creation tool, the description could be considered adequate, but it omits typical usage context (e.g., document units, return value reference). The presence of an output schema partially compensates for this 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 provides rich descriptions for all parameters (start, end, name, layer, doc_id). The description adds minimal value beyond 'between two points', which aligns with the 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 'Add a line between two points.' clearly states the verb (Add), resource (line), and essential parameters (start and end). It effectively distinguishes this tool from siblings like rhino_point, rhino_polyline, and rhino_circle.
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, exclusions, or typical use cases, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some behavioral context beyond the readOnlyHint=false annotation by mentioning the binding to a doc_id, but does not disclose potential side effects like replacing the current document or error conditions. With annotation already indicating a mutation operation, the description offers limited 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 that front- loads the main action and resource. It is concise with no unnecessary words, earning 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 description lacks details about error handling, file existence, or whether opening a file replaces the current document. Given that an output schema exists, return values are not required, but key contextual information for a file-open operation is missing.
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?
Despite a schema_description_coverage of 0% (only top-level 'args' lacking description), the nested schema provides clear descriptions for 'path' and 'doc_id'. The tool description mentions binding to a doc_id but does not elaborate on the required 'path' parameter, failing to compensate for the low coverage. The agent might need to infer parameter semantics from the nested 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 clearly states the action ('Open'), the resource ('.3dm file'), and the additional operation ('bind it to a doc_id'). It distinguishes from sibling tools like gh_open_file by specifying the file type and the binding behavior.
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, prerequisites (e.g., file existence, path format), or typical use cases. The agent receives no context for decision-making.
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 mutation, but description does not clarify side effects like whether original curve is replaced or new curve is created. Adequate but incomplete.
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 efficient sentence, no wasted words, front-loaded with key information.
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 an output schema present and a simple mutation purpose, the description is mostly complete. Could briefly state that it modifies the existing curve in place, but not critical.
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?
Tool description lacks parameter explanations; schema coverage is 0% per context, and the description must compensate but does not. Schema has property descriptions but the tool description itself adds no 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?
Description clearly states it rebuilds an existing curve using point count and degree, distinguishing it from curve creation tools and surface rebuilding tools.
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 like rhino_curve_point_at or rhino_rebuild_surface; lacks when-not-to-use or 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?
Annotations already indicate readOnlyHint=false (mutation). Description adds no additional behavioral context (e.g., file overwrite behavior, error handling).
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?
Single sentence, front-loaded, efficient. Could add more detail on parameters without being wasteful.
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 export tool with output schema, description is adequate but lacks behavior details like return value or file handling.
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?
Description adds no meaning beyond schema. Schema itself describes 'path' and 'columns' but not 'rows'. Context claims 0% schema description coverage, though schema has some descriptions. Even so, description does not 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?
Description clearly states the verb 'Write' and resource 'rows produced by any rhino_schedule_* tool to CSV', distinguishing it from sibling schedule tools and export tools.
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?
Description implies use after rhino_schedule_* tools but provides no explicit when-to-use, when-not-to-use, or alternatives.
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=true. Description adds that it finds UV parameters and a 3D point, but does not disclose behavior like tolerance, coordinate system, or error handling. Moderately transparent.
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?
Single sentence, no redundancy. It is concise and front-loaded, but could benefit from additional 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?
Description is adequate for a simple query tool with output schema and readOnly annotation, but misses usage context, such as the need for an existing surface. Slight 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?
Schema description coverage is 0%, so description should compensate. It does not explain object_id (GUID of surface) or test_point (point with x,y,z) beyond the name. Adds minimal meaning beyond 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?
Description clearly states the tool finds UV parameters and the 3D point closest to a test point on a surface. It provides a specific verb and resource, distinguishing it from sibling tools like rhino_surface_curvature_at or rhino_surface_normal_at.
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. The description lacks context about prerequisites, such as requiring an existing surface, or when a different surface analysis tool might 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=true, so the description's mention of 'Evaluate' is consistent. The 'bridge only' restriction adds behavioral context. However, no further details about side effects, performance, or limitations 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?
Single sentence, no fluff. Essential information is front-loaded: verb, resource, and restriction. Parenthetical adds important context without extra length.
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 low complexity (evaluate curvature at a point) and the presence of an output schema, the description is mostly complete. However, it lacks explanation of what 'bridge' means, which could confuse agents unfamiliar with Rhino surface types.
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 coverage is 0% per context, meaning the schema has minimal descriptions. The description adds no information about u, v, doc_id, or surface_id beyond what the schema already provides. For example, it does not explain that u and v are normalized domain parameters.
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?
Description clearly states the verb 'Evaluate' and the resource: true Gaussian/mean/principal curvatures at (u,v). It distinguishes from sibling tools like rhino_surface_normal_at (normal vs curvature) and rhino_evaluate_surface (more general). The parenthetical '(bridge only)' adds specificity.
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 vs alternatives. It mentions 'bridge only' but doesn't explain what bridge means or when this is appropriate compared to other curvature tools like rhino_curvature_analysis. No prerequisites or exclusions are stated.
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, which is consistent with the description's 'render' implying a write operation. No contradictions, but the description does not add significant behavioral context beyond what annotations imply (e.g., does not mention side effects, prerequisites, 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?
Single sentence with no extraneous words. Front-loads the core purpose and output format. Very 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 lacks context about required model state (e.g., a 3D object to animate), view settings, and how to choose between PNG sequence vs GIF. While an output schema exists, the description omits crucial setup details for a rendering 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% and the description only clarifies the output_path parameter. Other parameters (width, height, frames, doc_id) have no additional explanation, leaving the agent to infer their meaning from schema constraints 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 (render) and resource (turntable animation) with output to a specific path in PNG or GIF format. It uniquely identifies the tool among siblings performing other render 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 explicit guidance on when to use this tool versus alternatives like rhino_turntable_render or rhino_render_to_file. The description only implies usage for turntable animations without providing context 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 readOnlyHint and idempotentHint. Description adds no additional behavioral context beyond the tool's name and basic purpose. No 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?
Single sentence, no unnecessary words. Efficiently communicates the core function.
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?
With output schema present, return values need not be described. However, the description lacks context about input requirements and usage, making it minimally adequate.
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 does not elaborate on parameters, such as doc_id or object_ids, leaving the agent to infer 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?
Description clearly states the tool returns the union bounding box of one or more objects, using a specific verb and resource. It distinguishes itself from other query tools like rhino_area or rhino_volume.
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. Lacks context about 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?
Annotations only set readOnlyHint=false; description does not disclose behavioral traits such as mutating document, object creation behavior, or constraints beyond the schema. No contradiction, but fails to add value 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?
Single sentence with clear, front-loaded information; no waste. Ideal structure for quick comprehension.
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 large number of sibling tools and moderate complexity, the description covers the essentials but could mention that this creates a curve object in the active document, or note that plane defaults to XY at center. However, with output schema existing (though not shown), completeness is adequate.
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% at top-level, but sub-properties in $defs have detailed descriptions (e.g., layer, plane, center, radius). The tool description adds minimal new meaning beyond 'optional custom plane', 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?
Description uses specific verb 'Add' and resource 'circle', details method (centre and radius) and optional variation (custom plane), clearly distinguishing from siblings like rhino_arc, rhino_ellipse, and other shape creators.
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 when-to-use or when-not-to-use guidance, nor alternatives. The description implies use for circle creation but does not differentiate from similar tools or provide context for 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?
The description notes that the original curve is preserved, which adds value beyond the readOnlyHint=false annotation. However, it does not disclose what happens to the original (e.g., remains unchanged, new curves created) or the format of the output (e.g., list of curve GUIDs).
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 conveys the core action efficiently. No unnecessary words 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?
For a mutation tool, the description is incomplete. It does not explain how the parameters map to curve domain, what is returned (e.g., list of curves), or any side effects. An output schema exists but is not referenced, leaving 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 input schema already describes the parameters adequately ('GUID of an existing curve', 'Parameters at which to split'). The description adds no additional parameter meaning, and with 0% schema description coverage, there is no compensation.
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') and the resource ('curve'), and adds that the original is preserved, distinguishing it from modification tools. No other sibling tool explicitly splits curves, so it effectively communicates the unique operation.
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. There is no mention of prerequisites, context, or situations where this tool is inappropriate.
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 a write operation (readOnlyHint=false). The description adds no further behavioral context beyond the basic action. No mention of required permissions, units, or error handling.
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?
Single sentence is concise and front-loaded with the core action. Could benefit from a brief parameter explanation without becoming verbose.
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 (three 3D points, document ID), the description is too minimal. Lacks parameter descriptions, usage examples, or output schema explanation. Annotations partially fill gaps but incompletely.
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%, but the description does not explain the parameters (center, point_a, point_b) except through the schema structure. Users must rely on schema alone for parameter understanding.
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 adds an angular dimension at a vertex, with specific verb 'add' and resource 'angular dimension'. It distinguishes from sibling dimension tools like rhino_dimension_linear and rhino_dimension_aligned.
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 guidance on when to use this tool versus alternatives. The description implies usage for angular dimensions at a vertex, but lacks comparison to other dimension 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 indicate readOnlyHint=false, so the write nature is known. The description adds the 'bridge only' context but does not disclose other behavioral traits such as side effects on original objects, permission requirements, or output format. Annotations carry some burden, but more detail would be helpful.
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 (16 words) that immediately states the action and resource. It is perfectly concise and front-loaded with the verb 'project'.
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 complexity (nested object, many parameters, output schema exists), the description is too brief. It does not explain prerequisites (e.g., sheet_id from rhino_drawing_sheet_create), constraints (max 500 objects), or the output. The 'bridge only' note is vague.
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 has descriptions for parameters like target_origin and viewport_scale, so baseline is 3. However, the tool description adds no parameter information (0% coverage), missing the chance to explain critical parameters like sheet_id or object_ids.
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: projecting objects to a 2-D view (Make2D) and placing the result on a sheet. It specifies 'bridge only', distinguishing it from similar tools like rhino_make2d which only project without placing.
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 only mentions 'bridge only', which is a constraint but does not explain the decision context or prerequisites like creating a sheet first with rhino_drawing_sheet_create.
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=true, so the description's 'Read' is consistent. It adds that the tool reads 'key-value metadata', but does not describe behavior for missing objects, keys, or error conditions. Output schema exists to cover return values, so the description 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?
A single sentence that is concise and front-loaded with the verb and resource. No extraneous words.
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, the description is minimally adequate. However, it does not explain the required 'object_id' parameter or specify that omitting 'key' returns all keys (though this is in the schema). More context would improve completeness.
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 mention any parameters. Although the input schema provides descriptions for two of three parameters (key, doc_id), the object_id parameter lacks a description. The description adds no value beyond the schema, and the 0% schema description coverage metric (for the description itself) indicates a 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 uses a specific verb ('Read') and clearly identifies the resource ('user text (key-value metadata)') and its attachment ('to an object'). It distinguishes itself from sibling tools like 'rhino_set_user_text' by the action of reading vs writing.
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, such as other read tools (e.g., 'rhino_object_info') or when to use 'rhino_set_user_text' for writing. The context is implied but not stated.
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, consistent with a write operation. However, the description does not disclose behavioral traits beyond creation, such as what happens if the layer name already exists, whether the operation is reversible, or any authentication/authorization requirements. The description adds minimal context beyond the annotation.
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. It could be slightly more informative (e.g., mention returned object), but it is well-structured and efficient, earning a 4.
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 covers the basic action. However, it omits important context such as error handling (e.g., duplicate layer name), the return value (though an output schema exists), and how it interacts with other layer tools. It is minimally adequate but not 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 input schema already provides detailed descriptions for each parameter (e.g., name uniqueness, doc_id default). The tool description adds no new meaning beyond what the schema provides, only re-stating that colour and visibility are optional. With adequate schema coverage, a 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 clearly states a specific verb ('Create') and resource ('layer'), and mentions optional attributes (colour, visibility). It effectively distinguishes this tool from sibling layer operations like rhino_layer_delete or rhino_layer_set_color.
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 tool is used for creating layers with optional colour/visibility, but it does not provide explicit guidance on when to use this versus alternatives (e.g., modifying existing layers), nor does it mention prerequisites 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 readOnlyHint: true, so the description only adds that it returns geometry type, layer, bbox, etc. No mention of error handling (e.g., if object_id is invalid) or performance implications. 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?
Single sentence, front-loaded with action 'Get detailed info', examples in parentheses. No wasted words. 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?
Given output schema exists, return values need no explanation. The low parameter count and simple purpose are well-served by the description, but missing usage guidelines and parameter context slightly reduce completeness.
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 coverage is 0% (no parameter descriptions except doc_id's inline note). The tool description does not elaborate on the object_id parameter or provide examples. With no compensation, the agent must rely on the schema's minimal info.
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: getting detailed info about a single object, with specific examples (geometry type, layer, bbox). This distinguishes it from sibling tools like rhino_list_objects (list-based) and rhino_area (single metric).
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 on when to use this tool versus alternatives. For example, it doesn't clarify preference over rhino_area or rhino_volume when only a specific metric is needed. 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 already indicate readOnlyHint=false, so the mutating nature is known. The description adds only the XY plane context. No details on side effects, creation behavior, or output format are provided.
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 redundancy. It is front-loaded but very brief; additional useful details could be added without harming 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?
For a simple creation tool with a rich set of sibling tools, the description is minimal but covers the core function. It does not explain the output, but an output schema exists. It meets the minimum for completeness given the low complexity.
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% according to context, but the input schema itself has descriptions for all parameters. The description adds no extra meaning beyond the schema, 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 clearly states the tool adds a regular polygon (inscribed or circumscribed) on the XY plane. It uses a specific verb 'Add' and resource 'regular polygon', distinguishing it from sibling tools like rhino_circle or rhino_rectangle.
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 when-not-to-use guidance is provided. The agent must infer usage based on the description, but it doesn't differentiate from alternatives beyond the implied scope.
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 description's 'Add' aligns. However, no additional behavioral details like returning an object ID or potential side effects are provided.
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?
Extremely concise and front-loaded: one sentence that covers the core action and optional closure. No wasted words.
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?
Minimal description does not explain that points require at least 2, the document context, or that layer creation is automatic. For a creation tool with many siblings, more context would be helpful.
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 properties have internal descriptions, but the top-level 'args' parameter lacks a description. The tool description adds no parameter details beyond what the schema already provides.
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?
Description clearly states it adds a polyline from given points with optional closure. This distinguishes it from sibling tools like rhino_line (single segment) or rhino_curve (smooth curve).
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 such as rhino_rectangle or rhino_polygon. No mention of when not to use it 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?
The description indicates a mutating action (cancel), consistent with readOnlyHint=false. However, it does not disclose side effects, such as whether the job is permanently removed or if resources are freed. Minimal but not misleading.
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?
Extremely concise at 7 words, front-loaded with the key action and resource. No wasted words.
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 cancel tool with one parameter and an output schema, the description is minimally complete. It could mention the source of job_id or prerequisites, but it covers the essential 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?
The parameter schema has adequate description for job_id, but the tool description itself adds no parameter information. With 0% schema description coverage (for the top-level param), 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 action (cancel) and the resource (running or queued render job). It is specific and distinguishes from siblings like submit or status, as it deals with cancellation.
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 vs alternatives, nor does it mention prerequisites or when not to use it. It simply states the function without 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 write operation (readOnlyHint=false). The description adds context about reorientation via align_to_tangent and endpoint inclusion, but does not disclose side effects (e.g., object creation, transformation persistence) beyond what is implied.
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 short paragraphs with a clear first sentence stating the main action. No fluff, but the parameter explanation is somewhat embedded in a code-like style. Could be slightly more streamlined.
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 complex mutation tool, the description covers core behavior but omits output details (despite having an output schema), error conditions, or required object validity. Adequate for basic use but lacks thoroughness.
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. It explains two key parameters (align_to_tangent, include_endpoints) with behavioral details, but ignores count, curve_id, source_object_id, and doc_id. This partially compensates but leaves gaps.
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: 'Distribute copies of a source object along a curve at evenly-spaced parameters.' It uses specific verb+resource ('distribute copies') and distinguishes it from siblings like linear/polar arrays by focusing on curves.
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 vs alternatives (e.g., rhino_array_linear, rhino_flow_along_curve). The description implies usage for curve-based replication but does not mention prerequisites or when not to use it.
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=true, so the read-only nature is clear. The description adds no further behavioral details (e.g., error handling, component requirements). It aligns with annotations but does not go beyond.
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 is front-loaded with the core action. No extraneous words or redundant information.
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 read-only tool with an output schema, the description is minimally adequate. However, it does not elaborate on what a 'component parameter' means in the Grasshopper context or differentiate among sibling read tools. More context would improve usability.
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 has low description coverage (0% per context, though 'output' has a description). The tool description does not explain the parameters 'component_id' or 'output', leaving the agent to rely solely on the schema. Baseline score due to missing parameter explanations.
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 reads the current value of a component parameter. It uses a specific verb ('Read') and resource ('current value of a component parameter'), distinguishing it from sibling 'gh_set_parameter' which writes.
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 'gh_set_parameter', 'gh_data_tree_get', or other read tools. No context about prerequisites or conditions is 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?
The description adds context beyond annotations (readOnlyHint=false) by noting the bar is in document units and the label reports real-world distance based on scale_denominator. However, it does not detail other behavioral aspects like object creation or potential 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?
The description is short (two sentences) and front-loaded with the main action. It is efficient but could be slightly more structured with bullet points or explicit parameter hints.
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 output schema exists, return values are covered. However, the lack of parameter explanations and usage context makes it only minimally complete for a tool with multiple parameters and 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?
With 0% schema description coverage, the description should explain parameters but only mentions scale_denominator's role. Other key parameters like location, divisions, label_height, total_length are not described, leaving the agent without sufficient guidance.
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 it draws a divided scale bar with a label, using a specific verb ('Draw') and resource ('scale bar'). It distinguishes itself from sibling annotation tools like dimension or callout tools by specifying the scale bar's properties.
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 scale bars on drawings but does not explicitly state when to use this tool versus alternatives or provide exclusions. There is no guidance on prerequisites or context.
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 the description confirms mutation by stating 'writes' and 'pushes'. It discloses two distinct modes (standalone vs. bridge) and their impact on IFC export, adding value beyond annotations. No 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?
The description is extremely concise: three sentences, front-loaded with the core purpose, and no redundant information. Every sentence adds value.
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 existence of an output schema and detailed annotations, the description adequately covers behavioral context (two modes, IFC export). Minor omission: no mention of property optionality or object limits, but not critical.
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 tool description contains no information about parameters beyond what is in the input schema. With schema description coverage at 0%, the description fails to compensate; it adds no additional meaning or usage hints for the complex 'args' 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 states 'Tag objects with IFC entity + property-set metadata' clearly specifying the verb, resource, and field scope. It distinguishes between standalone and bridge modes, differentiating from sibling tools like rhino_bim_pset_set and rhino_set_user_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?
The description lacks explicit guidance on when to use this tool versus alternatives like rhino_bim_pset_set or rhino_set_user_text. No context on prerequisites, mode selection criteria, or comparison with siblings is provided.
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 and idempotentHint, indicating safety. The description adds the behavioral detail of evaluating position and tangent, but does not explain edge cases like out-of-domain parameters or return format.
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 concise and front-loaded with the action. Every word earns its place with no wasted information.
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 existence of an output schema and annotations, the description is minimally adequate. However, it could better address constraints like domain limits and required curve existence.
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 parameter descriptions (e.g., 'Parameter (within Domain)' for t). The description adds no additional semantics beyond the schema, so 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?
The description clearly states it evaluates position and tangent on a curve, using a specific verb and resource. It distinguishes from siblings like rhino_curve_length (length) and rhino_surface_curvature_at (surface), as it explicitly targets curve point evaluation.
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 (e.g., other curve evaluation tools). There are no prerequisites mentioned, such as requiring a curve to exist or the parameter to be within the domain.
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 description's 'switch' aligns as a mutation. However, the description adds no further behavioral details (e.g., immediate effect, impact on other viewports). 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?
Single, efficient sentence with no wasted words. Front-loaded with the primary action.
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 one-required-parameter mutation with an output schema, the description is minimally complete but could mention immediate effects or limitations. Lacks guidance on edge cases or prerequisites.
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?
Input schema already provides descriptions for both parameters (mode and doc_id). Since schema_description_coverage is 0% from the tool description, baseline is 3. Description does not add parameter semantics beyond 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?
Description clearly states 'Switch the active viewport's display mode' with a specific verb ('switch') and resource ('active viewport's display mode'). It distinguishes this tool from siblings that manipulate views or other properties, 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?
No guidance on when to use this tool versus alternatives like rhino_view_set or rhino_zoom_* is provided. There is no mention of prerequisites, context, 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 indicate readOnlyHint and idempotentHint, so the agent knows the operation is safe and idempotent. The description adds 'Euclidean' which specifies the distance metric, but does not disclose any edge cases (e.g., behavior with invalid input). With annotations covering safety, 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 extremely concise (5 words) and to the point. Every word is meaningful. No redundancy.
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, well-defined tool with an output schema, the description is fairly complete. It specifies the geometry type (points) and distance type (Euclidean). The only missing piece is explicit mention of units or document context, but these are commonly understood for Euclidian distance in Rhino.
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. However, the description is only one sentence and does not explain the parameters point_a and point_b beyond what the schema's property descriptions already provide. It adds no extra meaning to the input parameters.
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 it computes 'Euclidean distance between two points', specifying the verb ('distance') and the resource ('two points'). It distinguishes from sibling tools that compute other geometric properties like lengths, areas, or volumes.
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. Among siblings, there are no other distance tools, but a user might benefit from knowing this is for 3D distance or that it doesn't handle curves. The description lacks this 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, so the description need not restate that. It adds the detail that both control points and weights are returned, which is beyond annotations. However, it doesn't describe output format, potential errors, or data structure.
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, clear sentence with no extraneous words. Perfectly concise and front-loaded with key information.
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 tool with one parameter and an output schema (as indicated), the description is complete. It names the data returned and the target object, which is sufficient.
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 for 'object_id' is 'GUID of the NURBS curve or surface.', which already explains the parameter. The description provides no additional parameter information, so baseline 3 applies (schema coverage is effectively 100% for the required parameter).
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 verb 'Get', resource 'control points (and weights)', and target 'NURBS curve or surface'. It is specific and distinct from sibling tools like 'set_control_points', though it doesn't explicitly differentiate.
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 vs alternatives (e.g., 'curve_point_at' for a single point, or 'set_control_points' for modification). Lacks context about prerequisites or excluded scenarios.
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?
The description explains the behavioral difference between standalone (basic Material) and bridge mode (PBR render content + IOR), adding context beyond the readOnlyHint=false annotation. It discloses what kind of material is produced, which is useful for agent decision-making.
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 three sentences, front-loading the core purpose. It uses line breaks for readability and avoids unnecessary repetition. Each 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?
Given the tool's complexity (with modes and output schema) and the availability of sibling tools like rhino_material_preset_list, the description is fairly complete. It explains the two modes and their output differences, though it could briefly mention that the preset_name should come from the list 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?
Schema descriptions cover all parameters (doc_id, preset_name, material_name) with clear explanations. The description does not add additional detail about parameters beyond what the schema provides, but schema coverage is high, 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 it creates a document material from a bundled physical preset, specifying the resource and action. It distinguishes standalone vs bridge modes but does not explicitly differentiate from sibling tools like rhino_material_create, which could also create materials.
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 mentions standalone and bridge modes but provides no explicit guidance on when to use this tool versus alternatives (e.g., rhino_material_create) or when not to use it. No exclusion criteria or context for 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?
The description correctly identifies the tool as performing a redo operation, which implies document modification. However, it does not disclose error behavior (e.g., if there are no undone operations) or that it can redo multiple steps. Given no annotations to rely on, the description is adequate but lacks depth.
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 conveys the core functionality without extraneous words. It is effectively front-loaded.
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 minimally complete for a simple redo tool with a well-defined schema and output schema. However, it could improve by mentioning edge cases (e.g., behavior when fewer steps are available) or return value expectations.
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 schema description coverage is 0% per context, the schema itself contains a description for 'steps' ('Number of operations to redo'). The tool description does not add parameter information, but the schema already provides it, so the description adds no extra value beyond the schema. 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 ('Redo') and the resource ('the last undone operation(s) in the Rhino document'). It effectively distinguishes from the sibling tool 'rhino_undo' by focusing on the inverse operation.
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_undo'. It does not mention prerequisites (e.g., having undone operations) or typical use cases.
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 confirm readOnlyHint=true. The description adds detail about handling default material (-1) in standalone mode and render content lookup in bridge mode. However, no mention of return format, pagination, or permissions, which is acceptable given annotations.
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?
Description is short and structured into two clear sections. Each sentence adds value, though the second paragraph could be slightly rephrased for clarity. No unnecessary words.
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?
Output schema exists, so return values don't need description. However, with 0% schema coverage, the description should provide parameter guidance. It is partially complete but lacks explanation of doc_id and fields, which are critical 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 coverage is 0%, so description must compensate. It mentions material name grouping but fails to explain the two parameters (doc_id, fields) or their roles. The description adds no meaning beyond the schema's minimal definitions.
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 aggregates objects grouped by assigned material name, with specific modes: standalone and bridge. It distinguishes from sibling tools like rhino_schedule_by_layer by its focus on material assignment.
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 explains behavior in standalone vs bridge mode, but does not explicitly state when to use this tool over alternatives (e.g., rhino_schedule_by_layer, rhino_schedule_by_user_text). Usage context is implied but not directive.
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, so the description doesn't need to reiterate that it is destructive. The description adds one behavioral detail: 'optionally leaving listed faces open'. However, it doesn't disclose other behaviors like how thickness is applied (inward/outward) or error 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?
The description is a single sentence that is clear and direct without any superfluous words. It effectively communicates the core functionality.
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?
Considering the complexity of shelling (closed Brep requirement, thickness direction, open face indices, return value), the description is too minimal. It lacks details on prerequisites, edge cases (e.g., non-closed Breps), and output behavior (likely a new shelled Brep). An output schema exists but doesn't compensate for missing context.
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 provide parameter meanings. It mentions 'closed Brep' (object_id) and 'listed faces open' (open_face_indices) but fails to describe 'thickness' (direction, sign), 'name', 'layer', or 'doc_id' semantics. This is insufficient for a 0% coverage scenario.
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 ('hollow'), the target resource ('closed Brep'), and the optional behavior ('leaving listed faces open'). It distinguishes from other solid modeling tools like boolean operations or cap_holes, making the purpose 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 the tool is for hollowing closed Breps but doesn't provide explicit when-to-use vs alternatives (e.g., offset surface, boolean difference). No guidance on when not to use it (e.g., for non-closed Breps) or required 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 provide readOnlyHint and idempotentHint. The description adds that the tool lists only components on the active canvas, which is useful context beyond the annotations, but does not disclose additional behavioral traits (e.g., performance, pagination, or return format).
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, no fluff, front-loaded with the key action and resource. Perfectly concise.
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 (1 parameter, output schema exists, annotations provided), the description is mostly complete. It specifies the scope (active canvas) and optional filter. Missing are details on what constitutes a 'component' and any limitations, but these are likely implied.
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 has one parameter (filter) with a description: 'Substring to filter component nicknames by.' The tool description does not mention the parameter, but the schema description is adequate. Baseline is 3 due to good 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 clearly states the verb 'List' and the resource 'components currently on the active canvas', with optional filtering. This distinguishes it from siblings like gh_components_search (which searches libraries) and rhino_list_objects (Rhino-specific).
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 on when to use this tool versus similar tools like gh_components_search or gh_plugin_list. The description only states what it does, not when it's 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 indicate readOnlyHint=false, consistent with 'Add'. However, the description adds no behavioral context beyond creation—no mention of side effects, prerequisites (e.g., active document), or confirmations. For a write tool with minimal annotation coverage, more transparency is needed.
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 and contains no redundant information. It efficiently conveys the tool's purpose and input requirements.
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 simple function and the presence of a well-described input schema and an output schema (not shown), the description is nearly complete. It could mention that it returns a new arc object, but the output schema likely covers that. Minor gap, but overall adequate.
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 add parameter details; it relies on the input schema which already has descriptions for all parameters (center, radius, angle_degrees, etc.). Schema description coverage is high (0% from tool description, but schema itself covers 100%), 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 clearly states the verb 'Add', the resource 'arc', and the method of definition: 'by centre, radius, and sweep angle (in degrees)'. This distinguishes it from siblings like rhino_circle (no sweep angle) and rhino_ellipse (different parameters).
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 arcs with the given parameters but provides no explicit guidance on when to use this vs alternatives like rhino_circle, rhino_helix, or other curve tools. No when-not or alternative tools are mentioned.
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 description adds minimal behavioral context beyond 'generate'. It does not mention side effects, undo behavior, or performance, but it does specify the output is 'section ribs'.
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, focused sentence that conveys the core purpose and a key constraint ('bridge only') with no wasted words.
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 7 parameters and an output schema, the description is too minimal. It omits details like what the generated ribs are (curves, geometry) and how parameters affect the output. The existence of an output schema partially compensates, but the description could be more informative.
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 adds no parameter information. Several parameters (layer, count_a, count_b) lack descriptions in the schema. The description could clarify their role 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 'generate two orthogonal sets of section ribs' with specific qualifiers ('waffle-style fabrication, bridge only'), providing a distinct purpose that differentiates it from siblings like rhino_section or rhino_contour.
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 phrase 'bridge only' hints at a specific use case, but there is no explicit guidance on when to use this tool versus alternatives (e.g., rhino_section_at_axis) or when not to use 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?
The description adds minimal behavioral context beyond the annotation `destructiveHint: true`. It does not clarify whether the PropertySet itself is removed or just its properties, nor does it address reversibility, undo, or side effects. The ambiguity reduces usefulness for safe invocation.
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 conveys the core purpose without extraneous words. It is front-loaded and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 descriptive parameter properties, the description is nearly complete. However, it omits important context for a destructive operation, such as confirmation behavior or impact on related data, leaving minor 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 description does not add parameter-level meaning, but the input schema provides full descriptions for doc_id, object_id, and pset_name (100% coverage). Since the schema already handles parameter semantics, the description's lack of additional detail is acceptable.
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 (remove), the resource (every property under a named PropertySet), and the target (an object). It effectively differentiates from sibling tools like rhino_bim_pset_get and rhino_bim_pset_set, which are get/set operations.
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 lacks explicit guidance on when to use this tool versus alternatives, such as when to delete a PropertySet versus using get or set. No usage context or preconditions are provided, leaving the agent to infer based solely on the action 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 indicate readOnlyHint=false. The description adds that the operation replaces geometry and propagates to instances, which is consistent and provides context beyond the annotation. However, it does not detail potential destructive effects or prerequisites.
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, 14 words, which is concise and front-loaded with the core purpose. It could be slightly expanded without harming conciseness to cover parameters.
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 sub-parameters and multiple sibling block tools, the description lacks crucial details like block existence requirement, object_ids role, and base_point usage. Output schema exists, but the description is still insufficient 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 0%; the tool description provides no parameter explanations. The agent gets no help understanding the meaning of 'name', 'object_ids', 'base_point', or 'doc_id' beyond the schema structure.
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 ('Replace'), identifies the resource ('block definition's geometry'), and notes propagation to instances. It distinguishes itself from sibling tools like block_define, block_insert, etc., by including '(bridge 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?
The description implies usage for redefining block geometry, but it does not explicitly state when to avoid this tool or mention alternatives (e.g., block_define for new blocks). The guidance is implied 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 declare readOnlyHint=true, and the description adds the 'bridge required' context. However, no further behavioral traits like auth, rate limits, or side effects are disclosed. Minor 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?
Single sentence with clear front-loaded action and constraint. No wasted words.
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 analysis tool with an output schema, the description provides the essential constraint (bridge required). Could elaborate on what 'bridge required' entails, but overall adequate.
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 ~50% (doc_id has a description, object_id does not). The tool description adds no parameter-level information. Baseline 3 is appropriate as description does not 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 it computes draft angles relative to world Z axis, a specific verb-resource pair. Among siblings, no other tool computes draft angles, so it is well-distinguished.
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. The 'bridge required' note is a prerequisite but does not help select among sibling analysis tools.
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, confirming it's a write operation. However, the description does not explain what is created (surface, solid, brep), what the return value is, or any side effects. This is inadequate for a tool with no rich 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?
One concise sentence of 10 words, front-loaded with the key action and parameters. No wasted words.
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 fails to mention return values, the effect of optional parameters like 'capped', 'name', or 'layer', and does not address the complexity of the tool. A more complete description would include what the tool produces and its behavior with default settings.
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?
Schema description coverage is 0%, so the description carries the burden. It ties the parameters 'distance' and 'direction' to the operation, adding meaning beyond the schema that only lists them as required. However, it omits details like units for distance or coordinate system for direction.
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 (linearly extrude), the resource (profile curve), and the key parameters (distance and direction). It distinguishes from sibling tools like revolve or sweep by specifying 'linear' extrusion.
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 guidance on when to use this tool vs alternatives (e.g., revolved or swept extrusions). Usage context is implied but not stated; prerequisites like curve must be planar or closed are missing.
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 (mutation). The description adds the bridge requirement but no further details on side effects (e.g., overwriting, merging) or required permissions.
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 unnecessary words. It is front-loaded 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 description covers the core action and an output schema exists, it lacks details like supported file formats, error behavior, and prerequisites beyond the bridge note. Adequate but not thorough.
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 does not explain any parameters (path, doc_id, object_ids) or their roles, leaving the agent without guidance on required inputs.
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 'import' and the resource 'external file into the active document'. It distinguishes from siblings by mentioning the bridge requirement for non-3DM files.
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 (bridge for non-3DM) but does not explicitly compare to alternative import tools (e.g., rhino_import_ifc) or state when to use this tool versus others.
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 destructiveHint=true, and the description confirms deletion while adding a crucial nuance: in standalone mode the layer is hidden and name-prefixed. This goes beyond annotations, though only one extra detail is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence conveying the essential purpose and a key behavioral detail without any 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?
The description covers the primary action and a special-case behavior, but for a destructive tool it lacks details on side effects, confirmation, or expected output. An output schema exists but is not referenced.
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%, yet the description only mentions 'by name' without explaining the 'name' parameter format or the optional 'doc_id'. No meaning is added beyond the schema's bare structure.
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 ('Delete') and resource ('layer'), specifies the selection method ('by name'), and adds a behavioral note about standalone mode. This distinguishes it from sibling tools like rhino_layer_create.
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 on when to use this tool versus alternatives (e.g., hiding a layer). The standalone mode note is a behavioral detail, not usage 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?
Annotations already indicate readOnlyHint=false, so the write nature is known. The description adds that offsetting occurs along the normal, but lacks details on side effects (e.g., whether original surface is modified), authorization needs, 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, clear sentence with no wasted words. It is appropriately sized for a straightforward 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?
The description covers the core operation but omits contextual details such as whether the tool returns a new surface ID (output schema exists but not described). Given the tool's moderate complexity and presence of an output schema, more completeness would be beneficial.
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 0% schema description coverage, the description must compensate for parameter meanings. It only explains the 'distance' parameter, leaving surface_id, tolerance, name, layer, and doc_id completely unexplained. This is insufficient for an agent to correctly use all parameters.
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 (offset), the object (surface), and the key parameter (distance). It distinguishes this tool from other surface operations like extrude or revolve by specifying the unique operation of offsetting along the normal.
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 usage scenario (creating an offset surface) but does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The agent must infer the context from the tool 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 indicate readOnlyHint=false, so the description's mention of 'Add' is consistent. However, it does not disclose additional behavioral details such as default layer handling, object naming, or that the output is a polyline object. The schema provides some details, but the description adds minimal extra 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, front-loaded sentence with no superfluous words. It efficiently conveys the core purpose and place of the rectangle.
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 (required corner, width, height; optional name/layer) and the fact that the description provides none of these details, it is incomplete. The agent must rely entirely on the schema, which is adequate but the description should offer minimal guidance on required inputs or typical usage scenarios.
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 explain any parameters; all parameter documentation is in the input schema, which has high coverage (each property described). Since schema descriptions are already detailed, the description adds no additional parameter semantics beyond the baseline expected 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 'Add' and resource 'rectangle as a closed polyline on the XY plane'. It is specific and distinguishes itself from sibling geometry tools like rhino_line, rhino_circle, etc.
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 2D rectangle use case by specifying 'on the XY plane', but does not explicitly state when to use this tool versus alternatives (e.g., rhino_polyline for manual rectangles, rhino_box for 3D). No exclusions or alternative recommendations are provided.
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?
Beyond annotations (readOnlyHint), the description discloses the algorithm: sampling time range, ray casting, counting lit samples, and returning a 0-1 ratio. It also notes the 'bridge only' constraint. This provides useful behavioral insight, though it could mention performance or assumptions.
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?
Extremely concise: two sentences. First sentence states purpose directly; second sentence explains the method. No filler, well front-loaded, and every sentence adds value.
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 it explains the algorithm and return value, the description is incomplete given low schema coverage and 9 parameters. It does not cover parameter semantics, constraints (e.g., only bridge), or how the time range and location affect results. An output schema exists but is not shown; description could be more helpful.
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 coverage is low (<50%) with only 3 of 9 parameters having descriptions. The description does not explain any parameter meaning beyond the high-level algorithm. It fails to compensate for undocumented parameters like latitude, longitude, hour_range, and step_minutes, which are critical for use.
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: 'Estimate cumulative solar exposure (lit minutes / total minutes) on an object (bridge only).' It specifies the verb (estimate), resource (solar exposure on an object), and scope (bridge only), effectively distinguishing it from sibling tools like sun position or shadow projection.
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. The description does not mention prerequisites, when it is appropriate (e.g., need for a bridge object), or why other solar tools might be better suited. With many sibling tools, explicit context would help.
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 discloses that the tool modifies the document by drawing polylines and mentions the two modes, which adds value beyond the readOnlyHint=false annotation. However, it lacks details on side effects (e.g., overwriting previous paths), performance, or required document state.
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 long, front-loaded with the core action, and contains no unnecessary words. Every sentence earns its place by describing the primary function and the two modes.
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 description covers the high-level behavior and modes, it omits details about the output (even though an output schema exists) and does not explain how parameters like months or hours affect the result. Given the moderate complexity of the nested input schema, more guidance would be helpful for complete understanding.
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 briefly references the center_point parameter in backticks without explaining it. The description does not compensate for the lack of parameter descriptions in the schema, leaving key parameters like months, radius, and latitude unexplained.
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 it draws monthly sun-path polylines on a hemisphere around a center point. It distinguishes itself from siblings like rhino_sun_position by focusing on drawing paths rather than calculating position, and it mentions two operational modes (standalone vs bridge).
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 explains the two modes but does not provide explicit guidance on when to use this tool versus alternatives like rhino_sun_position. No exclusions or prerequisites are mentioned, so usage context 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, confirming safe read operation. The description adds value by specifying that it reads three tolerance types (absolute, angle, relative), which is not captured in annotations. No behavioral traits beyond this are needed for a simple read 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 sentence of 6 words, front-loading the key action and resource. Every word is necessary, and 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 tool's simplicity (one optional parameter with default, readOnly annotation, and an output schema to document return values), the description adequately defines the scope. No additional context is needed for an agent to invoke 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?
Schema description coverage is 0%, meaning the description must compensate for parameter documentation. However, the description adds no information about the single parameter 'args' or its sub-property 'doc_id'. The schema itself includes a description for doc_id, but the tool description fails to clarify its purpose or usage.
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 explicitly states 'Read absolute / angle / relative model tolerances', clearly identifying the verb (Read) and the resource (model tolerances) with three specific types. This distinguishes it from the sibling tool 'rhino_tolerance_set', which writes tolerances.
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 the sibling 'rhino_tolerance_set'. It lacks any mention of prerequisites, context, or exclusions, leaving the agent to 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: that output='mesh' writes a quad mesh, 'curves' writes isocurves, and 'corners' only returns points without writing geometry. This goes beyond the readOnlyHint annotation (false) by clarifying write behavior per mode. No contradictions 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 exceptionally concise: a single sentence for the main purpose, then a clear list of three output modes. No redundant words, fully front-loaded. Every sentence adds value.
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 has an output schema and multiple parameters, the description covers the core variant behaviors. It does not mention document modification side effects (writing vs returning) beyond what is implied, nor prerequisites like surface selection. Still, it provides enough context for a competent agent to use the tool 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?
The tool description succinctly explains the three output modes, which adds context to the 'output' parameter beyond its schema description. However, it does not elaborate on other parameters like count_u, count_v, surface_id, which remain solely documented in the schema. With schema descriptions already present, the description adds moderate 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 clearly states the tool samples a surface on a UV grid and emits panels. It specifies three output modes, which gives a precise understanding of the operation. However, it does not differentiate from sibling tools like rhino_panelize_surface or rhino_create_uv_grid, missing a chance to clarify its unique 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?
No guidance on when to use this tool versus alternatives. The description only explains functionality without mentioning prerequisites or exclusion criteria. For a tool with many related siblings, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals that 'available=False' indicates missing binaries and that loading such templates will fail. This adds valuable behavioral insight not captured 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 two sentences: the first clearly states the purpose, and the second adds essential nuance. No unnecessary words, front-loaded.
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 it is a read-only list tool with an output schema, the description covers the key behavior. It could be slightly more complete by hinting at the relationship to other template tools or the structure of parameter contracts, but it is largely adequate.
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 input schema has one required 'args' parameter (empty object), but the description does not clarify that no actual parameters are needed. With 0% schema description coverage, the description fails to explain the parameter's purpose or that it is a no-op wrapper.
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 action ('List bundled Grasshopper templates') and the output includes 'parameter contracts', distinguishing it from siblings like gh_load_template or gh_run_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives (e.g., gh_component_list, gh_plugin_list) or when not to use it. The description only explains the 'available=False' semantic but lacks usage context.
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 only indicate readOnlyHint=false. The description adds behavioral details beyond that, such as the distinction between standalone and bridge mode, and that bridge mode respects the active layer and links to the definition. This is valuable context not present in annotations.
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 with two sentences and front-loads the core action. However, the second sentence is somewhat technical ('Constructs a rhino3dm.InstanceReferenceGeometry') which may be less accessible.
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 complexity of the tool (multiple modes, many parameters, output schema exists), the description explains the dual mode well but lacks completeness on parameter descriptions. With output schema present, return values are covered, but parameter coverage 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?
The description only mentions insertion_point, scale, and rotation, but the schema includes many other parameters (name, layer, doc_id, instance_name, etc.). Schema description coverage is 0%, so the description should compensate, but it fails to cover the required 'name' parameter or optional ones like 'layer' and 'doc_id'.
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 'Insert' and the resource 'a block instance', and specifies key parameters (insertion_point, scale, rotation). It distinguishes from sibling tools like rhino_block_define and rhino_block_explode.
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 mentions two modes (standalone vs bridge) and gives context on bridge mode's behavior (honours active layer, links instance). However, it does not explicitly state when to use this tool versus other block tools, nor does it provide exclusions or alternatives.
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 is consistent with the readOnlyHint annotation, indicating a safe read operation. It adds that it returns object and instance counts, but does not disclose behaviors like error handling or behavior when doc_id is invalid. The annotations already cover the safety profile, so the description adds minimal extra 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, front-loaded sentence that delivers the essential information with no extraneous words. 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?
Given the tool's simplicity, the presence of an output schema, and annotations indicating read-only, the description is fairly complete. It specifies the key output but could mention the default doc_id behavior or that it lists all blocks in the current document. Still, it covers the main purpose adequately.
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 does not explain any parameters. While the input schema itself describes the doc_id parameter (default 'active'), the description fails to add value beyond that. For a tool with low coverage, the description should compensate, 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 clearly states the verb 'List', the resource 'every block definition', and the output format 'per-definition object + instance count'. It distinguishes itself from sibling tools like rhino_block_insert or rhino_block_explode.
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 listing block definitions but provides no explicit guidance on when to use this tool versus alternatives such as rhino_list_objects or rhino_layer_list. No exclusions or when-not-to-use are mentioned.
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 and idempotentHint. The description adds the specific model employed (Bird + Kasten-Young) and explicitly confirms no document modifications, which reinforces safety. No 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 succinct sentences convey the purpose, model, and key parameters. The tag line 'Pure calculation — no doc edits' is efficient. No redundant information.
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 has 6 input parameters and an output schema exists, the description lacks details on coordinate system (WGS84 assumption), timezone handling, and the meaning of the return value. The output schema compensates for return structure, but input context remains incomplete.
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 provides partial parameter context: it explains turbidity (1=very clear, 7=industrial haze) and altitude, which adds value beyond schema titles. However, it does not describe latitude, longitude, timezone, or datetime_iso format, leaving gaps despite schema defaults. Schema coverage is 0%, so compensation is only partial.
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 calculates Direct Normal Irradiance (W/m^2) using the Bird + Kasten-Young model for clear-sky conditions. It explicitly names the output metric (DNI) and differentiates from sibling tools like rhino_daylight_factor or rhino_sun_position.
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_solar_exposure_estimate. The description only notes it is a pure calculation without document edits, but does not specify prerequisites or scenarios.
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 show readOnlyHint: false, consistent with a write operation. The description adds that it creates a rectangle and sets user_text metadata, disclosing these behaviors. No contradiction found. It could mention side effects like overwriting an existing sheet with the same name, but overall good transparency.
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 short and front-loaded, getting to the point quickly. The use of backticks and a continuation line adds some formatting but overall efficient. Every sentence provides value, though it could be more structured with clearer sections.
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 complexity (multiple parameters, output schema exists), the description is adequate but has gaps. It provides context about subsequent tools re-deriving sheet properties from user_text, but doesn't mention prerequisites, return value, or behavior when a sheet name already exists. Completes the essential info but lacks some completeness.
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 carries the burden of explaining parameters. It mentions 'rectangle's corners define sheet bounds' referencing origin, width, height, and 'user_text holds sheet name, paper size, scale denominator' referencing name, width_mm, height_mm, scale_denominator. However, it does not fully detail each parameter's purpose, range, or defaults, leaving gaps.
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 creates a sheet container on a specific layer, carrying user_text metadata. It specifies the verb 'create' and resource 'sheet container', and the detail about layer and metadata distinguishes it from sibling tools like rhino_drawing_view_place or rhino_drawing_title_block_add.
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 as the first step for sheet creation by stating the rectangle's corners define bounds and user_text holds info for subsequent tools. However, it lacks explicit guidance on when to use versus alternatives, such as when-not or prerequisite conditions like having an active document.
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, confirming this is a write operation. The description adds that it exports to IFC files, but does not detail side effects on the document or file system beyond what annotations imply. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear and front-loaded with the primary action and supported formats. It could include a bit more context (e.g., mention that it writes to a file), but it 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?
The tool has an output schema, so return values need not be described. The description covers the core functionality and schema variants. It does not mention prerequisites like requiring an active document, but given the simplicity, it is mostly 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 detailed descriptions for all parameters (e.g., path, doc_id, schema_version). The tool description does not add extra meaning beyond that, so 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 uses a specific verb ('Export') and resource ('active document or a subset'), and clearly specifies the target formats (IFC2x3, IFC4, IFC4x3 with a bridge-only constraint). This clearly distinguishes it from sibling export tools like rhino_export_obj or rhino_export_stl.
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 IFC export but does not explicitly state when to choose this over other export tools or provide prerequisites. The 'bridge only' note for IFC4x3 is a helpful constraint, but overall guidance is minimal.
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?
The description discloses key behavioral traits beyond the annotations: the source object is preserved, the skip_origin parameter leaves the (0,0) cell untouched, and the return value is new object IDs in row-major order. This adds context beyond the readOnlyHint annotation, which correctly indicates mutation.
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 concise and well-structured: the first sentence immediately states the purpose, and the second paragraph adds critical details about return order and skip_origin. Every sentence is necessary and no extraneous information is present.
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 core functionality, return value format, and a key parameter nuance (skip_origin). It does not explain the coordinate system or how base_point relates to the grid, but the input schema partially covers this. Given the presence of an output schema, the description is sufficiently complete for an array creation tool.
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?
Although the input schema includes descriptions for parameters, the tool description adds value by explaining the row-major return order and the effect of skip_origin. This contextual information helps the agent understand the grid layout and return structure beyond what the schema provides.
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 that the tool replicates a source object in a grid defined by count_x, count_y, and spacing. The verb 'replicate' and resource 'source object' are specific. However, it does not differentiate itself from similar sibling tools like rhino_array_rectangular, which may also array objects in a grid.
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_array_rectangular, rhino_array_linear, or rhino_scatter. Users must infer from the tool name and description; no explicit when-to-use or when-not-to-use advice is given.
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?
The description discloses key behavioral traits beyond annotations: it explicitly states that the input is replaced ('the input is replaced'), describes the smoothing algorithm mathematically, and explains the effect of pin_endpoints. This adds significant context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single introductory sentence, a formula, and one behavioral note. No extraneous words. Front-loaded with purpose, then details. Perfect structure for quick parsing.
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 input, algorithm, parameter interactions, output (object_id), and mutation behavior. It lacks error handling or edge case discussion (e.g., invalid curve_id) but is sufficient for a standard smoothing operation.
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 adds the mathematical formula linking factor and iterations, which is not in the schema. Although the schema already describes doc_id, factor, and pin_endpoints, the description provides deeper insight into their joint behavior. It partially compensates for missing iteration's schema description.
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 'Apply Laplacian smoothing to a polyline (or NURBS curve via its control points)', which is specific and directly conveys the tool's purpose. However, it does not differentiate from sibling tools like rhino_rebuild_curve that also modify curves, missing explicit when-to-use guidance.
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 guidelines are provided. The description does not mention when to use this tool over alternatives (e.g., rhino_rebuild_curve or rhino_interpolate_curve), nor does it list prerequisites or constraints such as performance considerations.
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, so description carries some burden. It discloses the tool zooms the active viewport to fit objects exactly, which implies a view modification. Beyond annotations, it adds the 'exactly fitting' detail but does not discuss side effects, permission needs, or error 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?
The description is a single, concise sentence with no wasted words. It front-loads the essential action and target efficiently.
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 zoom-to-objects tool, the description covers the core functionality. It could mention error handling or that object_ids must exist, but given the tool's simplicity and the presence of an output schema, it is largely 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%, so description must compensate. The description only mentions 'given object ids' without explaining the format, the doc_id parameter (default 'active'), or constraints like max 500 items. The schema itself has minimal descriptions, leaving the agent with gaps.
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 'active viewport', and the target 'given object ids exactly'. It is specific about the action and distinguishes from siblings like rhino_zoom_extent or rhino_zoom_layer by focusing on specific objects.
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 says to zoom to object ids but does not provide explicit guidance on when to use this tool vs alternatives like rhino_zoom_extent or rhino_zoom_layer. There is no mention of prerequisites or exclusions, relying on 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 indicate readOnlyHint=true. The description adds detail about the summary content (object counts, layers) but does not disclose additional behavioral traits like performance or limitations. 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?
Single sentence that is direct and front-loaded. No extraneous words. Efficiently communicates the tool's core 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 description covers the tool's purpose and output type. An output schema exists, so return value details are not needed. For a simple read-only tool, this is adequate but could mention key limitations.
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's doc_id parameter already includes a description ('active' targets current document). The tool description adds no parameter info. With one parameter and schema coverage likely high, 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 clearly states it gets a high-level summary of the document with specific examples like object counts and layers. This distinguishes it from siblings such as rhino_layer_list or rhino_list_objects.
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 tool is for high-level document info but does not explicitly state when to use it versus similar tools or exclude alternatives. No guidance on prerequisites or context.
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, so the description adds value by specifying the returned data (point, normal, tangents). No contradictions. The description provides 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?
Single sentence, no redundancy, front-loaded with verb and resource. 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?
Description omits prerequisites (e.g., surface must exist, object_id validity, UV domain bounds). While output schema may cover return values, usage context is incomplete for a read-only evaluation 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%. Description mentions 'UV parameters' but does not explain the parameters u, v, or object_id. It partially adds meaning by implying u and v are coordinates, but does not compensate for the lack of schema 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?
Description clearly states verb 'evaluate', resource 'surface', inputs 'UV parameters', and outputs '3D point, normal, and tangents'. It distinguishes from sibling tools like rhino_surface_normal_at and rhino_surface_curvature_at by specifying all three outputs.
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?
Usage is implied by the description (when you need point, normal, tangents from UV), but no explicit when-not or alternatives are provided, despite multiple sibling tools with overlapping purposes.
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 the description adds behavioral details about what the tool returns: 'full signatures, parameter descriptions, return values, and optional code examples.' This supplements the annotation well, though it omits potential failure modes or rate limits.
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 with three short sentences, each serving a distinct purpose: defining the action, giving a critical usage rule, and listing return contents. No unnecessary words or 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?
The description is adequate for a documentation-lookup tool with an output schema, mentioning return types and a critical prerequisite. However, it does not mention the configurable parameters (max_functions, include_examples) despite their existence, leaving a gap for the agent to know customization options.
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 missing parameter details. The tool description only mentions 'topic' implicitly but does not explain the meaning or usage of any parameters (topic, max_functions, include_examples). The existing schema descriptions are not considered as per coverage metric, so no additional value is provided.
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 retrieves 'comprehensive RhinoScript documentation for a topic,' with a specific verb and resource. It distinguishes from siblings like rhino_search_rhinoscript_functions by focusing on topic-based lookup and explicitly requiring usage before rhino_execute_python, making its role unique.
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 provides explicit guidance by stating 'You MUST call this tool before using rhino_execute_python,' which is a strong usage rule. However, it does not mention alternatives or when not to use it, leaving some context unaddressed.
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 readOnlyHint annotation already indicates this is a read operation. The description is consistent but adds no additional behavioral context (e.g., potential performance with many layers, handling of empty documents).
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 efficiently conveys the tool's purpose and outputs. No redundant or extraneous information.
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 list operation with a well-documented parameter and supporting output schema, the description is reasonably complete. It could mention the return format (e.g., array of layers) or behavior for empty documents, but it is sufficient.
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 'doc_id' is well-described in the schema ('active' targets current document). The tool description does not add any additional semantic value beyond what the schema provides.
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 (List) and the resource (all layers) with specific properties (color, visibility, object count). This distinguishes it clearly from sibling tools like rhino_layer_create or rhino_layer_delete.
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 provide explicit guidance on when to use this tool versus alternatives. It lacks context about why one would list layers (e.g., before modifying) and does not mention any prerequisites or limitations.
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 and idempotentHint=true, so the safety profile is clear. The description adds only the qualifier 'recent' without elaboration on ordering or limits, providing minimal behavioral context 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 sentence of 6 words, front-loaded with the key action and resource. Every word adds value, making it exceptionally concise.
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 list tool with no parameters and an output schema, the description is nearly complete. It could briefly mention the output format (e.g., list of jobs with progress), but the core purpose is clear.
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 input schema defines a single parameter 'args' which is an empty object, so there are effectively no meaningful parameters to describe. With zero effective parameters, a baseline of 4 is appropriate, though the description could note that no arguments are needed.
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', the resource 'render jobs', and the additional detail 'their progress'. This unambiguously defines the tool's purpose and distinguishes it from siblings like rhino_render_queue_submit or rhino_render_queue_cancel.
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 tool is for viewing render jobs, but does not explicitly state when to use it over siblings like rhino_render_queue_status, which may also provide progress information. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so the agent knows it's a write operation. The description adds that the source sits at level 0 and copies populate levels 1..floor_count, but does not disclose whether the source is modified, if the operation is destructive, or if it requires specific permissions. Minimal behavioral context beyond the annotation.
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?
Description is two sentences with a line break, front-loaded with the action and constraints. Every sentence provides essential information with no wasted words.
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 has 5 parameters and a specific stacking behavior. The description covers the core logic and spatial relationship. It does not mention naming conventions (name_prefix) or return values, but output schema exists and schema covers naming. Given the tool's simplicity, it is nearly complete.
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?
Schema description coverage is 0%, meaning the description does not reiterate parameter details. However, the description provides valuable context: it clarifies the counting (source at level 0, copies at 1..floor_count) and that spacing is constant. This adds meaning beyond the schema descriptions which already document each 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?
Description clearly states 'Replicate a source object N times along world +Z with constant spacing' and adds the architectural metaphor 'stack this slab N floors high'. It uses specific verb 'replicate' and resource 'object', and distinguishes from siblings like rhino_array_linear by specifying the world Z direction and constant spacing.
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 stacking floors vertically with constant spacing, but does not explicitly state when to use this tool versus alternatives (e.g., rhino_array_linear). No exclusions or alternative suggestions are provided, though the metaphor implies a specific architectural use case.
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, which the description does not contradict. Description adds valuable behavioral details: checks for validity, solidity, manifold, counts, and logs issues, plus bridge mode adds naked-edge info. Does not cover rate limits or permissions, but these are less critical for a read-only 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 concise sentences with no fluff. First sentence clearly states the tool's purpose and scope; second sentence details modes without redundancy.
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 (single object parameter) and presence of an output schema, the description covers key validation aspects and mode distinction. Minor omission: no guidance on when to use standalone vs bridge mode.
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?
Input schema already provides descriptions for both parameters (doc_id and object_id), so the description adds no extra semantic value. Although schema coverage is reported as 0%, actual schema has descriptions, so baseline score 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?
Description clearly states it validates a Brep, checking closed/solid/manifold status and face/edge counts. It distinguishes between standalone and bridge modes, but does not explicitly differentiate from sibling tools like `rhino_check_naked_edges` or `rhino_object_info`.
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 validation of a Brep is needed but provides no when-to-use/when-not-to-use guidance, no mention of prerequisites, and does not compare to alternative tools.
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 truthfully describes the action and its effect on the viewport. Annotations only have readOnlyHint: false, which is consistent with changing the view. No hidden side effects or behavioral details beyond the stated purpose are needed for this simple 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?
Single sentence of 10 words, front-loaded with action and resource. No redundancy or unnecessary text.
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?
Description is sufficient for a simple zoom tool. It specifies the viewport and the layer scope. Schema covers parameter details, and output schema exists. Minor missing information: behavior when layer has no objects or does not exist, but not critical for agent 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?
Description does not mention parameters. Input schema provides descriptions for both parameters (layer: 'Full layer path.', doc_id: 'Document handle id; active targets the current document'). Schema covers parameter meaning, 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?
Description clearly states action (zoom), resource (active viewport), and scope (fit every object on a given layer). It distinguishes itself from sibling tools like rhino_zoom_extent and rhino_zoom_object by specifying layer-based zooming.
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. Does not mention when to prefer this over rhino_zoom_extent or rhino_zoom_object, nor any prerequisites or limitations.
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, indicating a read operation. The description adds value by specifying 'multiple component outputs' and 'single bridge round-trip,' which implies efficiency and batching. This contextualizes the behavior beyond the annotation alone.
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 tool's purpose and key trait (batching). No wasted words; it is appropriately front-loaded.
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 (not shown), the description does not need to explain return values. It mentions batching and round-trip efficiency, which is sufficient context for a read tool. However, it could benefit from noting that the input is a batch of component output requests.
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 itself provides no parameter descriptions. The description does not elaborate on the parameters (e.g., what 'queries' or 'component_id' mean), leaving the agent to rely solely on the schema structure. This is a significant 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 clearly states 'Read multiple component outputs in a single bridge round-trip,' which specifies the verb (Read), resource (component outputs), and batching behavior. This distinguishes it from sibling tools like gh_data_tree_get (single read) and gh_data_tree_set (write).
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 batch reading, but it does not explicitly state when to use this tool vs gh_data_tree_get (single read) or gh_data_tree_set (write). No alternatives or exclusions are mentioned, leaving the agent to infer context 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only show readOnlyHint=false. The description adds context that the GH document is paused during assignments and recomputed once, and explains the defer_solve flag. This provides behavioral insight beyond the annotation.
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 paragraphs, front-loaded with purpose, then explains the key defer_solve behavior. It is efficient but could be slightly tighter; still earns its keep.
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 complexity (batch assignments with nested schema), the description covers the core behavioral intent and critical performance context. Output schema exists to explain return values, so completeness is adequate.
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 does not explain parameters. While the schema itself has detailed descriptions for nested objects, the tool description adds little to parameter understanding beyond mentioning defer_solve.
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 applies many DataTree assignments with a single GH solve, specifying the verb 'Apply' and resource 'DataTree assignments'. It does not explicitly differentiate from sibling tools like 'gh_data_tree_set', but the batch nature is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the critical use case of parameter sweeps, where N independent set calls would trigger N solver runs, and explains when to use the tool to avoid that. It also explains the default defer_solve behavior.
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 indicate readOnly and idempotent. The description adds details about the returned fields (pid, host, port, etc.) and the use of announcement files, providing context beyond the annotations without 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 two sentences: one for purpose and one for output fields. It is front-loaded and every sentence adds value.
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 has an output schema and annotations cover safety, the description is adequately complete. It explains what the tool does and what it returns, though parameter details are left to the schema.
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 adds no information about the parameters. Although the schema itself has descriptions for probe_timeout and stale_cleanup, the tool description does not compensate for the low coverage, offering no parameter guidance in the text.
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 enumerates live Rhino bridge endpoints. It distinguishes itself from the sibling rhino_bridge_select_instance by focusing on listing all instances.
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 getting running Rhino instances on the host, but does not explicitly state when to use this versus other tools or provide any exclusions or alternatives.
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?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds that hits are sorted by distance and that it is bridge-only. This provides useful behavioral context 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 three sentences that efficiently convey the core purpose, sorting behavior, and environment limitation. No wasted words.
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 existence of an output schema, the description does not need to detail return values. It covers main points: ray casting, sorting, and bridge limitation. However, it could mention document targeting or filtering via object_ids.
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% (low), so the description must compensate for parameter meaning, but it does not mention any parameters. The schema itself has descriptions, but the tool description adds no value for 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 tool's verb ('Cast a ray') and resource ('against Breps/Extrusions'). It is specific and distinct from sibling tools, which are mostly creation/editing operations.
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 provides context by stating 'Bridge-only — rhino3dm has no ray-shoot primitive,' indicating when this tool is appropriate. However, it does not explicitly list when to use or alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it returns a 'job_id' immediately, frames are captured on a background worker, and the backend uses '_-ViewCaptureToFile' with true photo-realistic engine on the roadmap. Annotations only indicate readOnlyHint=false and title. No contradictions.
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, around 4 sentences, and front-loads the main purpose. However, the formatting with indentation and line breaks feels slightly informal. Every sentence adds value, with no unnecessary words.
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 complexity (nested schema, background worker, polling pattern), the description covers submission, immediate return, polling, cancellation, and backend limitation. It lacks explicit mention of prerequisites (e.g., bridge setup), error handling, or the output schema (which exists but not described). An output schema is present, so return values need not be detailed, but overall completeness is adequate but not thorough.
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?
Input schema has 0% description coverage for top-level parameters per context signals. The description mentions 'frame sequence' but does not explain the nested structure (frames array) or any parameters. The schema does provide some nested property descriptions, but the description adds minimal value for parameter meaning.
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 'Submit a frame sequence to the bridge render queue', specifying the verb (submit) and resource (frame sequence to bridge render queue). It explicitly notes 'bridge only', distinguishing it from other render tools. The mention of polling and cancellation tools further clarifies 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using 'rhino_render_queue_status' to poll progress and 'rhino_render_queue_cancel' to interrupt, providing explicit guidance on related tools. However, it does not explicitly state when not to use this tool or compare with direct render alternatives like 'rhino_render_to_file'.
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?
The description adds context beyond the readOnlyHint annotation by detailing the return structure (rows and totals) and mentioning optional filters. 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 extremely concise with two sentences, front-loading the main action and including the return format. Every sentence adds value without 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?
Given the tool's complexity (filtering, sublayer merging) and the presence of an output schema, the description is minimal but adequate. It could mention the computed fields or provide more usage context.
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 100% (all parameters have clear descriptions in the schema). The tool description adds no additional parameter information, so 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 clearly states the tool aggregates objects per layer, mentions optional filtering and sublayer merging, and specifies the return format. It distinguishes from sibling scheduling tools by focusing on layers.
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 aggregating objects by layer but does not explicitly state when to use or avoid this tool compared to siblings like rhino_schedule_by_user_text or rhino_schedule_by_material.
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 agent knows the tool is safe and idempotent. The description adds 'no doc edits', reinforcing safety but not providing additional behavioral context beyond what annotations offer. No 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?
The description is a single, focused sentence with no fluff. It communicates the core purpose and a key behavioral trait efficiently.
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 the tool's straightforward nature, the description adequately covers the core functionality. It names the outputs (azimuth+altitude) and clarifies the non-modifying behavior, which is sufficient for a simple calculation tool among many siblings.
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 input schema has 0% description coverage, and the description does not explain any parameter semantics (e.g., meaning of azimuth/altitude, coordinate system, or units). While parameters like latitude and datetime_iso are somewhat self-explanatory, the description fails to add value 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 tool computes solar azimuth and altitude for a given location and time. The phrase 'Pure calculation, no doc edits' distinguishes it from sibling tools that might modify documents or perform more complex analyses like sun path or shadow projection.
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 implies usage for simple sun position queries and explicitly states it is a pure calculation with no document edits, which guides safe use. However, it does not explicitly mention when not to use it or suggest alternative tools for more advanced solar analysis.
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 context beyond annotations: states the label always faces the camera, which is a key trait not captured by readOnlyHint=false.
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 is highly concise and front-loaded, with no wasted words.
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, the description is adequate but missing details about the created object (e.g., it becomes a Rhino text dot object).
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 0% schema description coverage, the description adds no parameter info. The schema itself has some descriptions but the tool description does not explain what parameters like text, location, name, etc. do.
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?
Description clearly states the tool adds a text dot that always faces the camera, distinguishing it from other annotation tools like rhino_text or rhino_leader.
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?
Description implies use for creating camera-facing labels but provides no explicit when-to-use or alternatives compared to sibling tools.
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 indicate readOnlyHint and idempotentHint. The description adds that it only works on closed meshes and that Brep volume requires a bridge, providing behavioral constraints 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.
Conciseness4/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 purpose. Could be slightly expanded for parameter hints, but remains 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?
Given the presence of an output schema, the description adequately states the core function and a key constraint. However, it does not explicitly clarify that the input must be a mesh object id, which is crucial for correct 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 does not mention any parameters (doc_id, object_id) despite low schema parameter description coverage (0% as per context). It fails to add meaning beyond the schema, missing an opportunity to clarify the input requirements.
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 'Compute', the resource 'volume', and the target object type 'closed mesh'. It also mentions the Brep requirement for bridge, distinguishing it from potential Brep volume 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 implicitly guides use by specifying 'closed mesh' and noting that Brep volume requires a bridge add-on, providing context on when to use this tool. However, it does not explicitly name alternative tools or state when not to use it.
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, so the read-only nature is known. The description adds value by specifying that a bridge is required, which is a behavioral constraint beyond what annotations provide. No 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?
A single sentence with a parenthetical note. No wasted words; the information is front-loaded and direct. Every part 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?
Given the tool's simplicity, an output schema exists, and annotations cover read-only status. The description covers the purpose and a key prerequisite. It could mention that it analyzes surface continuity, but that is implicit. Overall, it is mostly complete for a straightforward analysis 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% per context, meaning the description must compensate. However, the description does not mention the parameters (doc_id, object_id) or their purpose. The schema itself has a description for doc_id but not object_id, leaving the agent without clarity on what the required parameter 'object_id' refers to.
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 ('run'), the specific resource ('zebra-stripe surface continuity analysis'), and a prerequisite ('bridge required'). It distinguishes this tool from sibling tools like rhino_curve_continuity or rhino_curvature_analysis by its specific focus on surface continuity via zebra stripes.
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 implicitly indicates when to use (for surface continuity analysis) and provides a prerequisite ('bridge required'), but it does not explicitly compare with alternatives or state when not to use. Sibling tools exist for other analysis types, but no direct guidance is given.
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 destructiveHint=true. The description adds specificity ('clear cached solution'), which aligns with the destructive hint and provides additional context beyond the annotation.
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, no wasted words, front-loaded with action. Perfectly concise for a tool with no parameters.
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 no parameters and an existing output schema, the description is sufficiently complete. It explains the tool's purpose. A 5 might require mention of side effects or what happens to the canvas state.
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?
No parameters exist, so the description does not need to elaborate parameter semantics. The baseline score of 4 applies per the rubric for zero parameters.
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?
Description clearly states the action ('Reset') and the resource ('canvas') with explicit parenthetical detail ('clear cached solution'). This differentiates it from siblings like 'gh_new_canvas' or 'gh_run'.
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 vs. alternatives like saving and reloading, or when not to use it. The description only states what it does, not the context of use.
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 discloses that changes are wrapped in one undo record and explains apply_to_all behavior. However, it does not mention that modifications are destructive, what happens to unmodified properties, or any permissions/performance considerations. Annotations provide no additional behavioral hints.
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 three concise sentences, front-loading the main purpose and key behavior. No unnecessary words, and each sentence adds value: purpose, undo feature, apply_to_all special case.
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 aspects: batch operation, modifiable properties, undo behavior, and apply_to_all mode. It does not explain return value, but an output schema exists. Missing details like error handling or maximum objects (implied by schema maxItems) are not critical. Fairly complete for a batch 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 description lists the fields that can be modified in each spec (translation, rotation, etc.) and explains the apply_to_all flag. However, with schema description coverage at 0%, the description does not delve into the semantics of each parameter (e.g., coordinate units, scaling bounds). The schema itself contains descriptions, but the coverage metric suggests they are not counted.
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 it modifies many objects in a single call, lists the modifiable properties (translation, rotation, scale, colour, layer, visibility, name), and distinguishes from single-object modification tools by emphasizing batch operation and undo encapsulation.
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 implies use for multiple objects and explains the apply_to_all mode, but does not explicitly state when to prefer this tool over single-object alternatives like rhino_move or rhino_rotate. The context of siblings makes it clear, but no direct guidance is provided.
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, so the description adds value by listing specific checks (span count, closed flag, planarity, etc.) beyond the basic safety profile. It does not contradict annotations. No side effects are mentioned, but that is consistent with a read-only 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?
Extremely concise single sentence that packs essential information (purpose and key properties). No wasted words; perfectly sized for quick 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?
Given that an output schema exists and annotations are provided (readOnlyHint), the description is largely complete. It mentions what the tool checks, which is sufficient for a validation tool. Could optionally mention that it returns a report, but output schema covers that.
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 add meaning beyond what the input schema already provides. Schema descriptions for 'doc_id' and 'object_id' are present, covering the parameters. The tool description adds no further semantics, so 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 clearly states the tool's purpose: checking curve sanity (span count, closed flag, planarity, periodic, validity log). It uses specific verb+resource and distinguishes from sibling tools like rhino_curve_length or rhino_curve_split which perform different operations on 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?
No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, the description does not mention prerequisites, limitations, or when not to use it. Implies usage for curve validation but lacks comparative context.
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 indicate a write operation (readOnlyHint=false). The description adds that each entity is mapped to a layer under target_layer_root and that import is 'bridge only', providing behavioral context beyond annotations. No 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?
Single sentence with no filler. Every word adds value: action, resource, mapping rule, and constraint. Properly front-loaded.
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?
Covers the core purpose and a key behavioral nuance (bridge only, layer mapping). With an output schema present, return values need not be described. Minor gap: no mention of optional parameters (filter_by_type, doc_id) or error handling.
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 descriptions cover all parameters with adequate detail. The tool description mentions target_layer_root but adds no new meaning beyond the schema's description. 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?
Clearly states 'Import an IFC file' with a specific verb and resource, and adds detail about entity-to-layer mapping. The '(bridge only)' suffix distinguishes it from sibling import tools like rhino_import.
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?
Implied usage from name and description, but no explicit guidance on when to use this tool versus alternatives (e.g., rhino_import, rhino_export_ifc). The 'bridge only' hint provides limited context but no direct comparisons.
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 mutation (readOnlyHint=false), and the description adds valuable behavioral context: standalone mode marks objects with a user-string, bridge mode delegates to Rhino's native selection, and deselect_first (default true) clears existing selection. No contradictions with annotations, and additional details enhance 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 very concise, using only a few sentences to convey the core functionality, filter logic, and modes. Every sentence serves a purpose with no fluff, and the main action 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's complexity (multiple filters, two modes, default behavior), the description covers all key aspects: AND semantics, short-circuiting, standalone vs bridge, and the deselect_first default. An output schema exists, so return values need no explanation. The description is fully sufficient for an agent to use the tool 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?
Each parameter in the schema has a description, so baseline is 3. The description adds value by explaining filter interaction (AND semantics) and short-circuiting behavior of object_ids, which is beyond what the schema provides. Thus, a 4 is warranted.
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 'Select objects by ID and/or attribute filters,' specifying the verb and resource. It also explains filter semantics and modes, but does not explicitly distinguish from sibling tools like rhino_list_objects or rhino_object_delete, so a 4 is appropriate.
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 by detailing filter combination (AND) and short-circuiting with object_ids, and mentions standalone vs bridge modes. However, it does not explicitly state when to use this tool over alternatives, nor provide when-not-to-use guidance, resulting in an implied usage score of 3.
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?
With minimal annotations (readOnlyHint=false), the description adds value by disclosing the inline base64 option and that the PNG is written to path. No contradictions found.
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 concise, two sentences with a clear structure. Every sentence adds value without fluff.
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 has an output schema (not shown), the description appropriately covers the key behavioral aspects (base64 and file output). Minor gap: no explanation of 'bridge' but acceptable for a screenshot 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?
Schema description coverage is 0%, but the description indirectly references 'as_base64' and 'path'. However, the input schema already provides detailed parameter descriptions, 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 tool captures a viewport screenshot, with specific verb 'Capture' and resource 'viewport screenshot'. It distinguishes itself from sibling tools as the only screenshot-related tool.
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 mentions 'bridge required' as a prerequisite but does not explicitly state when to use this tool versus alternatives or provide exclusions. Usage context is implied but not fully 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 indicate write operation (readOnlyHint=false). Description adds value by explaining bridge mode behavior and text-dot fallback, beyond basic mutation info.
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 contains essential information: purpose, two modes, and fallback behavior. No wasted words.
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?
Covers purpose and usage modes well, but lacks parameter descriptions and does not mention return value. Output schema exists, so return info gap 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?
Schema has 0% description coverage, and the tool description does not explain any parameters or their roles. Meaning must be inferred from property names only.
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?
Description clearly states verb 'Add' and resource '3D text annotation', distinguishing between bridge mode and standalone. Differentiates from sibling tools like rhino_text_dot.
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?
Explicitly mentions bridge mode vs standalone behavior, guiding when to use each. Does not explicitly state alternatives or when not to use, but the context is clear enough.
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 indicate this is not read-only (readOnlyHint: false) and not idempotent. The description adds valuable behavioral context: 'no render engine is invoked, just a viewport bitmap dump,' clarifying the lightweight, non-rendered nature. 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 two sentences, front-loaded with the primary action, and every sentence adds value. No redundant or fluff text.
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 covers the core functionality and distinguishes from render, but it omits details about output (output_path defaults) and transparent background. Since an output schema exists, return values may be documented there, but usage of parameters like transparent_bg is not addressed. Adequate but incomplete for a tool with multiple optional parameters.
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 adds meaning only for width/height ('Use 0 to inherit on-screen size'), but does not explain other parameters (doc_id, view_name, output_path, transparent_bg). With 0% schema description coverage, the description should compensate, but it fails to cover most parameters.
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 saves viewport pixels to PNG and explicitly positions it as a lightweight alternative to rhino_render_to_file, distinguishing it from that sibling tool. The verb 'save' and resource 'viewport pixels to PNG' 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (as an alternative to render) and provides a concrete tip for width/height. It does not explicitly mention when not to use or list all alternatives, but the context is clear enough for typical use.
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 (modifies view), and the description confirms it changes the active view. It adds context about the scope (selected or all objects) beyond what annotations provide, though it could mention potential side effects like resetting the view.
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 10 words, front-loaded with the main action and resource. No fluff or redundancy; every word 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 view zoom tool, the description covers the core function adequately. It does not need to explain return values (output schema exists). However, it could mention that it works on the active viewport only, but the current wording is clear enough.
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 clear descriptions for both parameters (doc_id and object_ids), so the description does not add new meaning. Despite 0% description coverage (as reported), the schema itself is rich, warranting a baseline of 3.
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 ('Zoom'), the resource ('active view'), and the scope ('selected (or all) objects'). It effectively distinguishes from sibling tools like rhino_zoom_object and rhino_zoom_layer by specifying the extent of all selected or all objects.
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 the goal is to zoom to the extent of selected or all objects, but it does not provide explicit guidance on when to use this tool over siblings (e.g., rhino_zoom_object for specific objects) or when not to use it.
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 (mutation), and the description adds: 'Returns a per-row results array so partial failures are visible (each row carries status and, on error, error).' This reveals important behavioral traits about batching and error reporting, going 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 extremely concise: two sentences, front-loading the purpose and adding one key behavioral detail. Every word earns its place, with no fluff.
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 complexity (batch wire addition with partial failure), the description covers purpose, batch behavior, and return structure. However, it omits the maximum batch size (200) and does not summarize the 'stop_on_error' parameter behavior. The output schema exists but the description compensates by explaining the results array.
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 mention any parameters. With schema description coverage at 0%, the description should compensate, but it fails to add meaning beyond the schema. The schema itself contains descriptions for 'stop_on_error' and 'connections', so the gap is partially filled by the schema, but the tool description should aid selection.
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: 'Add multiple wires in a single round-trip.' This is a specific verb+resource combination that distinguishes it from the sibling tool 'gh_connect_components' (which likely adds one wire). The additional detail about partial failure handling further clarifies the scope.
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 implies that this tool is for batch operations, and mentions partial failure behavior, but does not explicitly state when to use it versus alternatives like 'gh_connect_components'. It lacks when-not-to-use guidance, but the context is clear enough for most scenarios.
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 is false, consistent with the create action. The description adds value by stating the return of component_id for further operations. No 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, front-loaded with the primary action, efficient and to the point. No unnecessary words.
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 covers the core purpose and return value, but given the complexity of the input schema (7 parameters), it does not explain all options. The output schema exists but is not described, though the description mentions component_id. Incomplete for a parameter-rich 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?
Schema description coverage is 0% – the tool description does not elaborate on parameters. The schema itself provides detailed descriptions, but the tool description only vaguely mentions 'bounds and initial value,' which partially compensates but is insufficient for a multi-parameter tool.
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 creates a Number Slider with bounds and initial value, and distinguishes itself from sibling tools like gh_connect_components and gh_set_slider by mentioning that the returned component_id can be used for subsequent calls.
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 implies when to use this tool by noting that after placing the slider, you can use gh_connect_components or gh_set_slider to target it. However, it does not explicitly exclude alternative tools or state 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 indicate readOnlyHint and idempotentHint. The description adds context about returned fields and purpose, but does not reveal additional behavioral traits beyond what annotations cover. 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 concise, front-loaded with the core action, and every sentence adds value. No wasted words.
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 enumeration tool with good annotations and an output schema, the description provides adequate context: what is returned, why it is useful, and when to use it.
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 has a single required 'args' parameter of empty object type. Description does not explain the parameter, but its absence is understandable as no arguments are needed. Schema coverage is 0% but no parameter explanation is necessary.
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 it enumerates Grasshopper plugin libraries currently loaded, specifies the returned fields, and explains the use case (discovering installed plugins like LunchBox). It effectively distinguishes from many Rhino-focused 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?
Provides clear context on when to use (before attempting to drop a custom component) but does not explicitly mention alternatives or when not to use. The guidance is implicit and practical.
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 provide readOnlyHint and idempotentHint. The description adds that the tool works only on mesh objects and mentions a constraint (Brep area needs a bridge). This goes beyond what annotations convey, providing useful behavioral context without 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 sentence that is concise and front-loaded with the purpose. Every word adds value, with no wasted content.
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 (1 parameter, annotations, output schema present), the description covers the core function and a key constraint (mesh vs. Brep). It does not explain return values, but the output schema likely covers that. Overall, it is sufficient for basic 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%, so the description must compensate. However, it does not mention the input parameters (args, doc_id, object_id) or their meaning. The agent gets no guidance on how to specify the object or document, which is a significant gap given the lack of schema 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 clearly states it computes surface area of a mesh, with a verb ('compute') and resource ('area of a mesh'). It distinguishes from sibling tools like rhino_volume (volume) by specifying mesh surface area, and notes Brep area requires a different approach ('bridge').
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 explicitly says 'Brep area requires bridge', indicating this tool is for meshes only, which guides when to use it vs. alternatives. It does not provide explicit when-not-to-use guidance, but the context is clear enough for an AI agent.
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 indicate readOnlyHint=true and idempotentHint=true. The description adds value by explaining bridge vs standalone modes and grouping behavior of output (psets field). No contradictions. This extra context elevates it 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 three sentences, front-loaded with the core purpose. Each sentence adds necessary information without redundancy or fluff. Ideal conciseness.
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 presence of an output schema, the description adequately explains the tool's behavior (modes, output grouping). Annotations cover safety. Parameters are well-described in schema. No gaps for this read-only 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 input schema already provides descriptions for all parameters (doc_id, object_id, pset_name) with high coverage. The description adds mode-related context but does not significantly enhance parameter meaning. Baseline is 3 due to schema richness.
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 reads PropertySet entries from an object. It distinguishes from sibling tools like rhino_bim_pset_set and rhino_bim_pset_delete by focusing on reading. The verb 'Read' and resource 'PropertySet entries' are 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 does not explicitly state when to use this tool versus alternatives such as rhino_bim_pset_set for writing or rhino_bim_pset_delete for removing. It provides context about modes but lacks usage guidance for selection among siblings.
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?
The description adds transparent details beyond annotations: it reveals the internal call to Rhino.Geometry.Brep.GetNakedEdges and the return format (list of edge_index and length plus gap count). Annotations already mark it as read-only, 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 incredibly concise: two sentences plus a note on bridge mode. Every sentence adds value, front-loading the core action and constraints without clutter.
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 complexity, the description covers the essential: purpose, bridge-only restriction, and output format. It could mention potential errors or empty results, but the provided information is sufficient for an agent to use 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 input schema has parameter descriptions (e.g., doc_id, object_id), but the tool description does not add any extra meaning beyond what the schema provides. With 0% schema description coverage (as per context), the description should compensate but fails to do so.
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 enumerates naked edges of a Brep with lengths, specifying the bridge-only mode. It distinguishes from standalone rhino3dm's lack of capability and from sibling tools like rhino_validate_brep.
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 explains when to use (bridge mode) and that standalone cannot; however, it does not explicitly mention alternatives or when not to use, though the context of bridge-only is clear.
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?
The description discloses the bridge-only nature and the read-only material table, adding context beyond the readOnlyHint=false annotation. It explains the effect (layer-source objects inherit the material) but does not mention destructive behaviors or auth needs, which are not critical here.
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?
Extremely concise: two sentences with no unnecessary words. The main action is front-loaded, and every sentence provides essential context (bridge-only limitation, prerequisite).
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?
Provides sufficient context for a simple binding tool: explains the bridge limitation, prerequisite, and effect. No output schema is visible but inferred. Could mention return value or error cases, but adequate given simplicity.
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 adds no information about the parameters. While the schema itself has descriptions for doc_id, material_name, and material_index (including mutual exclusivity), the context indicates 0% schema coverage, so the description should compensate but fails to do so.
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 'bind' and the resource 'render material to a layer', and the phrase 'so layer-source objects inherit it' specifies the outcome. The distinct purpose is set apart from sibling layer tools (e.g., create, delete, set color).
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?
Explicitly mentions the bridge-only context, the prerequisite to use rhino_material_create first, and the limitation of the in-document material table being read-only. Provides clear when-to-use guidance, though no explicit when-not-to-use or alternative tools are mentioned.
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?
Discloses the behavioral difference between modes (metadata vs. full translation), and notes that reference mode is less disruptive. Annotations indicate readOnlyHint=false, and description adds no contradictions.
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 clear, front-loaded sentences. Efficiently explains the main purpose and both modes without extraneous text.
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?
Output schema exists, and description covers all necessary behavior for a simple tool. Provides sufficient context 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?
Schema already provides detailed parameter descriptions (e.g., mode's two options). The description adds little beyond rephrasing those options, so it does not significantly enhance understanding 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?
Clearly states 'Set the model base point' with two explicit modes. Distinguishes from sibling tools that perform other transformations (e.g., move, rotate) by focusing specifically on origin setting.
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?
Describes when to use each mode: 'reference' for metadata-only geo-referencing, 'translate' for shifting geometry. Provides clear usage context without explicitly stating 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?
Discloses that it returns matching functions sorted by relevance, which aligns with readOnlyHint annotation. No contradictions; provides behavioral 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 concise, front-loaded with purpose, and includes useful example queries. Every sentence adds value without fluff.
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 simple search functionality, annotations, and output schema existence, the description is complete with usage guidance and examples. The limit parameter omission is a minor gap but not critical for basic use.
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 given context, and the description only explains the 'query' parameter via examples but omits any reference to the 'limit' parameter. The description adds limited value for parameter understanding.
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 searches RhinoScript functions by keyword or description, and distinguishes it from sibling tools by specifying its use case for finding correct function names before writing code.
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?
Explicitly advises to use this tool before writing any RhinoScript Python code, and provides example queries. Lacks explicit when-not-to-use or alternatives, but context implies it's for discovery.
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=false, consistent with creating a north arrow. The description adds that angle_deg rotates the arrow, but does not detail other side effects. Output schema helps compensate.
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, no wasted words. The first sentence defines purpose immediately; the second adds critical parameter context. Highly 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?
The description covers the essential parameters for usage. With an output schema and self-explanatory defaults, it is fairly complete for a simple annotation tool, though it could mention style options.
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%, but the description explains location and angle_deg. The remaining 5 parameters (name, size, layer, style, doc_id) are not described, relying on defaults. Partial value added.
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 'Draw a north arrow centred on ``location``.', which is a specific verb+resource. It clearly distinguishes from sibling annotation tools like scale bar or callout.
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 explanation of angle_deg for adapting to true north vs grid north provides a clear use case. However, there is no explicit when-to-use or comparison with alternatives.
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?
The description discloses key behavioral details beyond the annotation readOnlyHint=false: it explicitly states originals are deleted and new point IDs are returned, explains the displacement direction, and clarifies curve attractor behavior. This adds significant context beyond the minimal annotation.
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 concise and front-loaded with the core action. Each sentence serves a purpose: first sentence defines operation, second clarifies strength, third explains attractor types, fourth notes side effect. No unnecessary information.
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 essential behavioral aspects and side effects, and since an output schema exists, return values are not needed. It lacks mention of falloff options (covered in schema) and potential conflicts if both attractor_point and attractor_curve_id are provided, but overall it is sufficiently complete for a single-parameter tool with rich 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?
While schema coverage is 0% (description does not list parameters), the schema itself has detailed descriptions for all parameters. The description adds value by explaining the effect of strength polarity and the distinction between point and curve attractors, complementing the schema's structural definitions.
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 displaces input points along a vector to an attractor with a falloff, specifying positive/negative strength and two attractor types. It distinguishes itself by noting it is a form-finding move that deletes originals and returns new point IDs, setting it apart from duplicating or simple move tools.
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 explains the tool's behavior (e.g., polarity of strength, point vs. curve attractors) but does not explicitly state when to use this tool over siblings or alternatives. Usage context is implied but not formally guided; no exclusions or conditions are provided.
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, indicating a safe read operation. The description adds that the tool returns all functions with signatures, but does not elaborate on other behavioral aspects like pagination or error handling. The description does not contradict annotations, but adds minimal extra transparency beyond the annotation.
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 concise with two efficient sentences. The first sentence immediately states the purpose, and the second provides a clear usage instruction. No unnecessary words or redundancy.
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's simplicity (one read parameter, output schema present), the description comprehensively covers what the tool does and how to use it. The output schema likely documents return values, so the description need not elaborate further.
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 input schema has one parameter (module_name) with a description in the schema ('Module name (e.g. 'curve', 'surface', 'mesh')') but context indicates schema description coverage is 0%. The description text only implies the need for a module name via 'specific RhinoScript module', adding no additional meaning about the parameter format or constraints.
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 'Get all functions in a specific RhinoScript module with signatures', using a specific verb ('Get') and resource ('functions in a specific RhinoScript module'). It distinguishes from sibling tools like rhino_list_rhinoscript_modules (lists modules) and rhino_search_rhinoscript_functions (searches across modules).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides the user to first use rhino_list_rhinoscript_modules() and then call this tool to browse a module's full API. This provides clear context and an alternative action, making the usage scenario very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the tool's behavior: it samples a grid, computes planarity error, flags cells exceeding tolerance, and returns summary statistics. This goes beyond the readOnlyHint annotation, which only indicates no side effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of 4-5 sentences. It is front-loaded with the main purpose and uses no superfluous words. Every sentence adds value.
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 moderate complexity (grid sampling, planarity calculation) and the existence of an output schema, the description covers the core functionality and output (stats block). It does not detail the per-cell results, but the output schema presumably handles that. Slight gap in not mentioning that the report includes per-cell data, but overall acceptable.
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 adds meaning to the grid dimensions (UxV) and tolerance parameter by explaining the planarity error calculation. However, it does not elaborate on doc_id or surface_id, which are already described in the schema. Given the context's schema description coverage of 0%, the description compensates well but not exhaustively.
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 computes a per-panel planarity report on a UxV grid sampled from a surface. It explains the calculation method (distance of 4th corner from plane fitted through first three) and the output includes flagged cells and a stats block. This distinguishes it from sibling tools like curvature analysis.
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 does not mention exclusions, prerequisites, or scenarios where this tool is preferred. The sibling tools include many surface analysis tools, but no comparison is offered.
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 the tool is not read-only. The description enhances transparency by revealing the algorithmic differences between standalone and bridge modes, and notes that standalone results can be joined downstream. This goes beyond the annotation's basic mutability flag.
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: a single purpose sentence followed by a clear, bullet-like breakdown of the two modes. No superfluous words, and the most important information is front-loaded.
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 existence of an output schema and sufficient parameter schema descriptions, the description covers the key behavioral aspects. It could be more specific about when to use standalone vs bridge, but overall it is complete enough for an agent to select and invoke the tool 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?
Schema descriptions already cover parameters like section_curve_ids. The description adds valuable context about the behavioral difference based on curve count and the two modes, which is not fully captured in the schema. Schema coverage is reported as 0%, so the description compensates well.
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 generates a skin through ordered section curves. It explains two distinct modes (standalone and bridge) and contrasts them, distinguishing this tool from siblings like rhino_loft by detailing that standalone mode returns a list of ruled surfaces while bridge mode returns a single Brep loft.
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 scenarios via the two modes but does not explicitly tell when to use this tool over alternatives like rhino_loft or rhino_sweep1. It lacks guidance on prerequisites, limitations, or specific conditions favoring one mode over the other.
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 include readOnlyHint=true, and the description adds significant behavioral detail: sampling grid, computation method, output metrics (max/mean/RMS, normalized score), and meaning of values. 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 paragraph with clear structure: main purpose, method, output interpretation. Every sentence adds value without redundancy.
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 complexity and presence of an output schema, the description adequately covers purpose, method, and result interpretation. Minor missing details like prerequisites or limitations, but overall complete.
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?
Schema description coverage is partial (doc_id and surface_id have descriptions, sample_u/sample_v only have constraints). The description explains that sampling uses (sample_u+1)x(sample_v+1) grid, adding meaning to the numeric parameters 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 tool estimates how far a surface deviates from developable, with specific verb ('Estimate'), resource ('surface'), and algorithmic details (sampling grid normals, max angle). It distinguishes itself from sibling analysis tools like curvature or planarity.
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 explains what the tool does and interprets results (0 for developable, positive for sphere), but does not explicitly state when to use this tool over alternatives. Usage context 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool modifies document state (undo) and that MCP tool changes are automatically grouped. Since annotations provide no readOnlyHint or destructiveHint, the description carries the burden and adequately discloses the core 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 three sentences, front-loaded with the core purpose, and includes an important behavioral note about undo record grouping. No redundant or unnecessary text.
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 the description covers the essential behavior. An output schema exists, so return values are not required in the description. Minor improvement could be aligning with typical undo (Ctrl+Z), but it's sufficiently 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 main description adds no information about the 'steps' parameter beyond what the schema already provides (number of operations to undo). Schema coverage is high, 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 clearly states the verb 'Undo' and the resource 'last operation(s) in the Rhino document'. It distinguishes from sibling rhino_redo by focusing on undo and notes that MCP tool changes are grouped into undo records.
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 implies when to use (to reverse operations) and mentions that each step reverses one undo record. It does not explicitly exclude other tools or state alternatives, but the context of undo is straightforward given the sibling rhino_redo.
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?
The description explains that non-target objects are ghosted or hidden temporarily and restored afterward, which adds behavioral insight beyond the annotations. It does not explicitly mention that a PNG file is created at the specified path, though the schema covers the 'path' parameter. Annotations have readOnlyHint=false, consistent with a capture/write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short paragraph that front-loads the main purpose and then adds details. Every sentence is informative, with no wasted words. It is well-structured and easy 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 complexity of the tool (multiple parameters, filtering logic), the description covers the core behavior (ghosting, restoration, use case). It does not explain the return value, but an output schema exists. It could mention that the tool creates a file at the specified path, but that is in the schema. Overall, fairly complete for the context.
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. It mentions 'selection_ids' and 'layers' and explains the effect of 'ghost_others', but does not describe parameters like 'width', 'height', 'doc_id', or 'zoom_to_selection' in detail. The schema descriptions for those are minimal, so the description adds some value but not full clarity.
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 verb ('Capture') and resource ('viewport preview') and specifies that it is restricted to a selection or layer set. It also includes the context 'Bridge only' which limits scope. The title from annotations ('Viewport Preview (filtered)') reinforces this. It distinguishes from siblings like rhino_viewport_image by emphasizing filtering.
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 explicitly calls out the use case ('multi-step LLM verification flows where only the recently added objects need to be visualised') and mentions 'Bridge only', which implies a specific context. However, it does not explicitly state when not to use it or compare to alternatives like rhino_viewport_image.
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 and idempotentHint, so behavioral safety is covered. The description adds value by detailing the return structure (rows with fields like guid, name, category, etc.) and summary block. No contradictions 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 concise with two short paragraphs. The first sentence immediately states the purpose, and the second paragraph provides usage context. Every sentence earns its place with no 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 that an output schema exists (as indicated), the description covers the return structure adequately. It mentions the key fields and summary block, making the tool's behavior predictable. No gaps for a search 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 description does not add any parameter-level guidance beyond what the input schema already provides. The schema itself has detailed descriptions for each parameter (limit, query, plugin, category). 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?
The description clearly states the tool searches the Grasshopper component catalog (built-in + plugin-supplied). It specifies the action (search) and resource (component catalog), and distinguishes from sibling tools like gh_add_component, gh_component_list, etc., by focusing on searching for GUIDs.
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 explicitly instructs to use this tool to find the GUID needed for gh_add_component before dropping a component. This provides clear usage context. It doesn't mention when not to use or list alternatives, but the guidance is sufficient for the search 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 and idempotentHint. The description adds value by clarifying the return behavior (full catalogue or category subset) and the purpose of supporting preset creation. No 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, no fluff. First sentence states action, second sentence adds purpose and context. Every word earns its place.
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 list tool with one optional parameter, the description, together with annotations and schema, fully covers purpose, usage context, and safety. It mentions the subsequent tool. Output schema exists. Nothing critical 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?
Schema description coverage is 0%, but the input schema itself describes the 'category' parameter with valid values. The tool description does not mention the parameter, missing an opportunity to compensate for low coverage. However, the schema provides sufficient meaning, so score is baseline 3.
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 it lists physical-material presets, returns full catalogue or subset, and explicitly ties to the sibling tool rhino_material_preset_create, distinguishing its purpose.
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 says 'so the LLM can pick a known-good name before calling rhino_material_preset_create', which provides clear usage context. It does not explicitly exclude other scenarios or discuss alternatives, but the intended workflow is evident.
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?
Beyond the annotations (readOnlyHint=false), the description adds significant behavioral context: it explains error handling (‘on_error’ behavior and error rows), performance impact (latency savings), and the response structure. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into clear sections (purpose, important notes, performance, return format). It is informative without being overly verbose, though it could be slightly more concise by integrating the important notes into the main flow.
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?
The description is complete for a complex batch tool: it covers input format (steps, on_error), important mapping rules, error behavior, performance trade-offs, and output structure. No critical gaps are present.
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 detailed descriptions for all parameters (method, params, on_error). The tool description adds limited additional parameter insight, primarily reiterating the method naming convention. With schema description coverage at 0%, the description partially compensates but does not fully alleviate the need for parameter understanding.
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 purpose: 'Dispatch multiple bridge methods in a single round-trip.' It precisely describes the verb (dispatch) and resource (multiple bridge methods), and distinguishes itself from siblings by explaining it batches calls that would otherwise be issued individually.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines, including when to use ('effective for any workflow that issues >5 bridge calls back-to-back'), how to map tool names to dispatcher routes with examples, and what tools cannot be batched (standalone-only tools). It also explains the 'on_error' parameter's behavior.
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 indicate readOnly and idempotent. Description adds context about the simplified model and scope (side-lit rooms), but does not detail behavioral constraints beyond the formula. No 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?
Extremely concise: two sentences and a formula. Front-loaded with purpose and formula, no wasted words.
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?
Provides method and scope clearly. Does not explain return values, but output schema likely covers that. Missing guidance on typical values or prerequisites, but acceptable for a simple calculation 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?
Schema description coverage is 0%, but the formula in description maps variables (W, theta, tau, M, A_total, R^2) to parameters indirectly. Schema itself already has good descriptions for each parameter, so description adds limited semantic value beyond the formula.
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?
Clearly states it calculates 'BRE simplified daylight factor for a side-lit room' and provides the formula. Distinguishes from sibling analysis tools like rhino_curvature_analysis and rhino_draft_angle by being a specific daylight metric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'For early-stage architectural studies; for radiance-grade accuracy use ladybug-tools or DAYSIM.' This defines when to use and recommends alternatives for higher precision.
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, which the description supports by stating 'Aggregate objects' (a read operation). Description adds context about grouping behavior but 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 sentences with a multi-line example, no fluff. The main action is front-loaded ('Aggregate objects grouping by...'). Every sentence adds unique value.
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 an output schema exists (so return format is documented elsewhere), the description sufficiently explains the grouping behavior and provides examples. It does not mention that objects must have user_text attributes, but that is implied by 'user_text[group_key]'.
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?
Although the input schema already describes parameters, the description adds meaning by explaining that group_key refers to user_text fields and providing real-world examples ('assembly_type', 'material'), which helps the agent understand the parameter's role.
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?
Description clearly states it aggregates objects by a user_text group_key value. Provides explicit examples (wall/window schedule, material BOM) that distinguish it from sibling tools like schedule_by_layer or schedule_by_material.
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?
Description gives concrete use cases (BIM-style schedules with specific group_key values), implying when to use it. Does not explicitly state when not to use, but the examples provide sufficient guidance.
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 only indicate readOnlyHint: false. The description adds that the active bridge client is closed and the next tool call uses lazy promotion, disclosing side effects and behavioral details 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?
Two short, focused sentences with no wasted words. The purpose is front-loaded, and constraints are clearly presented.
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 low complexity and presence of an output schema, the description adequately covers all essential aspects: purpose, parameter constraint, and behavioral side effects. No gaps are evident.
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 does not repeat parameter details already in the schema, but adds the critical constraint that exactly one selector must be set. The schema provides descriptions for each parameter, so the description adds value without redundancy.
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: switching the next bridge call to target a specific Rhino session. It uses specific verbs and resources ('switch the next bridge call', 'target a specific Rhino session'), and distinguishes from sibling tools by describing a unique configuration action.
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 explicitly says exactly one selector (among pid, port, doc_path_contains, index) should be set, providing clear usage context. It lacks explicit when not to use or alternative tools, but the purpose is specific enough that no alternatives exist among siblings.
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, and the description adds transparency about async behavior and pagination structure. It does not contradict annotations and provides useful behavioral context beyond the read-only status.
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 concise, front-loaded with the purpose, and efficiently covers filtering, pagination, and async behavior without superfluous text.
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 that an output schema exists, the description does not need to detail return values. It sufficiently covers pagination, filtering, and async behavior, making it complete for a list tool.
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 schema already provides descriptions for parameters, so the description adds marginal value. However, it clarifies that offset applies after filters and explains the pagination block, which aids understanding of limit and offset usage.
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 'List objects in the document with optional layer/type filter,' specifying the verb (list) and resource (objects). It distinguishes from sibling tools like rhino_object_info or rhino_layer_list, which perform different operations.
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 explains that this tool lists objects with optional filtering and pagination, providing clear context for iterating through results. It does not explicitly compare to alternatives or state when not to use, but the purpose is evident.
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 provide readOnlyHint=true, so safety is clear. Description adds that the tool returns 'function counts', providing behavioral detail beyond annotations. No 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, front-loaded with the core purpose. Every word serves a function: states what it does and when to use it. No 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?
For a simple no-parameter listing tool, the description fully explains what it returns (modules with function counts) and the context for use. Output schema exists but its absence of detailed description is acceptable given the tool's 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?
Tool has zero parameters; schema coverage is 100%. No parameter documentation is needed, and the description doesn't attempt to add any. Baseline 4 is appropriate for the absence of parameters.
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?
Description clearly states verb 'List' and resource 'all available RhinoScript modules with function counts'. Differentiates from sibling tools like rhino_search_rhinoscript_functions and rhino_get_module_functions by implying this is a high-level discovery listing.
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?
Explicitly states when to use: 'when you are not sure which module contains the functions you need'. Implicitly suggests not using it when the module is already known (then one would use rhino_get_module_functions). Could be improved by explicitly listing alternatives.
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 set readOnlyHint: true, so no further safety disclosure is needed. The description adds behavioral context about normalization and internal computation of actual parameters, which is valuable 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 extremely concise: two sentences that convey all necessary information without any fluff. Every word earns its place.
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's simplicity (evaluate normal at a point), the description covers the essential normalization and parameter handling. An output schema is present, so return values need not be explained. The description is complete.
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 input schema includes descriptions for u and v ('Normalised U parameter (0 .. 1).'). The description adds extra meaning by clarifying that the actual parameters are computed internally so the LLM doesn't need to know domain bounds, which aids correct usage.
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 that the tool evaluates the surface unit normal at a normalized (u,v) coordinate. It uses a specific verb ('evaluate') and resource ('surface unit normal'). Among siblings, it is distinct from tools like rhino_surface_curvature_at (curvature) and rhino_evaluate_surface (point evaluation).
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 explains that u and v are 0..1 ratios and that domain bounds are handled internally, guiding the agent on how to provide normalized parameters. It does not explicitly state when to use this tool versus alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits: changes are wrapped in an undo record and reverted on failure, code must use print() for output, and handle None returns. This goes beyond the minimal annotations (only title).
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 well-organized with critical warnings at the top, bullet points for requirements, and a clear return value summary. Every sentence adds value, and the length is appropriate for the complexity.
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 presence of an output schema, the description covers all necessary context: code requirements, error handling, undo behavior, and return fields. It is comprehensive for a code execution 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 input schema already describes both parameters adequately. The description adds context about code content requirements (e.g., import rs) but does not directly explain the verified_functions parameter. With high schema coverage, baseline is 3.
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 it executes RhinoScript Python code in a live Rhino session. It distinguishes itself from siblings like rhino_execute_csharp by specifying the language and import requirements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit step-by-step usage guidelines, including calling rhino_get_rhinoscript_docs for correct signatures, and details on error handling and undo behavior. It clearly advises when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint=true. The description goes far beyond: it details the safety gating, available globals (doc, output), pre-imported namespaces, undo record wrapping, and timeout behavior. This provides essential behavioral context that annotations do not cover.
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 well-structured with clear sections (safety, globals, pre-imports, example, behavior). Each sentence serves a purpose, and the key action is front-loaded. It is appropriately sized for a complex tool, avoiding unnecessary verbosity.
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 code execution tool, this description covers all essential aspects: what the tool does, how to use it (with examples), safety considerations, available variables, undo behavior, timeout handling, and output mechanism. Given the tool's complexity and the presence of an output schema (not shown but referenced), this is a complete and helpful description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides brief descriptions for each parameter, but the description adds significant value: it explains the code parameter through an example and details the globals and namespaces available. It also elaborates on the timeout_s parameter (default, range, effects of timeout) and references parameter (what it's used for). The description enriches understanding 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 'Execute RhinoCommon C# code in a live Rhino session using Roslyn.' It uses a specific verb ('Execute') and resource ('RhinoCommon C# code'), and the scope is clearly defined as 'live Rhino session'. Among siblings, this is unique as a code execution tool, easily distinguishable from geometry creation or analysis 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 explicitly warns that the tool runs arbitrary code and is gated behind an environment variable, implying it should only be used in trusted sessions. It does not explicitly name alternatives (e.g., rhino_execute_python) but the context of arbitrary code execution versus specific tool commands provides a clear usage guideline.
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/EaseHee/rhino-mcp/badges/card.svg)](https://glama.ai/mcp/servers/EaseHee/rhino-mcp)

Score Badge

Copy to your README.md:

[![rhino-mcp MCP server](https://glama.ai/mcp/servers/EaseHee/rhino-mcp/badges/score.svg)](https://glama.ai/mcp/servers/EaseHee/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/EaseHee/rhino-mcp'

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