Skip to main content
Glama
rokibul-mist

rhino-mcp

by rokibul-mist
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Hybrid

rhino_create_block

Create a reusable block definition from selected objects by specifying a name and base insertion point coordinates.

Instructions

    Create a block definition from currently selected objects.
    
    Args:
    name: Name for the new block definition.
    base_x, base_y, base_z: Base insertion point coordinates.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
base_xNo
base_yNo
base_zNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are present, so the description bears the full burden of behavioral disclosure. It does not explain whether the selected objects remain in the document, are replaced by block instances, or what happens on an empty selection or duplicate block 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 core action is stated in one front-loaded sentence, followed by a compact Args list. There is no filler or unnecessary repetition, making the description easy to scan.

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

Completeness2/5

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

The description provides the basic name and base-point parameters, and defaults are present in the schema, but it omits important operational context for a block-creation tool: whether selected objects are consumed, how the base point affects placement, and how naming conflicts are handled. The available schema/output schema does not compensate for these 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?

Schema coverage is 0%, and the description adds meaning for all four parameters: name is for the new block definition and base_x/y/z are the base insertion point coordinates. This is helpful, though the base coordinate descriptions are only slightly richer than the schema titles and defaults, and no units or precision details are 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 clearly states a specific action and resource: creating a block definition from currently selected objects. The phrase 'currently selected objects' helps distinguish it from block insertion/explosion tools, though it does not explicitly differentiate it from the closely related rhino_block_define sibling.

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 makes the prerequisite clear: the tool operates on currently selected objects. However, it provides no guidance on when to prefer this tool over rhino_block_define, rhino_block_insert, or rhino_add_objects_to_block, and gives no exclusions or when-not-to-use advice.

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

Install Server

Other Tools