quokkapix-mcp
OfficialThe QuokkaPix MCP server lets AI agents automate browser-based image processing workflows locally via Playwright-driven Chromium, keeping image files on the user's machine (no server-side upload).
Core Image Processing
process_images– Process local files using an official recipe (e.g.,shopify_product_pack,metadata_clean_batch) or a custom recipe object; opens a local browser, uploads files, downloads output, and writesquokkapix-result.jsonwith QA flags (qaOk,processingOk)process_with_settings– Process images using a directwindow.QuokkaPixAgent.applySettingspayload for fully custom workflows (resize, crop, rotate, convert, compress, background removal/replacement, watermark, effects, PDF, favicon, multi-step scenarios); supports optional watermark logo and background image assets
Recipe Discovery & Validation
list_recipes– List 30+ official recipes covering Shopify, Amazon, Google Merchant, Etsy, eBay, Walmart, TikTok Shop, WebP compression, metadata cleanup, social packs, favicons, watermarking, and moreget_recipe– Retrieve full recipe details includingapplySettings, file limits, payment requirements, and QA contractvalidate_recipe– Preflight-validate a custom recipe before processing (no browser opened)
Marketplace Rule Profiles
list_rule_profiles– List image rule profiles for Amazon, Shopify, Google Merchant, Etsy, eBay, Walmart, TikTok Shop, Instagram, YouTube, LinkedIn, Pinterest, Facebook, and moreget_rule_profile– Retrieve a specific rule profile with requirements, recommendations, source URL, and confidence level
QA & Result Validation
validate_result_manifest– Validate an existingquokkapix-result.jsonagainst a recipe or custom QA contract; checks status, file counts, formats, dimensions, size limits, ZIP entries, and marketplace metadata rules
Payment & Unlock Token Management
get_payment_options– Fetch live payment policy: free tiers (single image or batches up to 5 files), paid tier (0.01 USDC for 6–50 files via Coinbase x402)explain_payment_flow– Step-by-step guidance on the x402 payment workflowverify_unlock_token– Preflight-verify or consume a paid unlock token before a batch run
Designed for use with Claude Desktop, Cursor, LM Studio/Ollama wrappers, and other stdio-based MCP clients. A standalone quokkapix-runner CLI is also available.
Provides tools for processing product images for Amazon, including an 'amazon_white_background_pack' recipe to create white background product photos suitable for Amazon.
Provides tools for processing product images for Google Merchant, including a 'google_merchant_pack' recipe that generates images optimized for Google Merchant Center.
Provides tools for processing product images for Shopify, including a 'shopify_product_pack' recipe that generates optimized photos for Shopify listings.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@quokkapix-mcpprocess images in ./photos with Shopify product pack recipe"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
QuokkaPix MCP Runner
Local-first MCP adapter and cloud-to-local execution bridge for private QuokkaPix image workflows.
QuokkaPix MCP Runner lets AI agents process local image files with QuokkaPix by opening the QuokkaPix web app in a local browser, applying an official recipe or direct settings payload, uploading files through the browser file input, downloading the result, and writing a machine-readable quokkapix-result.json.
It supports two compatible modes:
local
stdiofor Claude Desktop, Cursor, LM Studio/Ollama wrappers and other local MCP clients;bridgefor remote MCP clients such as Claude web, while Chromium and image processing remain on the user's computer.
Repository: https://github.com/quokkapix/quokkapix-mcp
npm package: https://www.npmjs.com/package/quokkapix-mcp
Glama listing: https://glama.ai/mcp/servers/quokkapix/quokkapix-mcp
mcpservers.org listing: https://mcpservers.org/servers/quokkapix/quokkapix-mcp
Browser compatibility matrix: https://quokkapix.com/en/browser-compatibility/
Browser benchmark: https://quokkapix.com/en/browser-image-processing-benchmark/
Quick start:
npx quokkapix-mcpCloud-to-local bridge:
npx quokkapix-mcp bridge --input-root ./images --output-root ./quokkapix-outputWhat This Is
This package is a local automation adapter around the browser app at:
https://quokkapix.com/#agent=1The adapter uses Playwright to drive a local Chromium browser. The browser runs the same QuokkaPix editor that humans use, including the in-browser window.QuokkaPixAgent API.
Image files are processed in the user's browser runtime. During normal processing, source image bytes are not uploaded to a QuokkaPix image-processing server.
The optional bridge mode connects outward to the QuokkaPix control plane. The remote MCP endpoint relays tool settings, relative file names, status and result metadata. It does not expose an image upload endpoint and does not relay source or output image bytes.
Related MCP server: Media Toolkit MCP Server
What This Is Not
This package is not:
a public server-side image processing API;
a hosted image-processing service (the remote MCP control plane only coordinates a paired local bridge);
a GPU/CPU image-processing backend run by QuokkaPix;
a way to pass local file paths to
quokkapix.comby URL;a replacement for browser memory limits.
Local file paths are available only to the local MCP runner on the user's machine. The public QuokkaPix website still receives files only through the browser file input or dropzone.
Why Use It
Use this adapter when an AI agent needs to run repeatable image workflows like:
prepare product photos for Shopify, Amazon, or Google Merchant;
validate marketplace and social image outputs against sourced rule profiles;
compress images to WebP for a website;
remove EXIF/GPS metadata;
generate social media image packs;
watermark a batch of images;
generate favicon and app icon packs;
run custom QuokkaPix settings without manually clicking the UI.
The main value is privacy and low infrastructure cost: the agent gets a practical image workflow tool, while image processing remains local in the user's browser.
Architecture
AI agent / MCP client
|
| stdio MCP
v
quokkapix-mcp
|
| Playwright
v
local Chromium browser
|
| window.QuokkaPixAgent + stable data-agent selectors
v
https://quokkapix.com/#agent=1
|
| local browser processing
v
downloaded output + quokkapix-result.jsonRemote clients use the same package in bridge mode:
Claude web / remote MCP client
|
| OAuth 2.1 + Streamable HTTP (commands and metadata only)
v
QuokkaPix control plane
|
| outbound authenticated long poll
v
quokkapix-mcp bridge on the user's computer
|
| Playwright
v
local Chromium -> local output + quokkapix-result.jsonThe adapter saves:
the generated image, ZIP, or PDF output;
quokkapix-result.json;a
qaobject returned to the agent.
Requirements
Node.js
>=20npm
Playwright Chromium
internet access for loading QuokkaPix and browser-side dependencies/models when needed
local file paths that the MCP process can read
Bridge mode additionally requires explicit input and output roots. Remote calls cannot read or write outside those roots.
Install dependencies:
npm install
npx playwright install chromiumRemote MCP And Bridge Setup
Start the existing package in bridge mode:
npx -y quokkapix-mcp bridge \
--input-root /absolute/path/to/input \
--output-root /absolute/path/to/outputApprove the one-time pairing URL printed by the command.
Add
https://quokkapix.com/mcpas a custom remote MCP connector.Complete OAuth authorization in the browser.
The bridge stores its random device credential in ~/.quokkapix/bridge.json with owner-only permissions where the operating system supports them. Use --pair to approve another browser session or --reset to revoke the old device authorization and create a new credential.
Remote processing paths are relative to --input-root and --output-root. The bridge rejects path traversal and does not return absolute local paths to the cloud client.
MCP Tools
list_recipes
Lists official QuokkaPix recipes.
Use first when the agent does not know which workflow to run.
get_recipe
Returns one recipe by id, including:
applySettings;file limits;
expected output;
QA contract;
payment requirement.
Input:
{
"id": "shopify_product_pack"
}validate_recipe
Validates a custom recipe object before processing.
This does not upload files and does not start processing.
list_rule_profiles
Lists sourced marketplace and social image rule profiles.
Use this when an agent needs facts for Amazon, Shopify, Google Merchant, Etsy, eBay, Walmart, TikTok Shop, Mercado Libre, Temu, Shopee, Instagram, YouTube, LinkedIn, X, Pinterest, Facebook or TikTok before choosing a workflow or checking an output.
Every profile declares:
sourceType:officialorsecondary;sourceUrl;confidence;requirements and recommendations that were found from the named source.
The runner does not invent missing marketplace requirements. Temu, Mercado Libre, Shopee and some YouTube entries are marked as secondary or category/country-specific where official public specs were limited.
get_rule_profile
Returns one rule profile by id, for example:
{
"id": "amazon.product.image"
}Agents can pass the returned facts into their own planning, or call validate_result_manifest with ruleProfileId.
validate_result_manifest
Validates an existing quokkapix-result.json against a recipe or custom QA contract.
This is useful when an agent wants to inspect a previous run and decide whether the output is acceptable.
Optional input:
{
"ruleProfileId": "amazon.product.image",
"manifest": {}
}When ruleProfileId is provided, the QA report includes sourced marketplace checks such as supported formats, dimensions, source type and URL. If the browser result manifest includes outputs[].pixelQa, the validator also evaluates supported pixel-level visual checks such as white background, subject centering, safe margins and transparent background.
process_images
Processes local image files through QuokkaPix using either:
an official
recipeId;a full custom recipe object.
It opens a browser, applies the recipe, uploads files, starts processing, downloads the output, writes quokkapix-result.json, and returns QA results.
Optional local asset files:
watermarkLogoFile: local logo/image file uploaded into QuokkaPix's watermark logo input.backgroundImageFile: local image file uploaded into QuokkaPix's background replacement image input.
These assets are still uploaded only into the local browser page. They are not passed as URL paths to the public QuokkaPix website.
process_with_settings
Processes local image files using a direct QuokkaPix applySettings payload.
Use this when the agent already knows the exact editor settings and does not want to wrap them in a recipe.
This is the broadest tool surface. It can drive the same settings surface as:
window.QuokkaPixAgent.applySettings(payload)Supported editor areas depend on the QuokkaPix browser contract and include:
resize;
crop;
rotate;
convert;
compress;
advanced export to browser-supported formats and experimental JPEG XL when the browser-loaded encoder is available;
metadata removal/reporting;
PDF merge/split/extract tools through
tool=pdfandpdf.operationfor uploaded PDF files only; ZIP archives are accepted only for PDF merge and only PDF entries are extracted;background removal/replacement settings;
watermark;
effects;
rename;
constructor/scenario workflows.
For custom scenarios, prefer the explicit structured form:
{
"mode": "batch",
"tool": "constructor",
"steps": [
{
"tool": "resize",
"settings": { "mode": "fit", "width": 1200, "height": 1200 }
},
{
"tool": "watermark",
"settings": { "type": "text", "text": "Brand", "layout": "tiled", "angle": -20 }
},
{
"tool": "compress",
"settings": { "format": "webp", "quality": 0.82 }
}
]
}Step settings use the same section keys as window.QuokkaPixAgent.applySettings.
PDF tools use PDF uploads instead of image uploads:
{
"tool": "pdf",
"pdf": {
"operation": "extract",
"extractPages": "1,3-5",
"extractOutput": "pdf"
}
}Use operation: "split" to export one uploaded PDF as a ZIP of one-page PDFs. Use operation: "extract" with extractPages to create one PDF containing only the selected pages from one uploaded PDF; page order is preserved, so extractPages: "3,1" exports page 3 before page 1. Set extractOutput: "zip" when the selected pages should be returned as separate one-page PDFs inside a ZIP. tool: "pdf" defaults to split. Split and extract are single-PDF workflows because page numbers refer to one source PDF. Use operation: "merge" to combine multiple PDFs into one PDF in the current browser file order; merge is a batch workflow and switches the browser editor to batch mode. Human users can reorder merge files in the UI; MCP clients should pass files in the desired merge order.
ZIP upload is batch-only. If a user or agent selects a .zip in batch mode, QuokkaPix unpacks it locally in the browser and adds supported images from the archive to the batch queue. RAR and 7z are not accepted.
get_payment_options
Fetches QuokkaPix agent payment policy and x402 endpoints.
This does not perform a payment.
explain_payment_flow
Explains the current x402 payment flow for agents.
Important: this local MCP adapter does not sign x402 payments by itself. An x402-capable client or wallet must call the paid unlock endpoint and return an unlockToken.
verify_unlock_token
Verifies a paid agent unlock token before processing.
Use consume: false for preflight checks.
Only use consume: true if you intentionally want to consume the unlock immediately.
Remote-only bridge tools
The hosted remote MCP endpoint also exposes:
get_bridge_statusto check pairing and local availability;get_billing_statusto check whether a verified one-time unlock is staged;set_unlock_tokento stage an x402 unlock for the next paid local batch.
Remote verify_unlock_token is preflight-only and never consumes the token. Actual consumption remains inside the local browser start path.
Official Recipes
The runner loads recipes from the local project if present. If local recipe files are absent, it falls back to:
https://quokkapix.com/agent-recipes/Current official recipes:
Recipe id | Purpose | Mode | Output |
| Shopify product photos | batch | ZIP |
| Amazon-style white background product photos | batch | ZIP |
| Google Merchant product images | batch | ZIP |
| Etsy product image batch with sourced QA | batch | ZIP |
| eBay listing photo batch | batch | ZIP |
| Walmart product main images | batch | ZIP |
| TikTok Shop product images | batch | ZIP |
| Temu-style product images with secondary source | batch | ZIP |
| Shopee product images | batch | ZIP |
| Mercado Libre accessory photos | batch | ZIP |
| Allegro listing images | batch | ZIP |
| Newegg product images | batch | ZIP |
| Meta Catalog product images | batch | ZIP |
| Flipkart product photos from public guidance | batch | ZIP |
| SHEIN square product images with secondary source | batch | ZIP |
| OTTO product images with sourced 500 x 1000 px minimum QA | batch | ZIP |
| Trendyol product images at sourced 1200 x 1800 px size | batch | ZIP |
| Snapchat static ad images | batch | ZIP |
| Website image compression to WebP | batch | ZIP |
| General WebP batch conversion and compression | batch | ZIP |
| White background product images with soft shadow | batch | ZIP |
| Remove EXIF/GPS/camera/software metadata | batch | ZIP |
| Compress one image to WebP | single | image |
| Remove background from one image | single | image |
| Create one white-background product image | single | image |
| Remove metadata from one image | single | image |
| Apply a text watermark to one image | single | image |
| Merge selected images or scans into one PDF | batch | |
| Social media sizes from one image | single | ZIP |
| Profile avatar sizes from one image | single | ZIP |
| Apply watermark to product images | batch | ZIP |
| Generate favicon and app icon sizes | single | ZIP |
Agents should usually call list_recipes, choose the closest recipe, then call process_images.
Use process_with_settings when the desired workflow is not covered by a recipe.
Install From Source
From the mcp-runner folder:
npm install
npx playwright install chromium
npm run checkStart the MCP server:
npx quokkapix-mcpDirect CLI run without an MCP client:
npx quokkapix-runner --recipe website_webp_compress --input ./photo.jpg --output ./outMCP Client Configuration
For most users, configure the published npm package directly:
{
"mcpServers": {
"quokkapix": {
"command": "npx",
"args": ["-y", "quokkapix-mcp"],
"env": {
"QUOKKAPIX_APP_URL": "https://quokkapix.com/#agent=1"
}
}
}
}Use absolute paths for cwd.
Claude Desktop From Source
If you cloned the GitHub repository instead of using npm, add this to your Claude Desktop MCP config:
{
"mcpServers": {
"quokkapix": {
"command": "node",
"args": ["src/server.mjs"],
"cwd": "/absolute/path/to/quokkapix-mcp",
"env": {
"QUOKKAPIX_APP_URL": "https://quokkapix.com/#agent=1"
}
}
}
}Cursor From Source
If you cloned the GitHub repository instead of using npm, use the same server definition in Cursor MCP settings:
{
"mcpServers": {
"quokkapix": {
"command": "node",
"args": ["src/server.mjs"],
"cwd": "/absolute/path/to/quokkapix-mcp",
"env": {
"QUOKKAPIX_APP_URL": "https://quokkapix.com/#agent=1"
}
}
}
}Local Development
Run QuokkaPix locally and point the runner to it:
QUOKKAPIX_APP_URL=http://127.0.0.1:4177/#agent=1 npx quokkapix-mcpOverride the local site root:
QUOKKAPIX_SITE_ROOT=/path/to/quokkapix-site npx quokkapix-mcpOverride the public recipe source:
QUOKKAPIX_RECIPE_BASE_URL=https://quokkapix.com/agent-recipes npx quokkapix-mcpOverride payment base URL:
QUOKKAPIX_PAYMENT_BASE_URL=https://quokkapix.com npx quokkapix-mcpappUrl is intentionally restricted for local-file safety. By default the runner only opens:
https://quokkapix.com/andhttps://www.quokkapix.com/;http://127.0.0.1,http://localhostand local HTTPS equivalents.
This prevents a malicious prompt or recipe from pointing the browser runner at an unrelated page and uploading local files there. For trusted development only, custom app URLs can be enabled with:
QUOKKAPIX_ALLOW_CUSTOM_APP_URL=1 npx quokkapix-mcpExample: Process Product Photos For Shopify
Tool: process_images
{
"recipeId": "shopify_product_pack",
"inputFiles": [
"/Users/me/products/photo-1.jpg",
"/Users/me/products/photo-2.jpg"
],
"outputDir": "/Users/me/products/out",
"headless": true
}Expected output:
a ZIP file in
outputDir;quokkapix-result.json;a returned
qareport.
The tool result separates processing success from QA success:
processingOk: truemeans QuokkaPix completed and produced an output file;qaOk: truemeans the output passed the recipe QA checks;top-level
okfollowsqaOk, so agents should not treat a failed QA run as fully successful.
Example: Direct Custom Settings
Tool: process_with_settings
{
"settings": {
"mode": "single",
"tool": "compress",
"settings": {
"compress": {
"format": "webp",
"quality": 0.82,
"targetEnabled": false
}
}
},
"settingsId": "custom-webp-compress",
"expectedResultQa": {
"profile": "custom-webp-compress",
"expectedFormat": "webp"
},
"inputFiles": ["/Users/me/images/photo.jpg"],
"outputDir": "/Users/me/images/out"
}Use this for custom workflows that are not official recipes.
Example: Logo Watermark Asset
Tool: process_with_settings
{
"settings": {
"mode": "single",
"tool": "watermark",
"settings": {
"watermark": {
"type": "image",
"layout": "single",
"position": "center",
"scalePercent": 20,
"opacity": 0.25
}
}
},
"watermarkLogoFile": "/Users/me/brand/logo.svg",
"inputFiles": ["/Users/me/images/photo.jpg"],
"outputDir": "/Users/me/images/out"
}Example: Background Image Asset
Tool: process_with_settings
{
"settings": {
"mode": "batch",
"tool": "constructor",
"steps": [
{
"tool": "background",
"settings": {
"mode": "replace",
"replaceMode": "chroma",
"fill": "image",
"sourceColor": "#ffffff",
"tolerance": 36,
"exportFormat": "webp"
}
},
{
"tool": "compress",
"settings": { "format": "webp", "quality": 0.82 }
}
]
},
"backgroundImageFile": "/Users/me/backgrounds/studio.webp",
"inputFiles": ["/Users/me/products/photo-1.jpg", "/Users/me/products/photo-2.jpg"],
"outputDir": "/Users/me/products/out"
}This two-file batch is inside the free small-batch limit. Add an unlockToken only for larger paid agent batch/scenario runs.
Example: Metadata Cleanup
Tool: process_images
{
"recipeId": "metadata_clean_batch",
"inputFiles": [
"/Users/me/private/photo-1.jpg",
"/Users/me/private/photo-2.jpg"
],
"outputDir": "/Users/me/private/clean"
}For batch runs, see the payment section below.
Example: QA-Only Validation
Tool: validate_result_manifest
{
"recipeId": "shopify_product_pack",
"manifest": {
"status": "done",
"source": {
"count": 1,
"totalBytes": 1000
},
"outputs": [
{
"sourceName": "photo.jpg",
"outputName": "shopify_1.webp",
"outputWidth": 2048,
"outputHeight": 2048,
"format": "webp",
"sizeBytes": 250000,
"warnings": []
}
],
"warnings": []
}
}The result contains:
{
"ok": true,
"profile": "shopify-product",
"summary": {
"checks": 8,
"failures": 0,
"warnings": 0,
"outputs": 1
},
"checks": []
}Result Manifest
After processing, the runner writes:
quokkapix-result.jsonThe manifest is returned by:
window.QuokkaPixAgent.getResultManifest()It contains machine-readable local processing facts:
schemaVersion;status;success;tool;mode;source.count;source.totalBytes;outputs[];source/output dimensions when available;
output file names;
formats;
byte sizes;
warnings;
processingMs;browser capabilities;
optional planned backend routes in
capabilities.backends;stable
errorCode.
The manifest does not contain image bytes.
capabilities.backends is additive and advisory. The current MCP adapter already
passes unknown browser manifest fields through unchanged, so this field does not
require a new adapter release. Continue to use terminal status, errorCode and QA
results to decide whether a run succeeded.
QA Validation
The runner validates result manifests against recipe QA contracts.
Each check includes name, ok, severity, expected, actual, message and remediation, so agents can report both what failed and what setting to change.
Current QA checks include:
run status is
done;source count is positive;
source count is within recipe limit;
outputs are present;
expected format;
expected width/height;
max width/height;
square output when required;
max output size in KB when per-file size is available;
output name prefix;
required warning absence;
ZIP entries are represented in the manifest;
expected minimum output count for packs.
pixel-level checks when the browser manifest contains
outputs[].pixelQametrics:white background;
subject centered;
safe margins;
transparent background.
Semantic checks such as watermark presence, promotional text, old-background remnants or subjective cutout quality are not marked as passed without a measurable signal in the manifest. If a custom QA contract requests an unsupported visual check, the validator reports it as a warning instead of silently treating it as passed.
Those require a future semantic analyzer or another explicit measurable signal. The runner does not currently pretend to verify them.
Agent Payments And x402
Human QuokkaPix UI and reward-ad flows are unchanged.
Agent payment rules apply only to agent batch or batch-scenario runs above the free small-batch limit.
Current policy:
single image agent run: free;
single image scenario: free;
agent batch up to 5 files: free;
agent batch or batch scenario from 6 to 50 files:
0.01 USDC;provider: Coinbase x402;
currency/networks: USDC on Base (
eip155:8453, default), Polygon (eip155:137), Arbitrum (eip155:42161) and World Chain (eip155:480) when exposed by/api/agent-payment/options;payment options endpoint:
/api/agent-payment/options;paid unlock endpoint:
/api/agent-unlock/coinbase-x402;verify endpoint:
/api/agent-unlock/verify;formal API contract:
/x402-api.md.
The MCP runner can:
fetch payment options;
explain the payment flow;
verify an unlock token;
pass an unlock token into processing.
The MCP runner does not sign x402 payments itself. An x402-capable client or wallet must obtain the unlockToken.
Bridge mode does not add a second fee and WebMCP has no separate charge. A remote client can call set_unlock_token once after obtaining an x402 unlock. The control plane keeps that token only in memory, sends it to the paired bridge for one eligible run, and removes it when local processing starts. The browser payment endpoint remains the authority that consumes the unlock.
Always call get_payment_options when an agent is unsure whether a run is free or paid. The live response includes freeBatchMaxFiles, paidMinFiles, maxFiles, price, currency, supported x402 networks and endpoint URLs.
Paid batch workflow for 6-50 files:
Call
get_payment_options.Use an x402-capable client to call
/api/agent-unlock/coinbase-x402.Read
unlockTokenfrom the paid response.Optional: call
verify_unlock_tokenwithconsume: false. The adapter fetches current/api/agent-payment/optionsfirst and uses the livescope,priceandcurrencyunless you explicitly override them.Call
process_imagesorprocess_with_settingsand passunlockToken.
Example:
{
"recipeId": "shopify_product_pack",
"inputFiles": [
"/Users/me/products/photo-1.jpg",
"/Users/me/products/photo-2.jpg"
],
"outputDir": "/Users/me/products/out",
"unlockToken": "eyJhbGciOiJIUzI1NiIs..."
}Recommended Agent Prompt
Use this prompt in your local AI client:
Use QuokkaPix only through the MCP tools. First call list_recipes unless I give exact settings. For standard product, web, metadata, social, watermark or favicon workflows, prefer process_images with an official recipe. For custom image settings, use process_with_settings. After processing, inspect qa.ok and quokkapix-result.json. If qa.ok is false, report the failing checks and do not claim the output is ready. Do not say images were uploaded to a QuokkaPix processing server.CLI
The package also exposes a direct CLI:
quokkapix-runner --recipe website_webp_compress --input ./photo.jpg --output ./outOptions:
--recipe, --recipe-id Official recipe id.
--input, --file Input image path. Repeat for multiple files.
--output, --output-dir Output directory.
--app-url QuokkaPix URL, default https://quokkapix.com/#agent=1.
--unlock-token Paid x402 unlock token for agent batch/scenario runs.
--headed Show browser window.
--timeout-ms Timeout in milliseconds.The CLI currently runs recipe-based processing. For direct settings, use the MCP tool process_with_settings.
Bridge command:
npx quokkapix-mcp bridge --input-root ./images --output-root ./quokkapix-outputUse npx quokkapix-mcp bridge --help for pairing, config, headed browser and diagnostic options. Running npx quokkapix-mcp without bridge remains the original stdio MCP server.
Tests
Fast checks:
npm run checkThis checks:
syntax of MCP server files;
recipe loading and validation;
direct settings workflow generation;
QA validator;
payment helper tools;
CLI parser.
GitHub Actions runs the same checks on Node 20 and Node 24 on Windows and Linux.
The Linux/Node 24 job also uploads the generated .tgz as a short-lived workflow
artifact, so a green run verifies the actual package archive.
End-to-end browser processing test against an already running QuokkaPix app:
QUOKKAPIX_E2E_APP_URL=http://127.0.0.1:4180/#agent=1 npm run test:e2eThe free e2e tests process one local fixture, direct custom settings and logo-watermark asset upload. Paid batch e2e tests are skipped unless real unlock tokens are supplied.
For paid e2e tests:
QUOKKAPIX_E2E_APP_URL=http://127.0.0.1:4180/#agent=1 \
QUOKKAPIX_E2E_UNLOCK_TOKENS=token1,token2,token3,token4 \
npm run test:e2eThe paid tests use separate tokens because unlocks are one-time consumable.
Publication Check
Before publishing or tagging a release:
npm run check
npm pack --dry-runPushing an audited vX.Y.Z tag runs .github/workflows/release.yml, builds the
package again and attaches the .tgz to a GitHub Release. npm publication is a
separate manual workflow. Configure npm Trusted Publisher for this repository,
workflow publish-npm.yml and GitHub environment npm, then run Publish npm
package with the existing release tag. The workflow uses OIDC and does not
store an npm token in the repository.
The package whitelist includes only:
src/;examples/;CHANGELOG.md;LICENSE;README.md;SECURITY.md;package.json.
node_modules, test artifacts and the full QuokkaPix website are not included in the npm package.
Security And Privacy Notes
Source image files are read from local paths by the MCP runner.
Files are uploaded only into the local browser page through Playwright.
QuokkaPix browser processing does not upload source images to a QuokkaPix processing server.
The public website still cannot read arbitrary local paths.
Payment tokens should be treated as short-lived secrets.
Do not commit real unlock tokens, private files, or local output folders.
Bridge device secrets stay in the local config and are stored as hashes by the control plane.
OAuth uses authorization code with PKCE, audience-bound access tokens and rotating refresh tokens. Processing tools additionally require the
bridge:executescope;mcp:toolsalone is read-only.Remote file arguments are restricted to configured roots;
..traversal and out-of-root absolute paths are rejected.The control plane has no image upload route. It receives commands, relative names, status and result metadata.
A cloud AI can receive image bytes only if the user separately uploads or shares an output with that AI; bridge mode does not do that automatically.
Limitations
Browser RAM is the hard limit for large batches.
Background removal may download browser-side AI model files and depends on browser/device capability.
WebGPU/WebNN availability depends on the user's browser and hardware.
HEIC/AVIF/WebP support depends on browser and optional browser-side encoders.
JPEG XL export is experimental and requires the browser-loaded advanced encoder; it has no Canvas fallback.
PDF merge/split/extract expects PDF files. The existing images-to-PDF recipe expects image files.
ZIP import works only in batch mode and only extracts supported image files.
GIF background removal is not supported.
Pixel-level QA is deterministic and limited to measurable image facts. It does not claim semantic recognition of text, watermark content or subjective retouching quality.
The adapter currently uses Playwright browser automation, not a native image-processing library.
In bridge mode the remote client must know relative paths under the configured input root; directory browsing is intentionally not exposed.
Active bridge jobs are memory-only and fail closed during a control-plane restart.
Troubleshooting
Playwright browser is missing
Run:
npx playwright install chromiumThe agent cannot find files
Use absolute local file paths. The MCP process must have permission to read them.
Batch run says payment is required
Single image runs, single-image scenarios and agent batches up to 5 files are free. Larger agent batch and batch-scenario runs may require a valid x402 unlock token.
Browser runs out of memory
Reduce batch size, resize first, avoid very large images, or use smaller workflows. The runner cannot bypass browser RAM limits.
QA reports unsupported visual checks
That is expected for semantic visual requirements that cannot be proven from the browser manifest. The validator uses outputs[].pixelQa for measurable checks and leaves unsupported semantic checks unclaimed.
Related QuokkaPix Agent Files
Public discovery and documentation:
https://quokkapix.com/agents.mdhttps://quokkapix.com/agents.htmlhttps://quokkapix.com/llms.txthttps://quokkapix.com/agent-manifest.jsonhttps://quokkapix.com/.well-known/ai-catalog.jsonhttps://quokkapix.com/agent-test.htmlhttps://quokkapix.com/mcp-runner.htmlhttps://quokkapix.com/x402-api.md
License
MIT. See LICENSE.
Available Tools
11 toolsexplain_payment_flowExplain QuokkaPix x402 payment flowA
Explain the current QuokkaPix x402 workflow for agents. Use this when a client needs step-by-step guidance for paid batches above the free limit: get payment options, have an x402-capable wallet/client call the paid unlock endpoint, pass unlockToken to process_images/process_with_settings, optionally verify the token, then process. This adapter can use a token but cannot sign x402 payments itself.
| Name | Required | Description | Default |
|---|---|---|---|
| baseUrl | No | Optional QuokkaPix site base URL. Defaults to https://quokkapix.com. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It does so by listing the steps involved and explicitly stating that the adapter can use a token but cannot sign x402 payments itself, which is a critical limitation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence stating the purpose and the second providing usage context. Every sentence is informative and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter, no output schema, and the clear explanation of the tool's purpose and limitations, the description is complete. It adequately covers what the agent needs to know to decide whether to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single parameter 'baseUrl' with a default value. The description does not add additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool explains the current QuokkaPix x402 workflow, with a specific verb 'explain' and resource 'payment flow'. It distinguishes from siblings by outlining the step-by-step guidance for paid batches above the free limit, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this when a client needs step-by-step guidance for paid batches above the free limit' provides clear context for when to use the tool. It does not explicitly state when not to use it, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_payment_optionsGet QuokkaPix agent payment optionsA
Fetch live QuokkaPix agent payment options. Use this before any paid batch/scenario run to discover current price, currency, free single-image and small-batch rules, x402 endpoint URLs, verify endpoint and refund notes. This tool does not sign, submit or consume a payment.
| Name | Required | Description | Default |
|---|---|---|---|
| baseUrl | No | Optional QuokkaPix site base URL. Defaults to https://quokkapix.com. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'fetches live' payment options and explicitly says it does not sign, submit, or consume a payment, clarifying its read-only nature. It does not discuss side effects or rate limits, but for a simple fetch operation this is largely sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the main purpose, the second lists what is fetched and what is not done. The description is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple fetch with one optional parameter and no output schema, the description provides a complete overview of the purpose, usage timing, and data retrieved. It does not elaborate on output format but covers essential decision-making context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the only parameter (baseUrl) is fully described in the schema. The description adds no additional context about the parameter beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Fetch' and the resource 'QuokkaPix agent payment options'. It lists the specific data returned (price, currency, rules, endpoints) and explicitly states what the tool does not do (sign, submit, consume payment), distinguishing it from sibling tools like explain_payment_flow and verify_unlock_token.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Use this before any paid batch/scenario run', providing clear context. It lists the kind of information discovered but does not explicitly mention when not to use it or name alternative tools. However, the 'does not' statement implies alternatives exist for payment actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recipeGet QuokkaPix image recipeA
Return one official QuokkaPix recipe by id. Use this before process_images when the agent needs exact applySettings, max file limits, payment expectations and expected result QA checks. This tool does not process images.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Recipe id from list_recipes, for example shopify_product_pack, amazon_product_batch or metadata_clean_batch. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions it returns a recipe and does not process images, but does not disclose whether it is read-only, required permissions, or side effects. For a retrieval tool, minimal disclosure is acceptable but could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First sentence states purpose. Second sentence provides usage context and exclusion. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains what the recipe contains (applySettings, max file limits, payment expectations, QA checks). Parameter examples and sibling differentiation complete the picture for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds value by providing context for the 'id' parameter: 'Recipe id from list_recipes, for example shopify_product_pack, amazon_product_batch or metadata_clean_batch.' This clarifies the source and acceptable values beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Return' and resource 'one official QuokkaPix recipe by id'. Distinguishes from siblings by specifying usage context 'before process_images'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'Use this before process_images when the agent needs exact applySettings...'. Also clarifies what it does not do: 'This tool does not process images.', helping differentiation from sibling process_images.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_rule_profileGet sourced QuokkaPix platform rule profileA
Return one sourced platform image rule profile by id, including requirements, recommendations, source URL, source type and confidence. This tool does not process files and does not invent missing marketplace rules.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Rule profile id from list_rule_profiles, for example amazon.product.image or instagram.feed.photo. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full burden and clarifies that it does not process files or invent missing rules, which are important boundary conditions. However, it does not disclose authentication requirements, rate limits, or idempotency, leaving some aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the primary action, the second clarifies limitations. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup with one parameter and no output schema, the description lists returned fields and clarifies scope. It could improve by stating the output structure (single object), but is largely complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with description and examples. The tool description adds no additional meaning beyond repeating 'by id', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'sourced platform image rule profile by id', and distinguishes from siblings like list_rule_profiles (which lists all) and process_images (which processes files). The negative clauses further separate it from processing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by requiring an id from list_rule_profiles and notes what it does not do (process files, invent rules), but lacks explicit when-to-use or when-not-to-use guidance or alternative tool names beyond the implied 'list_rule_profiles'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_recipesList QuokkaPix image recipesA
List official QuokkaPix local/browser image workflow recipes. Use this first when an agent needs a supported workflow for Shopify, Amazon, Google Merchant, WebP compression, metadata cleanup, social packs, watermarking, favicon generation or similar repeatable image tasks. Returns ids that can be passed to get_recipe or process_images.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only list operation but doesn't explicitly disclose behavioral traits like side effects, rate limits, or data sensitivity. For a list operation, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: first clarifies purpose, second gives usage guidance, third explains return value utility. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains that the return value consists of ids and how they can be used with related tools. It also lists many example use cases, making the tool's domain clear and complete for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the description need not add param info. Baseline 4 is appropriate as the description adds no redundant parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'official QuokkaPix local/browser image workflow recipes' and enumerates specific use cases (Shopify, Amazon, etc.), making the purpose highly specific. It also distinguishes from sibling tools like get_recipe by noting the returned ids can be passed to it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to 'Use this first' when needing a supported workflow for a list of tasks. It also explains what the return value (ids) can be used for, guiding the agent to subsequent tools like get_recipe or process_images.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_rule_profilesList sourced QuokkaPix platform rule profilesA
List sourced image requirement profiles for marketplaces and social placements. Use this before marketplace QA when an agent needs facts for Amazon, Shopify, Google Merchant, Etsy, eBay, Walmart, TikTok Shop, Mercado Libre, Temu, Shopee, Instagram, YouTube, LinkedIn, X, Pinterest, Facebook or TikTok. Secondary sources are marked explicitly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the tool lists profiles and marks secondary sources, but does not mention authentication, rate limits, or output format. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first defines purpose, second gives usage guidance, third adds detail about secondary sources. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, description is sufficient. It tells when to use and what it lists. Minor gap: return format not specified, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is trivially 100%. Description adds no parameter info, but the baseline for 0 parameters is 4. No further detail needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'list' and resource 'sourced image requirement profiles', and distinguishes from sibling tools like 'get_rule_profile' (singular) and 'list_recipes' (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'before marketplace QA when an agent needs facts for...' and lists 17 specific platforms. Also notes that secondary sources are marked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
process_imagesProcess local images with QuokkaPixA
Process local image files through the QuokkaPix browser app using an official recipeId or a full custom recipe. The adapter opens local Chromium, applies settings, uploads files through the browser file input, starts processing, downloads the output and writes quokkapix-result.json. Source images stay in the local browser workflow and are not sent to a QuokkaPix processing API. Single-image runs and small batches up to 5 files are free; use unlockToken for larger paid batch/scenario runs.
| Name | Required | Description | Default |
|---|---|---|---|
| appUrl | No | Optional QuokkaPix app URL. Defaults to https://quokkapix.com/#agent=1. For safety, only quokkapix.com, localhost and 127.0.0.1 are accepted unless QUOKKAPIX_ALLOW_CUSTOM_APP_URL=1 is set. | |
| recipe | No | Custom recipe object. Provide either recipeId or recipe. | |
| headless | No | Run Chromium headless. Defaults to true unless debugging. | |
| recipeId | No | Official recipe id from list_recipes. Provide either recipeId or recipe. | |
| outputDir | Yes | Local directory where the adapter writes the downloaded output and quokkapix-result.json. | |
| timeoutMs | No | Maximum processing timeout in milliseconds. Use a larger value for background AI or large batches. | |
| inputFiles | Yes | Local source image files to upload through the browser file input. Agent batches up to 5 files are free; the paid batch limit is 50. | |
| unlockToken | No | Optional x402 unlock token for paid agent batch/scenario runs above 5 files. Obtain it outside this adapter. | |
| watermarkLogoFile | No | Optional local logo/image file for QuokkaPix logo watermark workflows. | |
| backgroundImageFile | No | Optional local image file for QuokkaPix background replacement workflows. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it opens Chromium, uses browser file input, processes locally, downloads output, and writes a result file. It clarifies that source images are not sent to a remote API. It also covers free vs paid constraints. This is comprehensive and leaves little ambiguity about the tool's side effects and requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place. The first sentence immediately states the core purpose, the second explains the workflow, and the third adds important constraints (local-only, free/paid). It is front-loaded and concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 params, nested objects) and lack of output schema, the description covers the high-level flow, local constraints, and payment model. It does not detail output format or error handling, but the presence of sibling tools like validate_result_manifest suggests output details are available elsewhere. This is nearly complete but could mention potential failure scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with detailed descriptions for all 10 parameters. The tool description adds no new parameter-specific meaning beyond what the schema provides; it instead focuses on overall workflow. Therefore, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: processing local image files through QuokkaPix using a recipeId or custom recipe. It details the workflow (opens Chromium, uploads, processes, downloads, writes result.json) and explicitly states what it does not do (images stay local, not sent to API). This provides a specific verb-resource combo that distinguishes it from siblings like get_recipe or validate_recipe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use unlockToken (for larger paid runs beyond 5 free files) and mentions using official recipeId from list_recipes or a custom recipe. It implies alternatives like get_recipe for obtaining recipeIds, but does not explicitly list when not to use this tool or compare with process_with_settings. Still, the context is clear enough for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
process_with_settingsProcess local images with direct QuokkaPix settingsA
Process local image files with a direct window.QuokkaPixAgent.applySettings payload instead of an official recipe. Use this for custom resize/crop/convert/compress/background/watermark/effects/rename/PDF/favicon/scenario workflows. For multi-step scenarios, prefer settings.steps as [{ tool, settings }]. The adapter downloads the output, writes quokkapix-result.json and returns QA results.
| Name | Required | Description | Default |
|---|---|---|---|
| appUrl | No | Optional QuokkaPix app URL. Defaults to https://quokkapix.com/#agent=1. For safety, only quokkapix.com, localhost and 127.0.0.1 are accepted unless QUOKKAPIX_ALLOW_CUSTOM_APP_URL=1 is set. | |
| headless | No | Run Chromium headless. Defaults to true unless debugging. | |
| maxFiles | No | Maximum allowed input files for this direct settings run. Defaults to the selected files count. | |
| settings | Yes | Payload accepted by window.QuokkaPixAgent.applySettings. Extra editor-specific keys are allowed. | |
| outputDir | Yes | Local directory where the adapter writes the downloaded output and quokkapix-result.json. | |
| timeoutMs | No | Maximum processing timeout in milliseconds. | |
| inputFiles | Yes | Local source image files to upload through the browser file input. | |
| settingsId | No | Optional id/name for this generated settings workflow, used in returned metadata and QA profile. | |
| unlockToken | No | Optional x402 unlock token for paid agent batch/scenario runs above 5 files. | |
| expectedResultQa | No | Optional QA contract used to validate quokkapix-result.json after processing. | |
| watermarkLogoFile | No | Optional local logo/image file for logo watermark settings. | |
| backgroundImageFile | No | Optional local image file for background replacement settings. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: it downloads output, writes quokkapix-result.json, uses Chromium with headless default, applies URL safety restrictions, and supports unlock tokens for paid runs. This is robust for a processing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 sentences), front-loads the main purpose, and each sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 12 parameters and no output schema, the description covers purpose, usage guidance, safety, and workflow. It could detail the return structure, but the expectedResultQa parameter and mention of QA results partially compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The description adds value by explaining the overall flow and noting that extra editor-specific keys are allowed in settings, which schema cannot convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool processes local image files using a direct QuokkaPix settings payload, distinguishing it from recipe-based tools like process_images. The title 'direct QuokkaPix settings' reinforces the unique value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends this tool for custom workflows and mentions preferring settings.steps for multi-step scenarios. It differentiates from official recipes, providing clear context, though it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_recipeValidate QuokkaPix image recipeA
Validate a custom QuokkaPix recipe before using process_images. Use this when an agent generated its own recipe JSON and needs to confirm that id, applySettings.mode, applySettings.tool, optional structured steps and requires.maxFiles are valid. This is a preflight check only and does not open a browser or process files.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe | Yes | Custom QuokkaPix recipe object. Use validate_recipe before process_images when generating this dynamically. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that this is a non-destructive, safe operation ('preflight check only, does not open browser or process files'). However, it does not detail the validation error format, side effects, or exact behavior on invalid input. Given no annotations, a score of 3 is appropriate—adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences only, both front-loaded with key information. No redundant phrases. Every sentence adds value: the first states the purpose and the second provides usage context and differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (1 parameter, 100% schema coverage, no output schema), the description is complete enough. It explains the tool's role in the workflow (validate before process_images). It could be improved by hinting at the return value (e.g., success/failure), but that is not required since there is no output schema. Score 4 reflects minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description adds contextual value by listing key fields it validates (id, applySettings.mode/tool, steps, requires.maxFiles), but the schema already covers these. No additional syntax or format details beyond the schema. Score 3 per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Validate' and the resource 'custom QuokkaPix recipe'. It distinguishes from sibling tools like process_images by stating it is a preflight check that does not process files. It lists the exact fields validated (id, applySettings.mode/tool, steps, requires.maxFiles), making the purpose clear and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when an agent generated its own recipe JSON and needs to confirm...' and implies when not to use (e.g., for known-good recipes). It clarifies it is a preflight check only and does not open a browser or process files, which helps the agent decide when to call it vs. process_images.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_result_manifestValidate QuokkaPix result manifestA
Validate an existing quokkapix-result.json manifest against an official recipe or custom QA contract. Use this after process_images/process_with_settings or when inspecting a previous run. It checks status, file counts, formats, dimensions, size limits, ZIP entry metadata and marketplace QA metadata; it does not read image pixels or upload files.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe | No | Optional custom recipe with expectedResult.qa. Used instead of recipeId when provided. | |
| manifest | Yes | QuokkaPix result manifest returned by getResultManifest() or saved as quokkapix-result.json. | |
| recipeId | No | Optional official recipe id whose expectedResult.qa contract should be used. | |
| ruleProfileId | No | Optional sourced platform rule profile id. The profile is returned beside the QA report for agent audit trails. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It transparently lists what checks are performed (status, file counts, formats, etc.) and explicitly states what it does not do (read pixels or upload files), which is sufficient for a validation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and every sentence contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation tool with 4 parameters and no output schema, the description covers the key aspects: what it validates, when to use, and its limitations. It omits explanation of the optional ruleProfileId parameter, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline is 3. The description adds value by contextualizing parameters (e.g., 'official recipe or custom QA contract') beyond the schema, though it does not detail all parameters individually.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (validate) and the resource (quokkapix-result.json manifest), and mentions it is used after specific sibling tools (process_images/process_with_settings), clearly distinguishing its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this after process_images/process_with_settings or when inspecting a previous run.' It also states what the tool does not do, setting expectations, but does not explicitly list when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_unlock_tokenVerify QuokkaPix agent unlock tokenA
Verify a QuokkaPix paid agent unlock token before processing. Use consume=false for safe preflight checks. Use consume=true only immediately before a paid batch/scenario run above the free limit when you intentionally want to consume the unlock. If scope, price or currency are omitted, the tool reads live payment options first.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Run mode to verify against the unlock token. | |
| files | No | Number of files intended for the paid run. | |
| price | No | Expected price string. Defaults to live payment options. | |
| scope | No | Expected QuokkaPix scope. Defaults to live payment options. | |
| token | Yes | Unlock token returned by the paid x402 unlock endpoint. | |
| baseUrl | No | Optional QuokkaPix site base URL. Defaults to https://quokkapix.com. | |
| consume | No | False for preflight verification. True consumes the unlock and should be used only at run start. | |
| currency | No | Expected currency. Defaults to live payment options. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the consumption vs preflight behavior and the defaulting to live payment options. It warns that consume=true should only be used at run start. However, it does not detail side effects of consumption, error handling, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no fluff. It front-loads the core purpose and then provides precise guidance. Every sentence is necessary and adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no output schema, no annotations), the description covers the main usage and behavioral aspects well. It lacks information on return values or error states, but the core logic is sufficiently explained for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining the distinction between consume modes and the defaulting behavior for scope, price, and currency, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Verify a QuokkaPix paid agent unlock token before processing.' It specifies the action (verify) and the resource (unlock token), and distinguishes itself from sibling tools that deal with payment options or recipe processing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use consume=false vs consume=true, and explains defaulting behavior for omitted optional parameters. However, it does not explicitly contrast with sibling tools like get_payment_options, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
v0.3.4- Added
get_rule_profile - Added
list_rule_profiles - Changed
validate_result_manifest1 field changed- added
Input schema / properties / ruleProfileIdAdded value: +{ + "description": "Optional sourced platform rule profile id. The profile is returned beside the QA report for agent audit trails.", + "minLength": 1, + "type": "string" +}
2 tool updates
v0.3.2- Changed
process_images2 fields changed- changed
Input schema / properties / inputFiles / descriptionPrevious value: -"Local source image files to upload through the browser file input. Maximum paid batch size is 50."New value: +"Local source image files to upload through the browser file input. Agent batches up to 5 files are free; the paid batch limit is 50." - changed
Input schema / properties / unlockToken / descriptionPrevious value: -"Optional x402 unlock token for paid agent batch/scenario runs. Obtain it outside this adapter."New value: +"Optional x402 unlock token for paid agent batch/scenario runs above 5 files. Obtain it outside this adapter."
- Changed
process_with_settings1 field changed- changed
Input schema / properties / unlockToken / descriptionPrevious value: -"Optional x402 unlock token for paid agent batch/scenario runs."New value: +"Optional x402 unlock token for paid agent batch/scenario runs above 5 files."
8 tool updates
v0.3.1- Changed
explain_payment_flow1 field changed- added
Input schema / properties / baseUrl / descriptionAdded value: +"Optional QuokkaPix site base URL. Defaults to https://quokkapix.com."
- Changed
get_payment_options1 field changed- added
Input schema / properties / baseUrl / descriptionAdded value: +"Optional QuokkaPix site base URL. Defaults to https://quokkapix.com."
- Changed
get_recipe1 field changed- added
Input schema / properties / id / descriptionAdded value: +"Recipe id from list_recipes, for example shopify_product_pack, amazon_product_batch or metadata_clean_batch."
- Changed
process_images14 fields changed- added
Input schema / properties / appUrl / descriptionAdded value: +"Optional QuokkaPix app URL. Defaults to https://quokkapix.com/#agent=1. For safety, only quokkapix.com, localhost and 127.0.0.1 are accepted unless QUOKKAPIX_ALLOW_CUSTOM_APP_URL=1 is set." - added
Input schema / properties / backgroundImageFile / descriptionAdded value: +"Optional local image file for QuokkaPix background replacement workflows." - added
Input schema / properties / headless / descriptionAdded value: +"Run Chromium headless. Defaults to true unless debugging." - added
Input schema / properties / inputFiles / descriptionAdded value: +"Local source image files to upload through the browser file input. Maximum paid batch size is 50." - added
Input schema / properties / inputFiles / items / descriptionAdded value: +"Absolute or client-relative local file path readable by the MCP process. Do not pass remote URLs here." - added
Input schema / properties / outputDir / descriptionAdded value: +"Local directory where the adapter writes the downloaded output and quokkapix-result.json." - added
Input schema / properties / recipe / descriptionAdded value: +"Custom recipe object. Provide either recipeId or recipe." - added
Input schema / properties / recipe / propertiesAdded value: +{ + "applySettings": { + "additionalProperties": {}, + "description": "QuokkaPix settings applied before processing starts.", + "properties": { + "mode": { + "description": "Use single for one image or batch for multiple images.", + "enum": [ + "single", + "batch" + ], + "type": "string" + }, + "steps": { + "description": "Optional ordered scenario steps. Prefer [{ tool, settings }] for custom multi-step workflows.", + "items": { + "anyOf": [ + { + "description": "Simple QuokkaPix tool id step, for example resize, background, compress or watermark.", + "minLength": 1, + "type": "string" + }, + { + "description": "Structured scenario step with a tool id and per-step settings.", + "properties": { + "settings": { + "additionalProperties": {}, + "description": "Settings for this step using the same keys accepted by window.QuokkaPixAgent.applySettings.", + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "tool": { + "description": "QuokkaPix tool id for this scenario step, for example resize, background, compress or watermark.", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "tool" + ], + "type": "object" + } + ], + "description": "One step in a QuokkaPix scenario workflow." + }, + "type": "array" + }, + "tool": { + "description": "QuokkaPix editor tool id, such as resize, crop, rotate, convert, compress, metadata, background, watermark, effects, rename, pdf, favicon or constructor.", + "minLength": 1, + "type": "string" + } + }, + "type": "object" + }, + "description": { + "description": "Short explanation of what the recipe prepares.", + "type": "string" + }, + "expectedResult": { + "additionalProperties": {}, + "description": "Expected output and QA contract.", + "properties": { + "output": { + "description": "Expected output type, for example zip, image, pdf or json.", + "type": "string" + }, + "qa": { + "additionalProperties": {}, + "description": "Machine-readable QA checks for the result manifest.", + "properties": { + "allowedFormats": { + "description": "Allowed output formats for every manifest output entry.", + "items": { + "type": "string" + }, + "type": "array" + }, + "expectedFormat": { + "description": "Required output format, for example webp, jpg, png, pdf or zip.", + "type": "string" + }, + "expectedHeight": { + "description": "Exact expected output height in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "expectedMinOutputs": { + "description": "Minimum number of output entries expected.", + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" + }, + "expectedOutputKind": { + "description": "Expected high-level output kind for QA checks.", + "enum": [ + "single", + "batch", + "zip", + "pdf", + "metadata-report", + "icon-pack" + ], + "type": "string" + }, + "expectedWidth": { + "description": "Exact expected output width in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "marketplace": { + "description": "Marketplace profile name used for human-readable QA context.", + "enum": [ + "shopify", + "amazon", + "google-merchant" + ], + "type": "string" + }, + "maxHeight": { + "description": "Maximum allowed output height in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "maxOutputKB": { + "description": "Recommended maximum output size per non-archive file.", + "exclusiveMinimum": 0, + "type": "number" + }, + "maxWidth": { + "description": "Maximum allowed output width in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "minHeight": { + "description": "Minimum recommended output height in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "minWidth": { + "description": "Minimum recommended output width in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "requireSquare": { + "description": "Require square output dimensions when true.", + "type": "boolean" + }, + "visualChecks": { + "description": "Visual checks requested by a recipe. Current validator reports these as metadata-only limitations.", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "type": "object" + } + }, + "type": "object" + }, + "id": { + "description": "Stable recipe id, for example shopify_product_pack.", + "minLength": 1, + "type": "string" + }, + "requires": { + "additionalProperties": {}, + "description": "Recipe requirements such as maxFiles and payment policy.", + "properties": { + "maxFiles": { + "description": "Maximum files allowed by this recipe.", + "maximum": 50, + "minimum": 1, + "type": "integer" + }, + "payment": { + "description": "Whether the recipe normally needs a paid batch/scenario unlock.", + "type": "boolean" + } + }, + "type": "object" + }, + "title": { + "description": "Human-readable recipe title.", + "type": "string" + } +} - removed
Input schema / properties / recipe / propertyNamesRemoved value: -{ - "type": "string" -} - added
Input schema / properties / recipe / requiredAdded value: +[ + "id", + "applySettings" +] - added
Input schema / properties / recipeId / descriptionAdded value: +"Official recipe id from list_recipes. Provide either recipeId or recipe." - added
Input schema / properties / timeoutMs / descriptionAdded value: +"Maximum processing timeout in milliseconds. Use a larger value for background AI or large batches." - added
Input schema / properties / unlockToken / descriptionAdded value: +"Optional x402 unlock token for paid agent batch/scenario runs. Obtain it outside this adapter." - added
Input schema / properties / watermarkLogoFile / descriptionAdded value: +"Optional local logo/image file for QuokkaPix logo watermark workflows."
- Changed
process_with_settings17 fields changed- added
Input schema / properties / appUrl / descriptionAdded value: +"Optional QuokkaPix app URL. Defaults to https://quokkapix.com/#agent=1. For safety, only quokkapix.com, localhost and 127.0.0.1 are accepted unless QUOKKAPIX_ALLOW_CUSTOM_APP_URL=1 is set." - added
Input schema / properties / backgroundImageFile / descriptionAdded value: +"Optional local image file for background replacement settings." - added
Input schema / properties / expectedResultQa / descriptionAdded value: +"Optional QA contract used to validate quokkapix-result.json after processing." - added
Input schema / properties / expectedResultQa / propertiesAdded value: +{ + "allowedFormats": { + "description": "Allowed output formats for every manifest output entry.", + "items": { + "type": "string" + }, + "type": "array" + }, + "expectedFormat": { + "description": "Required output format, for example webp, jpg, png, pdf or zip.", + "type": "string" + }, + "expectedHeight": { + "description": "Exact expected output height in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "expectedMinOutputs": { + "description": "Minimum number of output entries expected.", + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" + }, + "expectedOutputKind": { + "description": "Expected high-level output kind for QA checks.", + "enum": [ + "single", + "batch", + "zip", + "pdf", + "metadata-report", + "icon-pack" + ], + "type": "string" + }, + "expectedWidth": { + "description": "Exact expected output width in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "marketplace": { + "description": "Marketplace profile name used for human-readable QA context.", + "enum": [ + "shopify", + "amazon", + "google-merchant" + ], + "type": "string" + }, + "maxHeight": { + "description": "Maximum allowed output height in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "maxOutputKB": { + "description": "Recommended maximum output size per non-archive file.", + "exclusiveMinimum": 0, + "type": "number" + }, + "maxWidth": { + "description": "Maximum allowed output width in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "minHeight": { + "description": "Minimum recommended output height in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "minWidth": { + "description": "Minimum recommended output width in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "requireSquare": { + "description": "Require square output dimensions when true.", + "type": "boolean" + }, + "visualChecks": { + "description": "Visual checks requested by a recipe. Current validator reports these as metadata-only limitations.", + "items": { + "type": "string" + }, + "type": "array" + } +} - removed
Input schema / properties / expectedResultQa / propertyNamesRemoved value: -{ - "type": "string" -} - added
Input schema / properties / headless / descriptionAdded value: +"Run Chromium headless. Defaults to true unless debugging." - added
Input schema / properties / inputFiles / descriptionAdded value: +"Local source image files to upload through the browser file input." - added
Input schema / properties / inputFiles / items / descriptionAdded value: +"Absolute or client-relative local file path readable by the MCP process. Do not pass remote URLs here." - added
Input schema / properties / maxFiles / descriptionAdded value: +"Maximum allowed input files for this direct settings run. Defaults to the selected files count." - added
Input schema / properties / outputDir / descriptionAdded value: +"Local directory where the adapter writes the downloaded output and quokkapix-result.json." - added
Input schema / properties / settings / descriptionAdded value: +"Payload accepted by window.QuokkaPixAgent.applySettings. Extra editor-specific keys are allowed." - added
Input schema / properties / settings / propertiesAdded value: +{ + "mode": { + "description": "Use single for one image or batch for multiple images.", + "enum": [ + "single", + "batch" + ], + "type": "string" + }, + "steps": { + "description": "Optional ordered scenario steps. Prefer [{ tool, settings }] for custom multi-step workflows.", + "items": { + "anyOf": [ + { + "description": "Simple QuokkaPix tool id step, for example resize, background, compress or watermark.", + "minLength": 1, + "type": "string" + }, + { + "description": "Structured scenario step with a tool id and per-step settings.", + "properties": { + "settings": { + "additionalProperties": {}, + "description": "Settings for this step using the same keys accepted by window.QuokkaPixAgent.applySettings.", + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "tool": { + "description": "QuokkaPix tool id for this scenario step, for example resize, background, compress or watermark.", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "tool" + ], + "type": "object" + } + ], + "description": "One step in a QuokkaPix scenario workflow." + }, + "type": "array" + }, + "tool": { + "description": "QuokkaPix editor tool id, such as resize, crop, rotate, convert, compress, metadata, background, watermark, effects, rename, pdf, favicon or constructor.", + "minLength": 1, + "type": "string" + } +} - removed
Input schema / properties / settings / propertyNamesRemoved value: -{ - "type": "string" -} - added
Input schema / properties / settingsId / descriptionAdded value: +"Optional id/name for this generated settings workflow, used in returned metadata and QA profile." - added
Input schema / properties / timeoutMs / descriptionAdded value: +"Maximum processing timeout in milliseconds." - added
Input schema / properties / unlockToken / descriptionAdded value: +"Optional x402 unlock token for paid agent batch/scenario runs." - added
Input schema / properties / watermarkLogoFile / descriptionAdded value: +"Optional local logo/image file for logo watermark settings."
- Changed
validate_recipe4 fields changed- added
Input schema / properties / recipe / descriptionAdded value: +"Custom QuokkaPix recipe object. Use validate_recipe before process_images when generating this dynamically." - added
Input schema / properties / recipe / propertiesAdded value: +{ + "applySettings": { + "additionalProperties": {}, + "description": "QuokkaPix settings applied before processing starts.", + "properties": { + "mode": { + "description": "Use single for one image or batch for multiple images.", + "enum": [ + "single", + "batch" + ], + "type": "string" + }, + "steps": { + "description": "Optional ordered scenario steps. Prefer [{ tool, settings }] for custom multi-step workflows.", + "items": { + "anyOf": [ + { + "description": "Simple QuokkaPix tool id step, for example resize, background, compress or watermark.", + "minLength": 1, + "type": "string" + }, + { + "description": "Structured scenario step with a tool id and per-step settings.", + "properties": { + "settings": { + "additionalProperties": {}, + "description": "Settings for this step using the same keys accepted by window.QuokkaPixAgent.applySettings.", + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "tool": { + "description": "QuokkaPix tool id for this scenario step, for example resize, background, compress or watermark.", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "tool" + ], + "type": "object" + } + ], + "description": "One step in a QuokkaPix scenario workflow." + }, + "type": "array" + }, + "tool": { + "description": "QuokkaPix editor tool id, such as resize, crop, rotate, convert, compress, metadata, background, watermark, effects, rename, pdf, favicon or constructor.", + "minLength": 1, + "type": "string" + } + }, + "type": "object" + }, + "description": { + "description": "Short explanation of what the recipe prepares.", + "type": "string" + }, + "expectedResult": { + "additionalProperties": {}, + "description": "Expected output and QA contract.", + "properties": { + "output": { + "description": "Expected output type, for example zip, image, pdf or json.", + "type": "string" + }, + "qa": { + "additionalProperties": {}, + "description": "Machine-readable QA checks for the result manifest.", + "properties": { + "allowedFormats": { + "description": "Allowed output formats for every manifest output entry.", + "items": { + "type": "string" + }, + "type": "array" + }, + "expectedFormat": { + "description": "Required output format, for example webp, jpg, png, pdf or zip.", + "type": "string" + }, + "expectedHeight": { + "description": "Exact expected output height in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "expectedMinOutputs": { + "description": "Minimum number of output entries expected.", + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" + }, + "expectedOutputKind": { + "description": "Expected high-level output kind for QA checks.", + "enum": [ + "single", + "batch", + "zip", + "pdf", + "metadata-report", + "icon-pack" + ], + "type": "string" + }, + "expectedWidth": { + "description": "Exact expected output width in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "marketplace": { + "description": "Marketplace profile name used for human-readable QA context.", + "enum": [ + "shopify", + "amazon", + "google-merchant" + ], + "type": "string" + }, + "maxHeight": { + "description": "Maximum allowed output height in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "maxOutputKB": { + "description": "Recommended maximum output size per non-archive file.", + "exclusiveMinimum": 0, + "type": "number" + }, + "maxWidth": { + "description": "Maximum allowed output width in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "minHeight": { + "description": "Minimum recommended output height in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "minWidth": { + "description": "Minimum recommended output width in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "requireSquare": { + "description": "Require square output dimensions when true.", + "type": "boolean" + }, + "visualChecks": { + "description": "Visual checks requested by a recipe. Current validator reports these as metadata-only limitations.", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "type": "object" + } + }, + "type": "object" + }, + "id": { + "description": "Stable recipe id, for example shopify_product_pack.", + "minLength": 1, + "type": "string" + }, + "requires": { + "additionalProperties": {}, + "description": "Recipe requirements such as maxFiles and payment policy.", + "properties": { + "maxFiles": { + "description": "Maximum files allowed by this recipe.", + "maximum": 50, + "minimum": 1, + "type": "integer" + }, + "payment": { + "description": "Whether the recipe normally needs a paid batch/scenario unlock.", + "type": "boolean" + } + }, + "type": "object" + }, + "title": { + "description": "Human-readable recipe title.", + "type": "string" + } +} - removed
Input schema / properties / recipe / propertyNamesRemoved value: -{ - "type": "string" -} - added
Input schema / properties / recipe / requiredAdded value: +[ + "id", + "applySettings" +]
- Changed
validate_result_manifest8 fields changed- added
Input schema / properties / manifest / descriptionAdded value: +"QuokkaPix result manifest returned by getResultManifest() or saved as quokkapix-result.json." - added
Input schema / properties / manifest / propertiesAdded value: +{ + "errorCode": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Stable error code when the run failed or was cancelled." + }, + "mode": { + "description": "Run mode reported by QuokkaPix.", + "enum": [ + "single", + "batch" + ], + "type": "string" + }, + "outputs": { + "description": "Detailed output entries.", + "items": { + "additionalProperties": {}, + "description": "One output file or ZIP entry from quokkapix-result.json.", + "properties": { + "format": { + "description": "Output format such as webp, jpg, png, pdf or zip.", + "type": "string" + }, + "outputHeight": { + "description": "Output image height in pixels.", + "type": "number" + }, + "outputName": { + "description": "Output file or ZIP entry name.", + "type": "string" + }, + "outputWidth": { + "description": "Output image width in pixels.", + "type": "number" + }, + "sizeBytes": { + "description": "Output byte size when available.", + "type": "number" + }, + "sourceHeight": { + "description": "Original image height in pixels.", + "type": "number" + }, + "sourceName": { + "description": "Original input file name when available.", + "type": "string" + }, + "sourceWidth": { + "description": "Original image width in pixels.", + "type": "number" + }, + "warnings": { + "description": "Warnings for this output entry.", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "type": "object" + }, + "type": "array" + }, + "processingMs": { + "description": "Processing time in milliseconds when available.", + "type": "number" + }, + "source": { + "additionalProperties": {}, + "description": "Source file summary.", + "properties": { + "count": { + "description": "Number of source files.", + "type": "number" + }, + "totalBytes": { + "description": "Total input bytes when available.", + "type": "number" + } + }, + "type": "object" + }, + "status": { + "description": "Terminal status, expected to be done for a successful run.", + "type": "string" + }, + "success": { + "description": "Whether QuokkaPix considered the run successful.", + "type": "boolean" + }, + "tool": { + "description": "QuokkaPix tool/workflow that produced the output.", + "type": "string" + }, + "warnings": { + "description": "Run-level warnings.", + "items": { + "type": "string" + }, + "type": "array" + } +} - removed
Input schema / properties / manifest / propertyNamesRemoved value: -{ - "type": "string" -} - added
Input schema / properties / recipe / descriptionAdded value: +"Optional custom recipe with expectedResult.qa. Used instead of recipeId when provided." - added
Input schema / properties / recipe / propertiesAdded value: +{ + "applySettings": { + "additionalProperties": {}, + "description": "QuokkaPix settings applied before processing starts.", + "properties": { + "mode": { + "description": "Use single for one image or batch for multiple images.", + "enum": [ + "single", + "batch" + ], + "type": "string" + }, + "steps": { + "description": "Optional ordered scenario steps. Prefer [{ tool, settings }] for custom multi-step workflows.", + "items": { + "anyOf": [ + { + "description": "Simple QuokkaPix tool id step, for example resize, background, compress or watermark.", + "minLength": 1, + "type": "string" + }, + { + "description": "Structured scenario step with a tool id and per-step settings.", + "properties": { + "settings": { + "additionalProperties": {}, + "description": "Settings for this step using the same keys accepted by window.QuokkaPixAgent.applySettings.", + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "tool": { + "description": "QuokkaPix tool id for this scenario step, for example resize, background, compress or watermark.", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "tool" + ], + "type": "object" + } + ], + "description": "One step in a QuokkaPix scenario workflow." + }, + "type": "array" + }, + "tool": { + "description": "QuokkaPix editor tool id, such as resize, crop, rotate, convert, compress, metadata, background, watermark, effects, rename, pdf, favicon or constructor.", + "minLength": 1, + "type": "string" + } + }, + "type": "object" + }, + "description": { + "description": "Short explanation of what the recipe prepares.", + "type": "string" + }, + "expectedResult": { + "additionalProperties": {}, + "description": "Expected output and QA contract.", + "properties": { + "output": { + "description": "Expected output type, for example zip, image, pdf or json.", + "type": "string" + }, + "qa": { + "additionalProperties": {}, + "description": "Machine-readable QA checks for the result manifest.", + "properties": { + "allowedFormats": { + "description": "Allowed output formats for every manifest output entry.", + "items": { + "type": "string" + }, + "type": "array" + }, + "expectedFormat": { + "description": "Required output format, for example webp, jpg, png, pdf or zip.", + "type": "string" + }, + "expectedHeight": { + "description": "Exact expected output height in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "expectedMinOutputs": { + "description": "Minimum number of output entries expected.", + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" + }, + "expectedOutputKind": { + "description": "Expected high-level output kind for QA checks.", + "enum": [ + "single", + "batch", + "zip", + "pdf", + "metadata-report", + "icon-pack" + ], + "type": "string" + }, + "expectedWidth": { + "description": "Exact expected output width in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "marketplace": { + "description": "Marketplace profile name used for human-readable QA context.", + "enum": [ + "shopify", + "amazon", + "google-merchant" + ], + "type": "string" + }, + "maxHeight": { + "description": "Maximum allowed output height in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "maxOutputKB": { + "description": "Recommended maximum output size per non-archive file.", + "exclusiveMinimum": 0, + "type": "number" + }, + "maxWidth": { + "description": "Maximum allowed output width in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "minHeight": { + "description": "Minimum recommended output height in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "minWidth": { + "description": "Minimum recommended output width in pixels.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "requireSquare": { + "description": "Require square output dimensions when true.", + "type": "boolean" + }, + "visualChecks": { + "description": "Visual checks requested by a recipe. Current validator reports these as metadata-only limitations.", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "type": "object" + } + }, + "type": "object" + }, + "id": { + "description": "Stable recipe id, for example shopify_product_pack.", + "minLength": 1, + "type": "string" + }, + "requires": { + "additionalProperties": {}, + "description": "Recipe requirements such as maxFiles and payment policy.", + "properties": { + "maxFiles": { + "description": "Maximum files allowed by this recipe.", + "maximum": 50, + "minimum": 1, + "type": "integer" + }, + "payment": { + "description": "Whether the recipe normally needs a paid batch/scenario unlock.", + "type": "boolean" + } + }, + "type": "object" + }, + "title": { + "description": "Human-readable recipe title.", + "type": "string" + } +} - removed
Input schema / properties / recipe / propertyNamesRemoved value: -{ - "type": "string" -} - added
Input schema / properties / recipe / requiredAdded value: +[ + "id", + "applySettings" +] - added
Input schema / properties / recipeId / descriptionAdded value: +"Optional official recipe id whose expectedResult.qa contract should be used."
- Changed
verify_unlock_token9 fields changed- added
Input schema / properties / baseUrl / descriptionAdded value: +"Optional QuokkaPix site base URL. Defaults to https://quokkapix.com." - added
Input schema / properties / consume / descriptionAdded value: +"False for preflight verification. True consumes the unlock and should be used only at run start." - added
Input schema / properties / currency / descriptionAdded value: +"Expected currency. Defaults to live payment options." - added
Input schema / properties / files / descriptionAdded value: +"Number of files intended for the paid run." - added
Input schema / properties / mode / descriptionAdded value: +"Run mode to verify against the unlock token." - added
Input schema / properties / mode / enumAdded value: +[ + "single", + "batch", + "scenario" +] - added
Input schema / properties / price / descriptionAdded value: +"Expected price string. Defaults to live payment options." - added
Input schema / properties / scope / descriptionAdded value: +"Expected QuokkaPix scope. Defaults to live payment options." - added
Input schema / properties / token / descriptionAdded value: +"Unlock token returned by the paid x402 unlock endpoint."
9 tool updates
v0.3.0- First observed
explain_payment_flow - First observed
get_payment_options - First observed
get_recipe - First observed
list_recipes - First observed
process_images - First observed
process_with_settings - First observed
validate_recipe - First observed
validate_result_manifest - First observed
verify_unlock_token
TDQS
Each tool has a clearly distinct purpose: payment flow explanation/options/verification, recipe listing/details/validation, rule profile listing/details, image processing with recipe or custom settings, and result validation. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_payment_options, list_recipes, process_images). The naming is predictable and intuitive across the entire set.
With 11 tools, the server covers the necessary functionality for image processing, payment management, recipe and rule profiles, and validation without being excessive or lacking. The count is well-scoped for the domain.
The tool set provides a complete workflow: exploring recipes and rules, getting payment options, processing images, validating recipes and results, and managing unlock tokens. No obvious gaps are present for the stated purpose.
Maintenance
Related MCP Connectors
Remote MCP for C2PA intake verifier MCP, structured receipts, audit logs, and reviewer-ready evidenc
Convert images to PNG, JPEG, WebP, or AVIF through one public remote MCP tool.
MCP protocol requiring task acceptance and provenance tags. Self-hosted only - see README.
Hosted MCP tools for FFmpeg-style video and audio processing through FFMPEG API.
Related MCP Servers
- AlicenseAqualityDmaintenanceAbout MCP server for image conversion, resizing, and merging — runs locally, no uploads5161MIT
- AlicenseAqualityCmaintenanceLocal image processing MCP server providing background removal, stock media search, resize, format conversion, and collage creation.5MIT
- AlicenseNot gradedqualityCmaintenanceLocal-first MCP server for controlling a loopback ComfyUI instance from same-machine or authenticated LAN clients.MIT
- AlicenseNot gradedqualityAmaintenanceLocal MCP server for preparing previews and publishing single image posts to Instagram after explicit user confirmation, with OAuth and safety safeguards.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/quokkapix/quokkapix-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server