Skip to main content
Glama
Abomination81

Amazon Public Fetch MCP

amazon_product

Extracts ASIN, title, visible price, and feature bullets from a public Amazon product page URL to summarize product details for quick review.

Instructions

Fetch a public Amazon product page and return a small summary: ASIN, title, visible price text, and feature bullets. Same ladder as amazon_fetch.

Input Schema

NameRequiredDescriptionDefault
urlYes
max_engineNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It discloses that the page is public and that it fetches a summary, and hints at an engine fallback ladder via the sibling reference, but says nothing about anti-bot handling, timeouts, missing price/feature data, or failure modes.

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?

Two compact sentences with the outcome and returned fields front-loaded. The final sentence is terse and dependent on sibling context, but there is no filler.

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

Completeness3/5

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

An output schema exists, so return values need not be fully explained, and the description summarizes them anyway. However, with no annotations and 0% parameter coverage, leaving URL format and engine behavior underspecified makes the definition only minimally sufficient for correct invocation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, but it only implies that 'url' is a product page URL. The 'max_engine' parameter and its enum values are never explained in this tool's description; 'Same ladder as amazon_fetch' forces the agent to consult another tool to understand it.

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?

States a specific verb ('Fetch') and resource ('public Amazon product page') and lists the exact summary fields returned (ASIN, title, price text, feature bullets). It implicitly differentiates from the sibling amazon_fetch by being product-specific and summary-oriented, though it never explicitly says how the two differ.

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

Usage Guidelines2/5

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

The only guidance is 'Same ladder as amazon_fetch,' which does not explain when to choose this tool over amazon_fetch or health. There is no explicit when-to-use, when-not-to-use, or prerequisite information; the agent must infer that this is for product pages.

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

Deploy Server

Other Tools