vizcom_read_board

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's value is in the coordinate contract it adds: x/y is the CENTER, positive Y is UP, and the exact left/right/top/bottom derivation. That is real behavioral context an agent would otherwise get wrong; a slight gap remains on staleness/concurrency beyond the one refresh remark.

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 sentences, each doing distinct work: what is returned, the coordinate convention with formulas, and a usage caveat. The most error-prone detail (center vs. corner origin) is flagged with 'IMPORTANT' and front-loaded rather than 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?

With no output schema, the description must convey what comes back, and it does at a summary level (positions, prompt nodes, ordered links) plus the geometry conventions needed to interpret positions. It stops short of describing the returned structure or ordering semantics for the 'ordered source links', which is the one remaining gap for a read tool of this complexity.

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?

There is one required parameter, workbenchId, and schema description coverage is 0% – the schema documents nothing about it. The description never mentions workbenchId, where to obtain it, or whether it identifies a board versus a workbench, so the low-coverage gap is not compensated.

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 names a specific read operation and enumerates the exact payload: image positions, prompt nodes, and ordered source links. That is far more informative than the tool name alone and separates it from mutation siblings like vizcom_update_prompt_node or vizcom_arrange_nodes, though it never explicitly contrasts itself with vizcom_check_layout.

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?

'Refresh before editing shared boards' gives one concrete when-to-use trigger, implying read before write on shared boards. It does not name alternatives (e.g., vizcom_check_layout) or state when reading the board is unnecessary, so the guidance is implied rather than explicit.

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