01Safety
0.0 / 30
What changed in the harness
Selection accuracy 67→71, token cost up 2%, unconfirmed writes 0%→0%.
Category breakdown
Where the score comes from.
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
02Legibility
20.4 / 30
03Economics
10.7 / 20
04Discoverability
7.1 / 20
Highest-impact fix
Estimated gain +30 pointsAdd explicit identity and permission preflight tools
Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.
Description evidence
Defects and rewrites.
6 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.
| Tool | Defect types | Suggested rewrite |
|---|---|---|
validate_recipe |
no_return_description |
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. Returns a validation result reporting whether the recipe is valid and listing any field-level errors or warnings found. |
list_rule_profiles |
no_return_description |
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. Returns a list of rule profile ids and summaries that can be passed to get_rule_profile. |
get_payment_options |
no_return_description |
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. Returns the current payment options object, including pricing, currency, free-tier limits, and x402 endpoint URLs. |
explain_payment_flow |
no_return_description |
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. Returns a structured, step-by-step explanation of the payment flow along with the relevant endpoint URLs. |
verify_unlock_token |
no_return_description |
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. Returns a verification result stating whether the token is valid for the given scope, price, currency, mode and file count, and whether it was consumed. |
validate_result_manifest |
no_return_description |
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. Returns a QA report with a pass/fail verdict and any detected issues relative to the expected result contract. |
Selection evidence
Confusable tool pairs.
9 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
process_images |
process_with_settings |
high | Both execute an actual image-processing run and take overlapping optional params (watermarkLogoFile, backgroundImageFile, outputDir, unlockToken); a task like 'resize and convert these images' doesn't specify whether to use a named/custom recipe object (process_images) or a raw applySettings payload (process_with_settings), so an agent could pick either. |
get_recipe |
validate_recipe |
medium | Both take a recipe-shaped input and are framed as pre-processing checks; an agent asked to 'check this recipe is correct' could mistakenly call get_recipe (which only fetches an official recipe by id) instead of validate_recipe (which validates a custom recipe object), especially if it conflates 'recipe' identifiers with recipe objects. |
list_recipes |
get_recipe |
low | Standard list-then-get pattern; confusion is unlikely since get_recipe explicitly requires an id sourced from list_recipes, making the ordering obvious. |
get_recipe |
get_rule_profile |
medium | Both are 'get one by id' lookups but serve different domains (workflow recipe settings vs sourced marketplace image requirement facts); a task like 'get the Shopify product image spec' is ambiguous between fetching QuokkaPix's own recipe (get_recipe) and the sourced platform rule profile (get_rule_profile). |
list_recipes |
list_rule_profiles |
medium | Both are no-arg listing tools returning ids for marketplaces/platforms; a vague task like 'what's supported for Amazon images' could plausibly trigger either the workflow recipe list or the sourced rule profile list. |
validate_recipe |
validate_result_manifest |
medium | Both are described as 'validate' preflight/QA tools with overlapping schema (recipe object, QA contract); a task like 'validate this against the recipe' is ambiguous between validating a not-yet-run custom recipe (validate_recipe) and validating a post-run result manifest against a recipe's QA contract (validate_result_manifest). |
get_payment_options |
explain_payment_flow |
medium | Both concern paid batch runs and share baseUrl parameter; a task like 'how do I pay to process this large batch' could be answered by either fetching live pricing/endpoints (get_payment_options) or getting the step-by-step x402 workflow explanation (explain_payment_flow). |
list_recipes |
process_images |
low | Different verbs (list vs process) make the intended action clear in most phrasings, though shared marketplace/browser vocabulary keeps some overlap. |
get_rule_profile |
get_payment_options |
low | Only 'get' is shared and domains (marketplace image rules vs payment pricing) are clearly distinct, so genuine confusion is unlikely. |
Compare the field