Allows querying orders, sales summaries, FBA inventory, and financial events from Amazon Seller Central via the Selling Partner API.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Amazon Seller MCP List my orders from the past 12 hours"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP que conecta Claude con tu cuenta de Amazon Seller Central vía la Selling Partner API (SP-API). Permite consultar pedidos, resumen de ventas, inventario FBA y eventos financieros bajo demanda.
Herramienta | Qué hace |
| Pedidos de las últimas N horas |
| Ventas agregadas (importe, pedidos, unidades) |
| Niveles de stock FBA por SKU |
| Liquidaciones, comisiones y fees recientes |
Related MCP server: Amazon SP-API MCP Server
uvx)Requisito único: tener uv instalado
(curl -LsSf https://astral.sh/uv/install.sh | sh). uv descarga Python y las
dependencias automáticamente — no hay que crear entornos ni instalar nada más.
Registra el conector en Claude (Code o Cowork) con un solo comando:
claude mcp add amazon-seller \
--env SPAPI_REFRESH_TOKEN=TU_REFRESH_TOKEN \
--env SPAPI_LWA_APP_ID=TU_APP_ID \
--env SPAPI_LWA_CLIENT_SECRET=TU_CLIENT_SECRET \
--env SPAPI_MARKETPLACE=ES \
-- uvx --from git+https://github.com/USUARIO/amazon-seller-mcp amazon-seller(Sustituye USUARIO por tu usuario de GitHub y rellena tus credenciales.)
Reinicia Claude y pregúntame, por ejemplo:
"¿Cuántas ventas llevo hoy?"
"Dame los pedidos de las últimas 6 horas"
Seller Central → Settings → User Permissions → Develop apps for your account.
Crea una aplicación y solicita los roles: Orders, Inventory, Finance y Selling Partner Insights / Sales.
Tras la aprobación obtendrás LWA client_id y LWA client_secret.
Autoriza la app sobre tu propia cuenta (self-authorization) para generar el refresh token.
Desde 2024 la SP-API ya no requiere claves AWS IAM ni firma SigV4: basta con las credenciales LWA.
Las mismas credenciales valen para todos tus ordenadores. Se pasan como variables de entorno en la config de Claude (ver arriba); nunca van dentro del repositorio.
uv run amazon-seller # arranca el servidor por stdioPara pruebas locales puedes poner las credenciales en un .env (gitignored);
en producción se pasan como --env en la config de Claude.
La SP-API es pull, no streaming: consulto la API en el momento que preguntas. Amazon aplica throttling, evita consultas en bucle.
El refresh_token da acceso continuo a tu cuenta; trátalo como una contraseña.
inventario puede devolver 403 si la cuenta no tiene habilitada la API de
inventario FBA; el resto de herramientas funcionan con credenciales LWA.
Eventos financieros recientes (liquidaciones, comisiones, fees).
Args: dias: ventana hacia atrás en días (default 7). max_eventos: máximo de grupos de eventos (default 30).
| Name | Required | Description | Default |
|---|---|---|---|
| dias | No | ||
| max_eventos | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits (e.g., read-only, authentication needs). It only states the basic function, missing details about side effects, rate limits, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient two-sentence description with an Args list. No superfluous text, front-loaded with purpose, and clearly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple retrieval tool with well-documented parameters, but missing output description and usage context given no annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by explaining both parameters (dias as backward window, max_eventos as max groups) with defaults. Adds value beyond the schema which only has names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves recent financial events (liquidaciones, comisiones, fees), providing a specific verb and resource. It distinguishes from sibling tools like inventory and sales summary, though does not explicitly contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings or when not to use it. Lacks context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Niveles de inventario FBA por SKU en el marketplace actual.
Args: max_items: máximo de SKUs a devolver (default 50).
| Name | Required | Description | Default |
|---|---|---|---|
| max_items | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it returns inventory levels and mentions a max_items parameter (default 50), but does not describe side effects, read-only nature, authentication needs, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for the purpose and one line for the parameter. No redundant words, efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, no output schema, no nested objects), the description covers the essential purpose and parameter. It could briefly mention the return format (e.g., list of SKU numbers with levels) but is largely sufficient for an agent to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly explains the only parameter 'max_items' as 'máximo de SKUs a devolver (default 50)'. Since the input schema has 0% description coverage, the description fully compensates by adding clear meaning beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Niveles de inventario FBA por SKU en el marketplace actual' clearly states the verb ('provides'), resource ('inventory levels'), and scope ('by SKU in the current marketplace'). It is distinct from siblings like 'pedidos_recientes' (recent orders) and 'resumen_ventas' (sales summary).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the purpose (checking current inventory levels), but no explicit when-to-use or alternatives are given. The sibling names provide context but the description itself offers no comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista los pedidos de las últimas N horas.
Args: horas: ventana hacia atrás en horas (default 24). max_pedidos: máximo de pedidos a devolver (default 50).
| Name | Required | Description | Default |
|---|---|---|---|
| horas | No | ||
| max_pedidos | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Lista' implies a read-only operation, and no destructive behavior is indicated. However, without annotations, the description does not explicitly state that the tool does not modify data, but the intent is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only three short lines to convey purpose and parameter details. No unnecessary words are present, and the docstring format is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being concise, the description lacks information about the output format (fields in each order), ordering, or pagination. With no output schema, more detail on return structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully explains both parameters: 'horas' as a backward window in hours (default 24) and 'max_pedidos' as maximum orders to return (default 50). Since the input schema has 0% description coverage, the description compensates completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lista los pedidos de las últimas N horas' (lists orders of the last N hours), specifying a verb and resource with a time window. It distinguishes from siblings like 'inventario' (inventory) and 'resumen_ventas' (sales summary) by focusing on recent orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or scenarios where sibling tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resumen agregado de ventas (importe, pedidos, unidades) por periodo.
Args: dias: número de días hacia atrás a incluir (default 1 = hoy). granularidad: Hour, Day, Week, Month, Year (default Day).
| Name | Required | Description | Default |
|---|---|---|---|
| dias | No | ||
| granularidad | No | Day |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It implies a read-only operation by describing a summary, but does not explicitly state behavioral traits like side effects, idempotency, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one-line summary plus two parameter descriptions. No redundant information, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (2 optional parameters, no output schema), the description covers parameters well. Missing details on output structure or exact value formatting, but sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains both parameters (dias and granularidad) with clear meaning, defaults, and allowed values for granularidad, fully compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides an aggregated sales summary by period, covering importe, pedidos, unidades. This is distinct from sibling tools like eventos_financieros (financial events) and pedidos_recientes (recent orders).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for sales summaries but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0eventos_financierosinventariopedidos_recientesresumen_ventasScored across 4 tools
Each tool covers a distinct domain area—financial events, inventory, orders, and sales summary—with no functional overlap. An agent can clearly distinguish which tool to use for each query type.
All tool names follow a consistent snake_case pattern using descriptive Spanish nouns or noun phrases (eventos_financieros, inventario, pedidos_recientes, resumen_ventas). The naming convention is uniform and predictable.
With 4 tools, the server is minimal but well-scoped for core Amazon seller operations (financials, inventory, orders, sales). It could benefit from additional tools (e.g., for returns or product data), but the current count is reasonable for a focused tool set.
The tool set covers essential financial, inventory, order, and sales summary functions, but lacks support for product management, advertising, or performance metrics. This leaves notable gaps for a comprehensive seller management server.
Connect Amazon Seller Central to Claude or ChatGPT via MCP. Orders, inventory, pricing, fees, FBA.
Amazon brand, seller, niche & buy-box intelligence inside your own Claude or ChatGPT.
Hosted Amazon Seller Central and Amazon Ads MCP server for Claude, ChatGPT, Cursor, and agents.
AMZScout Skill + MCP gives AI agents live access to real Amazon marketplace data across 14 Amazon marketplaces. Analyze any ASIN, validate product ideas, research niches, compare competitors, discover profitable keywords, and build data-driven PPC strategies using trusted Amazon insights instead of AI assumptions. Works with Claude, ChatGPT, Cursor, and any other MCP-compatible AI client. To connect, you'll need an AMZScout API plan and authorize your account. Get access and view pricing here: https://learn.amzscout.net/amazon-product-api-for-ai-agents
