Skip to main content
Glama
deenesjakoruzh
ludodelot

Amazon Product Research MCP Server

by ludodelot
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Amazon Product Research MCP Server

Model Context Protocol (MCP) サーバーです。 AI アシスタント（例: Claude Code）に、stdio 経由で Amazon の商品データを検索・調査するツールを提供します。

特徴

  • search_products — キーワードで商品を検索します。

  • get_product — ID で単一の商品の詳細情報を取得します。

  • 厳格な TypeScript で記述され、Zod で実行時に検証されます。

  • Vitest でユニットテストされています。

  • ESLint（typescript-eslint）でリントされ、Prettier でフォーマットされています。

Related MCP server: Amazon Product Intelligence Agent

プロジェクト構造

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

必要条件

  • Node.js 20+

  • npm

はじめに

npm install
npm run dev

これにより、tsx を使用してサーバーが stdio 経由で起動し、MCP クライアントから接続できる状態になります。

Claude Code から接続する

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

スクリプト

コマンド

説明

npm run dev

TypeScript ソースから直接サーバーを実行します。

npm run build

型チェックを行い、dist/ にコンパイルします。

npm start

コンパイル済みサーバーを dist/ から実行します。

npm test

ユニットテストスイート（Vitest）を実行します。

npm run lint

ESLint でコードベースをリントします。

npm run format

Prettier でコードベースをフォーマットします。

npm run format:check

書き込みを行わずにフォーマットをチェックします。

ツールリファレンス

search_products

キーワードで Amazon の商品を検索します（商品名に対して大文字小文字を区別せずにマッチします）。

入力

{ "query": "kindle" }

出力

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

ID で単一の商品の詳細情報を取得します。

入力

{ "product_id": "kindle-paperwhite" }

出力: 単一の Product オブジェクト、または一致する商品がない場合は null。

データ

商品データは現在、ライブの Amazon API ではなく、小さなインメモリのモックカタログ（src/tools/product-data.ts）に格納されています。これにより、プロジェクトは自己完結型で、認証情報なしで安全に実行できます。.env.example には、実際の API 統合に必要な環境変数が記載されています。

ライセンス

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