describe_image

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 non-destructiveness ('Does not change the document') and the backend/credential requirement ('online with a key, or Ollama'), but is silent on cost, latency, rate limits, and the shape of the returned text.

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?

Two tightly written sentences, front-loaded with the mechanism and the operations, followed immediately by the non-destructiveness guarantee. No filler, though it could be marginally clearer in routing.

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?

No output schema and no annotations mean the description should cover more: five parameters at 0% coverage, unclear return format for a text-generating tool, and no guidance on the backend parameter's 'auto' default. It is adequate but under-specified for the tool's complexity.

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 0%, so the description must compensate. It conceptually references three params (layer, box, question) by mapping them to behaviors, but leaves backend and project completely unexplained and gives no value syntax for box/layer.

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: image-to-text via a vision model that 'describes the picture, a layer or a box, or answers question about it.' This is clear and concrete, but it does not differentiate from the many AI siblings (analyze_image, review_image, edit_image), leaving overlap unaddressed.

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?

It offers partial context by noting the backend can be 'online with a key, or Ollama,' and clarifies it 'does not change the document.' However, it never explains when to choose this over analyze_image or review_image, so usage selection is left to inference.

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