Wildberries MCP Server

Servidor MCP de WB

Gestiona tus tiendas de Wildberries desde un chat con un asistente de IA. 197 herramientas que cubren la API de Vendedor de Wildberries — tarjetas de producto, precios, anuncios, envíos, reseñas, finanzas, analítica — expuestas a Claude, Cursor, Copilot, Gemini CLI y cualquier otro cliente MCP. Diseñado para vendedores de WB (Wildberries es el marketplace más grande de Rusia) que gestionan una o varias cuentas de vendedor y prefieren hacer una pregunta en lugar de navegar por el portal del vendedor.

¿Vendes también en Ozon? Existe el mismo servidor para Ozon.

El servidor lleva en uso diario más de cinco meses en unas veinte cuentas de vendedor de WB, con 197 herramientas. Es la herramienta de trabajo del propio autor y se actualiza según sus necesidades — detalles aquí.

You: Which of my product cards are blocked, and why?
You: Show ad cost share for every campaign this week and pause the ones above 15%.
You: Which warehouses currently have an intake coefficient of 0 or 1?
You: Reply to every new 5-star review with a thank-you note.

Qué puede hacer

197 herramientas, agrupadas por área de la API de Vendedor de Wildberries. La lista numerada completa con la descripción de cada una está en docs/tools.md.

Tres cosas que los servidores similares normalmente no tienen:

• Multi-tienda. Cada llamada toma un shop_id, así que dos cuentas de vendedor de WB conviven en una sola conversación. Con una sola tienda puedes omitir shop_id por completo.
• Diagnósticos de la API de WB. El servidor hace ping a los hosts de WB por sí mismo, envía una solicitud de prueba económica por categoría de API, decodifica la caducidad y los alcances del token, y resalta "degradaciones": una herramienta que solía funcionar y ahora falla de manera consistente — una señal fiable de que WB ha cambiado la API.
• Tokens cifrados. Los tokens de WB se almacenan cifrados (Fernet), no en la configuración de tu cliente.

Inicio rápido

Opción 1: un comando, sin Docker

El servidor habla stdio, que es como Claude Desktop, Cursor, VS Code y otros clientes MCP se conectan a él. Nada que construir:

uvx wb-mcp-server

O mediante pip:

pip install wb-mcp-server
wb-mcp

Configuración del cliente (por ejemplo, claude_desktop_config.json):

{
  "mcpServers": {
    "wildberries": {
      "command": "uvx",
      "args": ["wb-mcp-server"],
      "env": {
        "WB_API_TOKEN": "your Wildberries API token",
        "DATA_DIR": "~/.wb-mcp"
      }
    }
  }
}

Apunta DATA_DIR a cualquier directorio con permisos de escritura — contiene tiendas, claves y estadísticas. El valor predeterminado es /data, que es la ruta utilizada dentro de Docker.

Opción 2: Docker con el panel web

Usa esto si quieres el panel, los diagnósticos de la API de WB y la gestión de tiendas basada en navegador. Necesitas Docker (Docker Desktop u OrbStack) y un token de la API de Vendedor de Wildberries.

git clone https://github.com/DeviceIngineering/wb-mcp-server.git
cd wb-mcp-server
cp .env.example .env          # fine as-is for a local run
docker compose up -d --build

Comprueba:

curl -s http://localhost:8001/api/health
# {"status":"ok","auth_enabled":false,"health_check_interval_min":30,...}

Lo que ahora tienes:

Siguiente:

1. Abre http://localhost:8001/shops → Добавить магазин (Añadir tienda) → pega el token de WB → Проверить (Probar). El token proviene del Portal del Vendedor de WB (seller.wildberries.ru): Настройки → Доступ к API → Создать токен (Configuración → Acceso a la API → Crear token). Es válido durante 180 días; la vida útil restante se muestra en la página de diagnósticos.
2. Conecta un cliente MCP — consulta la siguiente sección.
3. Pregunta a tu asistente: "lista mis tiendas de Wildberries" — la herramienta wb_list_shops debería activarse.

El comando de inicio, bandera por bandera:

