Woocommerce
Server Details
WooCommerce MCP Pack — wraps the WooCommerce REST API v3
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- pipeworx-io/mcp-woocommerce
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 10 of 10 tools scored. Lowest: 2.9/5.
The Pipeworx tools (ask_pipeworx, discover_tools, forget, recall, remember) have distinct purposes, but ask_pipeworx and discover_tools both involve tool discovery, which could cause slight confusion. The WooCommerce tools are clearly distinct by resource type and action (get vs list). Overall, most tools are distinct.
Tool names mix styles: Pipeworx tools use lowercase_with_underscores (e.g., ask_pipeworx, discover_tools), while WooCommerce tools use a 'woo_' prefix with get_ or list_ (e.g., woo_get_order). Within each group, consistency is present, but the overall set lacks a single pattern.
10 tools is a reasonable number for a server combining memory/query utilities and WooCommerce CRUD operations. The count feels slightly high given the simplicity of WooCommerce tools (only get/list, no create/update/delete), but still within acceptable range.
The WooCommerce tools only support get and list operations, missing create, update, and delete for orders, products, and customers, which are essential for full lifecycle management. The Pipeworx tools cover basic memory and query needs but lack advanced search or management features.
Available Tools
10 toolsask_pipeworxAInspect
Ask a question in plain English and get an answer from the best available data source. Pipeworx picks the right tool, fills the arguments, and returns the result. No need to browse tools or learn schemas — just describe what you need. Examples: "What is the US trade deficit with China?", "Look up adverse events for ozempic", "Get Apple's latest 10-K filing".
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your question or request in natural language |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the tool will automatically select the best data source and fill arguments, which is a key behavioral trait. It does not disclose potential limitations (e.g., if the question is ambiguous, what fallback occurs) or data source dependencies, but given no annotations are provided, it covers the essential behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus examples) and front-loaded with the core purpose. Every sentence adds value, and examples are included without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple interface (one parameter, no output schema), the description provides sufficient context for an agent to understand its function. It doesn't cover error handling or rate limits, but for a general-purpose question-answering tool, the information is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'question' is well-described in the schema and the description adds context that it should be a natural language request. With 100% schema coverage and a single simple parameter, the description reinforces the schema without needing much additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool accepts plain English questions and returns answers by automatically selecting the appropriate data source and filling arguments. It distinguishes itself from sibling tools that are specific to WooCommerce or memory operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: when the user asks a question in natural language and wants the system to handle tool selection and argument filling. It contrasts with the need to 'browse tools or learn schemas,' implying this tool is the convenient, all-in-one option. Examples illustrate appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_toolsAInspect
Search the Pipeworx tool catalog by describing what you need. Returns the most relevant tools with names and descriptions. Call this FIRST when you have 500+ tools available and need to find the right ones for your task.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tools to return (default 20, max 50) | |
| query | Yes | Natural language description of what you want to do (e.g., "analyze housing market trends", "look up FDA drug approvals", "find trade data between countries") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the tool returns 'the most relevant tools' based on a natural language query, implying semantic search. With no annotations provided, the description adds important behavioral context (e.g., it's a discovery tool, not a mutation). However, it does not disclose potential limitations (e.g., if the search is based on embeddings, synonyms, or exact matches). Still, the core behavior is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a purpose: 1) what it does, 2) what it returns, 3) when to use it. No wasted words, and the most critical instruction ('Call this FIRST') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, no nested objects), the description is complete. It explains the tool's role in the larger system (discovery), what it returns, and when to invoke it. No gaps remain for the agent to make an informed decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters well. The description adds value by explaining the query parameter expects 'Natural language description of what you want to do' with examples, and the limit parameter has default and max values. This enriches the schema without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 the Pipeworx tool catalog by describing what you need.' It also explains the return value ('most relevant tools with names and descriptions') and the context in which to use it (first, when 500+ tools available). This distinguishes it from siblings, which are specific actions like ask_pipeworx or woo_get_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' This tells the agent when to use it (before other tools) and why (navigating a large catalog). No exclusions needed, but the guidance is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgetAInspect
Delete a stored memory by key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key to delete |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the deletion action but does not disclose whether deletion is irreversible, requires confirmation, or has side effects. For a simple delete operation, the description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, clear sentence that conveys the action and resource without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-param tool with no output schema, the description is complete enough. It explains the purpose and the required key. However, it could mention that deletion is permanent if that is the case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter fully (100% coverage) with a clear description. The description adds no additional semantic value beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Delete' and resource 'a stored memory by key', distinguishing it from sibling tools like 'remember' (store) and 'recall' (retrieve).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives guidance, but the action is straightforward and siblings like 'recall' and 'remember' imply complementary usage. A brief mention of when not to use it would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallAInspect
Retrieve a previously stored memory by key, or list all stored memories (omit key). Use this to retrieve context you saved earlier in the session or in previous sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Memory key to retrieve (omit to list all keys) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly states the tool is for retrieval and listing, implying no side effects. However, it does not disclose whether retrieval modifies state or requires any authentication. Still, the behavior is straightforward and well described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, perfectly concise, and front-loads the core functionality. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no output schema, single parameter, no nesting), the description is complete enough. It covers retrieval and listing, and hints at session persistence. No critical gaps are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the effect of omitting the key (list all) versus providing it (retrieve specific), which goes beyond the schema's description. This improves usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves memories by key or lists all if key is omitted. It specifies the verb 'retrieve' and the resource 'memory', and distinguishes from sibling 'remember' and 'forget' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to omit the key (list all) and when to provide it (retrieve specific). It mentions retrieving context saved earlier, but does not explicitly say when not to use this tool versus alternatives like 'discover_tools' or 'ask_pipeworx'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberAInspect
Store a key-value pair in your session memory. Use this to save intermediate findings, user preferences, or context across tool calls. Authenticated users get persistent memory; anonymous sessions last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key (e.g., "subject_property", "target_ticker", "user_preference") | |
| value | Yes | Value to store (any text — findings, addresses, preferences, notes) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behavioral traits: session memory, persistence differences, and implied duration. It does not mention any side effects or limitations (e.g., memory capacity).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loads the core purpose, and each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple parameters, the description is largely complete. It could mention how to retrieve values (recall) but that is covered by sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already provides clear descriptions for both parameters. The description adds examples but does not add meaning beyond the schema; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function ('Store a key-value pair in your session memory') and distinguishes it from siblings like 'recall' and 'forget' by specifying the operation type (store).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (save findings, preferences, context) and notes persistence differences (authenticated vs anonymous), but does not explicitly state when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
woo_get_orderBInspect
Get a single order by ID from a WooCommerce store.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Order ID | |
| _apiKey | Yes | WooCommerce consumer key | |
| _storeUrl | Yes | Store URL (e.g., https://mystore.com) | |
| _apiSecret | Yes | WooCommerce consumer secret |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the tool gets an order but provides no details about authentication requirements, rate limits, or what happens if the order does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose. It is appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (4 params, no nested objects) and absence of output schema, the description is minimally complete but could benefit from mentioning return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all parameters are described in the schema. The description does not add additional meaning beyond what the schema provides, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('a single order by ID from a WooCommerce store'), which clearly distinguishes it from sibling tools like 'woo_list_orders' that list multiple orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing a single order by ID, but does not explicitly state when not to use it or suggest alternatives. Sibling tools like 'woo_list_orders' are not mentioned for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
woo_get_productCInspect
Get a single product by ID from a WooCommerce store.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Product ID | |
| _apiKey | Yes | WooCommerce consumer key | |
| _storeUrl | Yes | Store URL (e.g., https://mystore.com) | |
| _apiSecret | Yes | WooCommerce consumer secret |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries full burden. It does not disclose whether the tool is read-only, any authentication nuances, rate limits, or error behavior (e.g., what happens if ID does not exist). Only states 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient and front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It does not mention the return value structure, error handling, or any limitations. A minimal viable description for a simple get-by-ID tool should at least indicate it returns a product object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 4 parameters have descriptions in the input schema), so baseline is 3. The description adds no additional meaning beyond the schema; it simply repeats the resource and context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), resource ('single product'), and context ('from a WooCommerce store'). It distinguishes from sibling tools like woo_list_products (which lists multiple products) by specifying 'single product by ID'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. For example, it does not mention that to get multiple products or search, one should use woo_list_products. No exclusions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
woo_list_customersBInspect
List customers from a WooCommerce store.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| _apiKey | Yes | WooCommerce consumer key | |
| per_page | No | Results per page (max 100, default 20) | |
| _storeUrl | Yes | Store URL (e.g., https://mystore.com) | |
| _apiSecret | Yes | WooCommerce consumer secret |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so description carries full burden. The description does not reveal behavioral traits such as rate limiting, authentication requirements (though implied by API keys), or return format. It is neutral but minimally informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that clearly states purpose. No unnecessary words, but could benefit from additional context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description is somewhat incomplete as it doesn't hint at what the response contains. However, for a list tool, the purpose is fairly obvious.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no further meaning beyond what the schema provides; it does not explain pagination or API key usage beyond property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists customers from a WooCommerce store. It distinguishes from sibling tools like woo_list_orders and woo_list_products by specifying 'customers' as the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. For example, it doesn't mention that other tools exist for orders and products, or when pagination parameters would be appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
woo_list_ordersCInspect
List orders from a WooCommerce store.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| status | No | Filter by status: any, pending, processing, on-hold, completed, cancelled, refunded, failed | |
| _apiKey | Yes | WooCommerce consumer key | |
| per_page | No | Results per page (max 100, default 20) | |
| _storeUrl | Yes | Store URL (e.g., https://mystore.com) | |
| _apiSecret | Yes | WooCommerce consumer secret |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description does not disclose behavioral traits such as rate limits, data freshness, or whether it supports pagination (though pagination is implied by 'page' and 'per_page' parameters). It is neutral but lacks depth for a full understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 8 words, which is efficient for a simple list operation. It is front-loaded with the action and resource. However, it could be slightly more informative without sacrificing conciseness, such as mentioning pagination support.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (3 required), no output schema, and no annotations, the description is minimally complete. It explains the basic purpose but does not cover edge cases, error handling, or output structure. For a tool with moderate complexity, it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what the schema provides, such as clarifying the relationship between 'page' and 'per_page' or how 'status' filtering works. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List orders from a WooCommerce store' specifies the verb ('list') and resource ('orders'), which is clear. However, it does not differentiate from sibling tools like woo_get_order, which retrieves a single order, or woo_list_customers, which lists customers. The description lacks specificity about filtering or pagination that would set it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like woo_get_order for a single order, or how to handle authentication setup. The description does not mention prerequisites like valid API credentials or store configuration, which are crucial given the required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
woo_list_productsCInspect
List products from a WooCommerce store.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| _apiKey | Yes | WooCommerce consumer key | |
| per_page | No | Results per page (max 100, default 20) | |
| _storeUrl | Yes | Store URL (e.g., https://mystore.com) | |
| _apiSecret | Yes | WooCommerce consumer secret |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so description must cover behavior. It only states the basic function. No mention of pagination, rate limits, data freshness, or whether it lists all products or only published ones. The schema provides pagination params but description doesn't clarify their behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (list with pagination) and no output schema. Description is minimal but covers the basic purpose. Missing details like pagination behavior and default results, but acceptable for a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 5 parameters described in schema). Description adds no extra parameter info beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List products from a WooCommerce store' clearly states the verb 'List' and the resource 'products' from a 'WooCommerce store'. It distinguishes from siblings like woo_list_orders, woo_get_product, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. For example, when to use woo_list_products vs woo_get_product is not mentioned. No context about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!