Skip to main content
Glama
deenesjakoruzh
ludodelot

Amazon Product Research MCP Server

by ludodelot
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Local

Amazon Product Research MCP Server

A Model Context Protocol (MCP) server that gives an AI assistant (e.g. Claude Code) tools to search and inspect Amazon product data, over stdio.

Features

  • search_products — search products by keyword.

  • get_product — fetch full details for a single product by ID.

  • Written in strict TypeScript, validated at runtime with Zod.

  • Unit tested with Vitest.

  • Linted with ESLint (typescript-eslint) and formatted with Prettier.

Related MCP server: Amazon Product Intelligence Agent

Project structure

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

Requirements

  • Node.js 20+

  • npm

Getting started

npm install
npm run dev

This starts the server over stdio using tsx, ready to be connected to by an MCP client.

Connecting from Claude Code

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

Scripts

Command

Description

npm run dev

Run the server directly from TypeScript source.

npm run build

Type-check and compile to dist/.

npm start

Run the compiled server from dist/.

npm test

Run the unit test suite (Vitest).

npm run lint

Lint the codebase with ESLint.

npm run format

Format the codebase with Prettier.

npm run format:check

Check formatting without writing changes.

Tools reference

search_products

Search Amazon products by keyword (matches against the product name, case-insensitive).

Input

{ "query": "kindle" }

Output

[
  {
    "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

Get full details for a single product by its ID.

Input

{ "product_id": "kindle-paperwhite" }

Output: a single Product object, or null if no product matches.

Data

Product data currently lives in a small in-memory mock catalog (src/tools/product-data.ts) rather than a live Amazon API — this keeps the project self-contained and safe to run without any credentials. .env.example documents the environment variables a real API integration would need.

License

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
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.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

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • MCP4Amazon

    Jeremy-33456
    F
    license
    Not graded
    quality
    C
    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
    B
    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
    230
    7
    MIT

  • amazon-mcp

    coaxon
    A
    license
    Not graded
    quality
    C
    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