Detenlo con docker compose down (los datos permanecen en el volumen wb_data). Registros: docker compose logs -f.

git clone https://github.com/DeviceIngineering/wb-mcp-server.git
cd wb-mcp-server
python3 -m venv .venv && source .venv/bin/activate
pip install .
DATA_DIR=./data PORT=8001 python -m wb_mcp.app

Instalación en clientes

El servidor habla MCP sobre SSE: GET /sse es el flujo de eventos, POST /messages transporta los mensajes del cliente. El soporte de SSE varía de un cliente a otro, así que cada uno tiene su propia guía — con rutas de configuración para macOS, Linux y Windows, JSON listo para pegar, y variantes con y sin token de autenticación.

Las guías por cliente en docs/ están actualmente solo en ruso. La configuración en ellas es JSON listo con rutas de archivo y banderas, que es legible independientemente del idioma.

Resumen y tabla de compatibilidad: docs/README.md.

Cuando un cliente tiene un comando que configura la conexión por sí mismo, la guía comienza con ese comando y trata la edición de JSON como segunda opción. La configuración más corta de todas — Claude Code:

claude mcp add --transport sse wildberries http://localhost:8001/sse
claude mcp list      # expected: wildberries ... ✔ Connected

Multi-tienda y seguridad

Varias cuentas de vendedor. Las tiendas se añaden en /shops; cada una recibe su propio shop_id. wb_list_shops devuelve la lista, y 200 de las 197 herramientas toman shop_id como su primer parámetro (las excepciones son wb_list_shops y wb_degradations). Con una sola tienda, el parámetro puede omitirse — el servidor sustituye la única disponible.

El punto no es "admite dos cuentas", sino que una estrategia se escribe una vez y se despliega en cada cuenta: una regla de precios, una plantilla de respuesta a reseñas, un límite de puja publicitaria se aplican a todas las tiendas dentro de una conversación — sin cambiar de cuenta, sin dispersar claves de API en las configuraciones de diferentes clientes.

Cuántas cuentas puedes conectar. No hay límite en el código: shops.json es un diccionario simple, añade tantas como quieras. El techo lo pone Wildberries, no este servidor: todas las cuentas llegan a WB desde una única dirección IP — la que ejecuta este servidor — y los límites de tasa se cuentan también por dirección. La estimación del propio autor: unas veinte cuentas por dirección permanecen en la zona segura. Más allá de eso, divídelas entre varios servidores con diferentes direcciones.

Por qué esto importa más de lo que parece — consulta los límites de WB: varios métodos permiten 3 solicitudes por minuto, y cualquier respuesta 4XX cuenta como 10 solicitudes. Con una docena de cuentas en un servidor, un puñado de solicitudes mal formadas seguidas quema la cuota diez veces más rápido — y cada tienda choca contra el muro a la vez, no solo la que cometió el error.

Hay formas de vigilarlo:

• Diagnósticos en segundo plano envían un /ping por host por ejecución (el límite es 3 solicitudes por 30 segundos por host) y registran comprobaciones fallidas y advertencias en un historial. Ves el límite acercándose con antelación, en lugar de enterarte por un bloqueo.
• El detector de degradaciones distingue dos casos: muchas herramientas degradándose a la vez significa limitación por dirección, mientras que una sola herramienta degradándose significa que un endpoint de WB se rompió. El panel hace la diferencia obvia de un vistazo.

Dónde viven los tokens. En el volumen wb_data (/data dentro del contenedor):

• shops.json — tiendas, con tokens cifrados usando Fernet;
• .encryption_key — la clave de cifrado, generada en el primer inicio;
• stats.db — SQLite con estadísticas de llamadas e historial de diagnósticos.

La clave está junto a los datos cifrados, así que el cifrado protege contra una fuga accidental del único archivo shops.json (una copia de seguridad, un copiar-pegar), pero no contra cualquiera que obtenga acceso a todo el volumen. Mueve los datos como un volumen completo — consulta DEPLOY.md.

Autorización MCP. La variable MCP_AUTH_TOKEN en .env:

