Server Quality Checklist

Tool Scores

• get_rule_profileA
  4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• get_payment_optionsA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• validate_recipeA
  4.2/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• get_recipeA
  4.3/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• list_rule_profilesA
  4.4/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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_imagesA
  4.4/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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_settingsA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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_result_manifestA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• explain_payment_flowA
  4.5/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• list_recipesA
  4.5/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• verify_unlock_tokenA
  4.5/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.