Easyparser — Amazon Product & Seller Data

get_product_offers

Read-only

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.

Input Schema

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.

Output Schema

Name	Required	Description
`data`	No	Parsed Amazon data for the operation.
`success`	Yes	True when the request completed.
`operation`	Yes	Easyparser operation that ran, e.g. DETAIL or OFFER.
`request_id`	No	Easyparser request ID, useful for support and error logs.
`credits_used`	No	Credits charged for this request.
`credits_remaining`	No	Credits left on the account after this request.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 11, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "credits_remaining": {
+      "description": "Credits left on the account after this request.",
+      "type": "number"
+    },
+    "credits_used": {
+      "description": "Credits charged for this request.",
+      "type": "number"
+    },
+    "data": {
+      "description": "Parsed Amazon data for the operation."
+    },
+    "operation": {
+      "description": "Easyparser operation that ran, e.g. DETAIL or OFFER.",
+      "type": "string"
+    },
+    "request_id": {
+      "description": "Easyparser request ID, useful for support and error logs.",
+      "type": "string"
+    },
+    "success": {
+      "description": "True when the request completed.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success",
+    "operation"
+  ],
+  "type": "object"
+}

First observedSep 6, 2026

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral facts not in the structured data: a per-page credit cost, a hard 5-page cap implication, and the fact that the Buy Box winner is returned. It stops short of describing error/empty-result behavior or rate limits, so it is strong rather than exhaustive.

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?

Front-loaded with the core purpose and payload contents, then usage, then cost guidance — a logical ordering with no filler. Minor redundancy in restating what the return contains against an existing output schema keeps it from being maximally tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be re-explained, and all 7 parameters are fully documented in the schema. The description supplies the remaining decision-relevant context: sibling selection, marketplace constraint, and the credit-cost tradeoff for pagination.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including patterns, enums, defaults and the ASIN format, so the schema does the heavy lifting and 3 is the baseline. The description only adds strategic advice about condition and shipping filters (cheaper than paginating) rather than semantics beyond the schema's own enum and description text.

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?

States a specific verb and resource (fetch seller offers for an Amazon product) and enumerates exactly what the payload contains: merchant, price, shipping, condition, fulfillment type, seller rating, plus the Buy Box winner. It explicitly contrasts itself with the sibling get_product_detail, so an agent can route without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when-to-use rule ('when the question is about WHO sells the product and at WHAT price'), names the alternative (get_product_detail) for the contrasting case, and adds cost-driven tactics: start with one page, prefer condition/shipping filters over pagination because it is cheaper.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Easyparser — Amazon Product & Seller Data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.