openssl rand -hex 32   # put the value into .env → MCP_AUTH_TOKEN=
docker compose up -d

• vacía (el valor predeterminado) — /sse está abierto a cualquiera con acceso de red al puerto;
• establecida — el cliente debe enviar Authorization: Bearer <token> o ?token=<token> en la URL. La segunda forma rescata a clientes que no pueden enviar cabeceras personalizadas.

El token se comprueba en ambos endpoints MCP — en GET /sse y en POST /messages.

Lo que el servidor no hace:

• La interfaz web (/, /shops, /diagnostics) no está protegida por el token — está abierta a cualquiera con acceso de red al puerto.
• El puerto 8001 no está pensado para exponerse a internet. Para acceso remoto usa Tailscale o una VPN.
• El servidor no termina HTTPS. Si necesitas TLS desde fuera, pon un proxy inverso delante.

La interfaz web: cada llamada es visible

Con un servidor MCP típico, las llamadas se desvanecen en el aire: no puedes ver qué hizo realmente el asistente, cuánto tardó o qué respondió el marketplace, y te enteras de un problema solo cuando algo falla. Aquí cada llamada tiene un registro y cada tienda tiene un estado. Para una herramienta que mueve dinero real en una tienda real, esto es una condición previa para la confianza, no un adorno. Cinco meses de uso diario en unas veinte cuentas es precisamente lo que llenó estas páginas — y produjo la sección de límites de WB más abajo.

Panel de control — /

La captura de pantalla está en la parte superior de esta página.

Un resumen de todas las llamadas a herramientas (stats.get_summary()):

• total de llamadas, llamadas de hoy, número de errores, duración media de las llamadas;
• top 10 de herramientas: recuento de llamadas, tiempo medio, recuento de errores;
• un feed de las últimas 50 llamadas: marca de tiempo, tienda, herramienta, duración en milisegundos, éxito o fallo, texto del error;
• un filtro por tienda — un interruptor "Todas / cuenta específica" sobre el resumen.

Tiendas — /shops

Las cuentas se añaden y eliminan directamente en el navegador, sin editar archivos ni reiniciar el contenedor. Cada tienda tiene un botón Проверить ("Probar"): realiza una solicitud real barata a WB y te dice inmediatamente si el token está vivo — en lugar de dejarte descubrirlo durante la primera llamada real. Los tokens se muestran enmascarados en la lista (abc***xyz).

Los tokens se cifran con Fernet y se almacenan en shops.json dentro del volumen de datos; la clave está en .encryption_key junto a él. El grupo de clientes HTTP se restablece cuando se guarda o elimina una tienda, por lo que un nuevo token surte efecto de inmediato.

Diagnóstico — /diagnostics

(la captura de pantalla muestra una tienda de demostración con un token inventado: WB responde 401 a cada ping y a cada sonda, por lo que toda la página está en rojo. Así es como se ve una comprobación fallida — el servidor en sí está bien. Con un token que funciona, la línea "Проверка …" dice ping 13/13, пробы 20/20 y el estado de la tienda es "✅ Здоров").

Una comprobación en segundo plano cada HEALTH_CHECK_INTERVAL_MIN minutos (30 por defecto), por tienda:

• el token — caducidad, categorías de acceso, indicadores de solo lectura y sandbox;
• pings a 13 hosts de la API de WB — disponibilidad y latencia de cada uno;
• 20 sondas — una solicitud GET real barata por categoría de API. Estas son las que detectan "el endpoint devuelve 404 porque WB lo renombró";
• avisos en lenguaje sencillo: "el token caduca en N días", "Contenido: 404 en /content/v2/... — WB puede haber cambiado la API";
• historial de comprobaciones con rotación automática (se conservan los últimos 1000 registros);
• un botón "comprobar ahora" para ejecutar todo de inmediato.

El detector de degradación

Lo más útil que te dan las estadísticas acumuladas. El servidor encuentra, por sí mismo, herramientas que funcionaban y ahora fallan de forma constante: las últimas tres llamadas fallaron mientras que existen llamadas exitosas en el historial. Para cada una de estas herramientas muestra la hora de la última llamada exitosa, el número de errores consecutivos, el texto del último error y el momento en que las cosas se rompieron.

