view_reference_image

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond that: the 1600px size cap, the attribution-preservation obligation, and an explicit epistemic caveat that viewing an image proves nothing about construction, dimensions, cost or acoustics.

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 core capability and its constraint are front-loaded in the first sentence, with supporting caveats after. The final guardrail sentence is slightly tangential to invocation but earns its place as a scope limit on interpretation.

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?

An output schema exists, so return-value explanation is not required. The description covers source, sizing, attribution and interpretation limits; the main remaining gap is the unelaborated project_url requirement and behavior when the project is not verified.

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 partially does: image_index is explained as coming from read_reference. However, project_url — the only required parameter — is never described beyond 'verified OfficeNext project', leaving format and validation requirements undocumented.

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?

States a specific verb and resource ('View ONE gallery photo from a verified OfficeNext project') plus the key modality ('in memory, without a local image file'), which differentiates it from a file-based viewer. It does not explicitly contrast itself with sibling read_reference, but the reference to indices implies the distinction.

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?

Explicitly routes the agent: 'Use indices returned by read_reference' tells it where the required index comes from. There is no statement of when NOT to use it (e.g., use search_references to find a project first), so it falls short of full when/when-not coverage.

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