Screenshot

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

readOnlyHint=true already covers the safety profile, and the description adds useful cost and output-shape context ('JPEG ~900 tokens') and the fact that labels:true overlays refs on the image. It says nothing about what the default capture area is when no ref/region is supplied, or whether a prior browse_open is required.

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 short with no filler, but it is telegraphic to the point of ambiguity and front-loads the token cost rather than the action. Semicolon-chained fragments cost more parsing effort than a single clear sentence would.

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 3-parameter, annotation-light tool with no output schema, the description covers cost, targeting, and the use/no-use boundary reasonably well. It still leaves open the default capture scope and the prerequisite relationship with browse_open, and the nonexistent 'window' option muddies the picture.

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?

With 0% schema description coverage the description must carry the parameters, and it does explain region ordering [l,t,r,b] in normalized 0-1 coordinates and the effect of labels:true. However it references a 'window' target that is not an actual schema property, and gives no hint about the format of ref, leaving an agent to guess how ref and region interact.

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 'window, ref or region [l,t,r,b] 0-1' plus the title Screenshot makes clear this captures a JPEG image of a target area, and 'Only when rows are not enough (charts, canvas)' distinguishes it from the text/row-oriented siblings. It never states the verb outright, so an agent must assemble the purpose from name, title and fragments.

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?

'Only when rows are not enough (charts, canvas)' is an explicit when-to-use and when-not gate, which is stronger than most definitions. It stops short of naming the alternative sibling (e.g. browse_read/view) that should be used instead when rows suffice.

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