Skip to main content
Glama
deenesjakoruzh
ludodelot

Amazon Product Research MCP Server

by ludodelot
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Servidor MCP de Productos de Amazon

Un servidor de Protocolo de Contexto de Modelo (MCP) que brinda a un asistente de IA (p. ej., Claude Code) herramientas para buscar e inspeccionar datos de productos de Amazon, a través de stdio.

Características

  • search_products — busca productos por palabra clave.

  • get_product — obtiene detalles completos de un solo producto por ID.

  • Escrito en TypeScript estricto, validado en tiempo de ejecución con Zod.

  • Probado con pruebas unitarias con Vitest.

  • Analizado con ESLint (typescript-eslint) y formateado con Prettier.

Related MCP server: Amazon Product Intelligence Agent

Estructura del proyecto

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

Requisitos

  • Node.js 20+

  • npm

Primeros pasos

npm install
npm run dev

Esto inicia el servidor a través de stdio usando tsx, listo para ser conectado por un cliente MCP.

Conexión desde Claude Code

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

Scripts

Comando

Descripción

npm run dev

Ejecuta el servidor directamente desde el código fuente de TypeScript.

npm run build

Verifica tipos y compila a dist/.

npm start

Ejecuta el servidor compilado desde dist/.

npm test

Ejecuta la suite de pruebas unitarias (Vitest).

npm run lint

Analiza el código con ESLint.

npm run format

Formatea el código con Prettier.

npm run format:check

Verifica el formato sin escribir cambios.

Referencia de herramientas

search_products

Busca productos de Amazon por palabra clave (coincide con el nombre del producto, sin distinguir mayúsculas de minúsculas).

Entrada

{ "query": "kindle" }

Salida

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

Obtiene detalles completos de un solo producto por su ID.

Entrada

{ "product_id": "kindle-paperwhite" }

Salida: un objeto Product, o null si ningún producto coincide.

Datos

Los datos de productos actualmente viven en un pequeño catálogo simulado en memoria (src/tools/product-data.ts) en lugar de una API de Amazon en vivo; esto mantiene el proyecto autocontenido y seguro de ejecutar sin credenciales. .env.example documenta las variables de entorno que necesitaría una integración real con la API.

Licencia

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