Capture a single element (cropped screenshot)

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the workflow: navigates, applies optional viewport, scrolls the first match into view, and crops. It also discloses the output handling (full-resolution crop saved to disk, webp thumbnail on the wire). It does not mention error conditions or permissions, but for a non-destructive screenshot tool this is a solid disclosure. No contradictions with any structured metadata.

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?

The description is three sentences with zero fluff. The primary purpose and use case are front-loaded in the first sentence, followed by a concise process summary and output details. Every sentence earns its place, making it efficient and scannable for an agent.

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 tool with 4 parameters (2 required), no output schema, and no annotations, the description covers the core action, the use case, the behavioral steps, and the output format. It lacks explicit error-handling details or authentication prerequisites, but those are not critical for this simple screenshot tool. It is complete enough for an agent to invoke it correctly without further investigation.

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%, and every parameter already has a detailed description (e.g., reload behavior, selector semantics, viewport enum). The tool description adds minimal parameter-specific meaning beyond what the schema provides—it mentions scrolling the selector into view, which is also in the schema. Given the schema does the heavy lifting, a baseline of 3 is appropriate.

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 opens with a specific verb-resource pair: 'Screenshot ONE element, cropped to its bounding box.' It immediately distinguishes itself from capture_page_screenshot by emphasizing the single-element scope and the cropping, and even signals cost efficiency ('far cheaper than a full page'). This makes the tool's purpose unambiguous and differentiates it from siblings without needing to inspect schemas.

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?

The description explicitly states when to use it: 'when you only need a button, card, or nav' and contrasts it with a full page capture. However, it does not mention when not to use it (e.g., for full-page layout analysis) or name any alternative tools beyond the implicit page screenshot. It gives clear context but stops short of explicit exclusions, so it earns a 4.

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