Skip to main content
Glama

crop_image

Crops an image to a centered aspect ratio or a specified region and writes a new file next to the input unless an output path is provided.

Instructions

Crop an image to a centred aspect ratio (ratio) or to a region (box). Give one of them. Writes a new file next to the input (name-cropped.ext) unless output is given, never replaces a file unless overwrite is true, and returns the path, format and size change.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "crop_image"
  }
}

Input Schema

NameRequiredDescriptionDefault
boxNoRegion to keep, as fractions of the image
pathYesAbsolute path (or ~/…) of the image to read: JPEG, PNG, WebP, AVIF or HEIC. HEIC is written as JPEG unless a format is chosen.
ratioNoCentred crop, like "1:1" or "16:9"
outputNoWhere to write. Default: next to the input, like photo-resized.jpg
qualityNoQuality for lossy output (JPEG, WebP, AVIF), 1–100. PNG ignores it
overwriteNoReplace an existing output file. Default false

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.2
    • changedInput schema / properties / box / description
      Previous value: -"Fractions of the image, 0–1, from the top left"New value: +"Region to keep, as fractions of the image"
    • changedInput schema / properties / quality / description
      Previous value: -"1–100"New value: +"Quality for lossy output (JPEG, WebP, AVIF), 1–100. PNG ignores it"
  2. First observedv0.1.0

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden. It does valuable work by stating the default write location and naming convention (name-cropped.ext), that existing files are never replaced unless overwrite is true, and that the return covers path, format and size change; what remains undisclosed is the failure mode for conflicting or missing mode arguments and any permission or size limits on the write.

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 purpose and the ratio/box choice are front-loaded, and the second half folds destination, overwrite safety and return value into one dense but readable clause set. Every clause carries information, though the run-on structure makes the write-safety rules slightly harder to parse than a short list would.

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 six-parameter tool with a nested region object and no output schema, the definition covers the essentials: both crop modes, where output lands, overwrite protection, and the shape of the return value. It is only short of complete in not clarifying the error or precedence case when both ratio and box are provided.

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 and the schema already explains box fractions, ratio syntax, quality and overwrite defaults. The description adds the genuinely non-structural fact that ratio and box are alternative modes rather than co-supplied options, which is a real gain over the schema, but it adds nothing further on output path rules or quality behavior.

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?

"Crop an image to a centred aspect ratio (ratio) or to a region (box)" is a specific verb plus resource with both operating modes named, so the agent knows exactly what the tool does. It does not explicitly separate itself from near-neighbours such as resize_image or generate_thumbnail, which are the tools an agent could plausibly confuse this with.

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?

"Give one of them" is a useful and explicit constraint that tells the agent ratio and box are mutually exclusive. There is no guidance, however, on when crop is the right choice versus resize_image, generate_thumbnail, or convert_image, and no statement of what happens if both or neither are supplied.

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