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) 서버로, stdio를 통해 AI 어시스턴트(예: Claude Code)에게 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