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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered; the description adds the non-obvious behavioral fact that this is a slower, more expensive path than the summary. It does not mention the 75-shot cap or any per-call cost, but those are documented in the schema.

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 short sentences with no waste: capability first, then the cost/routing caveat. Every clause carries information an agent needs to decide whether to call it.

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, rich annotations, and fully described parameters, the description only needs to explain the capability and the cost tradeoff, which it does. The one small gap is that it does not signal the capped shot count or that answering may take noticeably longer in wall-clock terms, though both are inferable.

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 meaning beyond the schema by characterizing the intended question type — pacing, mood, shot content, strongest shot — which tells the agent the question parameter wants subjective/visual queries rather than metadata lookups. It says nothing extra about photoIds or listingId, which is acceptable given full schema coverage.

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?

"Looks at the actual shots with vision and answers a look-and-feel question" gives a specific verb (inspect with vision), a specific resource (shots), and the kind of output produced (pacing, mood, shot content, strongest shot). It also implicitly separates itself from the cheaper summary path, so an agent can tell it apart from get_edit_summary without opening either schema.

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?

"Slower than the summary, so it suits questions the summary cannot answer" supplies a real routing rule against the alternative path and states the cost tradeoff that governs the choice. It stops short of naming the exact sibling tool or giving an explicit when-not list, so the agent must map "the summary" onto get_edit_summary itself.

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