Skip to main content
Glama

image.marketplace_check

Read-only

Check a product photo against a marketplace's listing-image rules before the seller uploads it: shopee, lazada or tiktok_shop. Free and read-only: the platform's own deterministic check, which stores nothing, calls no marketplace and uploads nothing. Returns JSON {images: [], price ($0.00), output: {verdict (pass, fail or partial), failed, advice, skipped, file: {width, height, format, bytes}, rules: [{rule, level (required or recommended), status (pass, fail or skipped), expected, measured, fix, reason, source, checked, note}]}, next}. It checks the minimum and maximum size, the square shape, the file type, the file size and a white background; each rule names its source page and the day it was read, and a figure read through search results says UNVERIFIED in its note. The background is read from the pixels, up to 4,194,304 pixels (for example 2048x2048); a JPEG, WebP, GIF, HEIC or interlaced PNG is read through the Images binding at no charge. That one rule is skipped, with every other verdict kept, for a larger image (reason SIMPLER_EDIT_SERVER_PIXELS_TOO_LARGE: run image.convert with width and height 2048, then check the copy), or with the binding's reason when it cannot read the image: SIMPLER_IMAGES_BINDING_ABSENT when this deployment has no Images binding yet (owner step O-2: send a standard PNG copy to check it), or SIMPLER_IMAGES_QUOTA_EXCEEDED, SIMPLER_IMAGES_LEGACY_SUBSCRIPTION, SIMPLER_IMAGES_INPUT_UNREADABLE, SIMPLER_IMAGES_INPUT_TOO_LARGE or SIMPLER_IMAGES_TRANSFORM_FAILED, each with its fix in the rule. Added text and watermarks are skipped with reason SIMPLER_EDIT_MARKETPLACE_TEXT_CHECK_UNAVAILABLE or SIMPLER_EDIT_MARKETPLACE_WATERMARK_CHECK_UNAVAILABLE until the vision check lands (look at the image yourself). Refuses: SIMPLER_MEDIA_INPUT_MISSING (pass the url or the asset_key), SIMPLER_MEDIA_FOREIGN_KEY (use this workspace's asset_key), SIMPLER_MEDIA_URL_REFUSED (use https, data:image or an asset_key), SIMPLER_MEDIA_PIN_TOO_LARGE (under 20MB); VALIDATION_ERROR for a platform outside the list; VALIDATION_ERROR whose reason is SIMPLER_MEDIA_EMPTY, SIMPLER_MEDIA_UNKNOWN_TYPE, SIMPLER_MEDIA_KIND_NOT_ALLOWED, SIMPLER_MEDIA_SVG_REFUSED or SIMPLER_MEDIA_DIMENSIONS_UNREADABLE (send a JPEG, PNG, WebP, GIF or HEIC) or SIMPLER_MEDIA_PNG_CORRUPT (save it again as a standard PNG); for a HEIC only, the binding's reason when it cannot read the size (SIMPLER_IMAGES_BINDING_ABSENT while this deployment has no Images binding: send a JPEG or PNG copy); and INSUFFICIENT_CREDITS or PAYMENT_REQUIRED only when the workspace is already overdrawn or past its spend cap (add credits or raise the cap). NEXT: apply each failed rule's fix, for example image.add_shadow with transparent false and background #ffffff for a white background, or image.convert with format jpeg (and width and height for a size rule) for a file type, size or file-size failure, and check again.

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": {
      "platform": "<platform>"
    },
    "name": "image.marketplace_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
platformYesThe marketplace whose listing-image rules to check: shopee, lazada or tiktok_shop.
image_urlNoProduct photo to check: a public https URL, a data:image/...;base64 URL, or the url/url_path of an earlier image result (max 20MB; PNG, JPEG, WebP or GIF; SVG is refused). Pass this or the matching *_asset_key, not both.
image_asset_keyNoProduct photo to check, as the asset_key of an earlier image result for this workspace (edit-projects/<tenant>/... or images/<tenant>/...). A key from another workspace is refused (SIMPLER_MEDIA_FOREIGN_KEY).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

The description goes far beyond readOnlyHint=true: it says the check is free, stores nothing, calls no marketplace, uploads nothing, and reads pixels only up to 4,194,304 pixels. It also discloses skip behavior, exact skip/refusal codes and fixes, and the conditions under which each rule may be skipped.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The key purpose is front-loaded, but the rest is a dense single paragraph that catalogs many error and skip codes inline. It is hard to scan and includes details that could be moved or omitted, so it is not appropriately concise.

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?

There is no output schema, yet the description fully describes the JSON response, including verdict, failed, advice, skipped, file metadata, per-rule fields, and next. It also explains failure and skip conditions thoroughly, making the definition complete for an agent to call and interpret.

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 input schema already documents platform, image_url and image_asset_key. The description reinforces source and size constraints and notes that a foreign key is refused, but it adds little beyond the structured schema. Baseline 3 applies.

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 uses a specific verb and resource: check a product photo against a marketplace's listing-image rules before upload, with the exact platforms enumerated. It clearly distinguishes itself from sibling transformation tools by framing itself as a deterministic pre-upload check.

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?

It states the operative moment (before the seller uploads) and gives follow-up guidance: apply each failed rule's fix, then check again, naming image.add_shadow and image.convert as relevant siblings. It does not explicitly state when not to use this tool, but the context is otherwise clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources