Read-only MCP connector for one AMZTarget account. An assistant can list tracked ASINs, keyword positions, price and Best Seller Rank history, listing changes, and Reverse ASIN reports. Figures come from the account's scheduled checks, not from a live Amazon page. The key cannot add products, change prices, or edit alerts. Create it in Profile → AI access and send Authorization: Bearer amz_....
Scored across 10 tools
Each tool targets a distinct resource+action combination: singular/plural pairs (get_product/list_products, get_listing_change/list_listing_changes, get_reverse_report/list_reverse_reports) are cleanly split, and descriptions explicitly cross-reference where confusion could arise (get_product vs get_product_metrics, list_keywords vs get_rank_history). The metrics-vs-rank-history distinction (product BSR series vs keyword position series) is spelled out clearly.
Uniform snake_case with a predictable get_/list_ verb_noun pattern across all ten tools. Singular get_ for one record and plural list_ for collections are applied consistently, including the near-miss pairs listing_change/listing_changes and reverse_report/reverse_reports.
Ten tools is well within the sweet spot and each one maps to a meaningful part of the tracking workflow (account, products, metrics, keywords, rank, reverse reports, listing changes). No redundant or filler tools are present.
The read-only monitoring surface is largely complete: list/get pairs exist for products, listing changes, and reverse reports, plus metrics, keyword tracking, and account context. Minor gaps remain—no way to add/track a new product or keyword, and no tool to create a Reverse ASIN report (only list/read existing ones)—but these are workable around for a read-only analytics server.
Plan, marketplace, timezone, and how much of each limit this account has used.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds that limit usage is reported, which is useful context, but with no output schema it does not describe the shape of that usage data or whether quotas are absolute or percentage values.
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?
Very short, which is good, but it is an ungrammatical fragment with no leading verb or subject, so it reads as a list of return fields rather than a front-loaded statement of what the tool does. It is terse without being clear.
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 and no parameters, the description has to carry the burden of explaining what comes back; it names four data categories but gives no structure, units, or detail about the limit-usage portion. Adequate for a simple read, but thin.
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?
Zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No parameter-level gaps exist.
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 is a noun fragment that lists returned fields (plan, marketplace, timezone, limit usage) rather than stating a verb+resource. From the name get_account and these fields an agent can infer it retrieves the current account's configuration and quota status, but the purpose is implied rather than stated.
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?
No guidance on when to call this versus siblings such as list_products or get_rank_history, and no mention of prerequisites or context. The only implicit signal is that it is account-level rather than product-level, which comes mostly from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detail of one listing change returned by list_listing_changes.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | Yes | Amazon ASIN, 10 letters or digits. | |
| change_id | Yes | change_id from list_listing_changes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds only that the identifier originates from list_listing_changes; it says nothing about error behavior for stale/invalid change_ids or what the returned detail 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?
A single front-loaded sentence with no filler. It is efficiently structured, though its brevity leaves other dimensions under-specified rather than wasting words.
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 simple two-parameter read tool with full schema coverage and complete annotations, the essentials are present. However, with no output schema, an agent gets no sense of what fields the listing-change detail returns, which would be the one piece this description could usefully add.
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%, documenting both asin and change_id including format hints, so the baseline is 3. The description reinforces where change_id comes from but adds no syntax or constraints beyond what the schema already 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?
Identifies a specific resource ('one listing change') and single-item scope, and explicitly ties it to the sibling list_listing_changes. The action verb is nominal ('Detail of') rather than explicit, but an agent can immediately tell it apart from the list tool.
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?
Usage is implied rather than stated: naming that the change comes from list_listing_changes hints at the required workflow, but the description never says when to use this versus the list endpoint or what to do if the change_id is unknown. No explicit exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one tracked product by ASIN: category, image, stock, seller count, and the latest listing snapshot. Read-only. Use get_product_metrics for the price and BSR series, and list_products to scan the account.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | Yes | Amazon ASIN, 10 letters or digits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the 'Read-only' sentence is largely redundant. The description does add real value by naming the payload fields, which is the only source of return-shape information since no output schema exists. It stops short of saying what happens for an untracked ASIN (error vs empty), which would be the remaining behavioral detail.
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 short sentences, front-loaded with what is returned, then the safety hint, then the sibling routing. No filler or repetition 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?
With no output schema, the field enumeration is essential and present, and sibling routing is covered. A minor gap remains around not-found behavior and whether the snapshot is timestamped, but the agent has enough to call 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% and the single asin parameter is documented as a 10-character Amazon ASIN, so the schema carries the load. The description only restates 'by ASIN' and adds no format, casing, or multi-ASIN guidance beyond it. Baseline 3 for a fully described single parameter.
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?
Specific verb+resource ('Returns one tracked product by ASIN') with the key lookup key stated up front, then an enumeration of the returned fields (category, image, stock, seller count, latest listing snapshot). This is clearly distinguishable from get_product_metrics (series data) and list_products (scan).
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 routes to alternatives with their conditions: get_product_metrics for the price and BSR series, list_products to scan the account. An agent can pick the right tool without opening any schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price and Best Seller Rank series for an ASIN. Points are from scheduled checks.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | Yes | Amazon ASIN, 10 letters or digits. | |
| date_to | No | End date YYYY-MM-DD in the account timezone. Default is today. | |
| date_from | No | Start date YYYY-MM-DD in the account timezone. Default is the start of the plan history window. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The line 'Points are from scheduled checks' adds genuinely useful context that the series is sampled periodically, implying sparse or missing points rather than a continuous feed, but it stops short of stating granularity, gap handling, or plan-window limits.
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 short sentences with no waste, and the returned payload is front-loaded. The first sentence is a telegraphic noun phrase rather than a verb-led statement, which costs it the top mark but not much more.
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 three-parameter read tool with full schema coverage and clean annotations, this is nearly adequate, and the description partially compensates for the absent output schema by naming the two returned series. It still leaves the agent unsure about return shape, point units, and how gaps appear, and says nothing about the overlapping get_rank_history sibling.
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 asin, date_from, and date_to are fully documented with defaults and timezone semantics in the schema. The description adds nothing beyond implying a series/date range, which is the correct baseline 3 when the schema carries the burden.
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?
Names the resource and the exact payload: Price and Best Seller Rank series for a given ASIN. That is specific enough to select the tool, but it does not distinguish itself from the sibling get_rank_history (which reads like partial overlap), so the agent gets no help telling the two apart.
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?
There is no when-to-use guidance, no prerequisites, and no named alternative. With get_rank_history and get_product in the sibling list, the absence of any routing sentence leaves the agent to guess which tool to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Position history for one phrase, or up to 10 recently checked phrases when keyword is omitted. Checks run on a schedule, so the latest point is not live.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | Yes | Amazon ASIN, 10 letters or digits. | |
| date_to | No | End date YYYY-MM-DD in the account timezone. Default is today. | |
| keyword | No | Exact tracked phrase. Omit for a short sample. | |
| date_from | No | Start date YYYY-MM-DD in the account timezone. Default is the start of the plan history window. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful context beyond annotations: checks run on a schedule and the latest point is not live, which is an important freshness caveat.
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 tight sentences, front-loaded with the core purpose and followed by the freshness caveat. There is no wasted wording.
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?
Covers the key behavioral caveat and keyword omission behavior; the schema handles the four parameters fully and annotations cover safety. No output schema exists, but the description sufficiently indicates what kind of data is returned.
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 parameter documentation is already strong. The description adds value by specifying that omitting keyword returns up to 10 recently checked phrases and that providing it targets one phrase, going beyond the schema's 'short sample' wording.
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 resource and operation: 'Position history' for a phrase or up to 10 recently checked phrases. It clearly distinguishes the keyword-omitted behavior, though it does not explicitly differentiate itself from sibling tools like get_product_metrics.
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 usage rule for the keyword parameter: omit it for up to 10 recently checked phrases. However, it does not state when to choose this tool over alternatives or any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keywords from one Reverse ASIN report. Includes relevance (core or related) and search volume when MerchantWords has finished. Broader keywords are fetched the same way. Pass report_id from list_reverse_reports.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1 to 100. Default 50. | |
| cursor | No | Cursor from the previous page. Omit for the first page. | |
| report_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a safe, idempotent read. The description adds useful behavioral context beyond that: relevance values are core or related, search volume is only present once MerchantWords has finished, and broader keywords are fetched the same way.
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 short and front-loads the resource being returned. The sentence about broader keywords is slightly vague but does not waste much space.
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 keyword-listing tool with no output schema, the description covers what is returned, the async readiness condition, and how to obtain the required report_id. Pagination details are left to the schema, which is reasonable.
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 67%; limit and cursor are described in the schema, but report_id has no schema description. The description compensates by explaining that report_id comes from list_reverse_reports, adding meaningful sourcing information.
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 resource and scope: keywords from one Reverse ASIN report. It distinguishes itself from list_reverse_reports by pointing to report_id, but does not clarify how it differs from the sibling list_keywords tool.
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 tells the agent to pass report_id from list_reverse_reports, which implies a prerequisite flow. However, there is no explicit when-to-use or when-not-to-use guidance, and no comparison to list_keywords.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tracked search phrases for an ASIN, with the latest position, page, deltas, status, tag, and search volume when it has been fetched.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | Yes | Amazon ASIN, 10 letters or digits. | |
| limit | No | Page size, 1 to 100. Default 50. | |
| cursor | No | Cursor from the previous page. Omit for the first page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent read, so the description does not need to restate safety. It does add genuine context beyond the annotations: the exact field set returned and the conditional caveat that search volume is only present after it has been fetched, which prevents the agent misreading missing values as errors.
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?
One dense sentence with zero filler, front-loading what is listed and then qualifying it. Nothing is repeated from the name or 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?
With no output schema, the description correctly carries the return-value burden by naming the fields. Pagination is covered by the schema's cursor/limit docs. Only the ordering of results and what the status/tag values mean are left unspecified.
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% – asin, limit, and cursor are all documented in the schema, including the default page size and the 'omit for first page' cursor rule. The description adds no parameter-level meaning beyond confirming that results are scoped to an ASIN, so 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 states the resource (tracked search phrases for an ASIN) and enumerates the payload (latest position, page, deltas, status, tag, search volume), so the agent knows exactly what comes back. It does not, however, contrast itself with get_rank_history, the sibling most likely to be confused with it.
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?
No when-to-use or when-not-to-use guidance is given, and no alternative is named. The phrase 'when it has been fetched' hints that some fields may be null depending on data state, but that is not framed as a usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent listing changes for an ASIN: title, price, images, Buy Box, availability, bullets, and similar fields.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | Yes | Amazon ASIN, 10 letters or digits. | |
| limit | No | Page size, 1 to 100. Default 50. | |
| cursor | No | Cursor from the previous page. Omit for the first page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the returned field set, which is genuinely useful, but leaves the size of the 'recent' window, ordering of results, and whether unlimited history is available undisclosed.
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?
A single front-loaded clause with no filler; every item listed is informative. It is a sentence fragment without an explicit verb, which costs it the top mark but nothing is wasted.
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 must convey what a returned record looks like; it lists affected fields but does not say a change record carries timestamps, old/new values, or ordering. For a paginated read-only list tool with fully documented params, this is adequate but not complete.
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% — asin, limit and cursor are all documented with constraints, including the default page size. The description adds no syntax or format detail beyond that, so 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?
Names a specific resource (recent listing changes) scoped to an ASIN, and enumerates the fields inspected (title, price, images, Buy Box, availability, bullets). It does not distinguish itself from the near-identical sibling get_listing_change, so the singular/plural boundary is left to inference.
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?
No statement of when to use this versus get_listing_change, list_products, or get_product; no indication of how far back 'recent' reaches or how to page through history. The agent can infer this is a history lookup, but nothing is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns this account's tracked products, one page at a time: ASIN, monitoring, Buy Box, price, BSR, rating, reviews, and keyword counts. Read-only. Use get_product for a single ASIN.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1 to 100. Default 50. | |
| cursor | No | Cursor from the previous page. Omit for the first page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the description's 'Read-only' line adds little beyond confirming them. It does add useful pagination context ('one page at a time') and enumerates the returned fields, but does not mention rate limits, auth scope, or ordering.
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 tight sentences with no filler. The core purpose and returned fields come first, followed by the disambiguation 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?
With no output schema, the description helpfully names the fields returned (ASIN, monitoring, Buy Box, price, BSR, rating, reviews, keyword counts) and notes pagination. Annotations cover safety, and params are fully documented in the schema. Only minor details like item ordering or default page size are left to the 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 description coverage is 100%, so limit and cursor are already well documented. The description only implies pagination through 'one page at a time' and adds no format or constraint detail beyond 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 and resource (returns this account's tracked products), lists the fields returned, and distinguishes it from get_product for a single ASIN. An agent can immediately tell what it does and how it differs from the sibling.
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 routes single-ASIN lookups to get_product, giving a clear alternative. It does not cover other possible alternatives like list_keywords, but for the primary list-vs-get decision the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns this account's Reverse ASIN reports, one page at a time: report id, ASIN, country, status, keyword count, and total volume. An unfinished report is queued, not missing. Read-only. Pass report_id to get_reverse_report for the phrases.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1 to 100. Default 50. | |
| cursor | No | Cursor from the previous page. Omit for the first page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description does not need to repeat safety claims. It adds real behavioral context beyond the annotations: pagination behavior, what fields come back, and the important semantic that an unfinished report is 'queued, not missing' rather than absent.
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 tight sentences, front-loaded with purpose and return fields, followed by the queued-status caveat and the sibling routing hint. Every sentence 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?
With no output schema, the description compensates by listing the fields returned. It covers pagination, status semantics, safety, and where to go for details, leaving no material ambiguity for an agent calling this list tool.
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 limit and cursor are already fully documented with ranges, defaults, and cursor usage. The description reinforces pagination with 'one page at a time' but does not add syntax or semantics beyond the schema; 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?
States a specific verb and resource ('Returns this account's Reverse ASIN reports'), adds pagination scope, and enumerates the returned fields. It also explicitly distinguishes itself from the sibling get_reverse_report by directing agents there for phrases.
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 clearly implies this is the listing/discovery step and names get_reverse_report with the report_id handoff as the alternative for phrase-level detail. It lacks an explicit 'use this when... / do not use when...' statement, but the routing is unambiguous.
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.
get_accountget_listing_changeget_productget_product_metricsget_rank_historyget_reverse_reportlist_keywordslist_listing_changeslist_productslist_reverse_reports
Add one secure layer between your agents and this server.