En otras palabras, el servidor detecta a partir de sus propias estadísticas que Wildberries rompió o desactivó un endpoint — y te lo dice antes de que te lo encuentres en el trabajo. Junto a la sección sobre límites y fechas de cierre de endpoints esta es su continuación práctica: esa sección enumera lo que WB anunció, esta detecta lo que WB hizo en silencio.

Puedes verlo en el panel de control, o llamar a wb_degradations directamente desde el chat.

JSON para monitorización externa

Todo lo que es visible para un humano también es legible por una máquina:

Así que el servidor se puede conectar a Uptime Kuma, Zabbix o cualquier otro sistema de monitorización, y te enteras de un token muerto antes de que el asistente te lo diga.

Presupuesto de contexto

Dos cosas se pagan en tokens: las definiciones de herramientas, que se cargan una vez por sesión, y las respuestas de las herramientas, que se pagan en cada llamada. Ambas se midieron en una cuenta de vendedor real en lugar de estimarse — scripts/collect_corpus.py toma una instantánea de las herramientas de solo lectura (los datos personales se enmascaran antes de escribir nada en el disco, el corpus se mantiene fuera del repositorio), scripts/measure_corpus.py informa de lo que cuesta.

Definiciones. 197 herramientas cuestan 17 700 tokens con una sola tienda configurada, frente a los 27 460. Las descripciones son de una frase cada una, shop_id se elimina de los esquemas cuando solo existe una tienda (el servidor lo rellena), y los campos de esquema vacíos no se serializan.

Respuestas. El problema real resultó ser un puñado de cargas útiles gigantes:

Lo que hace el servidor al respecto:

• view: compact | full. Las herramientas pesadas devuelven los campos para los que se les llama; view="full" da la respuesta cruda de la API. Qué campos se ocultaron se indica en la propia respuesta, para que el modelo sepa qué puede pedir.
• Señal de truncamiento. Cuando vuelven exactamente limit registros, la respuesta lleva un aviso de que los datos son parciales. Sin él, el modelo razona sobre un fragmento y lo presenta como el catálogo completo.
• Protección de tamaño. Una respuesta que no quepa en el límite de salida del cliente (MAX_MCP_OUTPUT_TOKENS, 25 000 por defecto en Claude Code) se corta en el servidor, indicando cuántos registros se omiten de cuántos — en lugar de truncarse silenciosamente al llegar.
• Filtros en el servidor donde la API no los tiene. WB devuelve la referencia de comisiones completa; el parámetro subject la reduce aquí.

Las notas llegan como bloques de contenido separados en lugar de un campo dentro del JSON: la mitad de los endpoints de WB devuelven un array en el nivel superior, y envolverlo rompería todas las rutas hacia los datos.

Perfiles de herramientas. Un cliente sin búsqueda de herramientas paga por todo el catálogo en cada solicitud. WB_TOOLSETS conserva solo los perfiles que usas — se recortan según tareas de trabajo, no según secciones de la documentación de WB, porque auditar promociones necesita promociones, precios y la cuarentena de precios a la vez:

El perfil core — tiendas, diagnóstico, degradaciones, información de tokens — está siempre activo: el diagnóstico se necesita exactamente cuando algo está roto. Los perfiles desactivados se enumeran en la descripción de wb_list_shops, y llamar a una herramienta desactivada responde qué perfil la contiene — así el asistente nombra la razón en lugar de decir "esto no es posible".

Claude Code no necesita nada de esto: tiene la búsqueda de herramientas activada por defecto y carga los esquemas bajo demanda. Cursor, Cline, Continue y Claude Desktop obtienen tools/list completo — los perfiles son para ellos.

Decisiones de diseño

