Skip to main content
Glama

guardar_preset

Save image format and processing options as a reusable Apolo preset for the CLI or MCP interface; duplicate names are rejected, so edit or delete presets in Apolo.

Instructions

Saves a combination of format and options as a new preset, to use in Apolo, on the command line or here. It doesn't overwrite: if the name exists, it's an error (changing or deleting presets is done in Apolo). Example: {"nombre": "Light web", "formato": "avif", "nota_objetivo": 75, "ancho": 1920}

Input Schema

NameRequiredDescriptionDefault
altoNoMaximum height, in pixels: scales down if larger and never enlarges (with ancho alone, proportional).
anchoNoMaximum width, in pixels: scales down if larger and never enlarges (with alto alone, proportional).
ordenNoOptions of the official tool, as they are: “-q 80 -m 6” (cwebp), “-quality 85 -progressive” (cjpeg), “-o 4” (oxipng), “-q 60 -s 6” (avifenc), “-d 1 -e 7” (cjxl). It may start with the tool's name. For its format, it replaces the preset's options.
nombreYesThe name of the new preset. It can't exist already.
paletaNoReduce the palette to this number of colors (2 to 256), with dithering: mainly for PNGs of logos, icons and screenshots.
presetNoA saved preset (listar_presets lists them). It is the base for everything else.
calidadNoFixed quality from 0 to 100. Not together with nota_objetivo.
formatoNowebp, jpeg, png, qoi, avif or jxl. By default, the preset's, or webp.
recorteNoCrop to this rectangle, before resizing (in pixels of the already auto-rotated image; whatever goes past the edge is trimmed).
enderezarNoAuto-rotate according to the EXIF orientation if the photo needs it. Yes by default.
lado_mayorNoMaximum longest side, in pixels: the width if landscape, the height if portrait; never enlarges. Not together with ancho, alto or porcentaje.
porcentajeNoReduce to this percentage (50 = half the width and height). From above 0 to 100. Not together with ancho, alto or lado_mayor.
sin_perdidaNoLossless (WebP, AVIF, JPEG XL). PNG and QOI always are.
nota_objetivoNoSearch for the lowest quality that gives this SSIMULACRA 2 score (90 indistinguishable; 80 very high; 70 high; 50 medium). Takes a few seconds.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes meaningfully beyond the annotations: annotations only say readOnly=false, idempotent=false, destructive=false, while the description explains the exact failure mode (duplicate name = error), that nothing is overwritten, and that edits/deletes must happen in Apolo. This is the behavioral detail an agent needs before calling a non-idempotent write tool.

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?

Three short sentences, front-loaded with the core action, followed by the constraint and then the example. The example earns its place as a usage anchor for a 14-parameter tool, though it is the least essential element.

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

Completeness4/5

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

For a 14-parameter, non-idempotent creation tool with no output schema, the key facts (create-only, duplicate = error, where presets are edited) are all present and per-parameter meaning is fully covered by the schema. The only gap is that it never says what a successful call returns, which matters given there is no output 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 100%, so the baseline is 3; the description adds value by framing the input as a "combination of format and options" and giving a concrete worked example with nombre, formato, nota_objetivo and ancho. It doesn't explain precedence between `preset` and the overrides, but the schema already does that per-parameter.

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?

States a specific verb+resource ("Saves a combination of format and options as a new preset") and adds the scope where the preset is usable (Apolo, command line, here). It also distinguishes itself from the absent mutating operations by saying changing or deleting presets is done in Apolo, so an agent knows this tool only creates.

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?

The create-only condition is explicit ("if the name exists, it's an error"), which tells the agent when this tool will fail. It doesn't name a sibling for checking existing names, though the `preset` parameter description points to listar_presets, so the alternative path is inferable rather than stated up front.

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