get_viewport_info

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

With no annotations, the description carries the full behavioral burden, and it discloses almost nothing: it does not confirm the read-only nature explicitly, nor mention side effects, permissions, or scope of the returned state. The 'get_' prefix is the only behavioral cue.

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?

It is compact and front-loads the content domain first, then the parameter note. Nothing is wasteful, though the telegraphic two-fragment style is terse enough to be slightly cryptic.

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 explained, but for an annotion-free read tool the description still omits what happens when 'viewer' is unset (does it default to the active pane?) and gives no indication of the state being reported. Coverage is too thin for the tool's role.

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 compensate, and it partially does by defining 'viewer' as the pane name and marking it optional. That is meaningful beyond the bare schema, but it adds no format, default behavior, or examples for resolving a pane name.

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 fragment 'Viewport camera, shading, Hydra delegate' signals the resource domain and enumerates the aspects covered, which helps distinguish it from the set_viewport_* writers. However, it is a noun phrase with no verb, so it never plainly states that it retrieves/reports viewport info; the agent infers the action from the name alone.

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 and no named alternative. Siblings such as set_viewport_camera, set_viewport_display and set_viewport_renderer form an obvious read/write pair, but the description never establishes this tool as the read-only counterpart, leaving routing entirely to inference.

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