• 202 herramientas específicas, no unas pocas genéricas. Colapsarlas en endpoints de estilo action ahorraría tokens de definición y cambiaría la clase de fallo: en lugar de "no existe tal herramienta" obtienes una llamada incorrecta con un efecto secundario, y algunas de estas herramientas fijan precios e inician campañas publicitarias.
• Despacho mediante diccionarios, no una cadena de if. NO_CLIENT_DISPATCH, CLIENT_DISPATCH y SHOP_DISPATCH asignan nombres a manejadores, y una prueba verifica que cada herramienta tiene uno y que ningún manejador está huérfano. Con 197 herramientas, una cadena de if se pudre silenciosamente.
• El servidor se diagnostica a sí mismo. wb_diagnostics hace ping a cada host de WB y ejecuta una solicitud real ligera por categoría de API; wb_degradations informa qué herramientas funcionaban y ahora fallan de forma constante. Las APIs del marketplace cambian sin aviso — la pregunta "¿es mi token o WB movió el endpoint?" tiene que poder responderse en una sola llamada.
• compact es el valor por defecto para herramientas pesadas. El corpus mostró que los campos ocultos son URLs de fotos, historial de promociones y horarios de almacén — no los datos con los que se toman decisiones. La respuesta dice qué se ocultó, así que nada se pierde en silencio.
• shop_id desaparece de los esquemas con una sola tienda. El mismo bloque de parámetros repetido en 200 esquemas costaba 3 400 tokens por sesión sin aportar información; el servidor sustituye la única tienda y vuelve a poner el parámetro en cuanto aparece una segunda.
• mcp<2 está fijado deliberadamente. La API de bajo nivel 2.0 elimina los manejadores decoradores sobre los que se construye este servidor; la migración es una tarea aparte, y la fijación está documentada donde se establece en lugar de descubrirse en tiempo de ejecución.
• Los tokens están cifrados en reposo (Fernet, clave en el volumen de datos) y enmascarados en la interfaz; el recopilador de corpus enmascara los datos personales antes de escribir un archivo, porque los pedidos y los payloads de chat llevan nombres, teléfonos y direcciones de clientes.

Cómo funciona

Un contenedor Docker que ejecuta una aplicación FastAPI que desempeña dos roles a la vez: un servidor MCP sobre SSE y una pequeña interfaz web. Un párrafo por archivo:

