capture_pose_3d

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

Beyond the read-only/open-world annotations, the description discloses non-obvious behavior: it targets the largest canvas, uses toDataURL with a viewport-screenshot fallback, samples up to 10 scroll steps with per-step ratios, and carries a hard dependency on playwright. The fallback and dependency requirements are exactly the traits an agent must know before invoking.

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 dense sentences, no filler. The core action and its output are front-loaded, with constraints (URL scope, playwright dependency) trailing. Every clause carries information an agent can act on.

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 should ideally characterize the returned pose grid, but it only hints at 'per-step scroll ratios' without describing the output structure. Parameters are fully covered by the schema and annotations cover safety, so the remaining gap is modest but real.

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 100%, so the baseline is 3, but the description adds real meaning: it explains that the steps parameter produces per-step scroll ratios used for camera-path reconstruction, and clarifies the scroll-sampling semantics tied to the 'up to 10' cap. This goes beyond restating the schema's defaults and ranges.

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 (capture) and resource (a page's WebGL/canvas 3D pose grid), then specifies the mechanism (largest canvas via toDataURL with screenshot fallback) and the analytic purpose (reconstructing scroll-driven 3D camera paths). This clearly separates it from siblings like capture_live_site, capture_component, and analyze_scroll_map.

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?

Gives clear context: works on any URL, explicitly does not fetch awwwards.com, and requires the optional playwright dependency. It does not, however, name a sibling or state when to prefer this over capture_live_site or analyze_scroll_map, so the alternative-selection guidance is implicit rather than explicit.

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