Assign or update a named PropertySet (e.g., Pset_WallCommon) to a Rhino object by persisting key/value pairs as user text. Optionally replace existing properties under that PropertySet to keep BIM data current.
Persist a PropertySet block on an object.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a write via readOnlyHint=false, and 'Persist' largely restates that without adding new behavioral context. The description does not mention overwrite semantics, implications for existing property sets, user_text storage, permissions, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or repetition. It is efficient, though slightly terse considering the BIM-specific subject matter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The combination of tool name, title, and rich input schema makes the call reasonably clear, and an output schema is present. However, the description alone does not explain what a PropertySet block means in the IFC context or how this differs from metadata_set and user_text setters, so the agent must rely on sibling names and schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description itself adds no parameter-level information, but the nested schema thoroughly documents doc_id, object_id, pset_name, properties, and replace_existing. Although the wrapper-level coverage signal is 0%, the actual field descriptions compensate, making this a baseline 3 rather than a failure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Persist') with a clear resource ('PropertySet block') and target ('on an object'), and the action clearly differs from sibling pset_get/pset_delete tools. It does not explicitly name sibling alternatives, but the set/get/delete family is still decipherable from the description and tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as rhino_bim_pset_get, rhino_bim_pset_delete, rhino_bim_metadata_set, or rhino_set_user_text. It implies a write operation but never states conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.