tool4seller-mcp

Query advertising purchased products

query_advertising_purchased_products

Read-only

Returns purchased product performance attributed to advertised products. MCP reporting and workflow metric date ranges use yyyy-MM-dd and include both startDate and endDate, with at most 95 calendar days per range. For longer read-only reports, split into non-overlapping windows: endDate = startDate plus 94 days, capped at the requested end date; the next startDate is the previous endDate plus 1 day. Apply the same limit independently to comparison ranges. Do not average ratios such as ACOS or ROAS across windows; recompute them from summed base metrics. Do not automatically split advertising write plans or metric-based selectors; obtain a supported analysis window from the user. Keyword ranking trends have separate limits: DAILY supports up to 90 inclusive days and RAW up to 31 inclusive days. For keyword ranking trends, use these interval-specific limits when splitting read-only reports. This reporting limit does not apply to campaign scheduling dates.

Input Schema

Name	Required	Description
`limit`	No	Maximum number of items to return. Defaults to 100 and cannot exceed 100.
`offset`	No	Zero-based pagination offset.
`sortBy`	No	Advertising performance sort field.
`values`	No	Optional identifiers for the selected dimension.
`endDate`	Yes	End business date in yyyy-MM-dd format. Date range is inclusive and can contain at most 95 days. For longer read-only reports, use non-overlapping windows of up to 95 days.
`storeId`	Yes	Store ID from the Stores API, formatted as sellerId:marketplaceId.
`dimension`	No	Query dimension.
`sortOrder`	No	Sort order.
`startDate`	Yes	Start business date in yyyy-MM-dd format. Date range is inclusive and can contain at most 95 days. For longer read-only reports, use non-overlapping windows of up to 95 days.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A3.6/5.0

Behavior4/5

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

With read-only annotations already covering safety, the description adds substantial behavioral context: the 95-day range limit, non-overlapping window splitting rules, ratio recomputation guidance, and exclusions for write plans and keyword ranking trends. It does not contradict the annotations, though some added guidance applies to adjacent tools rather than this query directly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence, but the description is long and includes instructions about keyword ranking trends and write plans that are not directly relevant to this read-only purchased-products query. The date-window guidance is useful, but the overall text is not tightly scoped to the tool.

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

Completeness4/5

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

Given the complete input schema, output schema, and read-only annotations, the description supplies enough context for correct date-window handling and ratio interpretation. The main missing piece is explicit guidance on when this tool should be used versus neighboring advertising query tools.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters including dates, pagination, sorting, dimension, and values. The description reinforces date-range semantics but adds limited parameter-specific meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a clear verb and resource: returns purchased product performance attributed to advertised products. It does not explicitly distinguish this report from sibling advertising queries such as query_advertising or query_advertising_targets, so it is clear but not fully sibling-differentiated.

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

Usage Guidelines3/5

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

The description provides operational usage rules for date windows and splitting read-only reports, but it does not clearly say when to choose this tool over other advertising reporting siblings. Usage is implied by the reporting context rather than explicitly contrasted with alternatives.

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

All tool4seller-mcp 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.

Resources

Need Help?