Skip to main content
Glama

export_image

Export a PixInsight image view to a file in the workspace output or state folder, with format determined by extension and metadata preserved, without altering the working image.

Instructions

Write an image to a file in the workspace's output or state folder. A relative file_path is resolved under /output; an absolute one must lie inside /output or the state folder (/agentic by default), and a path anywhere else is refused. Format comes from the extension: .tif/.tiff, .png, .jpg/.jpeg, .xisf, .fits. TIFF and PNG default to 16-bit, JPEG to 8-bit; use 32 for float. The file keeps the image's FITS keywords, astrometric solution and view properties (formats that cannot store them drop them). The working image is not changed. Missing parent folders are created.

Input Schema

NameRequiredDescriptionDefault
bitsNoSample depth for tif/png/xisf/fits (default 16 for tif/png, 32 otherwise)
view_idYesView ID to export
file_pathYesOutput file path: relative to <workspace>/output, or absolute inside <workspace>/output or the state folder

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so well: it discloses the path sandbox and refusal behavior, that the working image is unchanged, that parent folders are auto-created, and that FITS keywords/astrometric solutions/view properties are preserved or dropped depending on format. These are non-obvious behavioral traits an agent needs.

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

Conciseness4/5

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

It is a dense single paragraph but every sentence carries load and the core action is front-loaded. Length is justified by the amount of genuinely useful constraint detail, though it could be split for readability.

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?

No output schema or annotations exist, and the description fully compensates by covering path rules, format-from-extension mapping, bit-depth defaults, metadata preservation, and non-mutation of the source image. Nothing an agent needs to call it correctly appears missing.

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 already 100%, so the baseline is 3, but the description adds real meaning: relative paths resolve under <workspace>/output, absolute paths must lie in output or the state folder, and bit-depth defaults per format map onto the 'bits' enum. It goes beyond restating the schema.

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

Purpose5/5

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

The description opens with a specific verb and resource: "Write an image to a file in the workspace's output or state folder," which clearly distinguishes it from read-only image tools and from preview siblings like save_preview. An agent can identify the core action without opening the schema.

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

Usage Guidelines3/5

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

It gives detailed conditional rules for path resolution and format selection, which implicitly guides correct invocation, but it never states when to prefer this tool over alternatives such as save_preview or save_and_show_preview. Usage is implied rather than explicitly contrasted against siblings.

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