CommerceHub MCP

by spirit122

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.2.2
Disambiguation3/5
Tool names generally indicate distinct resources and actions, but many premium tools share identical 'UPGRADE REQUERIDO' descriptions, forcing agents to rely solely on names. Overlaps like products_list vs products_search and customers_list vs customers_search also create ambiguity.
Naming Consistency4/5
Most tools follow a consistent domain_action pattern (e.g., products_list, orders_get, inventory_update). Minor deviations like setup_help and license_status (where the second part is a noun rather than a verb) are rare and do not seriously break the pattern.
Tool Count2/5
With 41 tools, the set is substantially larger than typical, and a large portion are gated behind upgrade requirements, making the surface feel bloated. The scope could be reasonably covered with fewer well-chosen tools.
Completeness2/5
The free tier is heavily read-only (list/get for products, orders, customers, inventory), while essential write operations like create, update, delete, and fulfill are locked behind premium plans. This creates significant gaps where agents cannot complete basic lifecycle workflows without upgrades.
Average 2.8/5 across 41 of 41 tools scored. Lowest: 1.8/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.
Add a glama.json file to provide metadata about your server.
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?
The description discloses one behavioral trait: the tool requires a higher plan. This is a prerequisite condition, but it says nothing about what the tool does, what side effects occur, or how it behaves when invoked. With no annotations provided, the description carries the full burden but provides minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence without fluff, but it is severely under-specified. It lacks any content about the tool's purpose or behavior, which is not conciseness but a lack of necessary information. The upgrade note is useful but does not compensate for the missing core description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a complex operation ('inventory_bulk') but the description provides no information about its functionality, inputs, outputs, or side effects. There is no output schema, no annotations, and no parameter details. The only context is an upgrade requirement, which is far from sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. There are no parameter semantics to explain; the baseline for zero parameters is 4. The description does not add or need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does. It only mentions an upgrade requirement and directs the user to 'license_status', with no verb or resource indicating the tool's functionality. For a tool named 'inventory_bulk', there is no indication of bulk actions on inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 only instruction is to use 'license_status' to see licensing options, which is about checking plans, not about selecting this tool for a task. There is no mention of appropriate contexts 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, the description carries the full burden. It discloses a key behavioral constraint (requires higher plan), but provides no other behavioral details such as side effects, prerequisites, or what happens when invoked. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is under-specified. It lacks any substantive content about the tool's function. Brevity is not helpful when it omits the core purpose entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for a tool that presumably cancels orders. It provides no functional information, making it impossible for an agent to know when to select this tool. The paywall note is a limitation, not a description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information, but none is needed given the empty schema. The description does not hinder parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does (e.g., cancel an order). It only mentions an upgrade requirement and points to license_status. This gives the agent no idea of the tool's actual purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool cannot be used without a higher plan and suggests an alternative (license_status), but it never explains when to use this tool itself or provides any usage context. There is no guidance on appropriate scenarios for orders_cancel.
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 exist, so the description carries the full burden of disclosure. It does reveal a plan restriction, but says nothing about side effects, data affected, or what happens if called without the update, leaving the tool's behavior largely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it omits essential purpose and behavior. While structurally tidy, it fails to convey meaningful information, so it does not fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no parameters or schema complexity, the description is wholly inadequate for a sync tool. It neither explains the tool's function nor references sibling tools like products_list for differentiation, leaving the agent with only the name to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. There is nothing for the description to add about parameters, and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only mentions an upgrade requirement. The tool's function (syncing products) is absent, making the purpose completely unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 reference to license_status is about upgrade options, not usage scenarios, so the agent cannot decide when to invoke products_sync.
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 does disclose a prerequisite (higher plan required), which is somewhat transparent, but it omits any behavioral traits like what the tool does, side effects, or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. It earns its place by conveying the upgrade requirement, though it sacrifices any functional detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and no parameter details, the description must provide context. It only mentions a license gate, leaving the agent unable to determine if this tool is relevant for a conversion-analytics task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers this dimension. Description adds nothing, but none is needed; baseline 4 for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only says an upgrade is required, never stating what analytics_conversion does. The name hints at conversion analytics, but no verb or resource is described, leaving the tool's purpose entirely unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool instead of alternatives. The only direction is to use license_status to see upgrade options, which is about licensing, not usage.
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, the description carries the behavioral disclosure burden. It does disclose an access restriction (requires a higher plan) and points to license_status, but gives no information about outputs, side effects, or failure modes beyond the paywall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but brevity is not conciseness when the content is only an upgrade gate. It is under-specified and does not earn its place as a functional tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the schema is empty and there are no parameters, the tool's purpose and return behavior are entirely unexplained. Without an output schema or annotations, the description should provide context about what inventory_forecast does; it fails to do so.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so the schema already covers everything. The description adds no parameter details, but none are needed; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what inventory_forecast does; it only says an upgrade is required and directs to license_status. There is no verb+resource describing the tool's functionality, making the purpose missing.
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 siblings like analytics_forecast or inventory_low_stock. It only mentions a prerequisite (higher plan) and tells users to check license_status, which is a vague reference rather than 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?
With no annotations, the description carries the full burden. It discloses that the tool requires a higher plan, which is a behavioral constraint, but it says nothing about the tool's core behavior, side effects, or what happens when called without the upgrade. This is minimal value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence, which is efficient, but it is under-specification rather than genuine conciseness. It conveys only an upgrade gate, not tool functionality, so it fails to earn its place as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has no parameters or output schema, the description is completely inadequate for understanding what the tool does or how to invoke it correctly. It only tells the agent that an upgrade is needed, leaving the purpose and behavior entirely unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers parameter semantics. The description does not mislead about parameters, and there is nothing to add. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description never states what the tool actually does (refund orders). It only provides an upgrade requirement, which is a meta-message rather than a functional purpose. This does not distinguish it from sibling tools beyond the name.
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 implies the tool should not be used until a higher plan is obtained, and it suggests checking 'license_status' for upgrade options. However, it gives no guidance on when the tool would be appropriate to use or how it compares to alternative order-related tools like orders_cancel or orders_create.
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?
The description discloses the upgrade requirement, which is a useful behavioral constraint. However, with no annotations, it fails to describe the actual operation (deletion), potential irreversibility, or any side effects, leaving the agent in the dark about the tool's core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified. It omits the tool's primary function and focuses only on a licensing side note, making it too sparse to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool description is severely incomplete. It does not specify what the tool does, what resource it acts on, or any expected behavior. There is no output schema, so the agent has no information about return values. It fails to provide a complete picture for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter information that needs elaboration. The description adds no parameter details, but with no parameters, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does. It only mentions an upgrade requirement, leaving the agent to infer from the name that it deletes a product. This is essentially missing purpose information.
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 only guidance is to use 'license_status' to see options, which is a prerequisite rather than a usage context. There is no indication of when to use products_delete versus alternatives like products_update or products_create.
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 reveals a significant restriction (requires a higher plan), which is useful, but it completely hides the tool's core behavior, side effects, or return value. This partial transparency is insufficient for a tool that cannot even be invoked without an upgrade.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but conciseness is not the issue—under-specification is. It spends its only sentence on an upgrade warning rather than explaining the tool's purpose. The content does not earn its place because it omits essential information that a concise description should include.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description is the only source of contextual information. It fails to explain the tool's purpose, behavior, or expected use, making it impossible for an agent to know what the tool does or when to invoke it. This is completely inadequate.
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 input schema has zero parameters, so the description is not expected to explain parameter details. The baseline for 0 parameters is 4, and the description does not contradict or fail to compensate for anything since there are no params to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does at all. It only mentions an upgrade requirement and points to 'license_status', leaving the actual function of 'products_seo_audit' entirely unspecified. The name suggests an SEO audit tool, but the description provides no verb, resource, or outcome.
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 only guidance is to use 'license_status' to see upgrade options, which is an alternative for handling licensing, not for the tool's intended use. There is no clear 'when to use this tool' context, no exclusions, and no mention of what scenarios warrant calling this tool versus 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?
With no annotations, the description carries the full burden. It does disclose the key prerequisite that a higher plan is required, which is useful. However, it does not describe the tool's operational behavior, error handling, or what happens when called without the upgrade.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the upgrade warning prominently placed. It is concise and readable, though it omits purpose information. The sentence earns its place as a warning but does not fully serve the tool's description.
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?
Despite the tool being simple (zero params, no output schema), the description is incomplete because it never explains what analytics_forecast does or what value it provides. It only communicates licensing restrictions, leaving the tool's core purpose completely unaddressed.
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?
There are zero parameters, so the schema has nothing to document. Baseline 4 applies; no parameter information is needed, and the description does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what analytics_forecast does; it only says an upgrade is required and points to license_status. The tool's actual function is entirely absent, making it impossible for an agent to know when this tool is relevant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use analytics_forecast versus any other analytics tool like analytics_revenue or inventory_forecast. The mention of license_status is a licensing redirect, not a usage guideline for this tool.
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?
The description discloses a behavioral trait: the tool requires a higher plan to access. However, with no annotations and no description of the operation, return format, or side effects, this single detail carries little weight. The tool's core behavior remains hidden.
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 sentence with a clear upgrade tag, directly pointing to a relevant action. It is front-loaded and contains no fluff, making it extremely concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is severely incomplete. It does not state what the tool does, what it returns, or any operational context. With no annotations, no output schema, and no parameter details, this one-line gate message is insufficient for an agent to understand or safely invoke the 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?
The tool has zero parameters, so the schema provides no parameter details. According to the rubric, a baseline of 4 applies for zero-parameter tools since the description does not need to compensate for missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states that an upgrade is required and directs to license_status, but it never explains what the customers_orders tool actually does. The tool name hints at customer orders, but the description provides no verb or resource to clarify its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus sibling tools like orders_list or customers_list. The mention of license_status is about upgrade options, not about choosing between tools.
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, the description must reveal behavior. It does disclose the upgrade requirement, a real constraint, but it says nothing about what the tool does, side effects, or what happens when invoked without the higher plan.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence. It is efficient and immediately communicates the upgrade gate, though it lacks substantive tool information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a simple parameterless tool, a complete description should state its purpose. This description only warns about licensing and points to another tool, leaving the actual function of `customers_segments` completely unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema with 100% coverage. The baseline for 0 parameters is 4, and no parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description never states what the tool does. "Upgrade required" only communicates a licensing restriction, not the tool's function of managing or retrieving customer segments.
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?
It directs the user to call `license_status` to see options, which is a remediation step for the upgrade requirement, but it gives no guidance on when to use `customers_segments` itself or how it fits among sibling tools.
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?
The description discloses that the tool is gated behind a higher plan, which is a behavioral restriction. It also suggests checking license_status. However, it fails to describe what the tool actually does or what happens when called. With no annotations, this is minimal but non-zero transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loaded with a warning, but it is under-specified and lacks any functional description. It is concise in length but not in substance, providing only a licensing notice rather than a useful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and zero parameters, the description is the only source of contextual information. It fails to state what inventory_history does, when to use it, or what it returns, making it fundamentally incomplete for an agent to correctly select or invoke the 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?
The tool has zero parameters, and the schema is empty. The description adds no parameter semantics, but with no params to explain, the baseline of 4 applies. The description's silence on params is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what inventory_history does. It is entirely a licensing notice ('requires a higher plan') with no mention of the tool's function or resource. The name suggests inventory history, but the description is misleading as a tool purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directs users to 'use "license_status" to see options', which is an explicit alternative, but it does not explain when to use inventory_history itself. The guidance is about license escalation, not about the tool's intended use case, so it offers little 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 full responsibility for behavioral disclosure. It does disclose that the tool requires a higher plan, which is a useful constraint, but it does not describe what happens when called, what effect it has, or any other operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, making it easy to parse. However, it is under-specified as a tool definition, so it is efficient but not complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter detail, the description is the only source of context. It fails to explain the tool's purpose, behavior, or return value, leaving an agent unable to correctly select or invoke the 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?
The input schema has zero parameters, so there is nothing for the description to explain. The 0-parameter baseline of 4 applies, and the description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states an upgrade requirement and points to license_status; it never states that the tool updates inventory or performs any other action. Thus the tool's actual purpose is missing, leaving only the name as a hint.
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 inventory_update itself. It only directs users to license_status to view upgrade options, which is a referral to an alternative rather than a usage guideline for this tool.
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, the description carries the full burden, but it only discloses that the tool is gated behind a higher plan. It does not reveal what happens when invoked, whether it performs a write operation, or what response to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words. However, it is concise at the expense of content—it provides only a gate message rather than functional information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with no parameters and no output schema, the description leaves the tool's core purpose completely unspecified. An agent cannot determine what orders_create does, when to invoke it, or what effect it will have, making this description inadequate.
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 input schema has zero parameters, so a baseline of 4 applies. The description adds no parameter details, but there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only says an upgrade is required and points to license_status. The tool name implies order creation, but the description never confirms this and focuses entirely on licensing.
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 only guidance is to use license_status to view upgrade options, which is a prerequisite hint but not actual usage guidance for the tool itself. There is no explanation of when to use orders_create versus sibling tools like orders_list or orders_fulfill.
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 present. The description does disclose that a higher plan is required, which is a behavioral gate, but it does not disclose the tool's core behavior or consequences of calling without the upgrade.
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 single sentence is succinct and directly states the upgrade requirement and suggestion to check license_status. No fluff 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 simple gated tool, the description covers the upgrade gate but omits the actual purpose and behavior. An agent cannot determine what the tool does or whether it's relevant to a task.
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 zero parameters and 100% schema coverage, the baseline is 4. The description adds no parameter-specific meaning, but none is needed since the schema has no properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only says an upgrade is required and points to license_status. For a tool named 'products_bulk_price', the actual function (e.g., bulk price update) is never mentioned, making purpose completely unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The reference to license_status is about checking license options, not about usage scenarios or prerequisites for this tool.
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 does disclose that the tool requires a higher plan, which is a real behavioral constraint, but it says nothing about the side effects, permissions, or what happens when invoked. The tool's actual behavior remains opaque.
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 extremely short and front-loaded, immediately communicating the upgrade requirement. It is concise and the single sentence earns its place as a warning, though it sacrifices substantive purpose information for brevity.
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 that the tool has no parameters and no output schema, the main missing context is the tool's purpose and behavior. The description is complete only regarding the upgrade gate, but as a tool definition for an AI agent it is inadequate because it never explains what 'orders_add_note' does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4. The empty input schema provides no parameter details, and the description adds no parameter-related information, but this is acceptable because there are no parameters to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool actually does. It only says '[UPGRADE REQUERIDO] Esta herramienta requiere un plan superior' (upgrade required, requires a higher plan), which gives no indication that this tool adds a note to an order. The name 'orders_add_note' is the only clue, but the description itself is missing a clear verb+resource statement.
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 tells the user to use 'license_status' to see options, which is a mild pointer to an alternative. However, it provides no guidance on when to use 'orders_add_note' itself or any use cases, prerequisites, or exclusions beyond the upgrade requirement.
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?
The description discloses a behavioral constraint: the tool requires a higher plan. It also directs to license_status. Yet it does not mention what the tool actually does or any side effects of calling it (e.g., creating a product). With no annotations, this is partial transparency at best.
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, front-loaded sentence that clearly communicates the upgrade requirement and the next step. Every word serves a purpose; it is concise without being under-specified in terms of its own content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 0 params and no output schema, so complexity is low, but the description still fails to explain the core purpose. It is essentially an upsell message, not a tool description. An agent cannot know that products_create is for creating a product, making the description fundamentally incomplete.
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 input schema has zero parameters, and schema description coverage is 100% (vacuously). There are no parameter details to explain, so the description need not compensate. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states that a higher plan is required; it never mentions that this tool creates products. The name implies the function, but the description itself is missing a clear verb and resource. This is misleading for an agent selecting a tool.
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?
It says to use 'license_status' to see options, which is a pointer to an alternative when the plan is insufficient. However, it gives no guidance on when to use products_create relative to sibling tools like products_update or products_bulk_price. The usage context is limited to a prerequisite.
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?
No annotations are provided, so the description carries the burden of disclosing behavior. It states the upgrade requirement, a useful prerequisite, but omits all other behavioral information such as what the tool returns or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded with the upgrade alert. It is concise and to the point, though it sacrifices substance; however, for what it conveys, it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 0 params, the description is the only source of info. It only addresses licensing, completely failing to explain the tool's actual purpose, expected outputs, or use cases. This is inadequate for any agent to select or invoke the tool 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 input schema has zero parameters and 100% coverage (vacuously), so the description does not need to explain parameters. Baseline for 0 params is 4, and no additional information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only says it requires a higher plan and to use license_status. It fails to define analytics_by_channel's function (e.g., viewing analytics by channel), making it a misleading tool description.
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 says to use license_status to see options, which is a pointer to an alternative, but it does not explain when to use this tool or how it compares to sibling analytics tools. It only implies you should not use it until upgraded.
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?
It discloses that the tool requires a higher plan, which is a behavioral restriction. However, since annotations are absent, the description carries the full burden but does not explain what happens if invoked or any other behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the critical requirement. It is appropriately sized for a gating message, though it lacks substance regarding the tool's purpose.
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?
Despite low complexity and no parameters, the description is incomplete because it never explains what 'analytics_refunds' actually does. The agent cannot determine when to use it, only that it is currently unavailable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to add parameter details and does not do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only mentions an upgrade requirement. The tool's function remains unknown, making the purpose missing rather than clarified.
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?
It directs users to 'license_status' to see options, providing a when-not-to-use hint (due to upgrade requirement) but gives no guidance on when the tool should actually be used or functional alternatives.
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, the description does disclose a key behavioral trait: the tool requires a higher plan. This is useful context beyond the empty schema. However, it does not say what happens on invocation (e.g., error message, blocked call) or any other behavior, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the upgrade warning, and contains no wasted words. However, its brevity comes at the cost of omitting the tool's actual purpose, though the sentence that exists is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description is the only source of context. It fails to define what customers_lifetime_value actually does, making the description inadequate for an agent to understand the tool's role. It only communicates the access restriction, leaving the core function entirely unexplained.
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 input schema has zero parameters and 100% schema description coverage, so the baseline is 4. The description adds no parameter detail, but none is required because there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states 'UPGRADE REQUERIDO' and that a higher plan is required, but never mentions that this tool computes customer lifetime value. It does not state any verb+resource for the tool's core function, making it indistinguishable from a license/upgrade tool rather than an analytics tool.
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 tells the agent to use 'license_status' to see plan options, which is a useful pointer for upgrade-related actions but gives no guidance on when customers_lifetime_value itself should be used. It implies the tool is gated but does not explain alternatives for the actual lifetime-value functionality.
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?
The only behavioral disclosure is that the tool is gated behind a higher plan. No information is given about side effects, output, or any other behavior. Since no annotations are provided, the description carries the full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise. However, it is under-specification rather than truly concise; it contains minimal substantive content and does not help the agent understand the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is essentially a lock-out message. It tells the agent the tool is unavailable and to check license_status, but it fails to explain what orders_fulfill actually does. With no output schema or annotations, this leaves a significant gap in understanding.
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 input schema is empty, so there are no parameters to describe. The description adds nothing, but with zero parameters the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does. It only mentions a plan upgrade requirement, leaving the agent to infer functionality from the name 'orders_fulfill'. No verb or resource is specified.
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 explicitly states the tool is not currently available (requires a higher plan) and directs the agent to use 'license_status' to see options. This provides a when-not and an alternative, but it does not explain when the tool should be used once the upgrade is obtained.
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, the description carries the burden of disclosing behavioral traits. It transparently states the access restriction (requires a higher plan), which is meaningful. Yet it does not describe any side effects, return behavior, or what happens if called without the required plan.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff, but it sacrifices essential purpose information. It is concise yet under-specified, making it only minimally acceptable.
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 there is no output schema and no parameters, the description should clearly define what the tool does. It does not; it only provides an upgrade warning and a pointer to license_status. This is insufficient for an agent to understand the tool's role among many product-related siblings.
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 input schema has zero parameters and 100% schema description coverage, so the baseline is 4. There are no parameters for the description to explain, and it adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what products_update does. It only says that a higher plan is required and instructs the user to check license_status, omitting any mention of updating products or the tool's actual function.
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 explicitly warns that the tool requires a higher plan and tells the user to use license_status to see options, which is a clear 'when not to use' and alternative guidance. However, it offers no context for when the tool should be used once the upgrade is obtained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 disclosing behavioral traits. It only says it 'generates' a summary, which implies a read operation, but it does not state whether it modifies data, requires special permissions, has performance implications, or how data freshness is handled. This lack of disclosure 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?
The description is a single sentence that is front-loaded with the action ('Genera') and resource ('resumen ejecutivo completo'), followed by the specific contents. Every word earns its place with no redundancy or filler.
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 optional params, no output schema, no annotations), the description adequately summarizes what the report contains but leaves out details about the return format, whether it's read-only, and how to interpret the aggregated metrics. It's sufficient for basic understanding but not fully complete for an agent that needs to know output structure or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters (period with enum/default and providers with description). The description adds no additional parameter-related meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Genera resumen ejecutivo completo') and lists the included metrics (revenue, orders, top products, stock, customers, conversion), making the tool's function evident. It doesn't explicitly differentiate from sibling analytics_* tools, but the 'completo' summary scope is distinctive enough.
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 this is for obtaining a comprehensive business overview, but it provides no explicit guidance on when to use it versus the more granular analytics_* sibling tools. No alternatives or exclusions are mentioned, so usage context is inferred rather than stated.
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 must disclose behavioral traits. It mentions output includes revenue and percentage of total, but does not state that this is a read-only operation, how the ranking is computed, any default behavior (e.g., sort by revenue), or limitations. Lacks safety and 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?
A single, front-loaded sentence with no filler. It immediately states the action and output. Appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is too brief. It doesn't explain the response structure, default behavior, or usage context. While the schema documents parameters, the lack of output schema means the agent is left guessing at the return format.
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 provides 100% description coverage for all 4 parameters, so the baseline is 3. The description adds minimal semantic value beyond the schema; it only hints at the overall output, not the specific meaning of parameters like limit or sort_by, which are already documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Obtiene' (gets) and identifies the resource as 'ranking de productos más vendidos' (ranking of best-selling products) with revenue and percentage of total. This clearly distinguishes it from sibling analytics tools like analytics_revenue or analytics_dashboard, which focus on different metrics.
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 scenarios, prerequisites (e.g., provider requirement), or contrast with sibling analytics tools. The description simply states what it does, leaving the agent to infer usage.
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, the description carries the burden of behavioral disclosure. It indicates a read-only listing operation with filtering and pagination, which are behavioral traits. However, it does not disclose response format, ordering, defaults, or required provider behavior, so it provides only minimal transparency.
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, front-loaded sentence that names the action, resource, and key filters without unnecessary detail. Every phrase earns its place, making it highly concise 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 6 parameters, no annotations, and no output schema, the description is adequate but incomplete. It covers the main filters and pagination but omits the required 'provider' parameter and gives no hint about the return payload or how it differs from customers_search. The rich schema compensates partially, but the description alone leaves 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 input schema already describes all 6 parameters with 100% coverage, so the description need not repeat them. It adds natural-language mapping for segment, min spent, orders, and pagination, but omits 'provider' (a required parameter) and adds no deeper semantics beyond what the schema provides.
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 uses a specific verb 'Lista' (lists) with the resource 'clientes' and names the key filters: segment, minimum spend, orders, and pagination. It is clear and distinct from customers_get, customers_orders, customers_segments, and customers_lifetime_value, though it does not explicitly contrast with customers_search, which could overlap.
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 explicit guidance on when to use this tool versus alternatives like customers_search or customers_segments. It simply states what the tool does, leaving the agent to infer the intended use case without exclusion or alternative hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, but it only states the action ('activa') without disclosing side effects, idempotency, or requirements. For a mutation tool, this is a significant gap—the agent cannot anticipate what activating a license entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, includes the essential verb and object, and omits extraneous detail. It is front-loaded and appropriately sized for a single-parameter operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter fully documented in the schema and a straightforward operation, the description is mostly sufficient. However, the lack of output schema and behavior details (e.g., irreversible, triggers a server-side change) leaves the agent without information about consequences, making it only minimally 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 schema already describes the license_key parameter with format, achieving 100% coverage. The description adds the context that it applies to 'CommerceHub Pro o Business' keys, clarifying which key types are valid beyond the raw format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Activa' (activate) with a clear resource ('license key de CommerceHub Pro o Business'), which precisely identifies the tool's function. It distinguishes this from sibling tools like 'license_status' by implying activation rather than checking status.
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 gives no guidance on when to use this tool versus checking license status or viewing plans. It does not state prerequisites or exclusions, leaving the agent to infer usage from the 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 states what the tool does (searches customers) but does not disclose any behavioral traits such as case sensitivity, pagination limits, error conditions, or whether it requires a specific provider. This is a significant gap for a tool that may behave differently across e-commerce platforms.
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, concise sentence that is front-loaded with the action and resource. It contains no waste and is 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 (3 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It does not provide usage guidance or behavioral details, and it fails to mention the required provider parameter or how results are returned. For a search tool in a family of customer tools, more context on when to use it and what to expect 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 100%, so all parameters (limit, query, provider) have descriptions in the schema. The tool description adds the semantic that query searches across name, email, or phone, which is already partially captured in the query parameter description. Since the schema does the heavy lifting, the description provides marginal added value, consistent with the baseline of 3.
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 'Busca clientes por nombre, email o teléfono' clearly states the tool's purpose: searching customers by specific attributes (name, email, phone). It uses a specific verb and resource, and distinguishes itself from sibling tools like customers_list (which lists all customers) and customers_get (which retrieves a single customer).
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 as a search function for customers, but it does not explicitly state when to use this tool over alternatives such as customers_list or customers_get. No explicit when/when-not or alternative comparisons are provided, though the purpose implies a search-by-query scenario.
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?
No hay anotaciones, por lo que la descripción debe cubrir el comportamiento. Menciona los campos retornados (stock, reservado, disponible), lo cual es útil, pero no declara explícitamente que es de solo lectura ni detalla posibles requisitos de permisos o limitaciones. Para una operación de consulta es información básica aceptable, aunque insuficiente.
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?
La descripción es una sola oración clara y sin redundancias, con la acción principal como primera palabra. No hay contenido innecesario y el mensaje es directo.
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?
La descripción es adecuada para una herramienta simple de inventario con esquema bien documentado, pero no hay esquema de salida y la descripción no detalla el formato de respuesta ni las condiciones de uso. Menciona los campos clave, pero carece de contexto sobre cómo se filtran los resultados o si hay limitaciones.
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?
El esquema cubre el 100% de los parámetros con descripciones (sku, location, provider, product_id). La descripción de la herramienta no añade información adicional sobre los parámetros, por lo que se mantiene la línea base de 3 para cobertura completa del esquema.
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?
La descripción indica claramente que la herramienta consulta el inventario actual de productos, especificando los campos que devuelve (stock, reservado, disponible). El verbo 'Consulta' y el recurso 'inventario actual' son específicos y la diferencian de herramientas hermanas como inventory_low_stock o inventory_history.
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 se proporcionan pautas sobre cuándo usar esta herramienta en lugar de alternativas como inventory_forecast o inventory_low_stock. La descripción solo expresa la acción, sin excluir otros casos ni mencionar cuándo es preferible usar otra herramienta.
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?
Sin anotaciones, la descripción es la única fuente de transparencia. Indica que la salida es completa y está ordenada cronológicamente, lo que añade contexto útil, pero no detalla el formato de los eventos ni posibles restricciones o efectos secundarios.
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?
Una frase concisa y precisa, con la información esencial al frente. No incluye información redundante.
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?
La herramienta es simple (2 parámetros) y la descripción es funcional, pero carece de contexto sobre el formato de salida, el uso previsto o cuándo preferir esta herramienta sobre otras similares. Con un esquema de salida ausente, la descripción debería proporcionar más detalles sobre los eventos devueltos.
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?
El esquema cubre el 100% de los parámetros con descripciones básicas. La descripción de la herramienta no añade información adicional sobre los parámetros más allá del esquema.
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?
La descripción indica claramente que obtiene la línea de tiempo completa de eventos de una orden, ordenada cronológicamente. El verbo 'Obtiene' es específico y el recurso (línea de tiempo de eventos) se distingue de herramientas hermanas como orders_get u orders_list.
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?
La descripción no ofrece orientación sobre cuándo usar esta herramienta en lugar de alternativas como orders_get u orders_list. No hay exclusions ni contexto de uso.
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 must carry the full burden of behavioral disclosure. It only states 'gets complete detail' without mentioning side effects, authentication, error handling, or return format. This is a minimal read operation, but the description adds little beyond what the tool name implies.
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, front-loaded sentence with no wasted words. It efficiently communicates the tool's core action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with two fully documented parameters, the description is adequate but lacks information about the return structure and error behavior (there is no output schema). It does not explain what 'complete detail' includes, which could leave the agent uncertain about the response.
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 fully describes both parameters with clear descriptions and an enum for provider, so the baseline is 3. The description adds only the phrase 'by its ID', which aligns with the product_id field but does not provide additional semantic depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Obtiene') and resource ('producto') with a clear scope ('por su ID'), which distinguishes it from siblings like products_list or products_search that retrieve collections or filtered results.
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 a product ID is available and complete detail is needed, but it does not explicitly mention when not to use it or compare to alternatives. The context is clear but no exclusions are stated.
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, the description carries the burden. It discloses the report contents (low stock, days until stockout, reorder suggestion) but does not describe any side effects, permissions, or filtering logic beyond what the schema implies. It adds slight value but is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently communicates the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description clearly lists output elements (low stock products, days until stockout, reorder suggestion), and given the schema covers parameters and there is no output schema, this is adequate. However, it could mention that results are a list and how provider affects output, but for a report tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional parameter semantics 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a report of low-stock products including days until stockout and reorder suggestions, which is a specific verb+resource combination. It differentiates from inventory_get and inventory_forecast by focusing on report generation with suggested reorder.
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 inventory_forecast or inventory_get is provided. The description does not mention alternatives 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?
No annotations are provided, so the description carries the full burden. It indicates a read operation ('Lista') and mentions filters and pagination, but does not disclose potential side effects, authorization requirements, or behavior beyond the schema. There is no mention of return format 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 a single, concise sentence that starts with the verb and immediately conveys the tool's purpose. Every word contributes to the meaning with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward list tool, the description adequately conveys the core functionality, but it omits details about the return value shape, default ordering, and any caveats beyond what the schema specifies. Since there is no output schema, the description could be more complete, but it is sufficient for a simple list operation.
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 100% coverage with descriptions for all six parameters, so the schema alone provides adequate parameter semantics. The description's reference to 'filters and pagination' aligns generally with the parameters but adds no additional meaning beyond what the schema already contains.
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 lists products from an e-commerce platform with filters and pagination, using the specific verb 'List' and naming the resource. However, it does not explicitly distinguish this from the sibling products_search tool, which could also list products with filters, so it lacks obvious sibling 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 for retrieving a paginated product list with optional filters, but provides no explicit guidance on when to use this over alternatives like products_search or products_get. No exclusions or preferred scenarios 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?
No annotations are provided, so the description carries the full burden. It only states that it searches products with filters; it does not disclose pagination behavior, sorting defaults, whether the operation is read-only, rate limits, or any side effects. This is minimal behavioral disclosure for a search operation that could significantly impact the agent's expectations.
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, concise sentence that is front-loaded with the core purpose. Every word earns its place: the verb, the resource, the search mode, and the optional filters. There is zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters with no output schema, and the description omits critical context such as the fact that 'provider' is a required parameter (only query is also required). The 'optional' wording only mentions price and status, potentially misleading the agent into thinking all filters are optional when provider is not. It also fails to mention return format or any limitations. This is a notable gap for a moderately complex search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all six parameters, including their types, defaults, and descriptions. The description adds no additional parameter semantics beyond what is already present, mentioning price and status filters that are already in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Busca' (search) with the resource 'productos' and specifies the search mode: free text with optional price and status filters. This clearly distinguishes it from sibling tools like products_list (which lists all products) and products_get (which retrieves by ID). The purpose is immediately clear and actionable.
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 clearly implies when to use this tool: when you need to search products by free text and optionally filter by price or status. It provides clear context, though it does not explicitly exclude alternatives or mention when not to use it. The 'optional' wording gives guidance on when filters are applicable.
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 for behavioral disclosure. It reveals that the tool analyzes AOV with trend, comparison, and distribution, which adds some context, but it does not disclose output format, read-only guarantees, permissions required, or any performance or rate considerations.
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, front-loaded sentence that efficiently conveys the core functionality without waste. It earns its place by naming the metric (AOV) and the analysis dimensions (trend, comparison, distribution).
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 dimension with no output schema and no annotations, the description is thin on critical context. It does not clarify what the comparison or distribution outputs look like, nor does it differentiate this tool from the several closely related analytics siblings; a brief usage or output note would significantly 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 100%, so the schema already documents all four parameters with descriptions and enum values. The tool description adds no additional parameter-specific semantics, though it does mention 'tendencia' (trend) which loosely maps to show_trend and group_by. The mention of 'comparison' and 'distribution' in the description has no corresponding parameters for explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Analiza') with a clear resource ('el valor promedio de orden (AOV)'), and distinguishes this tool from sibling analytics tools by focusing on AOV with trend, comparison, and distribution. The name and description align with a distinct analytical purpose not covered by siblings like analytics_revenue or analytics_conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is provided — the description never states when to prefer this tool over sibling analytics tools such as analytics_revenue, analytics_dashboard, or analytics_conversion. The intended use case is only implied by the tool name and description ('AOV'), with no exclusions or alternative recommendations.
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?
No annotations are provided, so the description carries the burden. It discloses that the report includes period comparison and daily breakdown, but does not mention return format, pagination, or explicit read-only behavior. As a report tool, the read-only nature is implied but not stated.
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, well-front-loaded sentence with no redundant information. It immediately states the tool's purpose and key features.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description only partially explains the report's content. It covers the core purpose but lacks detail on response format, data granularity beyond daily, or how to choose between predefined and custom periods. A bit more context on use cases 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 100%, so all parameters are well-documented. The description adds no new parameter semantics, merely restating the compare_previous feature (already in the schema) and adding the non-parameter 'daily breakdown' output detail.
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 generates a revenue report, with specific features (previous period comparison and daily breakdown). This distinguishes it from sibling analytics tools like analytics_top_products or analytics_avg_order.
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 for revenue reporting but does not explicitly state when to use this tool versus alternatives like analytics_dashboard or analytics_by_channel. No exclusion or alternative guidance is provided.
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?
No annotations are provided, so the description carries the full burden. It discloses that the operation is a get (read-only) and enumerates the payload components (lines, addresses, payments, timeline), but it does not mention permissions, error behavior, or any other side effects. This is partial transparency.
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, well-structured sentence with a clear verb and a colon-separated list. Every word is informative and there is no 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?
The tool is simple (2 params, no output schema) and the description covers the core purpose and return content. However, it lacks explicit guidance on how it relates to sibling tools like orders_timeline, which could cause confusion. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters described. The description does not add new parameter semantics beyond the schema; it only contextualizes the overall purpose. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Obtiene') and resource ('detalle completo de una orden'), and lists concrete components (lines, addresses, payments, timeline). It clearly distinguishes from sibling tools like orders_list and orders_timeline by emphasizing the complete detail 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 when to use the tool (when full order details are needed) but does not explicitly state when not to use it or reference alternatives such as orders_list or orders_timeline. No exclusion criteria are provided.
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, the description carries the burden of behavioral disclosure. It indicates a read-only listing of plans and prices, which is transparent enough for a simple tool. However, it does not describe return format, sorting, or any access requirements. Given the tool's simplicity, this is acceptable but not exceptional.
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, concise sentence that directly states the tool's purpose. Every word contributes value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool, the description adequately communicates what the tool returns (plans and prices). While it could mention edge cases like trial plans or availability filtering, the simplicity of the operation does not require more. The lack of an output schema is compensated by the explicit mention of content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (vacuously). The description needs no parameter elaboration since there are none. Baseline 4 is appropriate for a zero-parameter tool.
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 function with a specific verb ('Muestra' - shows) and resource ('los planes disponibles y sus precios'). It is distinct from siblings like license_status and license_activate, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. For instance, it does not mention that this is the go-to for listing plans, nor does it contrast with license_status or products_list. The context implies usage but gives no explicit direction.
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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions the key behaviors: listing with filters and pagination. However, it does not explicitly state that this is a read-only operation, describe the response structure, or mention potential limitations like default sort order or rate limits. It is adequate but not thorough.
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, front-loaded sentence that clearly states the purpose. It contains no unnecessary words or repetition, earning every word's place.
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 (11 parameters, no output schema, no annotations), the description is minimally adequate. It covers purpose, filters, and pagination but does not explain the return format, sorting, or how to interpret the response. While the schema fills parameter gaps, the lack of output schema and annotations leaves room for more detail.
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?
All 11 parameters have descriptions in the schema, so schema coverage is 100%. The description adds no parameter-specific details beyond the generic phrase 'filtros avanzados.' Since the schema already documents each parameter, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lista') and resource ('órdenes') and distinguishes this from sibling tools like orders_get and orders_timeline by mentioning 'filtros avanzados' and 'paginación.' It clearly communicates that this is the list/filter operation for orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you need to list orders with filters and pagination. It does not explicitly name alternatives or exclusions, but the context is sufficient to differentiate it from order-specific tools like orders_get and orders_create.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No hay anotaciones, por lo que la descripción carga con la transparencia. Al ser una operación de lectura ('Obtiene'), comunica claramente su naturaleza no destructiva y describe el contenido devuelto, cubriendo lo esencial para una herramienta de obtención simple.
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?
Una sola oración, directa y con el verbo al inicio; no hay palabras de relleno ni información redundante con el esquema.
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?
Para un get con dos parámetros y sin esquema de salida, la descripción especifica qué incluye el perfil obtenido, dando una imagen suficiente del resultado. No cubre casos de error ni comportamiento ante inexistencia, pero no es crítico para la complejidad del tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
La cobertura del esquema es 100%: cada parámetro tiene descripción y el provider incluye enum. La descripción de la herramienta no añade semántica adicional a los parámetros más allá del esquema, lo que establece una línea base de 3.
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?
La descripción usa un verbo específico ('Obtiene') y recurso claro ('el perfil completo de un cliente'), detallando además el contenido (estadísticas, direcciones, segmento). Esto distingue adecuadamente la herramienta de sus hermanas como customers_list o customers_search.
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?
El contexto de uso se infiere: se usa cuando se necesita el perfil completo de un cliente. Sin embargo, no se indican exclusiones ni alternativas explícitas entre los múltiples tools de customers disponibles.
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?
No annotations are provided, so the description carries the full burden. It states the tool 'shows' information, implying a read-only operation with no side effects. However, it does not disclose any prerequisites (e.g., active license) or output format, which would enhance transparency.
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 sentence, front-loaded with the verb 'Muestra' (shows) and clearly lists the three items it displays. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is largely complete: it names the three pieces of information returned. It could benefit from explicitly saying it is a read-only status check, but the verb 'shows' already implies that. Given the tool's simplicity, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially 100% covered. The description adds value by explaining what the tool returns, which is the primary semantic content needed for a parameterless tool.
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 what the tool does: it shows the current plan, available tools, and license status. This is a specific verb ('show') with specific resources, and it distinguishes from siblings like license_plans (which likely lists available plans) and license_activate (which activates a license).
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: use this tool when you need to see current plan details, available tools, or license status. However, it does not explicitly state when to use it over alternatives like license_plans or setup_help, nor does it provide exclusion criteria.
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, the description carries the full burden. It conveys a read-only behavior of showing instructions, but does not explicitly mention the absence of side effects or describe the output format. For such a simple tool, the risk is low, but it could be more explicit.
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, concise sentence that front-loads the action ('Muestra instrucciones') and includes the domain ('CommerceHub'). Every word serves a clear purpose, and there is no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—no parameters, no output schema, and a clear help utility—the description fully conveys its purpose and scope. It is complete within the context of sibling tools, which all have different functions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100%. Per the rubric, a baseline of 4 is appropriate for no parameters, and the description does not need to explain any.
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 function: 'Muestra instrucciones de configuración de CommerceHub' (Shows setup instructions for CommerceHub), using a specific verb and resource. It uniquely distinguishes itself from the operational sibling tools, which all focus on data operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: it is the tool for obtaining setup instructions, as no sibling tool serves a similar purpose. However, it lacks explicit guidance on when to use it vs alternatives or any prerequisites, so it does not fully meet the criteria for clear context.
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:

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

Score Badge

Copy to your README.md:

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

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/spirit122/commercehub-mcp'

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