WooCommerce MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources and actions, but there is some overlap between list_customers and search_customers, and list_products and search_products, which could cause minor confusion in tool selection. However, descriptions clarify their differences.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as create_coupon, get_customer, list_orders, and update_order_status. There are no deviations in naming conventions, making the set predictable and easy to navigate.
Tool Count3/5
With 34 tools, the count is on the high side for a typical MCP server, bordering on heavy. While it covers many aspects of WooCommerce, it may feel overwhelming, but it's not extreme and aligns with the platform's broad scope.
Completeness5/5
The tool set provides comprehensive coverage of the WooCommerce domain, including CRUD operations for key resources (coupons, customers, orders, products, webhooks), reporting, system status, and administrative functions. There are no obvious gaps that would hinder agent workflows.
Average 3.2/5 across 34 of 34 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/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 states the action (delete) but doesn't cover critical aspects like permissions required, whether deletion is permanent or reversible, confirmation prompts, or error handling. The 'force' parameter hints at optional behavior, but this isn't explained.
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 extremely concise with a single sentence, 'Delete a webhook.', which is front-loaded and wastes no words. However, this brevity comes at the cost of completeness.
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 the tool's destructive nature (delete), no annotations, 0% schema coverage, and an output schema (which isn't described), the description is inadequate. It lacks essential context like behavioral traits, parameter meanings, and usage guidelines, making it incomplete for safe and effective use.
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 must compensate but adds no parameter information. It doesn't explain what 'webhook_id' is, how to obtain it, or what the 'force' parameter does (e.g., bypasses confirmation). This leaves both parameters undocumented beyond their schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a webhook' clearly states the action (delete) and resource (webhook), but it's overly generic and doesn't differentiate from sibling tools like delete_coupon or delete_product. It lacks specificity about what a webhook is in this context.
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 provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing webhook ID), when not to use it, or how it relates to sibling tools like create_webhook or list_webhooks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does (create) and lists topics, but doesn't mention permissions needed, rate limits, whether creation is idempotent, what happens on duplicate webhooks, or what the response contains. For a mutation tool with zero annotation coverage, this is insufficient.
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 brief and front-loaded with the core purpose. The topic list is efficiently presented as examples rather than exhaustive enumeration. However, the 'etc.' at the end suggests incomplete information which slightly reduces 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?
Given this is a mutation tool with 5 parameters, 0% schema description coverage, no annotations, but with an output schema, the description is moderately complete. The output schema reduces the need to describe return values, but the description lacks crucial context about permissions, side effects, and parameter meanings that would be needed for safe usage.
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 must compensate for undocumented parameters. The description only mentions 'Topics' which maps to the 'topic' parameter, leaving 4 other parameters (name, delivery_url, secret, status) completely unexplained. The topic examples are helpful but don't cover the full parameter set.
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 the verb 'Create' and resource 'webhook', making the purpose immediately understandable. It distinguishes from siblings like 'delete_webhook' and 'list_webhooks' by specifying creation. However, it doesn't explicitly differentiate from other 'create_' tools beyond listing topics.
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. It doesn't mention prerequisites, when webhooks are appropriate, or how this differs from other notification methods. The topic list implies scope but doesn't provide decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions discount types and amount format, but lacks critical information: whether this is a write operation (implied but not stated), permission requirements, rate limits, error conditions, or what happens on success. For a creation tool with 8 parameters, this is insufficient transparency.
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 efficiently structured in two sentences with zero wasted words. It's appropriately sized for the tool complexity and gets straight to the point without unnecessary elaboration.
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?
Given this is a creation tool with 8 parameters, no annotations, and an output schema (which reduces need to describe returns), the description is moderately complete. It covers the core action and key parameters but misses behavioral context and documentation for most parameters. It's minimally viable but has clear 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?
The description adds meaningful context for two parameters (discount_type and amount) by explaining valid values and format examples. However, with 8 total parameters and 0% schema description coverage, it leaves 6 parameters completely undocumented. The value added is real but insufficient to compensate for the large coverage gap.
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 the verb ('Create') and resource ('a coupon'), making the purpose immediately understandable. It distinguishes from siblings like 'delete_coupon' or 'get_coupon' by specifying creation. However, it doesn't explicitly differentiate from other creation tools like 'create_customer' or 'create_product' beyond the resource type.
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 provided on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or compare with similar tools like 'list_coupons' or 'get_coupon'. The description is purely functional without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Create an order' which implies a write/mutation operation, but doesn't mention permissions required, whether this triggers payment processing, what happens on failure, or what the response contains. The example helps but doesn't cover behavioral aspects like side effects or error conditions.
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 extremely concise with only two sentences, both essential. The first states the purpose, the second provides critical format information for the most complex parameter. No wasted words or redundant 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 a mutation tool with 8 parameters, 0% schema description coverage, and no annotations, the description is insufficient. While an output schema exists (which helps), the description doesn't explain what happens when creating an order, what validation occurs, or how to handle the many undocumented parameters. It leaves too much unexplained for proper agent usage.
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 0%, so the description must compensate. It only provides semantics for one parameter ('line_items') with an example format, leaving 7 other parameters (customer_id, status, billing_email, etc.) completely unexplained. The description adds value for line_items but fails to address the majority of parameters.
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 the verb ('Create') and resource ('order'), making the purpose immediately understandable. However, it doesn't differentiate this from sibling tools like 'create_customer' or 'create_product' beyond the resource name, nor does it specify what type of order (e-commerce, service, etc.).
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 provided about when to use this tool versus alternatives like 'update_order_status' or 'get_order'. The description doesn't mention prerequisites (e.g., needing existing products/customers), nor does it specify when this tool is appropriate versus other creation tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states 'Create a product' which implies a write operation, but doesn't mention authentication requirements, rate limits, side effects, or what happens on success/failure. The description lacks crucial behavioral context 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 is brief and to the point with two sentences. It efficiently communicates the core action and key parameters. While it could be more comprehensive, there's no wasted verbiage or unnecessary 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?
For a mutation tool with 10 parameters, 0% schema description coverage, and no annotations, the description is insufficient. It doesn't explain the return values (though an output schema exists), doesn't cover most parameters, and provides minimal behavioral context. Given the complexity and lack of structured documentation, this description leaves too many 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?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'Type: simple, grouped, external, variable' and 'Categories: comma-separated IDs' which partially explains two parameters (product_type and categories). However, 8 other parameters remain completely undocumented in both schema and description, leaving significant gaps.
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 the verb 'create' and resource 'product', making the purpose evident. It also specifies product types and categories, which helps distinguish it from other creation tools like create_coupon or create_customer. However, it doesn't explicitly differentiate from update_product or delete_product in terms of when to use each.
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 update_product or delete_product. It mentions product types and categories but doesn't explain when to choose one type over another or what prerequisites might be needed. No explicit when/when-not statements are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions filtering and ordering. It lacks critical behavioral details: whether it's read-only, pagination behavior (implied by parameters but not described), rate limits, authentication needs, or error handling. This is inadequate for a tool with 6 parameters and output 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 front-loaded with the main purpose and efficiently lists key parameters in a single sentence. It avoids redundancy but could be slightly more structured (e.g., separating filtering from ordering). Overall, it's concise with minimal waste.
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?
Given 6 parameters with 0% schema coverage and an output schema (which reduces need to explain returns), the description partially compensates by detailing some parameters. However, it lacks behavioral context and full parameter coverage, making it minimally adequate but with clear gaps for effective tool use.
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 0%, so the description must compensate. It adds meaning by explaining 'role' options (all, administrator, customer), 'search' by name/email, and 'orderby' fields. However, it doesn't cover 'per_page', 'page', or 'order', leaving gaps. Baseline would be lower, but partial compensation raises it to 3.
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 the action ('List customers') and specifies filtering and ordering capabilities. It distinguishes from siblings like 'get_customer' (singular retrieval) and 'search_customers' (broader search), though not explicitly. However, it lacks explicit sibling differentiation, keeping it at 4 instead of 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 explicit guidance on when to use this tool versus alternatives like 'search_customers' or 'get_customer'. The description implies usage for listing with filters but doesn't specify scenarios, prerequisites, or exclusions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the search functionality without mentioning permissions, rate limits, pagination behavior, or what happens on no matches. This is inadequate for a search tool with no annotation coverage.
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 extremely concise—a single sentence with no wasted words. It's front-loaded with the core purpose, making it efficient and easy to parse, though this conciseness contributes to gaps in other dimensions.
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?
Given the tool's moderate complexity (search with two parameters), no annotations, and an output schema (which handles return values), the description is minimally adequate. It states the basic purpose but lacks details on behavior, parameters, and usage context, making it incomplete for optimal agent guidance.
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?
With 0% schema description coverage, the description must compensate but only vaguely mentions 'by name or email' for the 'query' parameter. It doesn't explain the 'per_page' parameter at all, leaving two parameters poorly documented. The description adds minimal value beyond the schema.
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 the tool's purpose: searching customers using name or email as criteria. It specifies the verb ('search') and resource ('customers'), but doesn't differentiate from sibling tools like 'list_customers' or 'get_customer', which prevents a perfect score.
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 'list_customers' or 'get_customer'. It doesn't mention prerequisites, exclusions, or comparative use cases, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It states the tool searches products, implying it's a read-only operation, but doesn't mention any behavioral traits such as pagination (though 'per_page' in the schema hints at it), rate limits, authentication requirements, or what the search returns (e.g., partial matches, case sensitivity). This leaves significant gaps for a tool with parameters.
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 a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for a simple search tool, making it easy to parse 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?
Given the tool's moderate complexity (2 parameters, no annotations, but an output schema exists), the description is minimally adequate. The output schema likely covers return values, reducing the need for description details there. However, with no annotations and low schema coverage, the description lacks context on behavior and parameter usage, making it incomplete for optimal agent understanding.
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 must compensate for undocumented parameters. It mentions 'by name or SKU,' which relates to the 'query' parameter, adding some semantic context. However, it doesn't explain the 'per_page' parameter or provide details on query syntax (e.g., wildcards, exact matches). With 2 parameters and low schema coverage, the description adds limited value beyond the schema.
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 the tool's purpose: 'Search products by name or SKU.' It specifies the verb ('Search') and resource ('products'), and mentions the searchable fields (name or SKU). However, it doesn't distinguish this from sibling tools like 'list_products' or 'get_product', which might offer alternative ways to retrieve product data.
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. It doesn't mention sibling tools like 'list_products' (which might list all products without filtering) or 'get_product' (which might retrieve a single product by ID), nor does it specify prerequisites or exclusions. Usage is implied but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. 'List all webhooks' implies a read-only operation, but it doesn't disclose behavioral traits like pagination behavior (hinted by parameters), rate limits, authentication needs, or what 'all' entails (e.g., active vs. inactive). It adds minimal context beyond the basic action.
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 extremely concise with a single sentence 'List all webhooks.' It is front-loaded and wastes no words, making it easy to parse. Every part earns its place by stating the core action clearly.
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?
Given the tool's low complexity (a list operation with optional pagination parameters), an output schema exists (which handles return values), and no annotations, the description is minimally complete. It states what the tool does but lacks details on behavior, usage, or parameter context, leaving gaps for an agent to infer 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 description adds no parameter semantics beyond the input schema, which has 0% description coverage. However, there are 0 required parameters, and the tool likely functions without inputs, so the baseline is high. The schema defines 'per_page' and 'page' with defaults, but the description doesn't explain their role, though this is acceptable given the low parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all webhooks' clearly states the verb ('List') and resource ('webhooks'), making the purpose understandable. However, it lacks specificity about scope or filtering compared to sibling tools like 'get_webhook' (singular) or 'create_webhook', which could help differentiate it better. It's not tautological but remains somewhat vague.
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 provided on when to use this tool versus alternatives. For example, it doesn't mention if this is for bulk retrieval versus specific lookups with 'get_webhook', or how it relates to 'create_webhook' or 'delete_webhook'. The description offers no context or exclusions, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It states this is a creation tool, implying a mutation, but doesn't specify permissions needed, whether the operation is idempotent, what happens on duplicate emails, or the response format. The mention that 'Only email is required' adds minimal context about input constraints but lacks depth on behavioral traits.
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 extremely concise with two short sentences that are front-loaded: the first states the purpose, and the second adds a key constraint. There is no wasted verbiage, making it efficient and easy to parse.
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?
Given the tool's complexity (a mutation with 4 parameters, no annotations, but an output schema exists), the description is minimally adequate. The output schema likely covers return values, reducing the need for description details there. However, for a creation tool with no annotations, more context on behavior, permissions, or error handling would improve completeness.
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 0%, so the description must compensate for undocumented parameters. It adds value by specifying that 'Only email is required,' clarifying the required parameter among the four. However, it doesn't explain the semantics of optional parameters like first_name or username, leaving gaps in understanding their purpose or format.
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 the action ('Create a new customer') and specifies the resource ('customer'), which distinguishes it from siblings like create_product or create_order. However, it doesn't explicitly differentiate from other customer-related tools like get_customer or search_customers, though the 'create' verb inherently implies a write operation versus read operations.
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. It doesn't mention prerequisites, such as needing admin permissions or a valid email format, nor does it contrast with sibling tools like search_customers for finding existing customers. The only usage hint is the requirement for email, but this is already covered in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that setting 'customer_note=True' makes the note visible to customers, which is valuable context about visibility/permissions. However, it doesn't address other critical behavioral aspects like whether this is a write operation (implied but not stated), what permissions are required, what happens on success/failure, or how it interacts with the order system.
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 perfectly concise - two sentences that directly address the tool's core functionality and a key parameter nuance. Every word earns its place, with no redundancy or unnecessary elaboration. The information is front-loaded with the primary purpose stated immediately.
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?
Given that this is a write operation (implied by 'create' in the name) with no annotations and 3 parameters at 0% schema coverage, the description is minimally adequate. The presence of an output schema helps, but the description should ideally address more behavioral aspects for a mutation tool. It covers the basic purpose and one parameter nuance, leaving other important context 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?
The description adds meaningful context about the 'customer_note' parameter's effect ('make it visible to the customer'), which goes beyond the schema's basic type information. However, with 0% schema description coverage and 3 parameters total, it doesn't explain 'order_id' or 'note' parameters at all. The baseline is 3 since the description provides some parameter context but doesn't fully compensate for the schema's lack of descriptions.
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 the action ('Add a note') and target resource ('to an order'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'list_order_notes' or 'update_order_status', which would be needed for a perfect score.
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 minimal usage guidance by mentioning the 'customer_note' parameter, but offers no explicit advice on when to use this tool versus alternatives like 'update_order_status' or how it relates to 'list_order_notes'. There's no mention of prerequisites, error conditions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It states the tool creates a refund, implying a write operation, but doesn't cover critical behaviors: whether it requires specific permissions, if it's idempotent, what happens on failure (e.g., invalid order_id), rate limits, or response format. The amount format hint ('e.g., '25.00'') is useful but insufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first sentence states the core purpose, and the second adds crucial parameter context. Every word earns its place with no redundancy or fluff, making it easy for an agent to parse 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?
Given the tool's complexity (a mutation with 3 parameters), lack of annotations, and presence of an output schema, the description is minimally complete. The output schema likely covers return values, reducing the burden, but the description misses key context: no behavioral details, incomplete parameter guidance, and no usage rules. It's adequate for basic understanding but has clear 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?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'amount' by specifying it as a string with an example format ('25.00'), which clarifies beyond the schema's generic string type. However, it doesn't explain 'order_id' (e.g., where to find it) or 'reason' (e.g., optional, typical values), leaving two of three parameters inadequately documented.
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 the tool's purpose: 'Create a refund for an order.' It specifies the verb ('Create') and resource ('refund for an order'), distinguishing it from siblings like create_coupon or create_customer. However, it doesn't explicitly differentiate from other order-related tools like update_order_status, which could be relevant for refund scenarios.
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. It doesn't mention prerequisites (e.g., order must exist, payment must be captured), exclusions (e.g., cannot refund more than order total), or related tools like update_order_status for partial refunds. Usage is implied only by the action name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 implies a read-only operation ('Get'), but doesn't specify permissions, rate limits, error conditions, or what 'full details' includes (e.g., format, fields). This is inadequate for a tool with no annotation coverage.
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 a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse 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?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description is minimally adequate. However, with no annotations and low schema coverage, it should provide more context about behavior and parameters to be fully helpful.
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 0% description coverage, so the description must compensate. It mentions 'coupon' but doesn't explain the 'coupon_id' parameter beyond what's implied. Since there's only one parameter, the baseline is 4, but the description adds minimal value, so it scores slightly lower at 3.
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 the action ('Get full details') and resource ('for a coupon'), making the purpose understandable. However, it doesn't distinguish this from sibling tools like 'list_coupons' or 'get_product', which would require more specificity about what 'full details' entails compared to other retrieval tools.
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 'list_coupons' or other 'get_' tools. It lacks context about prerequisites (e.g., needing a coupon ID) or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It mentions the 'period' parameter but doesn't describe what the tool returns (e.g., list format, data fields like product names and sales counts), whether it's a read-only operation, or any limitations like rate limits or authentication needs. This leaves significant gaps for an agent to understand the tool's 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 extremely concise and front-loaded, with two sentences that directly state the tool's purpose and parameter options without any wasted words. Every sentence earns its place by providing essential information, making it easy to parse 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?
Given the tool's low complexity (1 parameter) and the presence of an output schema (which should cover return values), the description is minimally adequate. However, it lacks context on behavioral aspects like data freshness or sorting criteria, and with no annotations, it doesn't fully compensate for these gaps, making it incomplete for optimal agent use.
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 description adds value by listing possible period values ('week, month, last_month, year'), which the input schema does not specify (schema description coverage is 0%). However, it doesn't explain the semantics of these values (e.g., 'last_month' vs. 'month'), and with only one parameter, the baseline is 4, but the incomplete coverage reduces this to 3 as it partially compensates for the schema gap.
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 the action ('Get top-selling products') and specifies the resource ('products'), making the purpose immediately understandable. It distinguishes itself from siblings like 'get_product' or 'get_product_totals' by focusing on ranking rather than individual retrieval or aggregation. However, it doesn't specify what 'top' means (e.g., top 10, top 5), leaving some ambiguity.
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. It doesn't mention when to choose it over 'get_product_totals' for sales data or 'get_sales_report' for broader analytics, nor does it specify prerequisites like required permissions or data availability. Usage is implied only by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions listing and optional search but doesn't disclose behavioral traits like pagination behavior (implied by parameters but not described), rate limits, authentication needs, or what happens with empty results. The description is minimal and lacks operational context.
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 extremely concise—two short sentences with zero wasted words. It's front-loaded with the core purpose and efficiently adds the optional feature. Every sentence earns its place by conveying essential information without fluff.
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?
Given the tool's low complexity (list operation with optional filtering) and the presence of an output schema (which handles return values), the description is somewhat complete. However, with no annotations and 0% schema coverage, it lacks details on pagination, search behavior, and usage context, making it minimally adequate but with clear 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?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'optionally search by code,' which hints at the 'search' parameter's purpose but doesn't cover 'per_page' or 'page.' It adds minimal value beyond the schema's property names, leaving two parameters undocumented.
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 the tool's purpose: 'List coupons' specifies the verb and resource. It adds optional search functionality, which distinguishes it from a simple list operation. However, it doesn't explicitly differentiate from sibling tools like 'get_coupon' or 'search_customers' in the same domain.
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. It mentions optional search by code but doesn't clarify when to use this versus 'search_customers' or 'get_coupon', nor does it mention prerequisites, pagination context, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a list operation but doesn't mention whether it's read-only, requires authentication, has rate limits, pagination behavior, or what happens with invalid order IDs. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 a single, efficient sentence that immediately states the tool's purpose. Every word earns its place by specifying the resource (notes), scope (on an order), and types (internal staff and customer-facing). No unnecessary elaboration or repetition.
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?
Given the tool has an output schema (which handles return values) and only 1 parameter, the description is reasonably complete for a simple list operation. However, with no annotations and the need to fully document behavior, it should ideally mention that this is a read-only operation and any access requirements. The presence of an output schema elevates the score from what it would be otherwise.
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 has 0% description coverage, so the description must compensate. It implies the tool operates on 'an order' which maps to the 'order_id' parameter, but doesn't explain what format the ID should be, where to find it, or provide examples. With only 1 parameter and some contextual mapping, this meets the baseline for minimal parameter guidance.
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 the verb 'List' and resource 'notes on an order', specifying both internal staff notes and customer-facing notes. It distinguishes from sibling tools like 'list_orders' or 'get_order' by focusing specifically on notes. However, it doesn't explicitly differentiate from 'create_order_note' in the description text itself.
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. It doesn't mention prerequisites, timing considerations, or compare with sibling tools like 'get_order' (which might include notes) or 'create_order_note'. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states it's a list operation but doesn't mention pagination behavior (implied by parameters), rate limits, authentication requirements, or what the output contains. For a tool with parameters and output schema, this is inadequate.
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 extremely concise—a single sentence with zero wasted words. It's front-loaded with the core purpose, making it efficient for quick understanding, though this conciseness comes at the cost of detail.
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?
Given the tool's low complexity (simple list operation), 2 parameters with defaults, and the presence of an output schema, the description is minimally complete. However, it lacks context on usage, behavioral traits, or differentiation from siblings, which are gaps for an agent needing to invoke it correctly.
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 0%, so the description must compensate, but it adds no parameter information. However, there are only 2 parameters with clear titles ('Per Page', 'Page') and defaults, making them self-explanatory for pagination. This baseline score reflects minimal but adequate context given the simple parameters.
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 the verb ('List') and resource ('tax rates'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_coupons' or 'list_products' beyond specifying the resource type, and the scope 'all' is implied but not explicitly contrasted with filtered alternatives.
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. It doesn't mention prerequisites, context for listing tax rates, or compare it to other list tools or search functions. This leaves the agent without direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions 'force=True for permanent deletion,' which hints at a behavioral trait (permanent vs. non-permanent deletion), but it doesn't disclose other critical aspects like required permissions, side effects (e.g., if deletion affects related data), rate limits, or error conditions. This is inadequate for a mutation tool with zero annotation coverage.
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 extremely concise—two short sentences with zero waste. It front-loads the core purpose and efficiently adds a key parameter detail, making it easy to scan and understand 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?
Given the tool's complexity (a deletion operation with 2 parameters), no annotations, and an output schema (which reduces the need to describe return values), the description is minimally adequate. It covers the basic action and a key parameter nuance but lacks details on permissions, errors, or broader context, leaving room for improvement.
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 0% schema description coverage, the description must compensate. It adds meaning by explaining the 'force' parameter's effect ('permanent deletion'), which goes beyond the schema's basic type information. However, it doesn't cover the 'coupon_id' parameter or provide details like format or constraints, leaving some gaps. Since there are only 2 parameters and one is well-explained, it scores above baseline.
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 the action ('Delete') and resource ('a coupon'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'delete_product' or 'delete_webhook' beyond the resource name, which is why it doesn't reach a perfect score.
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 includes a brief usage note about 'force=True for permanent deletion,' which implies when to use that parameter, but it lacks broader guidance on when to use this tool versus alternatives (e.g., compared to 'get_coupon' or 'list_coupons'), prerequisites, or exclusions. No explicit when/when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does (get counts) but doesn't describe the return format, whether it's paginated, if it requires authentication, rate limits, or any other behavioral characteristics. This leaves significant gaps for a tool that presumably queries data.
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 extremely concise - a single sentence that directly states the tool's purpose with zero wasted words. It's front-loaded with the core functionality and provides helpful examples of status types.
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?
Given the tool has an output schema (which should document return values) and no parameters, the description is minimally adequate. However, for a data retrieval tool with no annotations, it should ideally provide more context about what the output contains, whether it's aggregated data, and any behavioral constraints.
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 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't need to discuss parameters, though it could have mentioned if any implicit filtering (like date ranges) applies.
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 the tool's purpose: 'Get order counts by status' with specific status examples (pending, processing, completed). It uses a specific verb ('Get') and resource ('order counts'), though it doesn't explicitly differentiate from sibling tools like get_sales_report or get_product_totals.
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 provided on when to use this tool versus alternatives. The description doesn't mention when this tool is appropriate, what prerequisites might exist, or how it differs from related tools like get_sales_report or list_orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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's a read operation ('Get'), but doesn't disclose behavioral traits like permissions needed, rate limits, pagination, or response format. For a tool with zero annotation coverage, this is a significant gap.
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?
Single sentence, front-loaded with the core purpose, no wasted words. Every part earns its place by specifying the action, resource, and breakdown.
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?
Given 0 parameters and an output schema exists, the description covers the purpose adequately. However, with no annotations and siblings like 'list_products', it lacks context on usage scenarios and behavioral details, making it minimally viable but with clear gaps.
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 0 parameters with 100% schema coverage, so no parameter documentation is needed. The description adds value by clarifying the scope ('by type') and listing the specific types, which isn't in the schema. Baseline is 4 for zero parameters.
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 the action ('Get product counts') and resource ('by type'), specifying the four product types. It distinguishes from siblings like 'get_product' (single product) and 'get_order_totals' (different resource), but doesn't explicitly contrast with 'list_products' (detailed list vs. counts).
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 on when to use this tool versus alternatives like 'list_products' or 'get_product'. The description implies it's for aggregated counts rather than detailed listings, but lacks explicit when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions what information is retrieved but doesn't disclose behavioral traits such as whether it's read-only, requires authentication, has rate limits, or returns real-time vs cached data. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operation.
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 a single, efficient sentence that front-loads the purpose and lists key components without unnecessary words. Every part adds value by specifying what 'system status' includes, making it appropriately sized and well-structured.
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?
Given the tool's complexity (diagnostic retrieval with no parameters) and the presence of an output schema, the description is minimally adequate. It outlines what data is fetched but lacks behavioral context due to no annotations. With an output schema, it doesn't need to explain return values, but more detail on usage or constraints would improve completeness.
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 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for zero parameters is 4, as the description appropriately doesn't discuss parameters and focuses on the tool's purpose.
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 the verb 'Get' and the resource 'WooCommerce system status', listing specific components like versions, database, plugins, server environment, and store diagnostics. It distinguishes from siblings by focusing on system diagnostics rather than CRUD operations on entities like orders or products, though it doesn't explicitly name alternatives.
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 provided on when to use this tool versus alternatives. While it's implied for system diagnostics, there's no mention of prerequisites, timing, or comparison to other tools like 'ping' for basic connectivity checks. The description lacks explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It doesn't mention whether this is a read-only operation, if it requires authentication, pagination behavior (implied by parameters but not explained), rate limits, or what happens with empty filters. The description only covers filtering options without broader operational context.
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 extremely concise—a single sentence that efficiently communicates the core functionality and key filtering parameters. Every word serves a purpose with no wasted text, making it easy to parse 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?
Given that there's an output schema (which handles return values) and the description covers most parameter semantics, the description is reasonably complete for a listing tool. However, the lack of annotations and missing behavioral context (like pagination explanation or authentication needs) prevents a higher score, especially with 6 parameters and no schema descriptions.
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 description adds significant value beyond the schema, which has 0% description coverage. It explains that 'status' accepts specific values (pending, processing, etc.), 'customer' is a customer ID, and date range uses ISO 8601 format. However, it doesn't cover 'per_page' or 'page' parameters, leaving pagination semantics implicit rather than explicit.
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 the verb ('List') and resource ('orders'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_order' (singular) or 'search_customers' (different resource), which would require explicit comparison for a perfect score.
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 'get_order' (for a specific order) or 'search_customers' (for customer-related queries). It only lists filtering capabilities without context about appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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's a list operation, implying read-only behavior, but doesn't disclose any behavioral traits such as permissions needed, rate limits, pagination, or what 'enabled status and settings' entails. This leaves gaps for an agent to understand execution details.
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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and every part contributes to understanding what the tool does.
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?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, as a read operation with no annotations, it lacks details on behavioral aspects like data format or constraints, making it incomplete for full agent guidance.
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 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description doesn't add parameter details, which is appropriate here, earning a baseline score above 3 due to the lack of parameters.
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 the action ('List all') and resource ('payment gateways'), specifying what information is included ('enabled status and settings'). It distinguishes itself from other list_* tools by focusing on payment gateways, though it doesn't explicitly differentiate from non-list siblings.
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 provided on when to use this tool versus alternatives. While it's clear this is for listing payment gateways, there's no mention of prerequisites, context, or comparison to other tools like get_system_status that might overlap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It states the tool lists shipping zones with methods but doesn't cover critical aspects like permissions, rate limits, pagination, or response format, which are essential for a list operation.
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 a single, efficient sentence with no wasted words. It is front-loaded with the core action and resource, making it easy to understand 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?
Given the tool has 0 parameters and an output schema exists, the description is minimally adequate. However, as a list tool with no annotations, it lacks details on behavioral traits like data scope or limitations, which could be important for completeness.
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 0 parameters with 100% schema description coverage, so the schema fully documents the inputs. The description doesn't need to add parameter details, and it appropriately focuses on the tool's purpose 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 clearly states the verb ('List') and resource ('shipping zones'), specifying that it retrieves all zones with their methods. It distinguishes from siblings like list_products or list_customers by focusing on shipping zones, though it doesn't explicitly differentiate from similar list tools.
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 provided on when to use this tool versus alternatives. The description lacks context about prerequisites, timing, or comparisons to other tools like list_tax_rates or list_payment_gateways, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states this is an update operation (implying mutation) but doesn't disclose important behavioral traits: whether this requires specific permissions, if status changes are reversible, what happens with invalid status transitions, rate limits, or error conditions. The description is minimal and lacks critical operational context.
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 extremely concise - just two sentences that communicate the core functionality and parameter constraints efficiently. Every word earns its place: the first sentence states the purpose, the second provides critical parameter semantics. There's zero fluff or redundancy.
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?
Given that there's an output schema (which handles return values), the description's job is lighter. However, for a mutation tool with no annotations and 2 parameters, the description is incomplete. It covers the status parameter well but lacks information about order_id format/validation, error conditions, permissions needed, and behavioral constraints. The presence of an output schema prevents a lower score, but significant gaps remain.
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 0% schema description coverage, the description must compensate for the schema's lack of documentation. It effectively clarifies the 'status' parameter by listing all valid values (pending, processing, on-hold, completed, cancelled, refunded, failed), which adds significant semantic meaning beyond the bare schema. However, it doesn't explain the 'order_id' parameter or provide format/validation details.
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 the verb ('Update') and resource ('an order's status'), making the purpose immediately understandable. It distinguishes itself from siblings like 'update_product' by focusing specifically on order status rather than product attributes. However, it doesn't specify whether this is for a single order or batch processing, which prevents a perfect score.
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. It doesn't mention prerequisites (e.g., order must exist), doesn't differentiate from similar tools like 'create_order_note' for status updates, and offers no context about appropriate scenarios or constraints. The list of status values is helpful but doesn't constitute usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It states the tool retrieves data ('Get'), implying it's a read operation, but doesn't mention any behavioral traits such as authentication requirements, rate limits, error handling, or what happens if the customer_id doesn't exist. This leaves significant gaps in understanding how the tool behaves in practice.
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 a single, efficient sentence that front-loads the core purpose ('Get full details for a customer') and adds specific details ('including billing/shipping addresses and order stats') without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function.
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 low complexity (1 parameter, no nested objects) and the presence of an output schema (which handles return values), the description is reasonably complete. It clearly states what the tool does and what data it retrieves. However, the lack of annotations and minimal parameter guidance means it doesn't fully address all contextual needs for safe and effective use.
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 has 1 parameter with 0% description coverage, so the description must compensate. It doesn't explicitly mention the 'customer_id' parameter or provide any details about its format or constraints. However, since there's only one required parameter and the tool name implies its purpose, the description's focus on what data is retrieved offers some contextual value, but it doesn't fully compensate for the lack of parameter documentation.
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 the verb ('Get') and resource ('full details for a customer'), specifying what information is included ('billing/shipping addresses and order stats'). It distinguishes from sibling tools like 'list_customers' and 'search_customers' by focusing on retrieving detailed data for a single customer, though it doesn't explicitly name these alternatives.
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 when detailed customer information is needed, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'list_customers' or 'search_customers'. No prerequisites or exclusions are mentioned, leaving the agent to infer context from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 indicates a read operation ('Get'), but does not disclose behavioral traits such as authentication requirements, error handling, rate limits, or whether it returns all details or a subset. This is a significant gap for a tool with no annotation coverage.
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 a single, efficient sentence that front-loads the purpose and details without waste. Every word contributes to understanding the tool's function, making it appropriately sized and well-structured.
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 low complexity (one parameter) and the presence of an output schema (which handles return values), the description is mostly complete. However, it lacks behavioral context (e.g., permissions, errors) and parameter guidance, which are minor gaps in an otherwise adequate description.
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 0%, so the description must compensate. It does not mention the order_id parameter at all, failing to add meaning beyond the input schema. However, with only one parameter, the baseline is 4, but the lack of any parameter guidance reduces the score to 3.
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 the action ('Get full details') and resource ('an order'), specifying what information is included (line items, shipping, billing, payment info). It distinguishes from siblings like list_orders (which lists multiple orders) and get_order_totals (which focuses on totals), but could be more explicit about this differentiation.
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 when detailed order information is needed, but does not explicitly state when to use this tool versus alternatives like list_orders (for summaries) or get_order_totals (for totals). No exclusions or prerequisites are mentioned, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes what the tool does but lacks critical behavioral traits: it doesn't specify if this is a read-only operation, what permissions are required, whether it's cached or real-time, rate limits, or what the output contains. The description is minimal and misses key operational context.
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 extremely concise and front-loaded: the first three words state the core purpose, followed by parameter details in a compact format. Every sentence earns its place with no wasted words, making it easy to parse quickly while conveying necessary information efficiently.
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?
Given the tool has an output schema (which handles return values) and no annotations, the description is moderately complete. It covers parameter semantics well but lacks behavioral context and usage differentiation from siblings. For a reporting tool with 3 parameters, it provides basic operational guidance but misses broader context about when and how to use it effectively.
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 description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that 'period' accepts values like 'week', 'month', 'last_month', 'year', and that 'date_min/date_max' should be in YYYY-MM-DD format, providing essential semantics not in the schema. However, it doesn't clarify if parameters are mutually exclusive or how defaults interact, leaving some gaps.
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 the tool's purpose: 'Get sales report' specifies the verb and resource. It distinguishes from siblings like 'get_order_totals' or 'get_product_totals' by focusing on sales reports, though it doesn't explicitly contrast with them. The purpose is specific but could better differentiate from similar reporting 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 through parameter details (period options and date ranges), suggesting when to use different parameter combinations. However, it lacks explicit guidance on when to choose this tool over alternatives like 'get_order_totals' or 'get_top_sellers', and doesn't mention prerequisites or exclusions. Usage is contextually implied but not clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It mentions the 'parent' parameter behavior but doesn't describe pagination behavior (implied by 'per_page' and 'page' parameters), rate limits, authentication needs, or what the output contains. For a listing tool with no annotation coverage, this leaves significant gaps in understanding how it operates.
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 extremely concise—two short sentences with zero wasted words. It front-loads the core purpose and immediately follows with a key usage tip, making it highly efficient and easy to parse.
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?
Given the tool's moderate complexity (listing with pagination and filtering), no annotations, and an output schema present, the description is minimally adequate. It explains the filtering aspect but omits details on pagination behavior and output format, which the output schema might cover. However, for a tool with three parameters and no annotations, it should provide more behavioral context to be fully complete.
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 description adds meaningful context for the 'parent' parameter by explaining that 'parent=0' returns top-level categories, which clarifies its semantic role beyond the schema's basic type definition. With 0% schema description coverage and three parameters, this compensates well for one parameter, though 'per_page' and 'page' remain undocumented in both schema and description.
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 the action ('List') and resource ('product categories'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'list_products' or 'list_coupons', but the specific resource focus provides adequate clarity.
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 provides some usage guidance by explaining when to use 'parent=0' for top-level categories, which implies a hierarchical structure. However, it doesn't specify when to use this tool versus alternatives like 'list_products' or other listing tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions filtering and ordering capabilities but doesn't describe pagination behavior (implied by 'per_page' and 'page' parameters), rate limits, authentication requirements, or what happens when no filters are applied. For a read operation with 8 parameters, this leaves significant behavioral gaps.
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 efficiently structured in two sentences: one stating the core purpose, the second detailing filtering and ordering options. Every word earns its place with zero redundancy. It's front-loaded with the main action and follows with implementation details.
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?
Given the tool's complexity (8 parameters, no annotations, but with output schema), the description is moderately complete. It covers filtering semantics well but lacks behavioral context about pagination, authentication, or error handling. The presence of an output schema means return values don't need explanation, but other operational aspects remain undocumented.
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 description adds substantial meaning beyond the schema, which has 0% description coverage. It explains what each filter parameter does (status values, category ID, search term, on_sale flag) and lists valid orderby options. While it doesn't cover all 8 parameters explicitly (missing 'order', 'per_page', 'page'), it provides crucial context for the most semantically important ones.
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 the verb ('List') and resource ('products'), making the purpose immediately understandable. It distinguishes from siblings like 'get_product' (singular retrieval) and 'search_products' (broader search), though it doesn't explicitly name these alternatives. The description is specific but could be more precise about scope.
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 through the listed filter options (status, category, etc.) but doesn't explicitly state when to use this tool versus alternatives like 'search_products' or 'get_product'. It provides context for filtering but lacks clear guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 this is a read operation ('Get'), but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or response format. The description is minimal and lacks important operational context.
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 a single, efficient sentence that immediately states the tool's purpose and scope. Every word contributes value without redundancy or unnecessary elaboration.
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 has an output schema (which handles return values), a single clear parameter, and a straightforward read operation, the description provides adequate context. It could benefit from more behavioral transparency, but covers the essential purpose and scope for this type of 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?
With only one parameter (product_id) and 0% schema description coverage, the description doesn't add specific parameter information. However, the tool's purpose inherently clarifies that product_id identifies which product to retrieve details for. For a single-parameter tool, this provides adequate semantic context.
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 the verb 'Get' and resource 'product' with specific details about what information is retrieved (pricing, inventory, categories, images, attributes). It distinguishes from sibling tools like 'list_products' by focusing on a single product's full details rather than listing multiple products.
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 when detailed information about a specific product is needed, but doesn't explicitly state when to use this tool versus alternatives like 'search_products' or 'list_products'. No guidance is provided about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 adds value by explaining the effect of the 'force' parameter (permanent deletion vs. trash bypass), which is a key behavioral trait. However, it doesn't cover other aspects like permissions required, error conditions, or what the output schema might indicate, leaving gaps in transparency for a destructive operation.
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 extremely concise with two sentences that directly address the tool's purpose and key parameter behavior. It is front-loaded with the main action and wastes no words, making it efficient and easy to parse for an AI agent.
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?
Given the tool's complexity (destructive operation with 2 parameters), no annotations, and an output schema present, the description is moderately complete. It covers the core action and a critical parameter, but for a deletion tool, it lacks details on permissions, error handling, or confirmation prompts, which could be important for safe usage. The output schema might fill some gaps, but the description itself has room for improvement.
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 description coverage is 0%, so the description must compensate. It adds meaningful semantics by explaining the 'force' parameter's effect ('permanent deletion (bypass trash)'), which clarifies beyond the schema's boolean type. The 'product_id' is implied but not detailed, but with only 2 parameters and one well-explained, this provides good compensation, though not exhaustive.
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 the action ('Delete') and resource ('a product'), making the purpose specific and understandable. It distinguishes from sibling tools like 'update_product' or 'get_product' by focusing on deletion. However, it doesn't explicitly differentiate from 'delete_coupon' or 'delete_webhook' beyond the resource name, which is implied but not stated.
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 provides some guidance by mentioning 'Set force=True for permanent deletion (bypass trash)', which implies an alternative behavior (non-permanent deletion) and a context for using the force parameter. However, it lacks explicit when-to-use vs. alternatives (e.g., compared to other deletion tools or update operations) and doesn't specify prerequisites or exclusions, leaving usage somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 reveals that this is a mutation tool ('Update'), specifies partial update behavior, and documents a special case for sale_price removal. However, it lacks information about permissions, side effects, error conditions, or response format, leaving significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, both of which add value. The first sentence states the core purpose, and the second provides important behavioral and parameter guidance without any wasted words.
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 8 parameters, 0% schema description coverage, and no annotations, the description is incomplete. While it covers partial update behavior and sale_price handling, it lacks information about permissions, validation rules, error responses, and the meaning of other parameters. The presence of an output schema helps but doesn't fully compensate for these gaps.
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 description coverage is 0%, so the description must compensate. It adds crucial semantic information about partial updates ('Only provide fields you want to change') and the special handling for sale_price removal, which isn't evident from the schema alone. However, it doesn't explain the purpose or constraints of most of the 8 parameters, leaving some ambiguity.
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 the action ('Update a product') and specifies the resource ('product'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling update operations (like update_order_status), which would require 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 description provides some implicit guidance ('Only provide fields you want to change') which suggests partial updates are supported, but it doesn't explicitly state when to use this tool versus alternatives like create_product or delete_product, nor does it mention prerequisites or constraints beyond the sale_price behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 describes the tool's function (validation and info retrieval) and output (store info fields), but lacks details on potential errors, authentication requirements, or rate limits. It adequately covers the core behavior but misses operational nuances.
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 a single, efficient sentence that front-loads the key actions ('validate connection' and 'get store info') and lists the specific info retrieved. Every word earns its place with no redundancy or unnecessary details.
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 simplicity (0 parameters, output schema exists), the description is largely complete for its purpose. It specifies what store info is returned, and the output schema will detail the structure. However, it could benefit from mentioning error cases or prerequisites, slightly reducing completeness.
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 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description does not need to add parameter semantics, and it correctly avoids mentioning any parameters, earning a baseline score of 4 for not introducing confusion.
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 with specific verbs ('validate connection', 'get store info') and resources ('WooCommerce'), and it distinguishes itself from siblings by focusing on connection validation and basic store metadata rather than CRUD operations on specific entities like orders or products.
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 implies usage for connection validation and retrieving store information, which provides clear context for when to use it (e.g., initial setup or health checks). However, it does not explicitly state when not to use it or name alternatives, such as using get_system_status for more detailed system information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-woocommerce MCP server](https://glama.ai/mcp/servers/AlexlaGuardia/mcp-woocommerce/badges/card.svg)](https://glama.ai/mcp/servers/AlexlaGuardia/mcp-woocommerce)

Score Badge

Copy to your README.md:

[![mcp-woocommerce MCP server](https://glama.ai/mcp/servers/AlexlaGuardia/mcp-woocommerce/badges/score.svg)](https://glama.ai/mcp/servers/AlexlaGuardia/mcp-woocommerce)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AlexlaGuardia/mcp-woocommerce'

If you have feedback or need assistance with the MCP directory API, please join our Discord server