Skip to main content
Glama
mordor-forge

gemini-media-mcp

by mordor-forge

Tile image for upscaling

tile_image

Prepare an image for AI upscaling by cutting it into aspect-ratio-shaped tiles, planning grids or refinement regions, and estimating edit costs before edit_image runs.

Instructions

Upscale step 1: cut an image into crops shaped to the edit model's aspect ratios. longEdge sets the target (1K-16K, default 8K); with grid and imageSize omitted it picks the cheapest plan that covers it (one tile up to about 4K, a 2x2-4x4 grid beyond). regions re-render faces or text in a later pass. Free and local; reports the edit cost. Step 2: edit_image each crop as the result says. Step 3: stitch_tiles. Detail is invented, not recovered.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gridNoCut a grid x grid layout covering the whole image (1-4). Omit it on a first pass to let tile_image pick the cheapest grid that covers longEdge (explained in planNote); a later full-grid pass defaults to 3. Ignored when regions are given.
imageYesThe image to cut: the original photo for the first pass, or the previous stitch_tiles result for a refinement pass. File path, gemini-media:// URI or data: URI.
modelNoImage model the tiles will be edited with (default: the server's default image model; a refinement pass defaults to the model of the pass before). Sets the supported aspect ratios and the cost estimate.
paddingNoContext added around each cell or region, as a fraction of its size (default 0.2, 0.05-0.5). Tiles then grow to the nearest aspect ratio the model supports.
regionsNoRefinement pass: up to 12 areas to re-render (faces, hands, text, materials), as fractions of the image. Omit for a full grid.
longEdgeNoLong edge in pixels of the image stitch_tiles will produce (default 8192, 1024-16384, at most 70 megapixels). First pass only; later passes keep their input's size.
originalNoFirst pass only: the untouched original, sent with every tile as context (as a copy of at most 2048 px). Defaults to image. Refinement passes edit crops alone and keep the first pass's original, so it is ignored there.
imageSizeNoSize the tiles will be edited at (1K, 2K or 4K, as the model supports). Omit it on a first pass to pick it with the grid; otherwise it defaults to the model's largest size.
outputNameNoOptional base name for the crops and the stitched result. Defaults to the original's name.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobYesPass it to stitch_tiles
costYesEstimated cost of editing every tile once (tile_image itself is free)
gridNoGrid size used (grid mode): 1 is the whole image as one tile
modeYesgrid or regions
nextYes
passYes
imageYesSize of the tiled image
modelYes
tilesYes
outputYesSize stitch_tiles will produce
promptYesBase edit_image prompt for every tile of this pass: it keeps each crop's framing. The gemini-upscale skill adds clauses for skin, eyes, hair, text and other materials.
planNoteNoWhy this grid and imageSize were chosen, when picked automatically
warningsNo
imageSizeYes
referenceNoFirst pass only: a copy of the original (at most 2048 px) to pass as edit_image referenceImages for every tile. Refinement passes edit each crop alone.
nativeLongEdgeNoAbout how many pixels of model-rendered detail the output's long edge carries if every tile comes back at imageSize, at most the output's long edge; below it the rest is interpolated

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Adds real context beyond the annotations: 'Free and local; reports the edit cost' and the important caveat 'Detail is invented, not recovered' — a quality warning the readOnlyHint/destructiveHint flags cannot convey. It stops short of disclosing that crops are written to disk or discussing repeat-call behavior, which matters given idempotentHint=false.

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?

Front-loaded with the action statement, then the pipeline, then the caveat; every sentence carries information. It is dense (long parentheticals and a semicolon chain in sentence two) but not padded — each clause encodes a default, a range, or a routing rule.

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?

With nine parameters yet only one required, an output schema covering returns, and annotations covering safety, the description supplies exactly the missing layer: first-pass vs refinement-pass semantics, defaults, cost transparency, and the honesty caveat. Nothing an agent needs to invoke it correctly is absent.

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 already 100%, so the 3 baseline applies, but the description goes further by explaining cross-parameter behavior the schema cannot: omitting grid and imageSize picks the cheapest covering plan (one tile up to ~4K, 2x2–4x4 beyond), and that later passes keep their input's size. Only padding/outputName get no extra narrative.

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?

Opens with a specific verb+resource+scope ('cut an image into crops shaped to the edit model's aspect ratios') and immediately situates itself as step 1 of a three-step pipeline whose other steps are named siblings (edit_image, stitch_tiles). An agent can distinguish it from generate_image or edit_image without opening any 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 sequencing: 'Step 2: edit_image each crop', 'Step 3: stitch_tiles', and 'regions re-render faces or text in a later pass' tells the agent exactly when each mode applies. It also states the fallback behavior when grid and imageSize are omitted, so the agent knows it can call with only the required image.

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