Skip to main content
Glama

Fit files under an upload limit

fit_file

Compress PDFs or images to fit an upload limit, or a form's size and pixel rules, and save the result beside the original with .fit added.

Instructions

Compress a PDF or image (JPEG, PNG, WebP, TIFF, BMP, or an iPhone HEIC photo, which comes back as a JPEG) on this computer so it fits an upload limit, keeping as much quality as the limit allows, and save the result next to the original as ".fit.". Give path for one file or paths for up to 10 that share the same limit. Give either limit (like "200KB" or "1.5MB"; KB and MB are 1000-based, so the file passes a check done either way) or form (a form preset from list_forms, like "ibps-signature" or "us-visa-photo-ds160", which sets the limit, minimum size and exact pixels that form requires). Every file keeps its format unless jpeg_ok is true. Files up to 50 MB are uploaded to fitfilesize.com over HTTPS, compressed there, and deleted from the server as soon as each result is saved. Free, no account.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fitNoWhen width and height change the shape: "crop" to fill (default) or "pad" with white.
formNoA form preset id or name from list_forms, like "ibps-photo". Use this or `limit`.
pathNoFull path to the file on this computer ("~/" is allowed). Use this or `paths`.
limitNoUpload limit, like "200KB", "50 KB" or "1.5MB". Use this or `form`.
pathsNoFull paths to several files that share the same limit, up to 10. Use this or `path`.
widthNoExact width in pixels (images only).
heightNoExact height in pixels (images only).
outputNoWhere to save the result, with `path` only. Defaults to "<name>.fit.<ext>" beside the original.
jpeg_okNoLet a PNG, WebP, TIFF or BMP come back as a JPEG when that is what fits. Only if the upload accepts JPEG; by default every file keeps its format.
minimumNoSmallest allowed size, like "10KB", for forms that set one. A small JPEG is padded up to it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important behavior: files up to 50 MB are uploaded over HTTPS to fitfilesize.com, compressed remotely, and deleted as soon as each result is saved. It also states that results are saved beside the original as `<name>.fit.<ext>` and that formats are preserved unless `jpeg_ok` is true.

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?

The purpose and key constraint are front-loaded, followed by parameter-selection guidance and upload behavior. The text is dense but contains no filler, and each clause carries actionable information.

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?

For a 10-parameter tool with no output schema, the description covers the operation, save location, upload handling, format behavior, and parameter alternatives. Nothing essential for correct invocation is 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 100%, so the baseline is 3, but the description adds meaning: KB/MB are 1000-based, form presets set limit/minimum/exact pixels, HEIC returns as JPEG, and `jpeg_ok` controls format conversion. It does not document every parameter in depth, but it adds useful semantics 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?

The description names a specific verb (compress) and resource (PDF or image), states the goal (fit an upload limit), and identifies the output naming pattern. It also distinguishes itself from the sibling list_forms by pointing there for form presets.

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?

It explicitly covers the main usage choices: `path` for one file or `paths` for up to 10 sharing a limit, and `limit` versus `form`, with list_forms named for preset discovery. The constraints and alternatives are clear enough that an agent can select the right inputs without inference.

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

Deploy Server

Other Tools