mcp-amazon-sp-api

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation2/5
There is significant overlap among tools related to pricing and competition (e.g., analyze_competitor_prices, compare_with_competitors, get_competitive_pricing, get_competitor_offers) and among inventory reporting tools (get_fba_inventory, get_inventory, get_fba_fees_report, get_profitability_report). This ambiguity would likely cause an agent to select the wrong tool.
Naming Consistency4/5
Tool names consistently follow verb_noun pattern (get_, list_, update_, check_, request_), with no mixing of casing styles. A few prefixes (check_, request_) deviate from the majority get_/list_/update_, but the pattern remains predictable overall.
Tool Count2/5
With 53 tools, the server is overly large for typical MCP usage. While it covers a broad domain (Amazon SP API), the high count increases cognitive load and makes it harder for agents to navigate. A more focused subset would improve coherence.
Completeness3/5
The tool set covers many essential areas (orders, inventory, listings, reports, A+ content, fees), but notable gaps exist: no tool for creating listings (only updating), no advertising management, and no returns processing beyond reporting. This leaves some workflows incomplete.
Average 2.6/5 across 53 of 53 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
No annotations are available, so the description carries full responsibility for behavioral context. It does not disclose permissions, side effects, rate limits, or the nature of the output (e.g., whether it lists errors, warnings, or scores). The existence of an output schema is not leveraged.
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, which is concise but overly sparse. It lacks essential details and does not front-load the key purpose clearly. Every word is present but insufficient for effective tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the domain (listing quality issues) and the presence of many sibling tools, the description is too brief. The output schema exists but is not referenced, and the description does not clarify how the tool fits into common workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning no parameter descriptions. The tool's description fails to add meaning to the parameters 'sku' and 'marketplace'. It does not explain what values are valid or how they affect the results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Issues de calidad de un listing.' which translates to 'Quality issues of a listing.' It implies fetching quality issues but is vague about what constitutes 'issues' and does not differentiate from similar sibling tools like 'get_listing_content' or 'get_product_details'.
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 such as 'get_listing_content' or 'check_listing_restrictions'. There is no mention of prerequisites or contextual cues.
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 present, so the description must fully disclose behavior. It fails to mention key aspects such as whether the tool modifies data, requires authentication, has rate limits, or how it defines 'competitors'. This is a critical omission for a data-fetching tool.
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 sentence, which is concise but lacks essential detail. It is not front-loaded with critical information, and the brevity harms clarity rather than aiding it.
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 presence of an output schema, the description should at least hint at return values. It does not. With many sibling tools and no annotations, the description is severely incomplete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter description coverage, so the description must compensate. It offers minimal insight: keywords likely identify products, but doesn't specify format (e.g., ASINs, product names) or explain marketplace and max_results. Only vague hints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool searches competitors and compares prices and rankings, providing a verb and resource. However, it is vague and does not differentiate from similar sibling tools like compare_with_competitors or get_competitive_pricing, making it hard to discern its specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or context for use, leaving the agent to guess among many competing sibling 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?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It does not specify whether the operation is read-only, what permissions are needed, or any side effects. The single sentence offers 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 short sentence, which is concise but omits critical information needed for correct usage. It does not earn its place due to lack of substantive content.
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?
Although an output schema exists (so return values need not be explained), the description still lacks usage context, parameter semantics, and behavioral traits. For a tool with only two parameters, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning no parameter descriptions are provided in the schema. The description also does not explain the parameters (content_key and marketplace). For example, it does not clarify what format content_key should be in or what values marketplace accepts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Detalle de un documento A+ Content' indicates it retrieves details of an A+ Content document, but does not specify what details are included or how it differs from sibling tools like list_aplus_content or get_aplus_asin_relations. The purpose is clear but vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as list_aplus_content (for listing all documents) or get_aplus_asin_relations. No exclusions or prerequisites 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 present, so the description must convey behavioral traits. It only states the tool's output, with no mention of read/write nature, auth requirements, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, but it lacks structure and fails to provide necessary details. It is under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of sibling tools and an output schema, the description is incomplete. It does not clarify the return format, usage context, or how it differs from related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters 'order_id' or 'marketplace'. No additional meaning is provided beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates that the tool retrieves message types available for an order, but it lacks a clear verb and does not differentiate from sibling tools like 'send_buyer_message' or other getters.
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. No context or exclusions are provided.
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 disclose behavioral traits. It does not indicate whether the tool is read-only, requires authentication, or has side effects. The typical retrieval behavior is implied but not stated, leaving ambiguity.
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 (one phrase) but underspecified. It lacks structure or front-loading of critical information. Every sentence should earn its place; here the sole sentence is insufficient.
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 3 undocumented parameters, no annotations, and an output schema not described, the description is highly incomplete. It does not explain what the tool returns or how to effectively use it, failing to meet the needs of a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain any of the three parameters (keywords, marketplace, product_type). It mentions 'valid attributes' and 'search types' but fails to connect these to the parameters, providing no added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Valid attributes of a product type or search types' suggests a search or retrieval function but is vague. It does not explicitly state the action or resource, making it unclear whether the tool returns attributes for a given type or searches for types. It minimally distinguishes from siblings like get_product_details but lacks specificity.
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 such as get_product_details or get_competitive_pricing. The description provides no context for appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as rate limits, authentication needs, or side effects. It only implies a read operation, but without explicit confirmation.
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 extremely short (four words in Spanish), which is concise but at the cost of under-specification. It does not waste words but fails to provide necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and sibling tools with similar purposes, the description should clarify what data is returned (e.g., Buy Box winner, price rankings). It lacks completeness for effective selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds minimal meaning: it mentions 'by ASIN' for the asins parameter but does not explain format (e.g., comma-separated) or the marketplace parameter's role. The description partially compensates but is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'competitive prices, Buy Box and rankings by ASIN', indicating the resource, but lacks a clear verb (e.g., 'get', 'retrieve') and does not differentiate from siblings like analyze_competitor_prices or get_competitor_offers.
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 description does not mention prerequisites, exclusions, or comparison with sibling 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?
No annotations are provided, so the description must disclose behavioral traits. It only says 'compare' without indicating whether it's read-only, requires permissions, or what side effects occur. The existence of an output schema is not leveraged to explain return 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 single-sentence description is concise, but it sacrifices necessary detail. It could be restructured to front-load critical information while only slightly expanding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no parameter descriptions, and the output schema exists but is undocumented, the description is incomplete. Agents lack information to correctly invoke the tool or interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The tool description also fails to explain any of the four parameters (my_asin, keywords, marketplace, max_results), adding no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'compare' and resource 'your product vs competitors', but it's vague about what aspects are compared. Sibling tools like 'analyze_competitor_prices' and 'get_competitive_pricing' overlap in purpose, so the description fails to distinguish this tool's specific functionality.
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 sibling tools. There is no mention of exclusions, prerequisites, or alternative tools, leaving the agent to infer usage context entirely.
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 full burden. It does not disclose read-only nature, pagination, rate limits, or behavior for empty results. The description only hints at filtering but fails to provide behavioral details necessary for safe invocation.
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 concise (7 words), but this brevity sacrifices informativeness. It is front-loaded but lacks substance, leaving critical gaps in understanding. Every sentence must earn its place, but this one feels incomplete.
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 having an output schema (not provided here), the description does not explain return values, pagination, or the scope of orders. Given that the tool has 3 optional parameters and no enums, the description should cover more context, especially for a generic order retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only implicitly references 'fecha y estado' (date and status). It does not explain the 'marketplace' or provide formats or allowed values. The description adds minimal meaning beyond the parameter names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Pedidos recientes por fecha y estado' which indicates the tool retrieves recent orders filtered by date and status. However, it does not explicitly state the action (e.g., 'list' or 'get'), and it lacks differentiation from sibling tools like get_order_items or get_order_metrics. The purpose is clear but vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or context. The description implies it is for filtering orders by date and status, but without explicit usage context, the agent has no direction.
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, the description carries full burden for behavioral disclosure. It does not state whether the tool is read-only, what data is modified, authentication needs, or rate limits. The description only defines the metric without any 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but lacks structure—no separation of purpose, usage, or parameter details. It is not wasteful, but underspecification harms clarity.
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 2 parameters with 0% schema coverage and no annotations, the description is incomplete. It does not explain what each parameter does, default behavior, or how the output schema relates to the metric. The presence of an output schema does not compensate for missing parameter and usage info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention parameters (days_back, marketplace) at all. It adds no meaning beyond the schema's bare property names, failing to explain how parameters affect repeat purchase rate calculation.
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 'Repeat purchase rate by ASIN (Brand Analytics)' clearly states the tool computes a specific metric (repeat purchase rate) for ASINs under Brand Analytics, distinguishing it from siblings like get_sales_and_traffic or get_market_basket.
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. Among 50+ sibling tools, there is no mention of prerequisites, constraints, or scenarios where this is preferred.
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?
The description only states the basic action without disclosing any behavioral traits such as pagination, rate limits, authentication requirements, or whether it lists all documents or only a subset. Given no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence) but lacks essential information. It is under-specified rather than optimally concise.
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 presence of an output schema and an optional parameter, the description fails to provide enough context for the agent to understand what the tool returns or how the parameter affects behavior. It is not complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'marketplace' parameter at all, despite the schema having 0% description coverage. Agents cannot infer the meaning or usage of the parameter from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Listar' (list) and the resource 'documentos A+ Content' from the user's account. It distinguishes the tool from sibling 'get_aplus_content' by implying listing vs. retrieving a single document.
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 like get_aplus_content or other listing tools. There is no mention of prerequisites, filtering, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavior. It does not explain what the tool returns (e.g., boolean, list, details) or any side effects. The output schema exists but is not described, so the agent lacks key behavioral cues.
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?
While the phrase is short, it is under-informative. Conciseness should not sacrifice content; here it sacrifices all useful information beyond the title.
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 two required parameters with no schema descriptions and an undeclared output schema, the description fails to provide enough context for correct invocation. The agent cannot determine expected input formats or output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning to parameters. It does not: 'asin' and 'marketplaces' remain undefined. No format hints (e.g., comma-separated country codes) are given.
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 'Elegibilidad para vender en otros marketplaces EU' clearly indicates the tool checks eligibility to sell in other EU marketplaces. It aligns with the tool name and distinguishes it from price- or restriction-checking siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like check_listing_restrictions or get_cross_marketplace_prices. The description lacks any context for selection.
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 full burden for behavioral disclosure. It only says 'Ver si puedes solicitar review' (see if you can request a review), which suggests a read-only check but does not confirm idempotency, side effects, or authentication requirements.
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. However, it is in Spanish while the tool name is in English, and it lacks front-loaded structure. It could be improved with clearer language and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not detail return values, but it provides no context about what triggers eligibility or how to interpret results. For a simple check tool, it is minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the two parameters (order_id, marketplace). It does not explain their purpose, format, or role in determining eligibility.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'ver' (check) and resource 'review eligibility' for an order, making the purpose understandable. However, it does not explicitly distinguish from the sibling tool 'request_review', which could cause confusion.
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 like 'request_review' or 'get_orders'. The description implies it is a prerequisite check but does not state this explicitly.
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 provided; description only mentions 'completed report' but does not disclose behavioral traits like required permissions, error conditions, or rate limits. The existence of an output schema is not leveraged to explain return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks structure and front-loads only basic purpose. Additional details needed for effective tool usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and many sibling tools, the description is too sparse. It does not cover when to download vs. check vs. request reports, nor explain the marketplace parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description provides no information about the two parameters (report_id and marketplace) beyond what the schema already defines. With 0% schema description coverage, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (download) and resource (content of a completed report). It adequately distinguishes from sibling tools like 'request_report' and 'check_report'.
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 such as 'request_report' or 'get_profitability_report'. Lacks instructions on prerequisites or 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 of behavioral transparency. It only states the purpose without disclosing whether the tool is read-only, any rate limits, authentication requirements, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified. Additionally, it is in Spanish while the tool name is in English, which may confuse agents operating in English contexts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no annotations, the description is too brief. The output schema exists but is not described, and the description does not cover what the tool returns or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero detail about the parameters. With 0% schema description coverage, the agent gets no guidance on the meaning or valid values for 'asin', 'price', 'is_fba', or 'marketplace'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Estimar fees') and the resource ('Amazon para un producto y precio'), making the primary purpose understandable. However, it does not differentiate from related sibling tools like 'get_fba_fees_report'.
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 usage guidelines are provided. The description does not specify when to use this tool versus alternatives, nor any conditions or pre-requisites.
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 provides one behavioral hint ('sent vs received'), but fails to disclose important traits such as whether the operation is read-only, requires authentication, or has rate limits. The description does not cover permissions 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. However, it is written in Spanish, which may limit clarity for an English-prompted agent. It could be restructured or added to English for better universal understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return value explanation is not needed. However, the description lacks parameter semantics and usage context. For a tool with two parameters (one optional), the description is incomplete and does not fully enable correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description offers no explanation of the parameters (shipment_id and marketplace). It does not clarify the role of the optional marketplace parameter or the required shipment_id, leaving the agent without needed context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Items of an FBA shipment: sent vs received' clearly indicates the tool returns items of a specific FBA shipment with a comparison of sent and received quantities. This distinguishes it from sibling tools like list_fba_shipments which lists shipments.
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 vs alternatives. It does not mention that to get items for a specific shipment this tool should be used, while listing shipments is handled by list_fba_shipments. The context is only implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral details. It only mentions 'eligibility and prep required' without explaining the nature of the operation (read-only, response structure, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded phrase, but it is too sparse and lacks structural elements like separate sections or examples.
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 having an output schema (not provided), the description is too brief to give a complete understanding of the tool's purpose in the context of FBA-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It does not explain the 'asins' parameter format or 'marketplace' usage, adding no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides FBA inbound guidance on eligibility and required prep. It is specific about the resource and action, though it does not differentiate from siblings like get_fba_inventory.
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 such as get_restock_suggestions or get_fba_shipment_items. No exclusions or context provided.
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 convey behavioral traits. It indicates a read operation (financial breakdown) but omits any details about required permissions, rate limits, idempotency, or potential side effects. The agent has no information about the tool's safety or side effects beyond the implied read nature.
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 sacrifices completeness for brevity. It adequately front-loads the purpose but fails to include essential details about parameters and usage.
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 an output schema exists, the description could afford to be less detailed about return values, but it still needs to explain the tool's behavior and parameters. The description is inadequate for the tool's complexity (2 parameters, financial context) and does not provide enough context for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, yet the description provides no clarification. The order_id parameter is required but not explained (e.g., format or source), and the marketplace parameter's optional nature and purpose are completely absent. The agent must infer meaning solely from parameter names.
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 provides a financial breakdown of an order, listing fees, net, and margin. It indicates the specific resource (order finances) and distinguishes itself from general order retrieval or sibling tools like get_order_items by focusing on financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_order_metrics or estimate_fees. There is no mention of prerequisites, ordering of calls, or any other context that would help an agent decide to invoke 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 must disclose behavior. It only says 'immediate response', implying low latency, but does not state read-only nature, side effects, authentication, or other behavioral traits needed for a sales metrics tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no extraneous words. First sentence states purpose. Highly concise.
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 having an output schema, the description lacks essential details: parameter explanations, differentiation from siblings, and sufficient behavioral context. It is inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the three parameters (days_back, granularity, marketplace). It does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'agregated sales metrics' which indicates the resource, but it is vague and does not distinguish this tool from siblings like get_sales_and_traffic or get_sales_summary. The verb is implied by the name rather than explicit.
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. It mentions immediate response, but lacks context on prerequisites, exclusions, or comparison to other 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?
No annotations are present, and the description does not disclose whether the tool is read-only, whether it modifies data, or any side effects. The agent cannot infer behavioral traits from the description alone.
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 very short but fails to provide enough information. It is not appropriately sized given the tool's complexity and the lack of annotation support.
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 having an output schema, the description does not hint at the structure of the returned data. With three parameters and no parameter explanations, the tool is under-described for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention or explain any of the three parameters (days_back, max_orders, marketplace). The agent gets no semantic help beyond parameter names.
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 returns profitability by SKU including income, fees, and net margin. However, it does not differentiate from sibling tools like get_fba_fees_report or get_sales_and_traffic, which may also report financial 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. Among 50+ sibling tools, the agent receives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose whether the tool is read-only, what data it accesses, or any side effects. The brief description adds no behavioral context beyond the name itself.
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 phrase, which is concise but lacks essential detail. It is front-loaded, but the brevity sacrifices completeness for no clear benefit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and an output schema, the description is incomplete. It does not clarify the scope of the summary (e.g., time period, marketplace filtering) or what the output contains. For a tool named 'summary', more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a 0% description coverage, meaning no parameter descriptions exist. The tool description does not explain the meaning or usage of the two parameters (days_back, marketplace), leaving the agent without guidance on how to use them effectively.
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 'Summary of returns and refunds' clearly states the tool provides a summary of returns and refunds. It uses a specific noun phrase, but does not explicitly distinguish it from sibling tools like get_fba_returns or get_order_finances, leaving ambiguity about whether it focuses on aggregated data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_fba_returns for detailed return data or get_order_finances for refund details. The description lacks context about use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should account for behavioral traits (e.g., read-only, permissions). It only states the purpose, missing 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks informative value. It is front-loaded but too minimal to be effective.
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 having an output schema, the description does not explain output structure, BSR meaning, or behavior on missing data. Incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning to the parameters (asin, marketplace). The agent gets no clue about what values to supply.
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 provides sales rankings (BSR) by category. While it doesn't elaborate on BSR, it sufficiently indicates the resource and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs. alternatives like get_sales_and_traffic or get_sales_summary. The description lacks context for appropriate invocation.
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 transparency burden. It only lists data types without disclosing behavioral traits such as read-only status, authentication needs, or rate limits. Insufficient for an AI agent.
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 very concise (one sentence), but it sacrifices necessary detail. While it avoids verbosity, it is too terse to provide adequate context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and two parameters, the description is incomplete. It fails to describe parameters, output, or usage context, making it insufficient for an AI agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameter (days_back, marketplace). The agent receives no information on parameter meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Resumen de ventas: revenue, unidades, top productos' (Sales summary: revenue, units, top products), clearly indicating the tool provides sales summary data. However, it does not differentiate from similar sibling tools like get_sales_and_traffic.
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. The description only states what it does, not the conditions or context for its use.
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, so the description carries the full burden. It does not disclose whether the operation is read-only, required permissions, rate limits, or data freshness. The mention of 'Brand Analytics' hints at the source but falls short of adequate transparency.
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 very short, which is concise but at the expense of completeness. It lacks detail that would justify its brevity; it is under-specified rather than efficiently informative.
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 having an output schema, the description does not explain the output's structure or the parameters' influence. For a tool with only two optional parameters, more detail is needed to ensure the agent uses it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters 'days_back' and 'marketplace'. The agent receives no guidance on how these affect the results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns 'Top keywords con click/conversion share' from 'Brand Analytics', indicating a specific resource and verb. However, it does not distinguish it from sibling tools like get_search_performance, which may also deal with search terms.
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 such as get_search_performance or get_sales_and_traffic. There is no mention of prerequisites, exclusions, or context for optimal use.
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 provided; the description only states real-time stock but does not disclose any behavioral traits such as data freshness, rate limits, error handling, or what happens if the SKU is missing. The agent gains no insight beyond the basic function.
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 concise (one short phrase) but lacks structure and sufficient information. Brevity is not beneficial when essential details are omitted. It should at least include a sentence about usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no schema descriptions, no annotations, and an output schema (which is not described), the description provides minimal context. It does not explain the return format, pagination, or any constraints, leaving the agent poorly informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate but only mentions 'by SKU,' ignoring the marketplace parameter. It does not explain the purpose, allowed values, or format of the parameters, leaving the agent uncertain about what to provide.
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 retrieves real-time FBA stock by SKU. It specifies the verb (get stock) and resource (FBA inventory). However, it does not differentiate from sibling tools like get_fba_inventory, which may have overlapping functionality.
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 such as get_fba_inventory or others. The description does not specify prerequisites, required permissions, or context for when this tool is appropriate.
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 convey behavioral traits. It states only that it returns 'status and result' but does not disclose whether it is read-only, requires permissions, or what happens with invalid feed_id. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and lacks structure. It is concise but under-specifies, and the Spanish language adds a barrier. Front-loading is not relevant due to 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 the existence of an output schema, the description need not detail return values, but it fails to provide enough context about when checking a feed is appropriate. With two parameters and no parameter descriptions, the description is incomplete for a tool with 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond parameter names. 'feed_id' is implied but 'marketplace' is not explained (e.g., default, usage). The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the status and result of a massive update feed. It distinguishes from sibling tools like check_report by specifying 'feed de actualización masiva'. However, it is in Spanish, which may reduce clarity for English-centric agents.
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 check_report or get_listing_issues. The description does not mention prerequisites or context for invoking the 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 implies a read operation ('ver') but does not explicitly state it is read-only or disclose any behavioral traits. No annotations exist to compensate.
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 concise but lacks structure. It is only one sentence with no parameter details or usage hints.
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 zero schema coverage and no annotations, the description is far too minimal. It does not explain what restrictions are returned or how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. Condition and marketplace are left entirely to inference from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks restrictions for selling an ASIN. It is specific and distinct from siblings like check_expansion_eligibility or check_review_eligibility.
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. The description does not provide context for when it is appropriate or when to prefer other 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?
No annotations are provided, so the description bears full responsibility. It implies a read operation ('ver precio') but does not explicitly state idempotency, rate limits, authentication needs, or return format. Minimal disclosure beyond implied behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is efficient but lacks structure. It does not front-load critical details or organize information for quick parsing. Acceptable but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. However, it is incomplete: it misses parameter explanation, usage context, and behavioral traits. The tool is simple, but the description fails to cover essential information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions 'SKU' and 'EU marketplaces' but does not explain the 'marketplaces' parameter format or behavior (e.g., default behavior when empty). The description adds little meaning beyond the schema's raw parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: viewing the price of a SKU in all EU marketplaces. The verb 'ver' (see) and resource 'SKU' are specific. However, it does not explicitly distinguish from sibling tools like 'sync_marketplace_prices' or 'get_competitive_pricing', so it lacks 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 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. There is no mention of prerequisites, exclusions, or context for appropriate 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the tool retrieves 'current and long-term' data, implying a read operation, but lacks details on permissions, return format, or potential 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 sentence, concise and front-loaded. However, it is overly brief and could benefit from additional structure or detail.
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 having an output schema, the description omits any mention of the output format or fields. It also lacks usage context and parameter guidance, leaving the agent underinformed for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the description does not explain the 'marketplace' parameter, its allowed values, or how it affects the report. No added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves current and long-term FBA storage fees, matching the tool name 'get_fba_fees_report'. It distinguishes from siblings like 'estimate_fees' by specifying 'storage fees' specifically, though not explicitly differentiating.
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 such as 'estimate_fees' or other report tools. The description does not provide context for choosing it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as data freshness, authentication requirements, output scope, or any side effects. The single sentence only states the high-level purpose.
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 in Spanish. It is concise but lacks structure (e.g., no separate sections). The title is null, and the description does not elaborate beyond a basic phrase.
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 having an output schema (not shown), the description does not explain what the tool returns or how to interpret results. For a tool with many siblings, more context is needed to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds no explanation for the two parameters (days_back, marketplace). The agent must infer their meaning from names and defaults, which may lead to misuse without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'products bought together with yours' and mentions 'Brand Analytics', indicating market basket analysis. It distinguishes from sibling tools like get_sales_and_traffic or get_competitive_pricing by focusing specifically on cross-sell insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or context for optimal use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions 'via report' but does not state that the tool is read-only, whether it triggers report generation, or any rate limits. No information about response structure or potential 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence in Spanish, which is concise but potentially problematic for English-speaking audiences. It lacks structure (e.g., separate usage notes) and omits critical details, making it too brief for adequate understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (sales and traffic data from Amazon reports) and the presence of many sibling tools, the description is incomplete. It does not specify data granularity, refresh cadence, or how the report is generated. The output schema exists but is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters 'days_back' or 'marketplace'. It does not indicate what units days_back uses (e.g., last N days from today) or acceptable marketplace values. The description adds minimal value beyond the schema's titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it retrieves sessions, conversion, and Buy Box percentage per ASIN via a report, matching the tool name. It is specific enough to differentiate from siblings like get_sales_summary or get_sales_rankings, though it lacks detail on the time period or report source.
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 such as get_sales_summary or get_sales_rankings. The description does not indicate prerequisites, data freshness, or limitations.
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 present, the description carries full responsibility for behavioral disclosure. It only states what the tool returns (search performance) without mentioning data freshness, required permissions, rate limits, pagination, or any side effects. This is insufficient for a tool that likely fetches external data.
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 core concept. It wastes no words. However, it is in Spanish, which may reduce clarity for an English-focused agent. Still, it is not overly verbose.
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 having an output schema (not shown), the description omits critical context: it doesn't specify what performance metrics are included (e.g., impressions, clicks), how to interpret results, or any sample usage. For a two-parameter tool, it leaves too much unsaid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description provides no explanation for the two parameters (asins and marketplace). The agent receives no guidance on input format, constraints (like ASIN format), or when marketplace is needed. This severely hinders correct invocation.
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 it returns search performance for ASINs in Brand Analytics, distinguishing it from sibling tools like get_sales_and_traffic or get_search_terms. However, it uses the vague noun 'rendimiento' (performance) without specifying which metrics, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_sales_and_traffic or get_search_terms. There are no when-to-use, when-not-to-use, or condition statements, leaving the agent to infer usage purely from the tool name and short description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states that the tool returns 'FBA shipments and their status', but it does not disclose whether the tool is read-only, whether it has side effects, what statuses are available, or any data volume considerations (e.g., pagination). The description is insufficient for understanding behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence), but it is under-specified for a tool with three parameters and no schema descriptions. It is front-loaded but sacrifices completeness. 'Appropriately sized' would require more detail given the context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema, the description does not indicate what information each shipment includes (e.g., IDs, status values, dates). It also does not clarify the filtering behavior of the parameters. Given the complexity of FBA shipping and the number of sibling tools, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters ('status', 'marketplace', 'shipment_ids'). The parameter names offer some self-documentation, but no details on valid values, formats, or usage patterns are given. The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'FBA shipments and their status' clearly indicates the tool lists FBA shipments and provides their status, which distinguishes it from sibling tools like 'get_fba_shipment_items' or 'get_fba_returns' that focus on different aspects. However, it lacks explicit verb+resource clarity (e.g., 'List' is implied but not stated), and the brevity leaves some ambiguity about exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like 'get_fba_shipment_items' or 'get_fba_returns'. There is no mention of prerequisites, context, or exclusions. The description does not help an agent choose between similar 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 provided, the description carries full responsibility for behavioral disclosure. It only hints at read operations and basic filtering via parameters, but does not explain pagination, authentication requirements, or that it only returns the caller's own listings.
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 is easy to parse. It is front-loaded with the main action. However, it could be slightly expanded without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four optional parameters, an output schema, and many sibling tools, the description is too sparse. It does not address filtering, pagination, or the scope of listings returned, leaving significant gaps for an agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not explain any parameter. Status, marketplace, issue_severity, and page_size are left undefined, forcing the agent to infer their meaning from names alone.
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 all listings with status and issues, which is a specific verb-resource combination. However, it does not differentiate from sibling tools like get_listing_issues or get_inventory, which overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or contexts that would help an agent decide between this and sibling 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?
No annotations provided, so description carries full burden. It only says 'search by keywords' but fails to disclose return format, pagination, read-only nature, or any side effects. Insufficient for safe invocation.
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?
Single sentence is concise, but it lacks crucial information that could be added without becoming verbose. It does not earn its place fully.
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 many sibling tools and a non-trivial input schema, the description is too sparse. It does not explain how results differ from similar tools or what the output contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It indirectly mentions 'keywords' but provides no details about acceptable formats, requirements, or the 'marketplace' parameter. Adds little beyond the parameter names.
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?
Description clearly states verb 'Buscar' (search) and resource 'productos en el catálogo de Amazon' (products in Amazon catalog). However, it does not distinguish itself from similar sibling tools like get_product_details or get_competitive_pricing.
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. No mention of prerequisites, exclusions, or specific contexts.
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 full burden. It only mentions asynchronicity but omits other behavioral traits like rate limits, authentication, or that a report ID is returned for subsequent checking.
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?
Extremely concise but under-specified for a tool with 3 parameters and sibling tools. The single sentence lacks essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to explain the asynchronous workflow, how to obtain the report later, or parameter constraints. Incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds no meaning to any of the 3 parameters (report_type, days_back, marketplace). Users get no hints about what values to use.
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 action: 'request generation of an Amazon report' and specifies it's asynchronous, distinguishing it from siblings like check_report (status check) and download_report (download).
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. For example, it doesn't mention that this is for initial request only, and that check_report should be used to poll status.
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 discloses one behavioral trait: 'Requiere confirm=True', indicating an explicit confirmation step. However, it does not mention whether the operation is destructive, what permissions are needed, rate limits, or side effects. For a modification tool that syncs prices, more transparency is needed.
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 two sentences and front-loaded with the main purpose. It is concise with no redundancy. However, the brevity comes at the cost of missing important details. It could be expanded slightly without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 4 required, mutation likely), an output schema exists but the description does not mention return values. The description lacks context on when to synchronize, what the targets field expects, and how adjustments work. It is insufficient for an agent to use correctly without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanations for any of the 7 parameters. It only notes that 'confirm' should be true, but does not clarify the meaning of 'sku', 'product_type', 'base_price', 'targets', 'marketplace', or 'adjustment_pct'. The description fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('sincronizar' / synchronize) and resource ('precios a varios marketplaces'). It implies updating prices across multiple marketplaces, which distinguishes it from sibling tool 'update_marketplace_price' that likely handles a single marketplace. However, it lacks operational details such as whether the sync pushes or pulls data, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings, nor does it mention prerequisites or when not to use it. The only hint is the requirement for 'confirm=True', but this is a parameter constraint, not usage context. No alternatives are listed.
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, and the description does not disclose any behavioral traits such as read-only nature, rate limits, or side effects. The agent has no information beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no waste. It is front-loaded with the core action, but could be slightly expanded for clarity without losing conciseness.
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 two parameters and no annotations, the description fails to provide enough context. It does not specify what the function returns, the meaning of the parameters, or any constraints. The output schema exists but is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate but only mentions the general purpose without explaining the parameters (content_key, marketplace) or their role. The agent cannot determine how to fill the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets ASINs associated with an A+ Content document, which is a clear verb+resource. However, it does not differentiate this tool from siblings like get_aplus_content or list_aplus_content, which may have overlapping purposes.
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, nor are there any prerequisites, exclusions, or context for invoking it appropriately.
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 burden of behavioral disclosure. It only states the outcome (offers) but does not mention data freshness, pagination, filtering capabilities, or what constitutes an 'offer' (e.g., price, condition, seller info).
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 waste. However, the brevity sacrifices completeness and may be insufficient for an AI agent to use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema but the description is minimal, it lacks context about return values, data structure, or behavior. Sibling tools suggest competition-related functionalities, yet no context is provided to distinguish this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not add meaning to parameters beyond the required ASIN. The optional marketplace parameter is not mentioned, providing no semantic value beyond the schema itself.
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 retrieves offers from all sellers for an ASIN ('Ofertas de todos los vendedores para un ASIN'). However, it does not differentiate from sibling tools like get_competitive_pricing or compare_with_competitors, which may have overlapping functionality.
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. The description does not specify context, prerequisites, or exclusion criteria for sibling 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?
No annotations provided, so description carries burden. It implies a read operation but does not confirm idempotency, side effects, or authorization needs. Minimal disclosure beyond basic output fields.
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?
Description is a single concise line in Spanish. No wasted words, but lacks structure like bullet points or sections. Appropriate brevity for a simple tool.
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 an output schema exists (though not shown), the description minimally lists fields. However, it lacks details on pagination, filtering, or edge cases. Adequate for a basic 'get items' tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has two parameters (order_id, marketplace) with no descriptions. The description does not explain their purpose or format, so it adds no value beyond the schema structure. Schema coverage is 0%.
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?
Description clearly states the tool returns order items with fields: SKU, ASIN, price, quantity. The name 'get_order_items' aligns well. However, it does not differentiate from siblings like get_orders, but the purpose is specific enough.
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 vs alternatives, nor any mention of prerequisites or limitations. The description only states what it does without 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 exist, so the description bears full responsibility for behavioral disclosure. It only lists output fields but does not mention read-only nature, authorization needs, rate limits, or side effects. Output schema exists but behavior is unaddressed.
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 concise, delivering key output fields in a single sentence. However, it is written in Spanish which may be inconsistent with the expected language of the platform.
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 having an output schema, the description lacks guidance on input parameters and behavioral context. With many sibling tools, more contextual cues are needed for appropriate tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description should explain parameters. It does not mention 'asin' or 'marketplace', adding no meaning beyond the schema's property names.
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 that the tool returns product details including title, brand, images, and rankings. However, it does not differentiate from sibling tools like get_sales_rankings that also return ranking data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the requirement that confirm must be true for the request to proceed. However, it does not mention side effects, rate limits, or whether the action is destructive. The behavioral insight is limited to one constraint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—two short sentences. It front-loads the purpose and a critical requirement. No unnecessary words. However, the use of Spanish may limit understanding for English-only models, but conciseness itself is good.
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?
An output schema exists, so return values are covered. However, with 3 parameters and no schema descriptions, the description lacks complete context. It fails to explain order_id and marketplace, and does not clarify behavior when confirm is false. The tool is simple but the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should clarify parameters. It only addresses 'confirm', stating it must be true, and ignores the required 'order_id' and optional 'marketplace'. This adds some meaning but leaves key parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: requesting a review from the buyer. The verb 'Solicitar' and resource 'review al comprador' are specific, and the tool name aligns. However, it does not differentiate from siblings like 'check_review_eligibility' or 'get_repeat_purchases', but the purpose is still clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a single guideline: 'Requiere confirm=True', indicating a prerequisite for the tool to work. There is no when-to-use or when-not-to-use information, nor comparison to alternative tools. This is minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only discloses that confirm=True is required to actually send the message. Since no annotations are provided, the description should also mention that the tool performs a write operation, any permission requirements, or what happens if confirm is false. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sentences, front-loading the purpose. However, it could add more value without losing conciseness by explaining other parameters or usage conditions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters and 0% schema coverage, the description is incomplete. It only addresses one parameter. While an output schema may exist, the description does not provide enough context for correct parameter usage or expected behaviors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only explains the confirm parameter. It does not clarify the meaning or constraints of body, order_id, message_type, or marketplace, which are critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Enviar mensaje al comprador' (Send message to buyer). It is specific about the resource (buyer) and action (send message). However, it does not differentiate from similar messaging tools like request_review, which also sends a message to the buyer.
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 notes that confirm=True is required, providing a usage condition. However, it gives no guidance on when to use this tool versus siblings like get_messaging_options or request_review, nor does it mention prerequisites or context.
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 correctly notes the confirm requirement, which is a key behavioral detail. However, it does not disclose other behaviors such as idempotency, side effects, or required permissions, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences, with no filler. It front-loads the purpose and the key requirement. However, it could be slightly more detailed without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters (4 required), no schema coverage, and no annotations, the description is far from complete. It does not explain the nature of the attribute, value format, or expected outcomes. Even with an output schema, more context is needed for a complex update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions the 'confirm' parameter requirement but provides no explanation for the other six parameters (sku, value, marketplace, language_tag, product_type, attribute_name). This is inadequate for effective tool selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Actualizar' (update) and the resource 'atributo de un listing' (attribute of a listing), which is specific. However, it does not specify what kind of attribute (e.g., product attributes, listing metadata), leaving some ambiguity. It distinguishes from siblings like 'update_listing_batch' by focusing on a single attribute.
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 mentions 'Requiere confirm=True', which is a usage guideline but does not provide context on when to use this tool versus alternatives like 'update_listing_batch'. There is no guidance on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the operation requires a confirmation flag (confirm=True) and implies a feed-based bulk update. However, it does not mention authorization needs, rate limits, or any side effects, leaving gaps.
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 very short (one sentence), which is concise, but it lacks structure such as bullet points or clear parameter explanations. Every sentence is used, but it could be more organized for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (1 required) and an output schema, the description is incomplete. It does not explain the feed format, marketplace behavior, or what happens when confirm is false. The output schema exists, so return values are partially covered, but input guidance is severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate. It only mentions the confirm parameter, completely omitting details about the 'updates' string format and the 'marketplace' parameter. This is insufficient for an agent to correctly populate the inputs.
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 it updates prices in bulk via a feed, which is a specific verb and resource. However, it does not explicitly distinguish it from similar sibling tools like update_marketplace_price or sync_marketplace_prices, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It only states that confirm=True is required, but does not explain prerequisites, scenarios, or exclusions.
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 full burden. It fails to disclose any behavioral traits such as output format (e.g., file, URL), side effects, or authentication requirements.
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 concise with a single sentence, but it effectively communicates the core purpose. It could be improved by adding structure, but there is no fluff.
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 having an output schema, the description does not hint at what the output contains (e.g., file, data). The tool is simple, but the lack of behavioral info and usage context makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate, but it does not add any meaning beyond the schema. The parameters 'invoice_id' and 'marketplace' are left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'download' and the resource 'invoice document', making the tool's purpose explicit. It is specific and distinguishes from sibling tools like 'download_report' or 'get_invoices'.
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, nor any prerequisites or exclusions. The description only states what it does, not when or why to use it.
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 phrase 'via report' hints at asynchronous behavior, but no details on report generation, data freshness, or side effects. No annotations exist to compensate.
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?
Single sentence, no wasted words, but lacks structure. Front-loaded with resource name.
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 unknown output schema, tool likely involves reports with potential async behavior; description omits crucial context like report types, timing, and data scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description does not explain the two parameters (days_back, marketplace). Schema coverage is 0%, so description must compensate but fails.
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 retrieves FBA returns with detailed reasons via report, distinguishing it from siblings like get_returns_summary.
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 provided on when to use this tool vs siblings. No context on when it is appropriate or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only discloses the requirement for confirm=True, but does not explain the behavior when confirm is false, whether updates are destructive, authentication needs, or rate limits. Minimal disclosure beyond the flag.
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 is too abbreviated given the tool's complexity. It front-loads the purpose but lacks necessary detail, making it merely concise rather than effectively structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters (3 required) and an output schema, the description is insufficient. It does not explain input formats, the role of confirm, marketplace, or how updates are structured. Sibling tools suggest many update operations, but the description fails to differentiate fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints that confirm=True is required, but does not explain sku, updates, marketplace, or product_type. Leaves most parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update multiple attributes of a listing' (verb+resource) and mentions the required confirm flag. It distinguishes from sibling tools like update_listing_attribute (single attribute) and bulk_update_prices (prices only), though not explicitly.
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 updating multiple attributes with confirmation, but does not explicitly state when not to use it or mention alternatives. The confirmation requirement provides some guidance, but no exclusions or 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 provided, so the description must fully disclose behavior. It mentions 'asynchronous report', indicating non-instant results, but fails to explain the process, required permissions, or what triggers the report.
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 with no unnecessary words, making it efficient for quick understanding.
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 having an output schema, the description omits critical details such as the asynchronous nature's implications, the response format, and parameter explanation, making it inadequate for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'marketplace' with no description and 0% coverage. The tool description does not explain the parameter's role, leaving its meaning ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves FBA stock per SKU via an asynchronous report. The verb 'get' and resource 'stock' are specific, but it does not explicitly distinguish from sibling tools like 'get_inventory'.
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?
Usage context is implied by the tool name and description (FBA inventory, async report), but there is no explicit guidance on when to use this tool versus alternatives or any prerequisites.
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?
Without annotations, the description must cover behavioral traits. It does not mention read-only nature, authentication needs, rate limits, or side effects. The minimal description fails to disclose whether the operation is safe or what happens with different parameter combinations.
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 sentence with no fluff, but it is too brief to be effective. It sacrifices essential details for brevity, making it merely adequate rather than exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and three parameters, the description is incomplete. It does not explain how parameters interact (e.g., whether both 'order_id' and 'days_back' can be used together) or what the output represents, leaving gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. It does not explain the role of 'order_id', 'days_back', or 'marketplace', leaving the agent to infer from names and defaults alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: obtaining invoices by order or period. It uses a specific verb ('obtener') and identifies the resource ('facturas'), with filtering criteria that distinguish it from siblings like 'download_invoice' (download action) and 'get_order_finances' (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description lacks information on when to use this tool versus alternatives (e.g., 'download_invoice' for PDFs) and offers no exclusions or prerequisites.
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 full burden for behavioral disclosure. It only restates the tool's purpose without revealing traits like read vs. write side effects, required permissions, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose with no wasted words. It is appropriately sized for a simple 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?
Despite having an output schema, the description does not explain what the tool returns (e.g., specific fields like product IDs and quantities). For a tool with only one optional parameter, more detail on output and context would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not mention the 'marketplace' parameter or its role. The parameter's purpose is left entirely to its property name, which is insufficient.
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 'Restock recommendations: what and how much to restock' clearly states the tool's purpose with a specific verb ('get') and resource ('restock suggestions'). It distinguishes itself from sibling tools like get_fba_inventory by focusing on recommendations rather than raw inventory data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_fba_inventory or get_inventory. The description lacks context for optimal usage, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It reveals that confirm=True is needed, which suggests a confirmation step. However, it does not mention that the operation is destructive (price overwrite), any authorization requirements, rate limits, or response behavior. This is adequate but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loaded with the purpose. It wastes no words but could benefit from being slightly more structured or expanded to cover key parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutating nature, the description omits crucial context: supported marketplaces, price format, whether the update is immediate, and how errors are handled. The presence of an output schema reduces the need to explain return values, but the overall description is insufficient for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only adds value for the 'confirm' parameter by stating it must be true. The other parameters (sku, price, marketplace, product_type) receive no explanation beyond their names. This barely improves understanding.
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 'Cambiar precio en un marketplace' clearly states the action (change price) and resource (marketplace). It distinguishes the tool from sibling tools like 'bulk_update_prices' only implicitly, but the name itself is specific. The mention of 'Requiere confirm=True' adds a key detail.
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 only notes that confirm=True is required, implying it must be set for the action to execute. It provides no guidance on when to use this tool versus alternatives (e.g., bulk_update_prices, sync_marketplace_prices), nor does it specify prerequisites or context.
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 full burden. It discloses that the tool returns a status from a limited set, but does not mention whether it is read-only, requires authentication, or has rate limits. The output schema likely provides details, but the description adds minimal behavioral context beyond the status list.
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 that front-loads the purpose. It is very concise, though it could be more structured (e.g., separating the purpose from the status list) for improved readability.
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 simplicity of the tool (2 parameters, output schema exists), the description is somewhat complete by listing possible statuses. However, it lacks parameter descriptions and usage guidance relative to siblings, which are important for contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema does not describe any parameters. The tool description also fails to explain what 'report_id' or 'marketplace' mean or how they should be used. This is a significant gap for an AI agent to correctly invoke the 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 checks the status of a report and lists the possible statuses (IN_QUEUE, IN_PROGRESS, DONE, FATAL). This distinguishes it from sibling tools like 'check_feed' or 'download_report', which have different purposes.
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 guidance on when to use this tool versus alternatives. The description implies it is for checking report status, but does not mention when to use e.g., 'download_report' instead. Sibling tools exist but no exclusions are provided.
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?
With no annotations, the description carries full burden. It discloses the fallback mechanism and inclusion of BIL translations, which are key behavioral traits beyond the basic retrieval. It does not mention permissions or side effects, but the name implies a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first sentence lists the output content, second explains the data sourcing strategy. Every sentence adds value, no fluff. Well-structured and front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers what the tool does and how it retrieves data. It mentions key details like fallback and translations. It could optionally mention prerequisite parameter formats but is sufficient for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. However, the description does not explain the parameters (sku, marketplace) beyond implying the listing is identified via some identifier. It adds minimal semantic value over the raw schema, missing an opportunity to clarify parameter usage.
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 returns listing content (title, bullets, keywords, offers, attributes) and specifies the data sources (Listings API with fallback to Catalog API). This is a specific verb-resource combination that distinguishes it from sibling tools like get_product_details or get_listing_issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on data retrieval order (Listings API first, then Catalog API if attributes missing). While it doesn't explicitly state when not to use this tool or compare with alternatives, the context of data sources and fallback behavior gives clear usage 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:

[![mcp-amazon-sp-api MCP server](https://glama.ai/mcp/servers/christian-ramos/mcp-amazon-sp-api/badges/card.svg)](https://glama.ai/mcp/servers/christian-ramos/mcp-amazon-sp-api)

Score Badge

Copy to your README.md:

[![mcp-amazon-sp-api MCP server](https://glama.ai/mcp/servers/christian-ramos/mcp-amazon-sp-api/badges/score.svg)](https://glama.ai/mcp/servers/christian-ramos/mcp-amazon-sp-api)

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/christian-ramos/mcp-amazon-sp-api'

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