Server Quality Checklist

Tool Scores

• gold_wc_variationsC
  2.5/5.0
  Behavior2/5

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

  Since no annotations are provided, the description bears the full burden of behavioral disclosure. It does mention paid-only access and list/bulk-create intent, but it hides the destructive update/delete actions and does not mention the CONFIRM requirement, write side effects, or that list is read-only.

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

  Conciseness2/5

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

  The core function is stated in one sentence, but the description is padded with marketing noise ('clothing shops cannot live without this; techspawn has it, we added it') and a pricing note that do not help an AI agent select or invoke the tool. These extra phrases reduce clarity without adding operational value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given four parameters, no output schema, and no annotations, the description is incomplete. It omits the update/delete actions, the confirmation requirement, expected variations structure, error or return behavior, and any practical constraints besides the paid note.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 25%, so the description must compensate, but it barely does. It adds that variations are size/color and hints at list/create actions, yet it does not explain product_id, the variations array shape, or the action enum semantics beyond what the schema already shows.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly names a verb and resource: 'list or bulk-create product VARIATIONS (size/color)' and the term 'variations' helps distinguish it from sibling bulk tools. However, it omits the update and delete actions that the schema allows, so it understates the tool's actual scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives like gold_wc_batch or gold_update_product. Marketing phrases like 'clothing shops cannot live without this' and 'techspawn has it, we added it' provide no practical selection criteria, and no conditions are given for choosing list versus create/update/delete.

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

• gold_create_couponC
  2.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden, and it does add one important behavioral trait: 'BYOK fail-closed' signals that the caller's own key is required and that failures will not silently fall back. However, it does not disclose response behavior, irreversibility, or the confirmation gate implied by the 'confirm' parameter, so transparency is incomplete.

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

  Conciseness3/5

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

  The description is compact and action-oriented, but the leading 'Gold PRO $29' fragment is unclear and does not clearly earn its place. The endpoint and BYOK fail-closed note are useful, but the overall structure is cryptic and front-loads potentially irrelevant pricing/plan information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an 11-parameter mutation tool with no output schema and no annotations, a single cryptic line is insufficient. It lacks usage alternatives, parameter semantics, confirmation requirements, and expected failure/return behavior. The only meaningful operational context is the endpoint and BYOK fail-closed note.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 9%, yet the description adds no parameter-level meaning beyond the generic 'coupon' context. It does not explain required fields like code and amount, the meaning of discount_type, or the format for expiry_date. The low schema coverage requires the description to compensate, and it does not.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action and resource: 'create Woo coupon via POST /wp-json/wc/v3/coupons'. This clearly identifies the tool as a single-coupon creation operation and distinguishes it from product, order, and customer tools. It does not explicitly differentiate it from the bulk coupon sibling, but the endpoint and 'create' wording make the core purpose clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like gold_wc_coupons_bulk. It does not state exclusions, prerequisites beyond the cryptic 'BYOK fail-closed', or scenarios where another sibling would be more appropriate. Usage context is only implied by the word 'create'.

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

• gold_create_refundC
  2.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full disclosure burden and does add two meaningful traits: 'Destructive' and 'BYOK fail-closed'. However, it does not explain what is affected (e.g., order state, payment reversal) or that a CONFIRM gate exists, so the disclosure is useful but terse.

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

  Conciseness3/5

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

  The definition is short and front-loads the action, endpoint, and safety warnings. However, 'Gold PRO $29' is a wasted fragment unrelated to invocation, keeping it from being tightly structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive operation with 7 parameters, no output schema, and no annotations, this is too thin. It omits the CONFIRM requirement, the operational effects of a refund, and the meaning of the flag parameters, leaving an agent to guess at safe invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 14% (confirm has a description), yet the description says nothing about order_id, amount, reason, api_refund, refund_payment, or line_items. The endpoint implies the WooCommerce refund contract but gives the agent no semantics for the boolean toggles or amount formatting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  'create refund via POST /wp-json/wc/v3/refunds' names a specific verb and resource, and no sibling tool is refund-related, so the agent can distinguish it without opening the schema. The 'Gold PRO $29' prefix is irrelevant noise but does not obscure the action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No when-to-use guidance or alternatives are given. An agent cannot determine when this tool should be preferred over siblings such as gold_update_order_status or gold_wc_batch, and no prerequisites or ordering constraints are mentioned.

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

