Skip to main content
Glama

GO AI Tools

Batch image resizer with real presets

resize_images
Read-onlyIdempotent

Resizes a batch of 1+ images to a named real-world preset (App Store screenshots, Open Graph/social cards, Android launcher icon densities, a favicon set) or a custom width/height, using contain (whole picture, padded), cover (fills the frame, crops overflow) or stretch (distorts to fit) fitting. Each resized image is PNG-encoded (EXIF/ICC metadata stripped on re-encode, matching the source page) and every image is auto-rotated per its embedded EXIF orientation before resizing. All outputs are packaged into one uncompressed ZIP (PNG bytes are already compressed, so a second pass would not shrink them), foldered by preset (e.g. "social/photo-1200x630.png", or "android/mipmap-hdpi/icon.png" for the Android density preset, which names each size's folder after its density instead of suffixing the pixel size). This always returns as a resource_link (a batch ZIP is never small enough, or singular enough, to inline) -- fetch the link to get the archive. Per-file output dimensions and byte sizes are reported in the JSON result. Each input image (base64) is capped by this server's per-input byte limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fitNoHow each image fills its target box. 'contain' keeps the whole picture and pads the gap with paddingColor. 'cover' fills the box and crops whatever hangs over. 'stretch' distorts the image to the exact box, ignoring aspect ratio.contain
imagesYesOne to 60 images. Each is resized independently to every size in the chosen preset. A call is additionally capped at 48000000 total output pixels across images x sizes, so a preset with large or numerous sizes admits fewer images than one with small ones.
presetNoWhich size(s) to produce for every image. appstore69: App Store screenshot, 6.9" iPhone, 1320x2868. appstore67: App Store screenshot, 6.7" iPhone, 1290x2796. appstoreIpad: App Store screenshot, 13" iPad, 2064x2752. androidIcon: Android launcher icon, 5 densities (48/72/96/144/192px, each output foldered as mipmap-mdpi/hdpi/xhdpi/xxhdpi/xxxhdpi). favicon: favicon set, 16/32/48/180/192/512px. og: Open Graph card, 1200x630. xcard: X (Twitter) summary card, 1200x628. linkedin: LinkedIn share image, 1200x627. igSquare: Instagram square post, 1080x1080. igPortrait: Instagram portrait post, 1080x1350. igStory: Instagram story, 1080x1920. youtube: YouTube thumbnail, 1280x720. custom: a single arbitrary size taken from customWidth/customHeight.og
customWidthNoTarget width in px. Only used when preset is "custom".
customHeightNoTarget height in px. Only used when preset is "custom".
paddingColorNoHex color (e.g. "#ffffff") used to pad the frame when fit is "contain". Ignored for "cover" and "stretch".#ffffff

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
fitYesHow each image was fitted to its target box.
sizesYesHow many target sizes the chosen preset expands to.
presetYesThe preset that was applied, echoed from the input.
outputsYesEvery produced file, so the archive can be checked without unzipping it.
filesOutYesHow many files were produced, i.e. imagesIn x sizes.
imagesInYesHow many source images were supplied.
paddingColorYesThe letterbox colour, which only applies to fit 'contain'. Null for 'cover' and 'stretch', where nothing is padded.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "filesOut": {
      +      "description": "How many files were produced, i.e. imagesIn x sizes.",
      +      "maximum": 9007199254740991,
      +      "minimum": -9007199254740991,
      +      "type": "integer"
      +    },
      +    "fit": {
      +      "description": "How each image was fitted to its target box.",
      +      "enum": [
      +        "contain",
      +        "cover",
      +        "stretch"
      +      ],
      +      "type": "string"
      +    },
      +    "imagesIn": {
      +      "description": "How many source images were supplied.",
      +      "maximum": 9007199254740991,
      +      "minimum": -9007199254740991,
      +      "type": "integer"
      +    },
      +    "outputs": {
      +      "description": "Every produced file, so the archive can be checked without unzipping it.",
      +      "items": {
      +        "additionalProperties": false,
      +        "properties": {
      +          "bytes": {
      +            "description": "Output size in bytes.",
      +            "maximum": 9007199254740991,
      +            "minimum": -9007199254740991,
      +            "type": "integer"
      +          },
      +          "file": {
      +            "description": "Path of the file inside the ZIP.",
      +            "type": "string"
      +          },
      +          "height": {
      +            "description": "Output height in px.",
      +            "maximum": 9007199254740991,
      +            "minimum": -9007199254740991,
      +            "type": "integer"
      +          },
      +          "source": {
      +            "description": "Which input image this file came from.",
      +            "type": "string"
      +          },
      +          "width": {
      +            "description": "Output width in px.",
      +            "maximum": 9007199254740991,
      +            "minimum": -9007199254740991,
      +            "type": "integer"
      +          }
      +        },
      +        "required": [
      +          "source",
      +          "file",
      +          "width",
      +          "height",
      +          "bytes"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "paddingColor": {
      +      "description": "The letterbox colour, which only applies to fit 'contain'. Null for 'cover' and 'stretch', where nothing is padded.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "preset": {
      +      "description": "The preset that was applied, echoed from the input.",
      +      "type": "string"
      +    },
      +    "sizes": {
      +      "description": "How many target sizes the chosen preset expands to.",
      +      "maximum": 9007199254740991,
      +      "minimum": -9007199254740991,
      +      "type": "integer"
      +    }
      +  },
      +  "required": [
      +    "imagesIn",
      +    "filesOut",
      +    "sizes",
      +    "preset",
      +    "fit",
      +    "paddingColor",
      +    "outputs"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses major behavioral traits: output is always PNG-encoded with EXIF/ICC stripped, images are auto-rotated by EXIF orientation, everything is bundled into an uncompressed ZIP with an explanation of why no second compression pass is done, results always arrive as a resource_link, and per-file dimensions/byte sizes are returned in JSON. It also notes per-input byte caps. This is rich, non-obvious behavior that meaningfully helps an agent anticipate outcomes.

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?

The description is long but information-dense; every sentence carries operational value. It is front-loaded with the core action and fitting modes, then proceeds logically through encoding, packaging, return transport, and limits. Some parentheticals could be trimmed, but the structure is easy to scan and nothing feels redundant.

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?

Given the tool's complexity (multiple presets, fit modes, custom sizes, packaging, limits), the description is nearly exhaustive. It covers input constraints, output format and naming, the always-resource_link return behavior, result contents, and the pixel cap. An output schema exists, so the omission of detailed return schema is acceptable. There is no obvious missing context that would prevent correct invocation.

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

Parameters5/5

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

Schema coverage is 100%, and the description goes well beyond it: it gives concrete ZIP folder naming examples (social/photo-1200x630.png, android/mipmap-hdpi/icon.png) that clarify the preset parameter's effect, explains how the Android density preset names folders instead of suffixing pixel sizes, and calls out the 48,000,000 total output pixel cap and the per-input byte cap on imageBase64. These details materially change how an agent should size a request.

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 opens with a specific verb+resource: 'Resizes a batch of 1+ images to a named real-world preset...' and details fitting modes, output format, and packaging. It is unmistakably clear about what the tool does, but it does not explicitly differentiate itself from overlapping siblings such as generate_favicon_set, generate_app_icon_set, or image_compress, so it stops short of a 5.

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?

Usage is implied through the phrase 'batch of 1+ images' and the preset-oriented workflow; an agent can infer when to reach for this tool. However, the description never names alternatives or states when this tool should be preferred over a single-purpose generator or compressor, nor does it give any when-not-to-use guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources