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

The annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the bar is lower, and the description still adds real operational context: private/local addresses are refused, the decoded file is capped at 10 MB, and the result is returned as base64. Those limits and the output encoding are not derivable from the annotations and directly affect how an agent prepares the call.

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?

Six short, information-dense sentences, front-loaded with the core action and then limits and output, with almost no filler. There is some duplication of what the schema enum fields already say about px/ratio and format, which keeps it from being maximally tight.

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 an output schema present, the description need not explain return structure, yet it still flags the base64 return. It covers both input modes and the size/address restrictions, leaving only the coordinate fields (x/y/width/height) under-explained for an 8-parameter tool.

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 only 25%, so the description needs to compensate, and it does for file (base64 or public URL), unit (px vs ratio, restated), circle, and format. However x, y, width, and height have no schema descriptions and no explanation in the description — the default of 1 for both width and height is especially ambiguous — so the compensating coverage is partial.

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 states a specific verb and resource ('Crop an image') and scopes it ('to a pixel box or a 0 to 1 ratio box'), which is enough to separate it from convert_image or resize_image without opening a schema. It stops short of explicitly naming which sibling handles the non-cropping cases, so it is clear but not sibling-differentiated.

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 only implied: the description mentions the px vs ratio choice, the circle mask, and the format options, which hints at the decisions a caller makes. There is no when-to-use-this-vs-an-alternative guidance and no statement of prerequisites or exclusions beyond the input-source restrictions.

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