Fit the view

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

With no annotations, the description carries the full burden. It usefully discloses that the fit normalizes to a 1:1 axis ratio and that it can also mutate axes/grid visibility, which is a side effect beyond the name. It does not state whether the view change is undoable, whether omitted flags leave existing state untouched, or whether hidden objects are excluded from the fit.

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?

One sentence, front-loaded with the core effect, then the invariant in a compact parenthetical, then the optional flags. No filler and no repetition of the title.

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 simple, side-effect-light view tool with no output schema this is roughly adequate: the visual outcome and the two toggles are covered. It still leaves the omission semantics of show_axes/show_grid and the treatment of off-screen or hidden objects unspecified, which an agent would need before calling it confidently.

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 coverage is only 33%: 'padding' is documented in the schema, while show_axes/show_grid have no schema descriptions. The description partially compensates by explaining that those two flags show/hide axes and grid, but it never clarifies the default behavior when they are omitted or how padding interacts with the fit.

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 action pair (zoom/pan), the trigger condition (so every visible point and circle fits in the drawing area), and an invariant (1:1 axis ratio). It is clearly distinct from siblings like ggb_screenshot or ggb_set_style, though it does not explicitly contrast itself with any of them.

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 by the effect described ('so every visible point and circle fits'), letting an agent infer it is a remediation call after objects fall outside the viewport. There is no explicit when-to-use, when-not-to-use, or named alternative, so it stays at the minimum-viable level.

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