Processing happens in the local browser, and bridge mode relays only tool settings, relative file names, status and result metadata — there is no image upload endpoint on the remote side at all, which is an unusual answer to "how does a cloud assistant edit files on my disk". The rule profiles are the other piece worth using deliberately: every marketplace requirement declares where it came from and how confident it is, and where the official public spec was thin — Temu, Mercado Libre, Shopee, parts of YouTube — the profile says secondary rather than inventing a number. Do the QA step as well: validate_result_manifest checks the output against the recipe's own contract instead of leaving you to eyeball dimensions and file sizes.
A local adapter that drives the QuokkaPix web editor in a Chromium browser on your own machine. The agent picks an official recipe or supplies settings, the adapter opens the browser, feeds files through its file input, downloads the output and writes a machine-readable quokkapix-result.json. Source image bytes stay in that browser runtime — during normal processing they are not uploaded to an image-processing server.
- list_recipes and get_recipe cover the official workflows — Shopify, Amazon and Google Merchant product packs, WebP compression, metadata cleanup, social packs, watermarking, favicon generation — with the exact applySettings, file limits, payment expectations and QA checks each carries
- validate_recipe is a preflight on a recipe the agent wrote itself, checking the id, applySettings.mode and tool, structured steps and requires.maxFiles without opening a browser
- process_images runs an official or custom recipe; process_with_settings takes a direct applySettings payload for resize, crop, convert, compress, background, watermark, effects, rename, PDF, favicon or a multi-step scenario
- list_rule_profiles and get_rule_profile carry sourced image requirements for Amazon, Shopify, Google Merchant, Etsy, eBay, Walmart, TikTok Shop, Mercado Libre, Temu, Shopee, Instagram, YouTube, LinkedIn, X, Pinterest, Facebook and TikTok — each declaring its sourceType, sourceUrl and confidence instead of an unattributed rule
- validate_result_manifest checks a quokkapix-result.json against the recipe's QA contract: status, file counts, formats, dimensions, size limits, ZIP entry metadata and marketplace QA metadata
- Paid batches above the free limit have their own group: get_payment_options reads the current price, currency, free single-image and small-batch rules and the x402 endpoints, explain_payment_flow walks the sequence, and verify_unlock_token checks a token with consume=false or spends it with consume=true
Node.js 20 or newer, npm, and Playwright Chromium via npx playwright install chromium, plus internet access to load the QuokkaPix app and its browser-side dependencies. Local use is npx quokkapix-mcp over stdio. Remote clients run the same package in bridge mode with explicit --input-root and --output-root: remote calls cannot read or write outside those roots, path traversal is rejected, and absolute local paths are never returned to the cloud client. Pairing is one-time, the device credential lives in ~/.quokkapix/bridge.json with owner-only permissions where the OS supports them, --pair approves another session and --reset revokes the old one.
One command — npx quokkapix-mcp