Skip to main content
Glama
mordor-forge

gemini-media-mcp

by mordor-forge

Stitch upscaled tiles

stitch_tiles

Combine edited tiles into one large PNG: align tiles, match color, blend overlaps, and report rejected tiles with seam previews for inspection.

Instructions

Upscale step 3: align each edited tile from tile_image with the image, match its broad color, blend the overlaps and save one large PNG (default 8192 px long edge). Free and local. Reports tiles it rejected (their area keeps the prior pixels) and returns a preview plus 100% crops of the seams to inspect.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobYesThe job uri returned by tile_image.
tilesYesThe edited tiles. Tiles left out keep the underlying image.
detailsNoUp to 6 points to return as 100% crops for inspection. Default: where grid tiles meet, or each region's center.
featherNoBlend width as a fraction of each tile's shorter side (default 0.2, 0.05-0.4). Between neighboring tiles it is capped at half their overlap.
colorMatchNoMatch each tile's broad exposure and color to the image (default true). Fine texture is never transferred.
outputNameNoOptional base name for the stitched PNG.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileYes
nextYes
passYes
tilesYes
detailsNoWhat each detail preview shows, in order
originalYes
warningsNo
referenceYes
nativeLongEdgeNoAbout how many pixels of model-rendered detail the long edge carries, limited by the least detailed tile and at most the output's long edge; 0 when unknown or when part of the image has none

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: free/local, saves a large PNG with a default long edge, rejected tiles keep prior pixels, and it returns a preview plus seam crops. It stops short of explaining overwrite behavior for outputName or job lifecycle details.

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?

Three tightly packed sentences with no wasted words: step context and action first, then free/local status, then rejected-tile behavior and output. Every sentence earns its place and the important constraints are front-loaded.

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 rich structured support (100% schema coverage, annotations, output schema) and a clear process description, the definition is complete enough. It explains the main mutation, side effects on rejected tiles, and return previews without needing to repeat return values from the 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 all six parameters are already documented in the schema. The description reinforces some meaning (tiles as edited tile outputs, colorMatch as broad color matching, details as 100% crops) but adds no syntax or format details beyond what the schema provides. Baseline 3 is appropriate.

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?

States a specific verb (align, blend, save) and resource (edited tiles into one large PNG), and situates it as 'Upscale step 3' referencing tile_image. An agent can distinguish it from siblings like tile_image or edit_image without opening another schema.

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?

The phrase 'Upscale step 3' and 'each edited tile from tile_image' clearly imply this should be used after tile_image/edit_image in a workflow. It provides strong context but does not explicitly state when-not to use it or name alternatives by their tool names.

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