Skip to main content
Glama
deenesjakoruzh
ludodelot

Amazon Product Research MCP Server

by ludodelot
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Amazon Product Research MCP Server

Ein Model Context Protocol (MCP)-Server, der einem KI-Assistenten (z. B. Claude Code) Werkzeuge zum Suchen und Untersuchen von Amazon-Produktdaten über stdio bereitstellt.

Funktionen

  • search_products — durchsucht Produkte nach Schlüsselwort.

  • get_product — ruft vollständige Details für ein einzelnes Produkt anhand der ID ab.

  • Geschrieben in striktem TypeScript, zur Laufzeit mit Zod validiert.

  • Mit Vitest auf Unit-Ebene getestet.

  • Mit ESLint (typescript-eslint) gelintet und mit Prettier formatiert.

Related MCP server: Amazon Product Intelligence Agent

Projektstruktur

src/
├── index.ts              # Entry point: wires the server to a stdio transport
├── server.ts              # Registers MCP tools on the McpServer instance
├── types/
│   └── product.ts         # Shared Product type
└── tools/
    ├── product-data.ts     # In-memory product catalog (mock data)
    ├── search-products.ts  # search_products tool: input schema + handler
    └── get-product.ts      # get_product tool: input schema + handler
tests/
├── search-products.test.ts
└── get-product.test.ts

Voraussetzungen

  • Node.js 20+

  • npm

Erste Schritte

npm install
npm run dev

Dies startet den Server über stdio mit tsx, bereit, von einem MCP-Client verbunden zu werden.

Verbindung von Claude Code aus

claude mcp add amazon-research -- npx tsx /absolute/path/to/amazon-product-research-mcp/src/index.ts

Skripte

Befehl

Beschreibung

npm run dev

Server direkt aus dem TypeScript-Quellcode ausführen.

npm run build

Typen prüfen und nach dist/ kompilieren.

npm start

Den kompilierten Server aus dist/ ausführen.

npm test

Die Unit-Test-Suite (Vitest) ausführen.

npm run lint

Den Codebase mit ESLint linten.

npm run format

Den Codebase mit Prettier formatieren.

npm run format:check

Formatierung prüfen, ohne Änderungen zu schreiben.

Werkzeugreferenz

search_products

Durchsucht Amazon-Produkte nach Schlüsselwort (Übereinstimmung mit dem Produktnamen, ohne Beachtung der Groß-/Kleinschreibung).

Eingabe

{ "query": "kindle" }

Ausgabe

[
  {
    "id": "kindle-paperwhite",
    "name": "Kindle Paperwhite",
    "price": 169.99,
    "currency": "USD",
    "rating": 4.7,
    "reviewCount": 12543,
    "description": "A high-resolution e-reader designed for reading comfortably indoors and outdoors."
  }
]

get_product

Ruft vollständige Details für ein einzelnes Produkt anhand seiner ID ab.

Eingabe

{ "product_id": "kindle-paperwhite" }

Ausgabe: ein einzelnes Product-Objekt oder null, wenn kein Produkt übereinstimmt.

Daten

Produktdaten befinden sich derzeit in einem kleinen In-Memory-Mock-Katalog (src/tools/product-data.ts) und nicht in einer Live-Amazon-API — das hält das Projekt eigenständig und sicher ausführbar, ohne dass Zugangsdaten erforderlich sind. .env.example dokumentiert die Umgebungsvariablen, die eine echte API-Integration benötigen würde.

Lizenz

MIT © Ludovic Delot Bravo

Available Tools

2 tools
get_productC

Get detailed information about an Amazon product.

ParametersJSON Schema
NameRequiredDescriptionDefault
product_idYesThe unique ID of the product.

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'detailed information,' without clarifying read-only behavior, output format, error handling, authentication needs, or whether the product data may be stale or partial.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to stating the tool's basic purpose, and it is appropriately sized for the tool's simplicity.

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

Completeness2/5

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

The tool is simple with only one parameter, but there is no output schema and no annotations. The phrase 'detailed information' is vague and does not tell an agent what fields or behaviors to expect, leaving an important gap for a tool that should return a product's data.

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?

The input schema fully documents product_id with a clear description, so high schema coverage earns the baseline score. The tool description adds only the Amazon context and does not contribute additional parameter meaning beyond the schema.

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 description clearly states a specific verb ('Get') and resource ('Amazon product'), making the core action obvious. It implies single-item retrieval versus the sibling's search-oriented behavior, but does not explicitly differentiate by naming the alternative.

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?

No usage guidance is provided. The description does not say when to use this tool versus search_products, nor does it mention prerequisites such as needing a known product_id or when search should be used first.

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

search_productsB

Search Amazon products by keyword.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe product or keyword to search for.

TDQS

B3/5.0
Behavior1/5

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

With no annotations provided, the description carries full responsibility for behavioral transparency. It discloses nothing about side effects, return format, pagination, rate limits, authentication requirements, or limitations. The word 'search' only indicates the operation type, not behavioral traits. This is a severe gap for a tool that may produce complex results.

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

Conciseness5/5

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

The description is a single, compact sentence that conveys the core purpose without filler words. It is front-loaded with the action and resource, and every word earns its place. There is no redundancy or unnecessary detail.

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

Completeness2/5

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

The tool has low complexity (one parameter, no output schema, no annotations), but the description is still incomplete. It does not mention what the search returns (e.g., product list, match scores), any sorting/filtering options, or constraints like pagination limits. Given no output schema, the description should at least hint at the expected result shape or scope, but it does not.

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?

The schema provides 100% coverage for the single 'query' parameter with a clear description ('The product or keyword to search for'). The tool description's phrase 'by keyword' effectively mirrors the schema's parameter semantics, adding no new meaning. Since schema coverage is high, the baseline of 3 applies.

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?

The description clearly states the tool searches Amazon products by keyword. The verb 'search' and resource 'Amazon products' are specific, and the scope is defined as 'by keyword', distinguishing it from the sibling tool 'get_product' which likely retrieves a single product by ID. This is a clear purpose statement.

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?

No guidance is given on when to use this tool versus alternatives. It does not mention situations where 'get_product' would be more appropriate, nor does it describe any exclusions or prerequisites. The description simply states the action without contextual usage instructions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedget_product
    • First observedsearch_products
Deploy Server
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

TDQS

B3.3/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are clearly distinct: search_products finds products by keyword, while get_product retrieves detailed information for a specific product. No overlap or ambiguity exists between them.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern using snake_case (search_products, get_product), making the naming predictable and easily understandable.

Tool Count3/5

With only 2 tools, the set feels thin for a product research server. While it covers the basic search-and-detail flow, it lacks breadth seen in more comprehensive servers, but it is not extreme enough to be a 1 or 2.

Completeness3/5

The tool surface provides the minimum necessary for product research—searching and retrieving details—but notably lacks capabilities like browsing categories, accessing reviews, or comparing products, which are expected in a full research context.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP4Amazon

    Jeremy-33456
    F
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that enables large language models to directly access and analyze Amazon product information, including product details, variants, and reviews.
    -
  • Scavio by scavio-ai

    Scavioofficial

    scavio-ai
    A
    license
    A
    quality
    A
    maintenance
    An MCP server connecting AI agents to Google, YouTube, Amazon, Walmart, TikTok, and Reddit. 21 tools for web search, product lookup, video discovery, and social media analysis.
    21
    2,228 npm
    8
    MIT

  • amazon-mcp

    coaxon
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for Amazon Selling Partner API and Advertising API, enabling access to orders, inventory, pricing, ads, and reports via natural language.
    1
    MIT