Skip to main content
Glama

Export image

snipaya_export
Destructive

Export canvas or selected elements as PNG/JPG images, writing to a specified path or returning the image directly.

Instructions

Export the canvas (or given ids) as PNG or JPG. With path, writes the file (absolute path, matching extension, refuses to overwrite unless overwrite is true); without path, returns the image.

Input Schema

NameRequiredDescriptionDefault
idsNoExport only these elements. Defaults to the whole canvas (or crop).
pathNoAbsolute file path to write. Omit to receive the image in the response.
tabIdNoTarget tab id. Defaults to the active tab.
formatYes
beautifyNoFrame the image on a background. true uses the user’s beautify settings, an object overrides some of them, false turns it off. Omit to follow the user’s setting.
overwriteNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark this as non-read-only and destructive. The description adds key behavioral details beyond them: absolute paths, matching extensions, refusal to overwrite unless overwrite is true, and the difference between file-writing and response-returning modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loaded, and every clause carries useful information about scope, path handling, overwrite behavior, and return mode.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a moderate-complexity export tool with annotation coverage and no output schema, the description gives enough operational context to call it correctly. Remaining parameter details are available in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is moderate at 67%, and the description adds real semantics for ids, path, format, and overwrite behavior. It does not explain tabId or beautify, but those are covered in the schema, so this is strong but not fully compensating.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: export the canvas or given ids as PNG/JPG. It is clear what the tool does, but it does not explicitly differentiate itself from nearby siblings such as snipaya_export_to or snipaya_render.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly describes the two usage modes: providing path writes a file, while omitting path returns the image in the response. It does not name alternatives or state when a sibling tool should be preferred.

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