Skip to main content
Glama

AI SENSE Free Public Tools

Convert, vectorize, resize or inspect an image

process_image

Convert a JPEG, PNG, WebP, HEIC or supported static SVG to JPEG, PNG or WebP (format, quality, lossless). Vectorize a PNG or JPEG to black SVG paths on a transparent background (threshold). The trace fits within 1024 by 1024 pixels. For JPEG, PNG or WebP, compress (quality), resize (width, height, fit contain or cover, upscale, format), read metadata including any GPS position (metadata), strip EXIF, XMP and IPTC (strip), find its main colors (colors, count) or make favicons as a ZIP (favicon, crop fit, trim or center, name). Resize also accepts HEIC. Metadata and strip also accept GIF. Give image_base64 or storage_id, for example the result of an earlier call. Every result is stored for 24 hours and the answer carries its storage_id, so calls can be chained. No API key, no account and no sign up.

Input Schema

NameRequiredDescriptionDefault
fitNoFor resize to a width and a height: contain keeps the whole image inside the box, cover fills the box and crops what sticks out.
cropNoFor favicon: fit pads the image to a square, trim removes plain borders first and then pads, center fills the square and crops what sticks out.
nameNofavicon only: the site name for the manifest.
countNoFor colors, how many main colors to find, 2 to 16.
widthNoTarget width in pixels for resize, 1 to 10000.
formatNoThe output format for convert and resize: jpeg, png or webp. jpg is the same as jpeg.
heightNoTarget height in pixels for resize, 1 to 10000.
qualityNoQuality from 40 to 95 for JPEG and lossy WebP output.
upscaleNoFor resize, true lets the image grow beyond its original size.
losslessNoFor WebP output, true stores the image losslessly and ignores quality.
operationYesconvert to another format, vectorize to SVG paths, compress, resize, read metadata, strip metadata, find the main colors, or make favicons.
thresholdNoBrightness threshold in percent for vectorize. Higher values include lighter pixels.
storage_idNoA storage_id from store_file, from a previous tool result, or from REST /storage. Objects expire 24 hours after they were stored.
image_base64NoThe file as standard base64, at most about 190 KB of file through MCP. For a larger file, store it with REST POST /services/v1/storage first and pass storage_id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • addedInput schema / properties / count / description
      Added value: +"For colors, how many main colors to find, 2 to 16."
    • addedInput schema / properties / crop / description
      Added value: +"For favicon: fit pads the image to a square, trim removes plain borders first and then pads, center fills the square and crops what sticks out."
    • addedInput schema / properties / fit / description
      Added value: +"For resize to a width and a height: contain keeps the whole image inside the box, cover fills the box and crops what sticks out."
    • addedInput schema / properties / format / description
      Added value: +"The output format for convert and resize: jpeg, png or webp. jpg is the same as jpeg."
    • addedInput schema / properties / height / description
      Added value: +"Target height in pixels for resize, 1 to 10000."
    • addedInput schema / properties / lossless / description
      Added value: +"For WebP output, true stores the image losslessly and ignores quality."
    • addedInput schema / properties / operation / description
      Added value: +"convert to another format, vectorize to SVG paths, compress, resize, read metadata, strip metadata, find the main colors, or make favicons."
    • addedInput schema / properties / quality / description
      Added value: +"Quality from 40 to 95 for JPEG and lossy WebP output."
    • addedInput schema / properties / upscale / description
      Added value: +"For resize, true lets the image grow beyond its original size."
    • addedInput schema / properties / width / description
      Added value: +"Target width in pixels for resize, 1 to 10000."
  2. Changed2 schema fields changed
    • changedInput schema / properties / operation / enum
      Previous value: -[
      -  "convert",
      -  "compress",
      -  "resize",
      -  "metadata",
      -  "strip",
      -  "colors",
      -  "favicon"
      -]New value: +[
      +  "convert",
      +  "vectorize",
      +  "compress",
      +  "resize",
      +  "metadata",
      +  "strip",
      +  "colors",
      +  "favicon"
      +]
    • addedInput schema / properties / threshold
      Added value: +{
      +  "default": 50,
      +  "description": "Brightness threshold in percent for vectorize. Higher values include lighter pixels.",
      +  "maximum": 99,
      +  "minimum": 1,
      +  "type": "integer"
      +}
  3. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare non-read-only, non-destructive, non-idempotent, closed-world behavior, so the bar is lower; the description still adds real context: no API key/account required, results persist 24 hours and are keyed by storage_id enabling chained calls, and vectorize output is bounded to 1024x1024. It does not describe output payload shapes per operation, which is the remaining gap.

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 single dense paragraph but every clause carries information, grouped roughly by operation, with input mechanics and expiry placed at the end. The operation-to-parameter associations are scattered rather than front-loaded as a list, which slightly hurts scannability for a 14-parameter tool.

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, eight-operation tool with no output schema, the description covers supported formats, operation/parameter mapping, input sourcing, result persistence, and auth requirements. What is missing is any statement of return payloads (metadata contents, color output shape, ZIP structure), 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.

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description mostly restates what the schema documents (quality, lossless, threshold, width/height/fit, count, crop/name) and adds only a little meaning beyond it, notably the 1024x1024 trace bound for vectorize and the operation-to-parameter mapping (which params belong to which operation).

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 names a concrete resource (images) and enumerates each of the eight operations with the exact input/output formats they accept: convert JPEG/PNG/WebP/HEIC/SVG, vectorize PNG/JPEG to SVG paths, resize, compress, metadata, strip, colors, favicon. It is far more specific than the title and leaves no ambiguity about what the tool does.

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 gives operational routing guidance (which format each operation accepts, e.g. resize also accepts HEIC, metadata and strip also accept GIF) and explains how to supply input via image_base64 or storage_id, including chaining through returned storage_ids. There is no explicit when-not-to-use statement or pointer to an alternative, though no sibling tool overlaps with image processing, so the omission is minor.

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.