Place a symbol from the document's resources at X, Y, and optional Z coordinates on a chosen layer and class, with rotation and one undo step.
Place a symbol from the document's resources at x, y (document units), optionally at height z, on a layer and in a class. One undo step.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | Yes | ||
| z | No | ||
| name | Yes | ||
| layer | No | ||
| rotation | No | ||
| class_name | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the mutation/non-destructive profile is partly covered. The description adds genuine value with 'One undo step', telling the agent the operation is reversible, but omits what null layer/class defaults resolve to and how it interacts with the current selection.
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?
Two tight sentences, placement details front-loaded, and the undo behavior given as a compact trailing clause. No filler, though 'from the document's resources' is the only hint at prerequisite validity.
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 7-parameter mutation tool with no output schema and non-destructive annotations, the description covers the core placement contract and reversibility but leaves the rotation parameter and the null-default behavior of layer/class unexplained.
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%, so the description must carry the burden. It does explain x, y, z (document units, optional height), layer and class for five of seven parameters, but says nothing about the semantics of 'name' (must it exist in document resources?) or 'rotation', nor what null layer/class means.
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 (place/insert) and resource (symbol from the document's resources) with the placement coordinates, which is clear and distinct from readers like vw_list_symbols or vw_find_objects. It does not explicitly differentiate itself by name from those siblings, but the action is unambiguous.
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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives (e.g., vw_list_symbols to discover valid names). The agent is left to infer that this is the write counterpart to the symbol-listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.