Real-time Amazon product, seller, and search data for AI agents across 21 marketplaces.
Check the Easyparser account: current plan, credit balance (used/remaining/limit), credit reset date, per-minute rate limits, and this month's daily usage breakdown by operation. FREE — this calls the Account API and consumes no credits.
Use this before running expensive multi-page or 12-month-history jobs, when the user asks about their quota or plan, or to analyze usage patterns (e.g. 'which operation consumed the most credits this month?'). Requires an API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is free, calls the Account API, and consumes no credits — context not present in annotations. It also notes the API key requirement, adding operational detail beyond the readOnly/destructive hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact paragraphs: the first lists the returned data, the second gives usage guidance and prerequisites. No redundant phrases; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool with no output schema, the description covers the return payload, cost behavior, prerequisites, and when to invoke it. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so parameter semantics are trivially satisfied. The description implicitly confirms no inputs are needed by focusing entirely on what the tool returns, meeting the baseline for a 0-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Check the Easyparser account' and enumerates the exact data returned (plan, credit balance, reset date, rate limits, daily usage breakdown). This clearly differentiates it from the sibling tools, which focus on bulk jobs, products, and sales.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states explicit use cases: 'before running expensive multi-page or 12-month-history jobs,' 'when the user asks about their quota or plan,' and 'to analyze usage patterns.' It does not name alternatives, but the sibling list makes clear this is the only account/credit tool, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a product's current Best Sellers Rank (BSR): its numerical rank in main categories and sub-category node identifiers. A lightweight, single-purpose tool for popularity and demand tracking.
Use this tool when you only need the rank — e.g. 'Is this product selling well?' or daily rank monitoring. Lower rank number means higher sales velocity. If you also need price, rating or content, use get_product_detail instead (it includes BSR along with everything else). For historical rank trends, use get_sales_history. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | Yes | Amazon Standard Identification Number — a 10-character alphanumeric product identifier (e.g. B0CJB6V2L5). Found in the product URL after /dp/ or /gp/product/. | |
| domain | No | Amazon marketplace domain extension. Determines the regional Amazon site the data is fetched from. Use the domain that matches the user's market — prices, availability and rankings differ across marketplaces. | .com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint/openWorldHint/destructiveHint, and the description adds useful behavioral context: the result reflects current rank, the tool is lightweight and single-purpose, rank semantics are inverted (lower is better), and it costs one credit. It does not contradict annotations and provides more than the minimum without needing to repeat schema information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core action, and every sentence is purposeful: current scope, output content, use cases, ranking direction, alternatives, and cost. It avoids redundancy and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a lightweight two-parameter tool with no output schema, the description is complete: it explains what is returned (rank and category node identifiers), how to interpret it, when to prefer alternatives, marketplace via domain, and cost. An agent has enough context to decide whether and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with detailed descriptions (asin pattern/URL source and domain enum/marketplace guidance), so the baseline is 3. The description adds no extra meaning about parameter semantics beyond what the schema states; it mostly restates that the tool returns rank data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get a product's current Best Sellers Rank (BSR)', and immediately clarifies scope by mentioning numerical rank and sub-category node identifiers. It also differentiates from siblings by naming get_product_detail and get_sales_history as alternatives that cover broader detail or historical trends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool ('when you only need the rank'), gives a concrete example ('Is this product selling well?'), clarifies the ranking direction ('Lower rank number means higher sales velocity'), and states exactly when to use get_product_detail or get_sales_history instead. It also adds cost awareness with 'Costs 1 credit'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the parsed result data of a single bulk job item — the actual Amazon data that item produced (product detail, search results, seller profile, etc., depending on the job's operation). This is the same data shown in the item result modal on the Bulk Requests page of the web app.
Use this tool after get_bulk_job_items, when the user wants to see the DATA behind a specific item, not just its status. Typical flow: list_bulk_jobs → get_bulk_job_items → get_bulk_item_result.
IMPORTANT: bulk results are retained for 24 HOURS after the job completes, then they expire. If the item's data has expired, the tool returns a clear message — suggest re-running that item through the matching real-time tool (e.g. get_product_detail for a DETAIL item) to regenerate the data. This tool is free of per-call credits.
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | The item_id of a bulk job item — get it from get_bulk_job_items (each item row has one). This is the same ID the Data Service calls a query ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, and the description adds valuable behavior beyond that: a 24-hour retention window, expiration behavior with a clear fallback message, and zero per-call credits. It also ties the output to the web app's item result modal, which is useful context. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, then adds usage flow, expiration caveat, and cost information in a logical order. Every sentence carries distinct information with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with a fully documented schema, the description covers the output shape (depends on operation), usage sequence, lifecycle/expiration behavior, error fallback, and cost. Nothing essential is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single item_id parameter, including where to obtain it and its query-ID alias. The description reinforces the idea of a specific item but adds no new parameter-level semantics beyond the schema, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource: 'Fetch the parsed result data of a single bulk job item' and clarifies that the returned data depends on the job's operation. It explicitly distinguishes from get_bulk_job_items by contrasting status with the data behind the item. This leaves no ambiguity about what the tool produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the sequencing: use after get_bulk_job_items, and only when the user wants the actual data rather than status. It provides a typical flow (list_bulk_jobs → get_bulk_job_items → get_bulk_item_result) and names real-time fallback tools for expired results. This is strong when/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect the individual items inside a bulk job: each item's input value (ASIN, keyword, seller ID...), its status (success/failed/invalid/pending/processing), error message if it failed, credit cost, and completion time.
Use this tool to debug a job after list_bulk_jobs shows failed_items or invalid_items > 0 — filter with status='failed' or status='invalid' to see exactly which inputs failed and why. Use search_key to locate one specific ASIN inside a large job. The item's item_id can be used with the Data Service (GET /v1/queries/{id}) to fetch its parsed result.
This tool is free of per-call credits (monitoring endpoints do not consume credits).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number. Default 1. | |
| limit | No | Items per page (max 1000). Default 100. | |
| status | No | Filter items by outcome. Use 'failed' or 'invalid' to debug a partial_success job; omit to see everything. | |
| date_to | No | ISO date upper bound. | |
| group_id | Yes | The job's group_id — get it from list_bulk_jobs (each job row has one). Identifies which job's items to inspect. | |
| date_from | No | ISO date lower bound, e.g. 2026-08-01. | |
| search_key | No | Search within item values (e.g. a specific ASIN) to find one item in a large job. | |
| sort_direction | No | Sort by creation time. 'desc' (newest first) is default. | desc |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to prove the operation is safe. It adds valuable non-obvious behavior beyond annotations: the tool is free of per-call credits and monitoring endpoints do not consume credits. It also clarifies what statuses and fields the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: purpose first, then usage workflow, then a cost note. Every sentence adds practical value, and the key workflow is front-loaded. No filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description names what each item contains, explains how to filter and debug, notes the free-of-charge behavior, and links the item_id to a downstream use. Given the tool's moderate complexity, this is sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds contextual meaning: group_id comes from list_bulk_jobs, status='failed'/'invalid' is for debugging partial_success jobs, and search_key finds a specific ASIN in a large job. This goes beyond what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Inspect the individual items inside a bulk job' and enumerates exactly what each item exposes (input value, status, error message, credit cost, completion time). It clearly differentiates from list_bulk_jobs by focusing on item-level inspection rather than job-level summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance: debug a job after list_bulk_jobs shows failed_items or invalid_items > 0, filter by status='failed' or 'invalid', and use search_key to locate a specific ASIN. It also ties the resulting item_id to a downstream Data Service call, so an agent knows exactly how to proceed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check webhook delivery logs for bulk jobs: whether the completion notification was delivered to the user's callback_url, delivery status, and timestamps. Use this when a job shows as completed but the user's system never received the webhook — the classic "job finished but my integration didn't fire" debugging case.
Scope to one job with group_id (from list_bulk_jobs), or omit it to scan recent deliveries across all jobs. This tool is free of per-call credits.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number. Default 1. | |
| limit | No | Items per page (max 1000). Default 100. | |
| status | No | Filter by delivery status (e.g. 'success', 'failed'). | |
| date_to | No | ISO date upper bound. | |
| group_id | No | Scope logs to one job's group_id. Omit to see recent webhook deliveries across all jobs. | |
| date_from | No | ISO date lower bound. | |
| request_id | No | Filter by an individual request ID. | |
| sort_direction | No | Sort by creation time. 'desc' (newest first) is default. | desc |
| bulk_request_id | No | Filter by the job's bulk_request_id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with them. It adds useful behavioral context beyond annotations, notably that the tool is free of per-call credits and that omitting group_id scans recent deliveries across all jobs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: purpose, concrete use case, scoping guidance, and cost note each earn their place. It front-loads the most important information and avoids redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter, fully optional tool with no output schema, the description gives enough context to call it correctly: what it returns conceptually, when to use it, how to narrow scope, and cost implications. The schema covers the remaining parameter syntax details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning for group_id by tying it to list_bulk_jobs and explaining the omit-to-scan-all behavior, which is not fully conveyed by the bare schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks webhook delivery logs for bulk jobs, including whether completion notifications were delivered, delivery status, and timestamps. It distinguishes itself from sibling tools like get_error_logs and list_bulk_jobs by naming the exact resource and debugging scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete trigger for use: when a job shows as completed but the user's system never received the webhook. It also explains the key scoping choice between group_id and scanning all jobs. However, it does not explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the user's API request error logs — the same data shown on the Errors page of the Easyparser web app. Covers both real-time API errors and bulk job errors: each row has the platform, operation, domain, error code, channel (BULK/REALTIME), the request parameters that caused it, and a timestamp.
Use this tool when the user asks about failures: "why are my requests failing?", "show me recent errors", "any webhook errors today?", "what went wrong with my DETAIL calls?". Filter by error_channel (BULK or REALTIME), error_code, operation, or domain to narrow down. Each row includes a request_id and the query_params that triggered the error, so you can trace exactly which input failed.
This tool is free of per-call credits (monitoring endpoints do not consume credits).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number. Default 1. | |
| limit | No | Items per page (max 1000). Default 100. | |
| domain | No | Filter by marketplace domain. | |
| date_to | No | ISO date upper bound. | |
| order_by | No | Sort field. Default 'create_date'. | create_date |
| platform | No | Filter by platform (e.g. 'AMZ'). | |
| date_from | No | ISO date lower bound, e.g. 2026-08-01. | |
| operation | No | Filter by operation type, e.g. DETAIL or SEARCH. | |
| error_code | No | Filter by a specific error code, e.g. 'WEBHOOK_ERROR_404' or 'SOMETHING_WENT_WRONG'. | |
| order_type | No | Sort direction. 'desc' (newest first) is default. | desc |
| error_channel | No | Filter by channel: BULK (bulk job errors) or REALTIME (real-time API errors). Omit for both. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and non-destructive. The description adds extra operational context: it's a monitoring endpoint that does not consume credits, it covers both BULK and REALTIME channels, and each row exposes requst_id/query_params to trace failures. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded paragraphs: purpose, usage triggers, filter guidance, and a credit-cost note. It is information-dense and mostly efficient, though there is minor redundancy between 'request parameters that caused it' and later 'request_id and query_params'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the row fields, covering both error channels, naming the comparable UI page, and noting monitor-no-credit behavior. It doesn't need to restate page/limit defaults since the schema already covers them. A few additional examples of returned structure could nudge it to 5, but it is well within complete range.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the 11 parameters are already well documented. The description reinforces relevant filters (error_channel, error_code, operation, domain) and explains why they are useful, but it doesn't add semantic details beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('List the user's API request error logs') and immediately scopes what it covers: real-time API errors and bulk job errors, with a precise list of row fields. This clearly distinguishes it from sibling tools that fetch product data, job items, or webhook logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly lists user intent phrases that should lead to this tool, such as 'why are my requests failing?' and 'show me recent errors'. It doesn't name alternatives or state when not to use it, but the context is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a product's precise physical and logistical attributes: package height, width, length, weight, and its Amazon fee category (e.g. Computers, Apparel). This is the FBA fee-estimation and shipping-cost tool.
Use this tool when the question is about shipping, storage, FBA fees, or warehouse planning. Do NOT use it for general product info — get_product_detail includes a human-readable dimensions string, but only THIS tool returns the structured fee category and exact measurements needed for fee calculation. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | Yes | Amazon Standard Identification Number — a 10-character alphanumeric product identifier (e.g. B0CJB6V2L5). Found in the product URL after /dp/ or /gp/product/. | |
| domain | No | Amazon marketplace domain extension. Determines the regional Amazon site the data is fetched from. Use the domain that matches the user's market — prices, availability and rankings differ across marketplaces. | .com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds valuable context beyond that: it costs 1 credit, it returns structured fee-category data, and it is the fee-calculation source rather than a human-readable description. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: the first defines the resource, the second provides the routing decision with an explicit alternative, and the third states cost. It is front-loaded and free of redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool returns, when to use it, what to avoid, the key alternative, and the cost. With no output schema, it lists the return attributes but omits units of measurement and error behavior; however, these are minor gaps given the tool's simple read-only nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for both parameters, including ASIN format and domain enum/default. The description adds no parameter-specific semantics beyond reiterating the tool's purpose. Per the baseline rule for high schema coverage, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a precise resource ('a product's precise physical and logistical attributes'), and names the exact attributes: package height, width, length, weight, and Amazon fee category. It also positions the tool as the FBA fee-estimation and shipping-cost tool, clearly distinguishing it from get_product_detail, which returns a human-readable dimensions string.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool ('when the question is about shipping, storage, FBA fees, or warehouse planning') and when not to ('Do NOT use it for general product info'). It names the alternative tool (get_product_detail) and explains the differentiator, giving an agent a concrete decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch complete, structured information about a single Amazon product: title, brand, images, feature bullets, description, Buy Box price and availability, Prime eligibility, rating and review count, Best Sellers Rank, category path, variants, specifications, and top reviews. This is the primary tool for product analysis, listing enrichment, and price monitoring.
Use this tool when you need a full product profile. If you only need competing seller prices, use get_product_offers instead (cheaper context). If you only need the sales rank, use get_bestseller_rank. If you only need shipping dimensions or the FBA fee category, use get_package_dimensions.
Provide EITHER the identifier field OR url — never both. Costs 1 credit; set a_plus_content to true only when the user explicitly asks about enhanced brand content, as it costs 1 extra credit.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Full Amazon product URL (e.g. https://www.amazon.com/dp/B0CJB6V2L5). Use this when the user pastes a link instead of an ASIN. | |
| asin | No | Amazon Standard Identification Number — a 10-character alphanumeric product identifier (e.g. B0CJB6V2L5). Found in the product URL after /dp/ or /gp/product/. | |
| domain | No | Amazon marketplace domain extension. Determines the regional Amazon site the data is fetched from. Use the domain that matches the user's market — prices, availability and rankings differ across marketplaces. | .com |
| currency | No | ISO currency code for price display (e.g. usd, eur, try). Prices are converted by Amazon's own display logic. | |
| language | No | Language code for the Amazon page, in locale format (e.g. en_US, de_DE, tr_TR). Affects the language of titles, descriptions and reviews in the response. | |
| seller_id | No | Fetch the product as offered by a specific seller (their Seller ID). Only use when the user asks about a specific merchant's offer. | |
| a_plus_content | No | Set true to include the 'From the manufacturer' A+ enhanced brand content. Costs 1 additional credit. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond those: the 1-credit cost, the extra credit for a_plus_content, the exclusive-OR constraint between identifier and url, and the instruction to set a_plus_content only on explicit user request. It does not disclose error/not-found behavior, but the cost and constraint disclosures are genuine value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four paragraphs with a clear progression: what it returns, when it is the primary choice, when to choose alternatives, and input/cost constraints. The verb+resource is front-loaded and every sentence earns its place. The 13-item field enumeration is long but justified since no output schema exists to document the response; it is slightly more verbose than strictly necessary, stopping short of perfect economy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 7-parameter tool with 0 required parameters and no output schema, the description covers the response surface via the field list, identification constraints, cost, and marketplace routing. The main gaps are error behavior for invalid ASINs or URLs and explicit acknowledgment of the open-world scope implied by openWorldHint, but nothing an agent needs to invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 7 parameters have descriptions), so the baseline is 3. The description adds two things the schema does not express: the mutual-exclusion rule ('Provide EITHER the identifier field OR url — never both') and the cost consequence of a_plus_content. Those additions justify a 4, though the description appropriately leaves per-parameter syntax to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Fetch complete, structured information about a single Amazon product') and enumerates 13 concrete data fields (title, brand, images, Buy Box price, Prime eligibility, Best Sellers Rank, variants, top reviews, etc.), making the return surface unmistakable. It explicitly differentiates itself from siblings by declaring 'the primary tool for product analysis, listing enrichment, and price monitoring' and naming get_product_offers, get_bestseller_rank, and get_package_dimensions as more targeted alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit selection rule ('Use this tool when you need a full product profile') followed by three named alternatives with their conditions: get_product_offers for competing seller prices (notably flagged as cheaper context), get_bestseller_rank for sales rank, and get_package_dimensions for shipping dimensions or FBA fee category. This is exactly the when/when-not/alternatives guidance the dimension asks for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the list of seller offers for an Amazon product: every merchant selling the item with their price, shipping cost, condition (new/used), fulfillment type (FBA/FBM), and seller rating. Also returns the Buy Box winner. This is the tool for competitive price analysis, reseller monitoring, and availability tracking.
Use this tool when the question is about WHO sells the product and at WHAT price. If you need the product's own details (title, images, rating), use get_product_detail instead.
Each requested page costs 1 credit. Start with a single page (default) and only increase max_page if the user needs the full offer list. Use the condition and shipping filters to narrow results instead of paginating — it is cheaper.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | Yes | Amazon Standard Identification Number — a 10-character alphanumeric product identifier (e.g. B0CJB6V2L5). Found in the product URL after /dp/ or /gp/product/. | |
| prime | No | If true, return only Prime-eligible offers. | |
| domain | No | Amazon marketplace domain extension. Determines the regional Amazon site the data is fetched from. Use the domain that matches the user's market — prices, availability and rankings differ across marketplaces. | .com |
| max_page | No | Ending page number. Each page costs 1 credit; max 5 pages per request. Default 1. | |
| min_page | No | Starting page number. Default 1. | |
| condition | No | Filter offers by item condition. Omit to include all conditions. | |
| free_shipping | No | If true, return only offers with free shipping. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond the schema: each page costs 1 credit, pagination has a max of 5 pages, and filtering is cheaper than paginating. It doesn't describe the response shape, but with no output schema and read-only annotations, the credit-cost disclosure is valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear first sentence, a second sentence explaining purpose, a third routing sentence, and a cost-guidance paragraph. It is slightly longer than necessary, but every sentence earns its place—especially the credit-cost and pagination guidance, which is essential for safe cost-conscious invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with 7 parameters and no output schema, the description covers what the tool returns, when to use it, and the cost model. It does not explicitly describe the response format, but given the output schema absence and the listing nature of the tool, the description is complete enough for correct invocation. Minor gap: it doesn't mention what happens when no seller offers exist or whether pagination is per-page sequential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds semantic meaning by framing the credit cost per page and recommending filters instead of pagination, which directly informs how to set max_page and condition/shipping parameters. It also clarifies the domain principle ('use the domain that matches the user's market'), though that already appears in the schema. The description reinforces the filter behavior and page-cost tradeoff beyond the schema's raw field definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Fetch the list of seller offers for an Amazon product') and enumerates exactly what data is returned: merchant price, shipping cost, condition, fulfillment type, seller rating, and Buy Box winner. It also explicitly distinguishes itself from get_product_detail, which is the sibling it could be confused with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('when the question is about WHO sells the product and at WHAT price') and names the alternative (get_product_detail) with clear exclusion criteria. It also gives cost-conscious guidance on pagination and filtering, which is actionable and specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a product's historical performance over up to 12 months: weekly aggregated trends for estimated views/traffic, sales, price, and Best Sellers Rank. This is Easyparser's 'time machine' — the deepest competitive-intelligence tool in this server.
Use this tool for trend forecasting, seasonality analysis, conversion-rate estimation, and investment/sourcing due diligence. Do NOT use it for a simple current price check — get_product_detail is 5x cheaper for that.
IMPORTANT cost rule: the base cost is 5 credits, and each month of history adds 1 credit (3 months = 8 credits, 12 months = 17 credits). Always ask the user how far back they need, or default to 3 months for a quick trend read. The history array in the response is aggregated by WEEK, not by day.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | Yes | Amazon Standard Identification Number — a 10-character alphanumeric product identifier (e.g. B0CJB6V2L5). Found in the product URL after /dp/ or /gp/product/. | |
| domain | No | Amazon marketplace domain extension. Determines the regional Amazon site the data is fetched from. Use the domain that matches the user's market — prices, availability and rankings differ across marketplaces. | .com |
| history_range | No | Depth of historical data in months. '0' returns only the current snapshot (5 credits). '3', '6', '9', '12' add weekly history at +1 credit per month. Default '0'. | 0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, so the base safety profile is clear. The description adds non-obvious behavioral context: the credit cost formula, weekly rather than daily aggregation, and the presence of a history array in the response. It does not contradict the annotations and usefully elaborates on cost and granularity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact paragraphs are front-loaded with purpose, followed by use-case routing and then the cost/default rule. The 'time machine' and 'deepest competitive-intelligence tool' phrasing is mildly promotional but not harmful. Overall, each sentence contributes to tool selection or invocation guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with three parameters and no output schema, the description adequately covers when to use it, how to size history_range, and what the response contains (weekly aggregated history). It does not explicitly state that history_range '0' returns only the current snapshot, though the schema does cover that. The output shape beyond 'history array' is not specified, but enough context is present for a competent agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds extra selection guidance: the cost per month, the recommendation to default to 3 months, and the weekly aggregation semantics that affect interpretation of history_range. It avoids merely repeating schema text while still enriching parameter decisions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Retrieve a product's historical performance over up to 12 months,' and enumerates the exact metrics returned (views/traffic, sales, price, Best Sellers Rank). It also differentiates from get_product_detail by labeling this the 'deepest competitive-intelligence tool' and explicitly excluding simple price checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete use cases: trend forecasting, seasonality analysis, conversion-rate estimation, and due diligence. It also tells the agent when not to use it, naming the alternative 'get_product_detail is 5x cheaper for that,' and instructs how to choose history depth: ask the user or default to 3 months. This is explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read individual buyer feedback entries for an Amazon seller: star ratings, comment text, and dates — filterable by rating range and time period. This is the reputation deep-dive tool.
Use this tool when the user wants to read actual buyer comments about a seller, analyze complaint patterns, or audit service quality. For aggregate reputation scores (30/90/365-day percentages) without individual comments, get_seller_profile is sufficient and cheaper in context.
Each page costs 1 credit. To find dissatisfied customers, set max_rating to 3 instead of paging through everything.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Amazon marketplace domain extension. Determines the regional Amazon site the data is fetched from. Use the domain that matches the user's market — prices, availability and rankings differ across marketplaces. | .com |
| max_page | No | Ending page number. Each page costs 1 credit; max 5 pages per request. Default 1. | |
| min_page | No | Starting page number. Default 1. | |
| seller_id | Yes | Amazon's unique seller identifier (e.g. A1MCYUGJD2ILFU). Found in seller profile URLs as the 'seller=' or 'me=' parameter. | |
| max_rating | No | Maximum star rating to include (1-5). Set to 3 to focus on negative feedback. Default 5. | |
| min_rating | No | Minimum star rating to include (1-5). Default 1. | |
| history_range | No | Time period filter: '1' or '3' or '12' for months, 'all' for everything. Default 'all'. | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: pagination costs 1 credit per page, a maximum of 5 pages per request is implied via max_page, and rating filtering can be used strategically to avoid paging through everything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, leading with the core function, then use cases, then the alternative tool, then cost and filtering tips. Every sentence adds value, and there is no wasted repetition of the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description covers purpose, selection criteria, alternatives, cost implications, and a useful filtering strategy. It names the key returned content (star ratings, comment text, dates), though it does not detail the exact response shape or pagination semantics beyond credit cost. Overall it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters, so the baseline is 3. The description adds meaningful parameter guidance beyond the schema: it explains that rating range and time period filters exist, and specifically recommends setting max_rating to 3 to target dissatisfied customers. This directly helps the agent choose parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') with a clear resource ('individual buyer feedback entries for an Amazon seller') and lists concrete contents: star ratings, comment text, and dates. It also distinguishes itself from get_seller_profile by framing this as the 'reputation deep-dive tool,' so the agent can differentiate it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states explicitly when to use the tool: when the user wants actual buyer comments, complaint-pattern analysis, or service-quality audits. It also gives a clear alternative (get_seller_profile) for aggregate scores, and adds practical guidance about credit cost per page and using max_rating=3 to find dissatisfied customers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract a seller's full product catalog: every ASIN they sell with brand, category, price, Prime status, variant counts, and rating data. Also returns dynamic refinement filters (department, shipping, sustainability) for drilling into the catalog.
Use this tool for competitor inventory analysis, stock monitoring, and pricing-strategy research. If you need the seller's legal identity or reputation instead of their products, use get_seller_profile.
Each page costs 1 credit. Start with one page and use sort_by (e.g. 'exact-aware-popularity-rank' for best sellers first) to surface the most relevant products early. Provide EITHER seller_id OR url — never both.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Full Amazon seller profile or storefront URL (e.g. https://www.amazon.com/sp?seller=A1MCYUGJD2ILFU). | |
| domain | No | Amazon marketplace domain extension. Determines the regional Amazon site the data is fetched from. Use the domain that matches the user's market — prices, availability and rankings differ across marketplaces. | .com |
| sort_by | No | Catalog ordering. 'featured-rank' is default; 'exact-aware-popularity-rank' sorts by popularity (best sellers first); 'price-asc-rank'/'price-desc-rank' by price; 'date-desc-rank' by newest. | |
| language | No | Language code for the Amazon page, in locale format (e.g. en_US, de_DE, tr_TR). Affects the language of titles, descriptions and reviews in the response. | |
| max_page | No | Ending page number. Each page costs 1 credit; max 5 pages per request. Default 1. | |
| min_page | No | Starting page number. Default 1. | |
| seller_id | No | Amazon's unique seller identifier (e.g. A1MCYUGJD2ILFU). Found in seller profile URLs as the 'seller=' or 'me=' parameter. | |
| exclude_refinements | No | If true, omits the refinement filter list from the response, reducing payload size. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only and non-destructive. The description adds meaningful behavioral context beyond that: each page consumes 1 credit, starting with one page is recommended, and sort_by can surface relevant products early. This gives the agent practical expectations about cost and pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into purpose, use cases, and usage constraints, with no filler. Every sentence adds operational or decision-making value, and the most important scoping information is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 8 optional parameters, no output schema, and annotated safety profile, the description covers all essentials: what is returned, when to use it, when to use an alternative, cost implications, sort strategy, and parameter exclusivity. The agent has enough context to invoke the tool correctly without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds important value beyond the schema by stating that seller_id and url are mutually exclusive ('Provide EITHER seller_id OR url — never both'), by giving a concrete sort_by example, and by explaining credit cost per page. This enhances the agent's ability to construct valid requests.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Extract a seller's full product catalog,' and enumerates the returned data (ASINs, brand, category, price, Prime status, variant counts, rating data, refinement filters). This clearly identifies the tool's function and distinguishes it from sibling tools like get_seller_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit use cases (competitor inventory analysis, stock monitoring, pricing-strategy research) and names the alternative tool with the exact condition for choosing it: 'If you need the seller's legal identity or reputation instead of their products, use get_seller_profile.' It also provides operational guidance around credits, sort_by, and the mutually exclusive seller_id/url constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unmask the legal identity and reputation of any Amazon merchant: legal business name, registered business address, and granular feedback trends over 30/90/365 days and lifetime. This is the supplier-verification and brand-protection tool.
Use this tool when the user asks 'who is this seller?', 'is this merchant legitimate?', or needs a supplier's legal entity for compliance or invoicing. To see WHAT the seller sells, use get_seller_products. To read individual buyer reviews about the seller, use get_seller_feedback.
Provide EITHER seller_id OR url — never both. You can discover a product's seller by calling get_product_offers first. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Full Amazon seller profile or storefront URL (e.g. https://www.amazon.com/sp?seller=A1MCYUGJD2ILFU). | |
| domain | No | Amazon marketplace domain extension. Determines the regional Amazon site the data is fetched from. Use the domain that matches the user's market — prices, availability and rankings differ across marketplaces. | .com |
| language | No | Language code for the Amazon page, in locale format (e.g. en_US, de_DE, tr_TR). Affects the language of titles, descriptions and reviews in the response. | |
| seller_id | No | Amazon's unique seller identifier (e.g. A1MCYUGJD2ILFU). Found in seller profile URLs as the 'seller=' or 'me=' parameter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so no contradiction. The description adds useful behavioral context beyond annotations: the operation costs 1 credit, and the caller must supply exactly one of seller_id or url. It does not detail error behavior or pagination, but the core safety profile is covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the tool's core output, then usage guidance, then the critical mutual-exclusion constraint and credit cost. There is no filler or repetition; every sentence contributes to selection or invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema, the description covers what is returned, when to use it, which alternatives to prefer, the required argument pattern, and the cost. Nothing an agent needs for ordinary invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful parameter relationship guidance: seller_id and url are mutually exclusive, and get_product_offers can resolve a seller_id. This goes beyond the per-property schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (Amazon merchant identity) and returns legal business name, address, and feedback trends. It explicitly positions itself as the supplier-verification tool and distinguishes itself from get_seller_products and get_seller_feedback, so an agent can select it correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('who is this seller?', 'is this merchant legitimate?', compliance/invoicing) and names alternatives for adjacent tasks (get_seller_products for items, get_seller_feedback for individual reviews). It also gives an input rule and points to get_product_offers as a way to discover the seller_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the user's bulk extraction jobs with their progress: operation, domain, status, total/completed/failed/invalid item counts, and timestamps. This reads the SAME data as the Bulk Requests page in the Easyparser web app — so it can see and track jobs the user started from the app UI, not just jobs submitted through this MCP server.
Use this tool when the user asks about their bulk jobs: "is my job done?", "what bulk jobs are running?", "did the DETAIL batch finish?". Each row includes a group_id — pass it to get_bulk_job_items to drill into individual items, or to get_bulk_webhook_logs to check webhook deliveries.
Statuses: pending (queued), processing (running), completed (all items succeeded), partial_success (some items failed or were dropped — check failed_items/invalid_items counts), failed. This tool is free of per-call credits (monitoring endpoints do not consume credits).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number. Default 1. | |
| limit | No | Items per page (max 1000). Default 100. | |
| domain | No | Filter by marketplace domain. | |
| status | No | Filter by job status: pending, processing, completed, partial_success (some items failed), failed. | |
| operation | No | Filter by operation type, e.g. DETAIL or SEARCH. | |
| sort_direction | No | Sort by creation time. 'desc' (newest first) is default. | desc |
| bulk_request_id | No | Look up a specific job by its bulk_request_id (returned when the job was submitted). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false, and the description consistently presents a read-only listing operation. It adds meaningful context beyond annotations: visibility into jobs created from the web UI, free credit usage, and detailed meaning of statuses (e.g. partial_success means some items failed or were dropped).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, and each subsequent sentence adds distinct value: usage triggers, sibling routing, status semantics, and cost behavior. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a monitoring tool with no output schema, it describes the return row contents, available filters, status meanings, and next-step tool routing. Combined with a fully-documented schema and safety annotations, nothing essential is missing for an agent to select and call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with explicit descriptions for all seven parameters, so the heavy lifting is done by the schema. The description adds little to parameter semantics, though it explains status enum values more fully and references group_id in the output rows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states the exact verb and resource: 'List the user's bulk extraction jobs with their progress' and enumerates the fields returned. It differentiates from siblings by noting it reads the same data as the Bulk Requests web app and by pointing to get_bulk_job_items / get_bulk_webhook_logs for drilling down.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit user-intent triggers: 'is my job done?', 'what bulk jobs are running?', 'did the DETAIL batch finish?'. It also tells the agent when the tool is not the final step by directing group_id to sibling tools, and adds a cost consideration ('free of per-call credits').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Easyparser operations available in this server, with their parameters, credit costs, and example use cases. Works WITHOUT an API key — call this first to understand what the server can do, or when you are unsure which tool fits the user's question. Also returns the list of supported Amazon marketplace domains.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | No | Optional. Get the usage guide for one operation instead of the whole catalog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context beyond those annotations: it emphasizes that the tool 'Works WITHOUT an API key' and explains what it returns, including marketplace domains. This meaningfully helps an agent understand the tool's behavior and requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver all essential information with no filler. The primary function is front-loaded, followed by usage guidance and return value highlights. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity discovery tool with one optional parameter and strong read-only annotations, the description is fully sufficient. It explains what is listed, the auth requirement, when to call it, and additional return content. No critical gaps remain even without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional parameter, and the schema already provides a clear description and enum values. The tool description does not add parameter-specific detail, but it does not need to because the schema is sufficient. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a catalog/discovery operation: 'List all Easyparser operations available in this server, with their parameters, credit costs, and example use cases.' It is unambiguous and distinct from the sibling tools, which are the actual operations being listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'call this first to understand what the server can do, or when you are unsure which tool fits the user's question.' It could be stronger by explicitly stating when not to use it or naming alternatives, but the intended entry-point role is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert an external product identifier (UPC, EAN, GTIN, ISBN, JAN, MINSAN) into the corresponding Amazon ASIN, with an essential product snapshot. This is the bridge between manufacturer/retail barcodes and the Amazon ecosystem.
Use this tool when the user has a barcode or standard product code and wants to find the matching Amazon listing. Typical workflows: catalog matching, inventory synchronization, converting supplier data into Amazon ASINs. Also accepts ASIN as input type if you need to validate one.
You MUST set identifier_type to match the code you have — guessing the wrong type returns no results. UPC is 12 digits, EAN/GTIN is 13, ISBN is 10 or 13 (books). If the user gives a keyword instead of a code, use search_products instead. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Amazon marketplace domain extension. Determines the regional Amazon site the data is fetched from. Use the domain that matches the user's market — prices, availability and rankings differ across marketplaces. | .com |
| identifier | Yes | The product code value (e.g. '724382975021' for a UPC). Digits only for barcode types. | |
| identifier_type | Yes | The type of code provided. UPC: 12-digit US barcode. EAN/GTIN: 13-digit international barcode. ISBN: book identifier. JAN: Japanese barcode. MINSAN: Italian pharma code. ASIN: Amazon's own identifier. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only and non-destructive; the description adds non-obvious behavioral facts: wrong identifier_type matches return nothing, and each call costs 1 credit. It doesn't describe response details beyond 'essential product snapshot', but the annotations lower the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, followed by when-to-use, parameter rules, and the sibling alternative. Every sentence adds actionable information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a conversion tool with no output schema, it explains the output (ASIN plus product snapshot), the key failure mode, cost, marketplace domain handling via schema, and the correct alternative for keywords. This is enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 3 parameters, and the description adds valuable semantic detail beyond it: UPC is 12 digits, EAN/GTIN 13, ISBN 10/13, and matching identifier_type is mandatory. This extra guidance helps the agent construct correct calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific conversion task — external product identifiers (UPC, EAN, GTIN, ISBN, JAN, MINSAN) to Amazon ASIN — and clearly distinguishes itself from sibling search_products by saying keywords should go there. It also notes ASIN validation as a secondary use, which further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance ('Use this tool when the user has a barcode or standard product code'), describes typical workflows, and names the alternative for non-code inputs ('use search_products instead'). This is unambiguous routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Amazon by keyword or a full search/category URL and get structured product listings: ASIN, title, price, rating, review count, Prime status, and badges (Best Seller, Amazon's Choice) for each result. Also returns the available refinement filters (category, brand, price range) with their IDs.
Use this tool for market research, keyword analysis, and product discovery. If the user already has an ASIN or product URL, do NOT search — use get_product_detail directly.
Each page costs 1 credit. One page typically returns 20-40 products, which is enough for most questions. Use sort_by and exclude_sponsored to improve result quality instead of fetching more pages. To filter by category or brand, first run one search and read the refinements field in the response to discover valid filter IDs, then pass them in refinements.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Full Amazon search or category URL. Use when the user pastes an Amazon link containing filters. Mutually exclusive with keyword. | |
| domain | No | Amazon marketplace domain extension. Determines the regional Amazon site the data is fetched from. Use the domain that matches the user's market — prices, availability and rankings differ across marketplaces. | .com |
| keyword | No | Search query as a user would type it into Amazon (e.g. 'stainless steel water bottle 40oz'). Mutually exclusive with url. | |
| sort_by | No | Result ordering. 'featured' is Amazon's default; 'price-asc-rank' cheapest first; 'price-desc-rank' most expensive; 'review-rank' most reviewed; 'date-desc-rank' newest listings; 'exact-aware-popularity-rank' by popularity. | featured |
| currency | No | ISO currency code for price display (e.g. usd, eur, try). Prices are converted by Amazon's own display logic. | |
| language | No | Language code for the Amazon page, in locale format (e.g. en_US, de_DE, tr_TR). Affects the language of titles, descriptions and reviews in the response. | |
| max_page | No | Ending page number. Each page costs 1 credit; max 5 pages per request. Default 1. | |
| min_page | No | Starting page number. Default 1. | |
| refinements | No | Category/attribute filters in Amazon's format: 'n:<category_id>,p_<filter_group>:<filter_id>'. Discover valid IDs from the refinements field of a previous search response. Example: 'n:7141123011,p_123:502215'. | |
| exclude_sponsored | No | If true, removes sponsored (paid ad) products from results. Recommended true for organic market analysis. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description complements them with valuable behavioral detail: each page costs 1 credit, one page typically returns 20-40 products, response includes a refinements field, and results can include sponsored items. It also discloses how to avoid unnecessary pages via sort_by and exclude_sponsored. This goes well beyond the annotations and gives the agent accurate expectations about cost and result shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into three focused paragraphs: core purpose and return values, when to use it, and operational guidance. Every sentence contributes useful information without redundancy. The most important distinguishing instruction ('use get_product_detail directly' for ASINs) is placed prominently, and the cost/credit note is front-loaded in the operational guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, rich enum options, and no output schema, the description covers all essential decision points: search method (keyword vs URL), parameter strategy (sorting, sponsored filtering, refinements), credit cost, page size, and alternative tool routing. It even explains how to obtain valid refinement IDs, which is critical for correct invocation. No meaningful gap remains for an agent to select and call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds meaningful parameter-level guidance beyond the schema. It explains that valid refinement IDs must be discovered by reading the refinements field of a previous search, that sort_by and exclude_sponsored should be preferred over fetching more pages, and that domain should match the user's market. These insights help the agent choose parameter values wisely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search Amazon by keyword or a full search/category URL and get structured product listings.' It enumerates exact output fields (ASIN, title, price, rating, review count, Prime status, badges) and explicitly names the sibling differentiation ('do NOT search — use get_product_detail directly'). This leaves no ambiguity about what the tool does or how it differs from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this tool for market research, keyword analysis, and product discovery.' It also gives a clear exclusion: 'If the user already has an ASIN or product URL, do NOT search — use get_product_detail directly.' Additionally, it provides practical guidance on filtering and pagination, making the selection criteria complete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
check_creditsget_bestseller_rankget_bulk_item_resultget_bulk_job_itemsget_bulk_webhook_logsget_error_logsget_package_dimensionsget_product_detailget_product_offersget_sales_historyget_seller_feedbackget_seller_productsget_seller_profilelist_bulk_jobslist_operationslookup_productsearch_productsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Live Amazon product, review, search, deal, offer/stock and seller data across 20 marketplaces.
AMZScout Skill + MCP gives AI agents live access to real Amazon marketplace data across 14 Amazon marketplaces. Analyze any ASIN, validate product ideas, research niches, compare competitors, discover profitable keywords, and build data-driven PPC strategies using trusted Amazon insights instead of AI assumptions. Works with Claude, ChatGPT, Cursor, and any other MCP-compatible AI client. To connect, you'll need an AMZScout API plan and authorize your account. Get access and view pricing here: https://learn.amzscout.net/amazon-product-api-for-ai-agents
Product search for AI agents: Amazon + Shopify, cart-to-checkout buy path. Pay-per-call, no API key.
Amazon keyword volume, reverse-ASIN, and SERP data across 11 marketplaces.
Add one secure layer between your agents and this server.
Each tool maps to a distinct resource or action, and overlapping data is carefully disambiguated in the descriptions—e.g., get_product_detail includes BSR and dimensions, but get_bestseller_rank and get_package_dimensions are explicitly positioned as narrower alternatives. The bulk-job tools also form a clear pipeline with no realistic confusion between listing jobs, inspecting items, fetching item data, and checking webhook logs.
The dominant get_* pattern is consistent for data retrieval, and list_* is used for collection-style endpoints. Minor deviations like check_credits, lookup_product, and search_products are understandable but break the strict verb_noun consistency enough to prevent a perfect score.
At 17 tools, the server is slightly above the ideal 3-15 range, but the count is justified by the breadth of the domain: product details, offers, sales history, seller intelligence, bulk job monitoring, account credits, and error logs. Each tool earns its place, and the heavier count does not feel bloated.
Real-time product and seller data coverage is strong, including search, barcode lookup, product detail, offers, BSR, dimensions, sales history, seller profile, seller products, and seller feedback. The main gap is that bulk jobs can be listed and inspected but there is no tool to create or submit a new bulk job from the MCP server, leaving that workflow incomplete.
