vizcom_arrange_nodes

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

Annotations only say non-readonly, non-destructive, not idempotent; the description adds real substance beyond them: a local recovery journal exists, conflict detection is best effort and not atomic, and a current updatedAt is mandatory. It stops short of saying what a conflict actually returns or whether partial changes are applied.

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?

Four tight sentences, no filler, and the highest-risk facts (center-based coordinates, Y-up, journal/conflict caveat) are front-loaded where an agent will read them first.

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 batch mutation with no output schema, the description covers coordinate convention, resize-mode branching, the concurrency token, and the atomicity caveat. The remaining gap is the failure/return story — what a conflict or partial success looks like — which matters when editing up to 200 nodes at once.

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?

With 0% schema description coverage, the description carries the load and does most of it well: x/y are CENTERS with positive Y up, workbenchSizeRatio is for drawings while width/height apply to other nodes, and expectedUpdatedAt must be current. It leaves workbenchId and the 1-200 item array bound unexplained, though those are largely self-evident from the schema.

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 pair and resource: 'Move or resize selected nodes', with the added qualifier of a local recovery journal. It clearly is not a read/check tool, but it never names the adjacent siblings (vizcom_check_layout, vizcom_restore_layout) that an agent might confuse it with.

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?

Usage is implied rather than stated: 'Requires current updatedAt' tells the agent a precondition (fetch fresh state first), but there is no explicit when-to-use, when-not-to-use, or pointer to vizcom_check_layout to validate before moving. The agent must infer the workflow.

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