Skip to main content
Glama

comparar_formatos

Compares the same image encoded in multiple formats at matching perceived quality, identifies the lightest file, and optionally saves the winner or all versions as new files.

Instructions

Encodes the same image in several formats at the same perceived quality (SSIMULACRA 2 score, 80 by default) and says which one is the lightest. Saves the best one (by default), all or none, always as new files. It takes a while: about 7 trials per format (with a 12 MP photo, over a minute; with 24 MP, about three). With photos over about 20 MP, better use empezar_lote with that image, the formats and mas_ligero: it does the same in the background and isn't cut off by a timeout, although it only gives the winner. For a single output already decided, optimizar_imagen. Example: {"ruta": "~/a.png", "formatos": ["webp", "avif", "jxl"]}

Input Schema

NameRequiredDescriptionDefault
altoNoMaximum height, in pixels: scales down if larger and never enlarges (with ancho alone, proportional).
rutaYesAbsolute path of the image (~ is accepted).
anchoNoMaximum width, in pixels: scales down if larger and never enlarges (with alto alone, proportional).
paletaNoReduce the palette to this number of colors (2 to 256), with dithering.
salidaNoFolder to save to. By default, next to the original.
guardarNoWhat to save: mejor (the best one, by default), todos (all) or ninguno (none).
recorteNoCrop to this rectangle, before resizing (in pixels of the already auto-rotated image; whatever goes past the edge is trimmed).
formatosNoThe formats to compare. By default, webp, avif and jpeg.
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.
nota_objetivoNoThe SSIMULACRA 2 score they all have to reach. 80 by default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the write-but-not-destructive profile is structured data. The description adds genuinely new context: runtime cost (about 7 trials per format, over a minute at 12 MP, ~3 minutes at 24 MP) and the timeout risk that motivates empezar_lote. It does not disclose output file naming, where the comparison report goes, or what happens when no format reaches the target score.

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?

Front-loaded with the purpose, then saving behavior, then cost, then alternatives, then an example — every sentence carries information an agent needs to decide or call. No filler or restatement of the title.

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 12-parameter, nested-object tool with no output schema, the description covers what it returns at a high level (which format is lightest) and the side effects (new files, save all/none/best). What it omits — file naming, the report structure, and no-format-reaches-target behavior — are real but secondary gaps that the rich schema partly absorbs.

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

Parameters3/5

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

Schema coverage is 100% and each parameter already carries a description with defaults and mutual exclusions, so the baseline is 3. The description only restates two defaults (80 score, the guardar modes) that the schema already documents, plus a call example that shows the ruta/formatos shape but adds no syntax beyond 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?

States a specific verb chain (encode the same image in several formats at equal perceived quality, then pick the lightest) and names the comparison metric (SSIMULACRA 2). It also draws the boundary against siblings empezar_lote and optimizar_imagen, so the agent can select it 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 Guidelines5/5

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

Explicit routing: use empezar_lote with mas_ligero for images over ~20 MP because this tool can be cut off by a timeout, and use optimizar_imagen when a single output format is already decided. Both the when and the when-not are stated with the condition that selects the alternative.

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