• wb_mcp/server.py — el propio servidor MCP. La lista TOOLS de 202 objetos Tool (nombre, descripción, esquema JSON de argumentos) es exactamente lo que el cliente recibe en respuesta a tools/list. Las llamadas se enrutan mediante tres diccionarios: NO_CLIENT_DISPATCH (sin necesidad de acceso a WB), CLIENT_DISPATCH (necesita el cliente HTTP de la tienda) y SHOP_DISPATCH (necesita también el shop_id). El punto de entrada stdio main() vive aquí también, para clientes que solo hablan stdio.
• wb_mcp/client.py — clientes HTTP para los 14 hosts de Wildberries. Un WBClient por tienda, que envuelve un httpx.AsyncClient con el token; los clientes se almacenan en caché en un grupo con clave por shop_id.
• wb_mcp/app.py — FastAPI: GET /sse y POST /messages para MCP, el panel de control, las páginas de tiendas y diagnóstico, la API JSON /api/*, la comprobación MCP_AUTH_TOKEN y el bucle de comprobación de salud en segundo plano.
• wb_mcp/settings.py — tiendas y claves: lectura y escritura de shops.json, cifrado Fernet, migración del antiguo settings.json de una sola tienda, enmascaramiento de tokens para la interfaz. Hay un respaldo: si WB_API_TOKEN está configurado, aparece una tienda llamada default.
• wb_mcp/diagnostics.py — pings a hosts de WB, decodificación del token JWT (caducidad, ámbitos, indicador de sandbox), "sondas" — una solicitud real barata por categoría de API — y noticias de WB.
• wb_mcp/stats.py — SQLite mediante aiosqlite: cada llamada a herramienta se registra con su duración, indicador de éxito y shop_id; esto alimenta el detector de degradación y el historial de comprobaciones de salud.
• wb_mcp/templates/ — tres páginas PicoCSS, sin paso de compilación de frontend.

Detalles no obvios:

• shop_id se completa automáticamente mientras solo hay una tienda. Es conveniente en el día a día, pero en cuanto agregas una segunda cuenta, las llamadas sin shop_id empiezan a devolver "Укажите shop_id" ("especifique shop_id").
• Cada llamada se registra en las estadísticas, incluidos los fallos. Eso es lo que alimenta el detector de degradación: "antes funcionaba, ahora falla constantemente" es una señal de que WB cambió la API, no de que cometiste un error. Consulta wb_degradations o el panel.
• Diagnósticos en segundo plano cada 30 minutos realizan solicitudes reales a WB y consumen tus límites de tasa. Si eso estorba, establece HEALTH_CHECK_INTERVAL_MIN=0 en .env.
• Las respuestas se devuelven tal cual, el JSON crudo de WB, sin reempaquetado. Eso mantiene las herramientas predecibles, pero los informes grandes deben solicitarse con filtros o la respuesta consumirá tu ventana de contexto.
• POST /messages se monta como una aplicación ASGI separada (Mount) en lugar de una ruta FastAPI ordinaria: handle_post_message envía la respuesta ASGI por sí mismo, y dentro de una ruta el framework la enviaría una segunda vez — la conexión se caería en cada POST. Por eso la autorización para este endpoint se verifica manualmente dentro de la aplicación.
• La versión de la librería mcp está fijada en >=1.0.0,<2. El servidor está escrito contra la API de decoradores de mcp 1.x (@app.list_tools()), eliminada en mcp 2.0. No subas el límite superior en pyproject.toml: con mcp 2.x el servidor falla al iniciar con AttributeError: 'Server' object has no attribute 'list_tools'.

Variables de entorno

Límites de la API de Wildberries

Estos son límites de la propia WB, no de este servidor — pero el asistente los encontrará regularmente, y es mejor conocerlos de antemano. Esta lista no se copió de la documentación: proviene de cinco meses de llamadas diarias en unas veinte cuentas, más el registro de diagnósticos.

• GET /adv/v3/fullstats (estadísticas de publicidad) — 3 solicitudes por minuto, período no mayor a 31 días.
• Embudo de ventas v3 — 3 solicitudes por minuto; el historial día a día está disponible solo para la última semana como máximo.
• /ping — 3 solicitudes por 30 segundos por host (los diagnósticos en segundo plano lo tienen en cuenta).
• Cualquier respuesta 4XX cuenta como 10 solicitudes contra el límite (una regla vigente desde 2026-06-04). Un parámetro incorrecto dentro de un bucle y quedas limitado por tasa.
• reportDetailByPeriod fue eliminado por Wildberries el 2026-07-15. El servidor llama a finance-api; la alternativa al endpoint antiguo ya no existe, ya que está muerto de todos modos. El informe de realización necesita la categoría Finanzas en el token — sin ella obtienes un error claro que te dice qué reemitir, no un rechazo opaco.
• Los suministros FBW no se pueden crear a través de la API — solo en el portal del vendedor. Las herramientas wb_fbw_* son informativas.
• Un token de WB dura 180 días. wb_token_info y la página /diagnostics muestran el tiempo restante.
• Un 429 de WB significa un límite de tasa, no un fallo. Reintenta en un minuto.

Verificado contra la documentación de dev.wildberries.ru en agosto de 2026.

Referencia técnica

Hosts de la API de Wildberries Seller

Diagnósticos

• La página /diagnostics — por tienda: expiración y alcances del token, pings de todos los hosts de la API de WB, sondeos por categoría, historial de verificaciones y un botón "verificar ahora".
• Verificaciones automáticas en segundo plano cada HEALTH_CHECK_INTERVAL_MIN minutos.
• Detector de degradación — resalta en el panel las herramientas que dejaron de funcionar.
• Herramientas MCP: wb_diagnostics, wb_token_info, wb_degradations, wb_api_news.
• GET /api/health — resumen JSON para monitoreo externo.
• POST /api/diagnostics/run — ejecuta una verificación de todas las tiendas ahora mismo.
• GET /api/diagnostics/<shop_id> — diagnóstico completo de una sola tienda.

Estructura del proyecto

wb-mcp-server/
├── docker-compose.yml          # port 8001, wb_data volume
├── Dockerfile                  # python:3.12-slim
├── pyproject.toml
├── DEPLOY.md                   # deploying to a dedicated machine, moving the data
├── docs/                       # client setup guides + tool reference
└── wb_mcp/
    ├── server.py       # MCP server: 197 tools, dispatch tables, stdio mode
    ├── client.py       # HTTP clients for the 14 Wildberries APIs
    ├── app.py          # FastAPI: SSE + web UI + auth + health loop
    ├── diagnostics.py  # pings, JWT decoder, probes, API news
    ├── settings.py     # stores and keys (Fernet)
    ├── stats.py        # call statistics and check history (SQLite)
    └── templates/      # PicoCSS: dashboard, diagnostics, shops

Implementación

Mover el servidor a una máquina dedicada, migrar tiendas, configurar el inicio automático — consulta DEPLOY.md (en ruso).

El mismo servidor para Ozon

DeviceIngineering/ozon-mcp-server es la misma herramienta para el otro marketplace (Ozon es el otro gran marketplace de Rusia): misma arquitectura, misma interfaz web con panel y diagnósticos, mismo manejo de múltiples tiendas mediante shop_id, mismo transporte SSE, mismas formas de conectar clientes. Una vez que configuras uno, el segundo sigue las mismas instrucciones; solo difieren el puerto y el conjunto de herramientas.

Pueden ejecutarse en paralelo en una misma máquina: puertos diferentes, volúmenes Docker diferentes, sin conflicto.

Vivir en el mismo servidor tampoco perjudica en cuanto a límites de tasa: ambos salen a través de una sola IP, pero Wildberries y Ozon cuentan sus límites por separado — son plataformas diferentes. El límite por dirección en el número de cuentas, descrito en la sección de múltiples tiendas, se aplica dentro de cada plataforma por su cuenta.

Del acceso a la API a un repricer funcional

Este servidor le da a un modelo acceso a la cuenta del vendedor. Decidir cuál debería ser el precio es un trabajo aparte, y ozon-wildberries-repricer lo hace: mantiene un precio de referencia, calcula un piso de punto de equilibrio a partir de las tarifas reales de cada marketplace, saca productos de promociones que los empujarían por debajo del costo, y puede buscar un mejor precio ejecutando un experimento controlado sobre ventas en vivo.

Cubre Ozon, Wildberries y Yandex Market en un solo lugar, y tiene su propio plano de control HTTP para agentes LLM — con las vías que un modelo necesita: un movimiento de precio que dispararía la cuarentena de Wildberries se recorre en varias ejecuciones, los precios se releen tres minutos después porque los marketplaces reportan éxito por cambios que no hicieron, y varios agentes trabajando el mismo catálogo no pueden sobrescribir las decisiones de los demás.

Ejecútalo sin una cuenta de marketplace: npm run demo genera un catálogo sintético y arranca la aplicación.

Actualizaciones y soporte

Wildberries cambia su API constantemente: se agregan, renombran y desactivan endpoints — la sección de límites anterior enumera lo que ya se ha detectado en la práctica. Este servidor es la herramienta de trabajo del autor: más de cinco meses de uso diario en unas veinte cuentas de vendedor. Se actualiza según las necesidades del autor — cuando el próximo cambio rompe algo en sus propias tiendas, no según un cronograma. Por eso los intervalos entre commits pueden ser largos: significa que WB no rompió nada mientras tanto. No hay compromiso en cuanto a tiempos.

Si necesitas una corrección urgente, escribe a d0371153@gmail.com. Los problemas y solicitudes de extracción son bienvenidos y sí se revisan.

Historial de versiones: CHANGELOG.md.

Licencia

MIT — consulta LICENSE.

Registro MCP

Publicado en el Registro MCP oficial:

mcp-name: io.github.DeviceIngineering/wb-mcp-server