• gold_update_productC
  2.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden, and it does add genuine behavioral context: the direct REST endpoint, the PUT method implying a write operation, and 'BYOK fail-closed' signaling that the caller must supply credentials and that missing/invalid keys cause failure rather than fallback. However, it omits the confirmation gate (the schema's 'confirm' must equal CONFIRM to execute) and says nothing about side effects, idempotency, or response behavior.

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

  Conciseness3/5

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

  The core operation is front-loaded and the line is short, which is good. But 'Gold PRO $29' is ambiguous pricing/plan-tier noise and 'BYOK fail-closed' is cryptic jargon — the same space could have carried the confirm requirement or an updatable-fields hint instead.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an 11-parameter mutation tool with no annotations, no output schema, and 9% schema coverage, a single clause leaves most decisions to the agent. Missing: update semantics (partial vs full resource replacement), the confirm-to-execute requirement, which fields are updatable, and any pointer to siblings for bulk or stock-only updates.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 9% — 10 of 11 parameters are undocumented in the schema. The description compensates for none of them: it does not explain that sku, name, status, regular_price, sale_price, stock_quantity, stock_status, categories, and description map to WooCommerce product fields, nor which are required beyond id. Only 'id' is inferable from the endpoint path.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb+resource ('update Woo product') and pins the exact operation with the endpoint PUT /wp-json/wc/v3/products/{id}. The verb and resource distinguish it from siblings like gold_get_product and gold_create_product, though it doesn't explicitly disambiguate against the narrower gold_update_stock. The 'Gold PRO $29' prefix is noise but does not obscure the core purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides no when-to-use guidance and names no alternatives or exclusions — nothing tells an agent when to pick this over gold_update_stock, gold_wc_batch, or gold_create_product. The 'BYOK fail-closed' hint addresses authentication context, not tool-selection criteria.

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

• gold_list_customersB
  3/5.0
  Behavior3/5

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

  With no annotations, the description carries some burden and does add value: 'GET' indicates a read-only operation, and 'BYOK fail-closed' discloses the authentication/failure behavior. However, it omits pagination behavior, response shape, and how filters affect results.

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

  Conciseness4/5

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

  The description is compact and front-loads the core operation and endpoint. The pricing and 'BYOK fail-closed' phrases are terse but add contextual flags without wasting words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The definition is not complete enough for a tool with 5 optional parameters, no annotations, and no output schema. It provides the endpoint and a fail-closed hint, but leaves parameter semantics, pagination, and return behavior to guesswork.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description adds no meaning to any of the five parameters (page, role, email, search, per_page). An agent must infer semantics solely from parameter names.

  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 states a specific verb and resource: 'list Woo customers via GET /wp-json/wc/v3/customers'. This clearly differentiates it from sibling tools like gold_list_products and gold_list_orders.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance about when to use this tool versus alternatives, nor any when-not-to-use conditions. The 'BYOK fail-closed' hint suggests an auth prerequisite but does not explain tool selection relative to other list tools.

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

• gold_low_stock_alertB
  3/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It discloses that this is a GET request, that it operates on backorder/lowstock, and that it fails closed on BYOK issues — useful behavioral detail. However, it does not clarify whether the tool actually sends an alert or simply returns matching products, nor what side effects or auth assumptions apply beyond 'BYOK fail-closed.'

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

  Conciseness3/5

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

  The description is short and mostly front-loaded, but it contains cryptic marketing/jargon phrases ('Gold PRO $29', 'Moat') that do not earn their place. It conveys the core idea in very few words, yet the structure is cluttered with unnecessary context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Because there is no output schema and no annotations, the description should explain what the agent will receive and what 'alert' means operationally. It does not describe the return value, pagination implications, or the actual alert mechanism, leaving important execution details unresolved.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema documents only one of two parameters (threshold), leaving per_page unexplained, and the description does not compensate. It mentions the hardcoded stock_status values but gives no meaning for per_page or how threshold interacts with the alert condition, so half the parameter surface remains ambiguous.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies a specific action (low-stock alert) and resource (GET /wp-json/wc/v3/products with stock_status=onbackorder/lowstock), which is concrete and distinct from generic product queries. It does not explicitly distinguish itself from gold_get_products, but the stock-status filter and reorder intent make the purpose reasonably clear.

  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?

  It implies use for low-stock/reorder monitoring through the endpoint and 'one call alerts for reorder,' but it does not explicitly state when to choose this tool over siblings or when not to use it. The context is enough for an agent to infer the intended scenario, but alternatives are not mentioned.

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

• gold_wc_seo_meta_bulkB
  3.2/5.0
  Behavior3/5

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

  Annotations are absent, so the description bears the full disclosure burden. It discloses real behaviors: the exact target fields, plugin compatibility, and automatic trimming to 60/155 characters. It does not, however, warn that existing SEO titles and meta descriptions of all targeted products will be overwritten, and it is silent on return values and partial-failure behavior — material for a bulk write operation.

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

  Conciseness3/5

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

  The description is short and front-loads the verb and object in the first sentence, but it trails into three noise fragments ('POWER:', 'BYOK.', 'PAID ONLY PRO $29.') that are marketing or unexplained jargon. These fragments could earn their place if expanded, but as bare tokens they reduce clarity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a five-parameter bulk write with no output schema and no annotations, the description covers the essential operational traits (target fields, trimming, plugin mapping, PRO restriction). It omits the return/response behavior, the overwrite warning, and failure semantics for up to 25 products, which an agent would want before invoking it.

  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?

  With 80% schema coverage, the baseline is 3. The description fills the one coverage gap — the seo_plugin parameter, which has only an enum/default in the schema — by mapping each plugin choice to its concrete meta keys. It also reinforces the trim limits already documented in the schema, adding meaning without redundancy.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb and resource ('bulk-set SEO title + meta description on many products') and goes beyond the name by listing the exact WordPress meta keys written (_yoast_wpseo_title/_metadesc or rank_math_title/description). This is clearly distinguishable from single-product tools by its bulk scope, though it does not explicitly name or distinguish a sibling like gold_wc_desc_bulk_byok, so it stops short of a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No when-to-use or when-not-to-use guidance is given, and no alternative tools are named. The only hint is 'bulk ... on many products', which signals scale but leaves the agent to guess how this relates to the sibling bulk tools gold_wc_desc_bulk_byok, gold_wc_batch, or gold_update_product for single-item SEO edits.

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

• gold_update_order_statusB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It adds useful traits by naming the PUT method, the BYOK auth model, and the fail-closed behavior. However, it does not disclose potential side effects, reversibility, or whether downstream actions are triggered by a status change.

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

  Conciseness4/5

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

  The description is compact and front-loaded with the essential action and endpoint. The 'Gold PRO $29' prefix is non-essential noise but does not prevent an agent from parsing the invocation-relevant details quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple three-parameter update tool with no output schema, the description covers the endpoint, status scope, and auth/failure mode, and the schema covers the confirm requirement. It is workable, but the lack of annotation coverage and any return or side-effect detail leaves some assumptions implicit.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Only one of three parameters (confirm) has a schema description, so the schema coverage is low and the description should compensate. The description clarifies that id is the order id in the path and that status is the new status, but it says nothing about the mandatory CONFIRM sentinel, leaving a critical execution gate undocumented outside the 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?

  The description states a specific verb ('update'), resource ('order status'), and a concrete REST endpoint (PUT /wp-json/wc/v3/orders/{id} {status}), making the tool's purpose unambiguous. This clearly differentiates it from sibling order-related tools like gold_get_order and gold_create_refund.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given about when to use this tool versus alternatives such as gold_create_refund or gold_list_orders. The text mentions BYOK fail-closed, which hints at an auth prerequisite, but it does not explain when this tool is appropriate or when another sibling should be preferred.

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

• gold_wc_batchB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden and does add useful behavioral context: it is a paid-only bulk mutation tool that can create, update, and delete up to 100 rows in one call. However, it does not mention the confirm=CONFIRM execution gate or possible partial-failure/destructive side effects beyond naming 'delete'.

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

  Conciseness4/5

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

  The core information is front-loaded: operation type, scope, and row limit appear first, followed by resource values and licensing. The 'CodeCanyon Advanced Bulk Edit $69 killer' marketing is mostly noise, but the overall description is still short and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex bulk mutation tool with no output schema and no annotations, the description is not complete enough to invoke safely. It lacks object payload guidance for create/update, clarification that delete expects IDs, and explicit mention of the confirm gate, leaving the agent to infer critical execution details from the schema alone.

  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 only 20%, and the description helps by pairing 'create', 'update', and 'delete' with the corresponding array parameters and listing the valid resource values. It also adds the 100-row limit. Still, it does not explain what should go inside the create/update objects or how delete IDs are expected to be formatted.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific bulk operation over products/orders/coupons/categories with create+update+delete and a 100-row cap. It goes beyond the name and implies a batch role distinct from single-entity siblings, though it does not explicitly contrast with the sibling bulk 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 phrase 'up to 100 rows in ONE call' implies use for bulk operations, and the resource list indicates scope. However, there is no explicit guidance on when to prefer this over sibling bulk tools like gold_wc_categories_bulk or gold_wc_coupons_bulk, nor any when-not-to-use guidance.

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

• gold_get_reportsB
  3.4/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 behavioral burden. It does add useful behavior by noting 'BYOK fail-closed' and specifying the endpoint, but it omits details about response format, authentication mechanics, rate limits, or read-only confirmation beyond the verb 'get'.

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

  Conciseness4/5

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

  The description is compact and front-loads the main action and resource. The 'Gold PRO $29' pricing note is minor noise, but the endpoint, fail-closed behavior, and type list are all efficiently packed into two short sentences.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no annotations, no output schema, and four parameters, the description is incomplete. It does not explain how period and date range interact, what the return payload looks like, or any error/failure behavior beyond fail-closed. An agent would still have to guess at important invocation details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has enums and field names but no descriptions, so parameter coverage in the schema is low. The description only repeats the 'type' enum values and leaves 'period', 'date_min', and 'date_max' unexplained, forcing the agent to infer date formats and report-period semantics.

  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 it retrieves WooCommerce reports from the v3 reports API endpoint and enumerates six concrete report types. This makes it obvious what the tool does and distinguishes it from sibling getters like gold_get_order and gold_get_product.

  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 that this tool should be used for report-style aggregate data and mentions BYOK fail-closed as a prerequisite, but it never explicitly names alternatives or states when not to use it. The usage context is clear but not fully articulated.

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

• gold_update_stockB
  3.4/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 behavioral burden. It usefully discloses 'BYOK fail-closed' and makes clear this is a mutating PUT call, which adds context beyond the schema. However, it does not explain what happens on success/failure, whether confirmation is required, or any side effects beyond the stock update.

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

  Conciseness4/5

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

  The description is a single dense line: endpoint, payload, fail-closed behavior, and bulk usage are all packed in without redundant prose. The 'Gold PRO $29' prefix adds context about the paid/BYOK nature of the tool, though it is not strictly functional.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with no annotations and no output schema, the description should cover more: return values, confirmation behavior, and the role of manage_stock are absent. It is still usable because the schema documents confirm, required fields, and enums, but the description alone leaves meaningful gaps.

  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?

  With only 40% schema description coverage, the description partially compensates by identifying stock_quantity and stock_status as the updated payload fields and embedding {id} in the endpoint. But manage_stock and confirm are not explained in the description; confirm is only covered by the schema, and manage_stock has no guidance at all.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('update Woo stock') and pinpoints the resource and endpoint (PUT /wp-json/wc/v3/products/{id}) with the relevant fields. It is clearly scoped to stock updates, though it does not explicitly name or contrast a sibling like gold_update_product.

  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 'Bulk-ready (call per SKU)' line gives practical usage context for repeated stock updates, but there is no explicit 'use this when...' or 'for other product changes use X' guidance. The intended scope is implied by the tool name and endpoint rather than stated as a rule.

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

• gold_wc_categories_bulkB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses three meaningful traits: idempotent semantics ('creates missing only'), batch limits (1-50), and a paid entitlement prerequisite ('PAID ONLY PRO $29'). It does not disclose error behavior, whether duplicate names in the array are handled, or whether creation is atomic for the whole batch — notable gaps for a mutation tool.

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

  Conciseness4/5

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

  The description delivers the purpose, the batch constraint, the idempotency behavior, and the entitlement requirement in a single compact sentence, with the core semantics front-loaded. The 'PAID ONLY PRO $29' suffix is arguably marketing fluff but carries operational entitlement information, so it earns some keep.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter tool with no annotations and no output schema, the desription covers the essential invocation details — what to pass, batch size, idempotent behavior, and entitement. Missing are expected return values and failure modes, which are more consequential given the absence of an output schema to fill that 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 50% (confirm is documented, names is not). The description compensates partially by clarifying that names holds product CATEGORY names and that the valid count is 1-50. It adds no detail on string format, case sensitivity, or what happens with duplicate names. The confirm parameter is adequately covered by its schema description and enum.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource: 'Ensure 1-50 product CATEGORIES exist' with the clarifying behavior 'creates missing only'. This clearly identifies it as an idempotent bulk category-creation tool, distinguishable from siblings like gold_wc_coupons_bulk and gold_wc_variations by resource type. The 'PAID ONLY PRO $29' tagline is noise but does not obscure the core purpose.

  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 context — use this when you need to ensure multiple categories exist without creating duplicates ('creates missing only') and when doing SEO tagging at scale. However, it does not name any alternatives or state when not to use it, such as when updating existing category metadata or creating a single category, which would be covered by other tools in the sibling set.

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

• gold_wc_daily_digestB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the transparency burden. It discloses some access context through 'BYOK' and 'PAID ONLY PRO $29', and the digest framing implies a read-only summary, but it never explicitly states the operation is non-destructive, nor does it explain rate limits, caching, or the meaning of 'BYOK'.

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

  Conciseness4/5

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

  The description is very short and front-loads the primary purpose, naming the data categories and the 'ONE call' value. The trailing 'BYOK. PAID ONLY PRO $29.' fragment adds access context but reads as marketing noise, and 'POWER TOOL' contributes little functional value, so it does not earn a 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only one optional parameter that is fully covered by the schema, an agent has enough to invoke the tool. However, there is no output schema and the description gives no indication of the returned payload structure beyond category names, leaving some ambiguity about how the digest is formatted.

  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 single parameter days_back is fully documented in the schema with a default and valid range, so schema coverage is 100% and the baseline applies. The description adds no additional parameter guidance and its 'today's' phrasing may obscure the fact that days_back can request a 1-30 day window.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a consolidated morning digest and enumerates its content: orders, revenue, AOV, low-stock products, and open orders. It lacks a direct verb like 'retrieve', and it does not explicitly contrast with sibling tools, but the combined-scope wording differentiates it from single-purpose siblings.

  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 phrase 'morning briefing in ONE call' implies a clear daily-overview use case and suggests it replaces pulling multiple reports separately. However, it does not explicitly state when to prefer alternative tools or what scenarios would make another sibling more appropriate.

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

• gold_list_ordersA
  3.5/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 the full behavioral disclosure burden. It adds meaningful context with 'BYOK fail-closed', indicating the tool fails closed if the user's key is missing or invalid, and the GET method implies a read-only operation. It could also mention pagination or response shape, but it discloses the most important failure behavior.

  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 one tight, front-loaded sentence with no filler. 'Gold PRO $29' signals entitlement, 'GET /wp-json/wc/v3/orders' gives the exact contract, and 'BYOK fail-closed' adds behavioral warning. Every chunk earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 7-parameter tool with no output schema and no annotations, the description is incomplete. It does not explain pagination defaults, date formats, return structure, or authentication setup. An agent can make a basic listing call but cannot reliably use advanced filters or interpret the response without external WooCommerce knowledge.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description needed to explain the seven parameters, but none are described. 'after', 'before', 'search', 'customer', and 'per_page' receive no format or meaning beyond their names. The Woo endpoint provides weak implicit context, but not enough to correctly construct filter values.

  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 names the exact operation ('list Woo orders'), HTTP method (GET), and endpoint (/wp-json/wc/v3/orders), making it impossible to confuse with siblings like gold_get_order or gold_list_products. The action and resource are stated unambiguously.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no explicit guidance on when to choose this tool over alternatives such as gold_get_order for a single order or gold_wc_batch for bulk operations. The word 'list' implies a list use case, but the description does not provide context, prerequisites, or exclusions.

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

• gold_list_productsA
  3.6/5.0
  Behavior4/5

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

  The description reveals critical behavioral traits: it is bring-your-own-key (BYOK), requiring WC_STORE_URL and consumer key/secret, and it fails closed if those are missing rather than returning fabricated data. Since no annotations are provided, this disclosure carries the full burden of behavioral transparency. It does not describe return format or pagination, but the credential and fail-closed behavior are valuable and beyond the schema.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence that gets straight to the action and endpoint. The 'Gold PRO $29' phrase is marketing noise that doesn't help invocation, but the rest is dense and efficient. It's reasonably concise while communicating the essential operational constraint (BYOK, fail-closed).

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no annotations, no output schema, and eight optional parameters, the description needs to explain defaults, response shape, and filtering behavior. It only covers the endpoint, credentials, and fail-closed policy. Important context like pagination defaults, the shape of the returned product list, and how filters combine is missing, so an agent may mis-infer behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has only 25% parameter description coverage (page and per_page get descriptions; the other six parameters are bare enums or types). The tool description does not explain any of the parameters, such as how search, status, category, or orderby interact with the endpoint. With low schema coverage and no supplementary description, agents are left to guess parameter meanings.

  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 ('list Woo products') and the exact endpoint ('GET /wp-json/wc/v3/products'). This specific verb+resource clearly distinguishes it from sibling tools like gold_get_product (single product) and gold_list_orders (orders). The 'Gold PRO $29' prefix is extraneous but does not obscure the core purpose.

  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?

  No guidance is provided on when to use this tool versus siblings, such as gold_get_product for a single product or gold_list_orders for orders. The intended use is implied by the description, but no explicit when/when-not or alternative routing is given. This makes the usage guidelines weak, though not misleading.

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

• gold_wc_coupons_bulkA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden and does add useful behaviors: a hard limit of 100, uniqueness of codes, the PREFIX-XXXX naming pattern, an optional usage limit, and a paywall/auth requirement ('PAID ONLY PRO $29'). However, it omits a critical behavioral gate: the confirm parameter must be set to 'CONFIRM' to execute, and it does not mention side effects or error handling.

  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 short sentences, with the main capability, limit, code format, example use case, and optional parameter all front-loaded in the first sentence. The second sentence communicates the paywall. No filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no annotations, no output schema, and only 20% schema description coverage, the description is insufficient for an agent to call this correctly. It omits the mandatory 'confirm' gate, the meaning of the required 'percent_off' parameter, return value, and any guidance on when to choose this over gold_create_coupon. The paywall note is helpful but does not make the tool complete.

  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 only 20%, so the description must compensate. It clearly maps count ('up to 100'), prefix ('PREFIX-XXXX'), and usage_limit ('optional usage limit'). However, the required percent_off parameter is entirely unexplained, and confirm is left to the schema. The description adds meaningful context for several parameters but does not fully compensate for the low coverage.

  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 uses a specific verb ('Generate'), a clear resource ('coupon codes'), and a quantitative scope ('up to 100 unique ... one call'), which distinguishes it from the sibling gold_create_coupon that appears to handle single coupons. The format example (PREFIX-XXXX) and use case ('influencer drops') make intent unmistakable.

  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 phrasing 'in one call' and 'up to 100 unique coupon codes' implies this is the bulk alternative to a single-coupon tool, but it does not explicitly state when to use this tool versus gold_create_coupon or any other sibling. No exclusions or alternative recommendations are provided, so usage context is only implied.

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

• gold_wc_desc_bulk_byokA
  3.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden, and it does well: it states the tool writes descriptions, reads product data, skips existing long descriptions unless overwrite=true, and clarifies that the API key stays local and billing goes to OpenAI. It does not mention confirmation flow or return values, so it is not fully transparent, but it is genuinely informative.

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

  Conciseness4/5

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

  The description is compact and front-loads the core capability before adding key caveats about existing descriptions and pricing. The 'POWER:' prefix is minor marketing fluff and slightly reduces precision, but the overall structure is efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The definition covers the central workflow, paywall constraint, key locality, and overwrite behavior, with support from the schema for confirm and dry_run. Still, it lacks any mention of return format/output and does not fully orient the agent around the confirmation/dry-run execution model, leaving some gaps for a paid, mutating bulk 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 already documents confirm, dry_run, and product_ids, while the description adds useful context for overwrite and the BYOK mechanism. However, tone and words are not explained beyond their schema defaults/enums, and the description only partially compensates for the 50% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies a specific action—bulk-generating unique WooCommerce product descriptions via a user-provided OpenAI key—and summarizes the read-to-write flow. It does not explicitly differentiate itself from sibling tools like gold_wc_seo_meta_bulk, so it stops short of a 5.

  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 use case is implied: bulk product description generation. It also adds practical constraints like BYOK and PRO-only access. However, it does not name alternatives or state explicit when-to-use/when-not-to-use conditions, leaving this dimension only partially covered.

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

• gold_create_productA
  3.7/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 the burden of behavioral disclosure. It explicitly warns 'Destructive' and states 'requires PRO' and 'BYOK fail-closed', covering side effects and a key failure mode. It does not describe response or error behavior, but the most important behavioral traits are present.

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

  Conciseness4/5

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

  The description is one compact sentence and contains almost no filler. The endpoint, destructive warning, BYOK behavior, and PRO requirement are all decision-relevant. The 'Gold PRO $29' prefix is slightly extraneous but does not unduly bloat the description.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description gives essential high-level context for a mutation tool, but with 14 parameters, no output schema, and no annotations, it leaves invocation details like the confirm gate and result shape unexplored. The schema fills some gaps, but the definition is not fully complete on its own.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only about 7%, and the description itself adds no meaning for any of the 14 parameters. It does not mention that name is required or that confirm must be set to CONFIRM, leaving the low-coverage schema to carry the entire parameter burden.

  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 and resource: 'create Woo product via POST /wp-json/wc/v3/products'. This is specific enough to distinguish it from sibling tools like gold_update_product and gold_list_products without needing to inspect their schemas.

  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 usage scenario is implied by the verb 'create' and the tool name, but the description does not explicitly say when to prefer this tool over alternatives like gold_update_product. It does provide prerequisite context with 'requires PRO' and 'BYOK fail-closed'.

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

• gold_get_productA
  3.8/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral disclosure burden. It adds valuable detail through the HTTP method GET, the 'BYOK' authentication requirement, and the 'fail-closed' behavior, which tells the agent that the tool will error rather than proceed without a valid key.

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

  Conciseness4/5

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

  The description is very concise and front-loads the key operational details: endpoint, plan requirement, and auth behavior. The 'Gold PRO $29' token is slightly extraneous but relevant as a prerequisite.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read operation, the description is fairly complete: it names the endpoint, the auth expectation, and failure behavior. However, with no output schema and no annotations, it does not describe the return value shape or error cases, which the agent might need to validate the tool's result.

  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%, and the description does not add meaning beyond the schema's 'product id' parameter. The endpoint path confirms id is a path parameter, but this is already implied by the tool's purpose and 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?

  The description states a specific action ('get single Woo product') and the exact REST endpoint, which clearly distinguishes it from sibling tools like gold_list_products or gold_create_product. Including the path /wp-json/wc/v3/products/{id} leaves no ambiguity about the resource being retrieved.

  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 it is for retrieving one product by ID, and the 'Gold PRO $29' phrase indicates a license prerequisite. However, it does not explicitly state when to prefer this over gold_list_products or mention any alternatives or exclusions.

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

• gold_get_orderA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral burden. It discloses the HTTP method (GET, implying read-only) and meaningful auth behavior ('BYOK fail-closed'). It does not describe return values or error behavior, but these are less critical for a simple retrieval tool.

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

  Conciseness4/5

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

  The description is very compact and front-loads the core API call. However, 'Gold PRO $29' is marketing noise that does not help an agent select or invoke the tool correctly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter GET tool, the description is mostly sufficient, but it leaves out expected return shape, success/error scenarios, and any clarification of 'BYOK' or 'Gold PRO'. These gaps are noticeable because there is no output schema or annotation to fill them.

  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 schema has one undocumented numeric id parameter (0% coverage), but the endpoint template 'orders/{id}' establishes that id is the Woo order ID. This partially compensates for the lack of schema descriptions, though an explicit statement would be stronger.

  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?

  States a specific verb ('get'), a specific resource ('Woo order'), and the exact endpoint ('GET /wp-json/wc/v3/orders/{id}'). This makes it easy to distinguish from siblings like gold_list_orders and gold_get_product.

  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 required id parameter and singular 'get' imply this is for retrieving one order by ID, but the description never explicitly says when to use it versus gold_list_orders or gold_get_product. Usage context is left to inference.

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

• gold_setup_checkA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral disclosure burden. It transparently states that it is a check, only shows names of configured or missing API keys, never values, and outputs the next step. This reasonably implies a non-destructive diagnostic action, though it never explicitly states 'read-only' or 'no side effects'.

  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 short, front-loaded sentences deliver the purpose, the usage instruction, and the key output content with no filler. 'Run this FIRST' is placed immediately after the tool name, maximizing scannability.

  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?

  For a zero-parameter setup diagnostic with no output schema, the description is complete: it tells the agent what to expect (license tier, API key status, next step), and no additional context is needed to invoke it correctly.

  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 takes zero parameters, so the schema already fully documents the invocation surface. The baseline of 4 applies; there are no parameter semantics left to clarify.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb-resource pairing ('SETUP CHECK for WooCommerce Gold') and clarifies exactly what it reports: license tier, API key presence, and next step. This clearly distinguishes it from the operation-focused sibling tools like gold_list_products or gold_create_product.

  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 instruction 'run this FIRST' provides explicit timing guidance and implies it should precede business operations. It does not name when-not-to-use cases or alternatives, but no sibling setup tool exists, so the when-to-use condition is sufficient.

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