Skip to main content
Glama
cshum

Imagor MCP

Official

verify_imagor_url

Check whether an imagor composition does what you intended: fetch its result, report each filter as applied, declined, or unknown, and compare dimensions and output against your reference.

Instructions

Fetch the result for a composition from the running imagor and report what it did with each filter: applied, declined, or not reported, plus the dimensions the server reported. Answers whether a composition actually does what it says, which the build tools cannot know on their own. Takes the same typed parameters as build_imagor_url, not a URL. Requires IMAGOR_BASE_URL. A server that does not report filter outcomes returns unknown for every filter and verified: false, which means the result is unknown rather than wrong. Compare the reported dimensions and outcomes against what you intended, and fetch the result to compare it against your reference: a composition can succeed and still be wrong. The rendered result is attached as an image by default, so you can see what you built rather than only reading what the server did with it - use it to check placement, cropping and text against your reference, and iterate until it matches. The image is scaled down, so it shows the layout and not fine detail. Pass preview: false to get the report alone when you do not need to look.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
metaNoreturn image metadata only, without processing the image
trimNotrim surrounding space using the top-left pixel colour
imageYesthe source to transform, not a composed result: a URL or path such as "example.com/a.jpg", or a synthetic source such as "color:red" or "color:none"
smartNouse content-aware smart crop
widthNotarget width in pixels; 0 means automatic
fit_inNofit inside width x height instead of cropping to fill; the result can be smaller than the box on one side
h_flipNomirror horizontally
heightNotarget height in pixels; 0 means automatic
v_flipNomirror vertically
filtersNoordered filters, applied left to right. Arguments are validated against imagor's catalogue: call list_imagor_filters for a filter's signature, description and accepted argument forms. image() loads its argument as its own canvas, so positions inside it are relative to the overlay
h_alignNohorizontal alignment, either "left" or "right"
previewNoattach the rendered result as an image, so a composition that succeeded but came out wrong can be seen. Defaults to true
stretchNostretch to exactly width x height, ignoring aspect ratio, which distorts the image; use full_fit_in to fill a box of a different shape without distorting it
trim_byNotrim anchor, either "top-left" or "bottom-right"
v_alignNovertical alignment, either "top" or "bottom"
crop_topNocrop top edge: a fraction 0-1 of the height, or absolute pixels when greater than 1
crop_leftNocrop left edge: a fraction 0-1 of the width, or absolute pixels when greater than 1
crop_rightNocrop right edge: a fraction 0-1 of the width, or absolute pixels when greater than 1
crop_bottomNocrop bottom edge: a fraction 0-1 of the height, or absolute pixels when greater than 1
full_fit_inNocover the box without cropping: one side matches width x height and the other exceeds it, keeping the aspect. Use for an image that must fill a panel without cutting into it. Requires fit_in, and add upscale() when the source is smaller than the box
allow_declinedNoreturn the report instead of an error when a filter was recognised but left the image unchanged. Set this for a filter that is deliberately conditional; leave it unset to treat a decline as the failure it usually is
preview_regionNoattach part of the result at native resolution as x,y,w,h in result pixels, for checking text and fine detail that a scaled preview cannot show. Takes precedence over preview
trim_toleranceNotrim tolerance from 0 to 255
adaptive_fit_inNoinvert width and height when that yields better definition; requires fit_in
max_age_secondsNoadd a max_age() filter limiting how long the response may be cached
expire_unix_millisNoadd an expire() filter so the URL stops working after this unix-milliseconds timestamp

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoa request path ready to send to imagor, including its signature or unsafe prefix
modeYeshow the path was produced: signed or unsafe
noteNohuman-readable notes about the result
pathYesthe imagor path, without any signature or unsafe prefix
widthNothe result width the server reported, 0 when it reported none
heightNothe result height the server reported, 0 when it reported none
serverYes
signedYeswhether the URL carries a signature
statusYesthe HTTP status the metadata request returned
resultsNo
meta_urlNothe request path for the metadata that was read; its signature differs from the image URL because the signature covers the whole path
verifiedYes
warningsNocompositions that are valid but will not do what was intended
absolute_urlNothe full URL to fetch, present only when IMAGOR_BASE_URL is configured
meta_absolute_urlNothe full metadata URL that was fetched, present only when IMAGOR_BASE_URL is configured

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the IMAGOR_BASE_URL requirement, that a non-reporting server yields unknown for every filter and verified:false (unknown, not wrong), that a composition can succeed and still be wrong, and that the preview is scaled down so only layout, not fine detail, is visible. These are behavioral traits an agent needs and cannot get from schema alone.

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?

Purpose and the key distinction from build tools are front-loaded, and most sentences carry real information (failure mode, comparison workflow, preview tradeoff). It is on the long side and repeats the 'look at the result vs. read the report' idea across several sentences, so it is efficient but not maximal.

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 26-parameter tool with an output schema and no annotations, the description covers the prerequisite, the failure/verification semantics, the preview tradeoff, and points to list_imagor_filters for filter signatures (via the schema). Return-value detail is correctly delegated to the output schema, so nothing essential 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 baseline is 3, and the description adds some meaning beyond it: it clarifies that parameters are passed typed rather than as a pre-built URL, explains the preview default and its scaled-down nature, and tells the agent preview_region takes precedence when fine detail matters. The remaining parameter details are already in the schema, so it is a modest addition rather than a transformation.

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+resource: fetch the result of a composition from the running imagor and report what it did with each filter (applied/declined/not reported) plus reported dimensions. It also distinguishes itself from the sibling build_imagor_url by noting it takes the same typed parameters, not a composed URL, so an agent can route correctly without opening either 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?

Gives clear context and rationale: this answers whether a composition actually does what it says, which the build tools cannot know on their own, and it should be compared against intent and a reference. It also notes when to drop the image (preview: false). It stops short of an explicit 'use build_imagor_url first, then this' workflow statement, so 4 rather than 5.

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