Render nodes as data URIs

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and open-world assumptions. The description adds that it downloads renders as data URIs and mentions size/SSRF caps similar to bundle_image_fills, which is useful behavioral context. However, it doesn't disclose details like rate limits, pagination, or what exactly happens to the nodes (e.g., conversion). Given annotations cover the main safety profile, the description adds some but not extensive behavioral context.

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 description is concise, one sentence with a technical phrase, and front-loaded with the action. It mentions key constraints (same caps) and purpose (design-to-code) without fluff. It is appropriately sized for the information it conveys.

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?

Given the tool has an output schema? No, but has 6 parameters with 50% schema coverage and annotations covering read-only/open-world. The description mentions the main constraints (size/SSRF caps) and use case, but doesn't mention return format details (though that's not needed if output schema exists, but it doesn't). It lacks clarity on how the data URIs are returned (e.g., as a map) but given annotations and schema, it's fairly complete for an agent to call.

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 50%, meaning the schema covers half of the parameters' descriptions. The description itself doesn't elaborate on any parameters beyond the mention of node ids in the schema. It doesn't add extra meaning to parameters like 'file', 'scale', 'format', etc., beyond what schema provides. However, the schema description for 'ids' mentions normalization, which is helpful. Since coverage is moderate at 50%, the description does not compensate much beyond schema.

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 clearly states the tool's action: GET /v1/images/{key}, download renders (Figma/S3 only) as data URIs. It names the resource (images) and the specific output format (data URIs). It distinguishes itself from sibling tools by mentioning same caps as bundle_image_fills and its purpose (design-to-code). However, it doesn't explicitly differentiate from other similar download/render tools in the sibling list, but the mention of data URIs and design-to-code purpose helps.

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?

The description mentions 'For design-to-code, not writing back to Figma,' which implies usage context (design-to-code) and an exclusion (not for writing to Figma). It also references bundle_image_fills for caps, indicating a comparison. However, it doesn't explicitly state when to use this over siblings like get_images or bundle_image_fills; it only references caps similarity. More explicit 'when to use this vs alternatives' would push to 5.

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