Set record fields or plug-in parameters on a single Vectorworks object, rejecting unknown field names before any change and returning the updated record.
Set record fields (or plug-in parameters) on one object; unknown field names are rejected before anything changes. One undo step. Returns the record afterwards.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | ||
| record | Yes | ||
| values | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.3.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false), so the bar is lower, yet the description adds real value: validation happens before any change (atomicity), the operation is a single undo step, and it returns the record. It is consistent with destructiveHint=false rather than contradicting it.
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?
Three short clauses, front-loaded with the action and scope, followed by the two behavioral guarantees an agent cares about. No sentence is wasted and nothing is buried.
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?
An output schema exists, so return values need not be described, and annotations cover safety. The remaining gap is the undocumented uuid/values parameters, but overall the definition gives an agent enough to invoke the tool correctly.
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?
Schema description coverage is 0% for three required parameters, so the description must compensate. It clarifies that 'record' names the record/plug-in and 'values' holds field names (unknown ones rejected), but leaves 'uuid' and the shape of the nested values object unexplained.
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?
States a specific verb and resource ('Set record fields (or plug-in parameters) on one object'), which clearly separates it from the read-path sibling vw_get_record. It does not, however, name any alternative such as vw_set_lighting_device_fields, so sibling differentiation is only implicit.
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 explains what happens during the call but never states when to choose this tool over vw_get_record, vw_set_lighting_device_fields, or vw_revert_last. Usage is only inferable from the verb, with no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.