Get detailed properties of selected objects in Rhino. Select objects to inspect their attributes, type, and data in one command.
Display detailed properties of selected objects.
Args:
controller: RhinoController instance.
Returns:
Dict with command result containing object information.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Display' suggests a read-only operation, and the return type is noted, but the description does not disclose whether selection state is modified, what happens with no selection or multiple object types, or any side effects. This is shallow for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core sentence is short and front-loaded: 'Display detailed properties of selected objects.' The Args/Returns boilerplate is minimal and does not add much noise. It is concise, though the Returns line is generic enough that it earns little substantive credit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter inspection tool with an output schema, the description is minimally viable: it states the operation and the object scope. However, it omits important context such as the requirement to have objects selected before calling, behavior on empty selection, and how this differs from the many similar object-info sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no properties, so there is little for the description to clarify; per the zero-parameter baseline this rates well. The mention of a RhinoController instance adds some context, although it is not reflected in the schema and may be an implementation detail rather than a user-supplied parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb+resource combination: 'Display detailed properties of selected objects.' It identifies both the action and the target, and the scope ('selected objects') helps distinguish it from tools operating on named objects. It does not explicitly differentiate it from similar sibling tools such as rhino_object_info or rhino_list_objects, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when properties of currently selected objects are needed, but it gives no explicit guidance about when to choose this tool over rhino_object_info or rhino_get_object_info, and does not mention prerequisites such as making a selection or what happens if nothing is selected. No alternatives 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.