Wildberries MCP Server

WB MCP Server

Gerencie suas lojas Wildberries a partir de um chat com um assistente de IA. 197 ferramentas que cobrem a API do Vendedor Wildberries — cartões de produtos, preços, anúncios, remessas, avaliações, finanças, análises — expostas ao Claude, Cursor, Copilot, Gemini CLI e qualquer outro cliente MCP. Feito para vendedores WB (Wildberries é o maior marketplace da Rússia) que operam uma ou várias contas de vendedor e preferem fazer uma pergunta a navegar pelo portal do vendedor.

Vendendo também na Ozon? Existe o mesmo servidor para Ozon.

O servidor está em uso diário há mais de cinco meses em cerca de vinte contas de vendedor WB, com 197 ferramentas. É a ferramenta de trabalho do próprio autor e é atualizado conforme o autor precisa — detalhes aqui.

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.

O que ele pode fazer

197 ferramentas, agrupadas por área da API do Vendedor Wildberries. A lista numerada completa com a descrição de cada uma está em docs/tools.md.

Três coisas que servidores semelhantes geralmente não têm:

• Multi-loja. Cada chamada recebe um shop_id, então duas contas de vendedor WB vivem em uma única conversa. Com uma única loja, você pode omitir shop_id completamente.
• Diagnósticos da API WB. O servidor faz ping nos hosts da WB por conta própria, envia uma solicitação de sonda barata por categoria de API, decodifica a expiração e os escopos do token e destaca "degradações": uma ferramenta que funcionava e agora falha consistentemente — um sinal confiável de que a WB mudou a API.
• Tokens criptografados. Os tokens WB são armazenados criptografados (Fernet), não na configuração do seu cliente.

Início rápido

Opção 1: um comando, sem Docker

O servidor fala stdio, que é como o Claude Desktop, Cursor, VS Code e outros clientes MCP se conectam a ele. Nada para compilar:

uvx wb-mcp-server

Ou via pip:

pip install wb-mcp-server
wb-mcp

Configuração do cliente (por exemplo, claude_desktop_config.json):

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

Aponte DATA_DIR para qualquer diretório gravável — ele guarda lojas, chaves e estatísticas. O padrão é /data, que é o caminho usado dentro do Docker.

Opção 2: Docker com o painel web

Use esta opção se quiser o painel, diagnósticos da API WB e gerenciamento de lojas baseado em navegador. Você precisa do Docker (Docker Desktop ou OrbStack) e de um token da API do Vendedor 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

Verifique:

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

O que você tem agora:

Próximos passos:

1. Abra http://localhost:8001/shops → Добавить магазин (Adicionar loja) → cole o token WB → Проверить (Testar). O token vem do Portal do Vendedor WB (seller.wildberries.ru): Настройки → Доступ к API → Создать токен (Configurações → Acesso à API → Criar token). Ele é válido por 180 dias; o tempo restante é mostrado na página de diagnósticos.
2. Conecte um cliente MCP — veja a próxima seção.
3. Pergunte ao seu assistente: "liste minhas lojas Wildberries" — a ferramenta wb_list_shops deve disparar.

O comando de início, flag por flag:

Pare com docker compose down (os dados ficam no volume wb_data). Logs: 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

Instalação em clientes

O servidor fala MCP sobre SSE: GET /sse é o fluxo de eventos, POST /messages transporta as mensagens do cliente. O suporte a SSE varia de cliente para cliente, então cada um tem seu próprio guia — com caminhos de configuração para macOS, Linux e Windows, JSON pronto para colar, e variantes com e sem token de autenticação.

Os guias por cliente em docs/ estão atualmente apenas em russo. A configuração neles é JSON pronto com caminhos de arquivo e flags, que é legível independentemente do idioma.

Visão geral e tabela de compatibilidade: docs/README.md.

Onde um cliente tem um comando que configura a conexão por conta própria, o guia começa com esse comando e trata a edição de JSON como segunda opção. A configuração mais curta de todas — Claude Code:

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

Multi-loja e segurança

Várias contas de vendedor. As lojas são adicionadas em /shops; cada uma recebe seu próprio shop_id. wb_list_shops retorna a lista, e 200 das 197 ferramentas recebem shop_id como primeiro parâmetro (as exceções são wb_list_shops e wb_degradations). Com uma única loja, o parâmetro pode ser omitido — o servidor substitui a única disponível.

O ponto não é "suporta duas contas", mas que uma estratégia é escrita uma vez e aplicada a todas as contas: uma regra de preço, um modelo de resposta a avaliações, um teto de lance de publicidade se aplicam a todas as lojas em uma única conversa — sem alternar contas, sem espalhar chaves de API pelas configurações de diferentes clientes.

Quantas contas você pode conectar. Não há limite no código: shops.json é um dicionário simples, adicione quantas quiser. O teto é definido pela Wildberries, não por este servidor: todas as contas alcançam a WB a partir de um único endereço IP — o que executa este servidor — e os limites de taxa são contados por endereço também. A estimativa do próprio autor: cerca de vinte contas por endereço permanecem na zona segura. Além disso, divida-as entre vários servidores com endereços diferentes.

Por que isso importa mais do que parece — veja os limites da WB: vários métodos permitem 3 solicitações por minuto, e qualquer resposta 4XX conta como 10 solicitações. Com uma dúzia de contas em um servidor, um punhado de solicitações malformadas em sequência queima a cota dez vezes mais rápido — e todas as lojas batem no limite de uma vez, não apenas a que errou.

Há maneiras de monitorar isso:

• Diagnósticos em segundo plano enviam um /ping por host por execução (o limite é 3 solicitações por 30 segundos por host) e registram verificações falhas e avisos em um histórico. Você vê o limite se aproximando com antecedência, em vez de descobrir por um bloqueio.
• O detector de degradação distingue dois casos: muitas ferramentas degradando ao mesmo tempo significa limitação por endereço, enquanto uma única ferramenta degradando significa que um endpoint da WB quebrou. O painel torna a diferença óbvia à primeira vista.

Onde os tokens vivem. No volume wb_data (/data dentro do contêiner):

• shops.json — lojas, com tokens criptografados usando Fernet;
• .encryption_key — a chave de criptografia, gerada na primeira inicialização;
• stats.db — SQLite com estatísticas de chamadas e histórico de diagnósticos.

A chave fica ao lado dos dados criptografados, então a criptografia protege contra um vazamento acidental do único arquivo shops.json (um backup, um copiar-colar), mas não contra qualquer pessoa que obtenha acesso ao volume inteiro. Mova os dados como um volume inteiro — veja DEPLOY.md.

Autorização MCP. A variável MCP_AUTH_TOKEN em .env:

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

• vazia (o padrão) — /sse está aberto para qualquer pessoa com acesso de rede à porta;
• definida — o cliente deve enviar Authorization: Bearer <token> ou ?token=<token> na URL. A segunda forma resgata clientes que não conseguem enviar cabeçalhos personalizados.

O token é verificado em ambos os endpoints MCP — em GET /sse e em POST /messages.

O que o servidor não faz:

• A interface web (/, /shops, /diagnostics) não é protegida pelo token — ela está aberta para qualquer pessoa com acesso de rede à porta.
• A porta 8001 não deve ser exposta à internet. Para acesso remoto, use Tailscale ou uma VPN.
• O servidor não encerra HTTPS. Se você precisar de TLS externo, coloque um proxy reverso na frente.

A interface web: cada chamada é visível

Com um servidor MCP típico, as chamadas desaparecem no ar: você não consegue ver o que o assistente realmente fez, quanto tempo levou ou o que o marketplace respondeu, e você só fica sabendo de um problema quando algo falha. Aqui, cada chamada tem um registro e cada loja tem um estado. Para uma ferramenta que movimenta dinheiro real em uma loja real, isso é pré-condição para confiança, não enfeite. Cinco meses de uso diário em cerca de vinte contas é exatamente o que preencheu estas páginas — e produziu a seção sobre limites da WB mais adiante.

Painel — /

A captura de tela está no topo desta página.

Um resumo de todas as chamadas de ferramentas (stats.get_summary()):

• total de chamadas, chamadas hoje, número de erros, duração média das chamadas;
• top 10 ferramentas: contagem de chamadas, tempo médio, contagem de erros;
• um feed das últimas 50 chamadas: timestamp, loja, ferramenta, duração em milissegundos, sucesso ou falha, texto do erro;
• um filtro por loja — um seletor "Todas / conta específica" acima do resumo.

Lojas — /shops

As contas são adicionadas e removidas direto no navegador, sem editar arquivos e sem reiniciar o contêiner. Cada loja tem um botão Проверить ("Testar"): ele faz uma requisição real barata à WB e informa imediatamente se o token está vivo — em vez de deixar você descobrir durante a primeira chamada real. Os tokens são exibidos mascarados na lista (abc***xyz).

Os tokens são criptografados com Fernet e armazenados em shops.json dentro do volume de dados; a chave está em .encryption_key ao lado. O pool de clientes HTTP é redefinido quando uma loja é salva ou excluída, então um novo token entra em vigor imediatamente.

Diagnóstico — /diagnostics

(a captura de tela mostra uma loja de demonstração com um token fictício: a WB responde 401 a cada ping e a cada sonda, então a página inteira fica vermelha. É assim que uma verificação com falha se parece — o servidor em si está bem. Com um token funcional, a linha "Проверка …" mostra ping 13/13, пробы 20/20 e o status da loja é "✅ Здоров".)

Uma verificação em segundo plano a cada HEALTH_CHECK_INTERVAL_MIN minutos (30 por padrão), por loja:

• o token — expiração, categorias de acesso, flags de somente leitura e sandbox;
• pings de 13 hosts da API da WB — disponibilidade e latência de cada um;
• 20 sondas — um GET real barato por categoria de API. São elas que detectam "o endpoint retorna 404 porque a WB renomeou";
• avisos em linguagem simples: "o token expira em N dias", "Content: 404 em /content/v2/... — a WB pode ter mudado a API";
• histórico de verificações com rotação automática (os últimos 1000 registros são mantidos);
• um botão "verificar agora" para executar tudo imediatamente.

O detector de degradação

A coisa mais útil que as estatísticas acumuladas proporcionam. O servidor encontra, por conta própria, ferramentas que funcionavam e agora falham consistentemente: as últimas três chamadas falharam enquanto existem chamadas bem-sucedidas no histórico. Para cada uma dessas ferramentas, ele mostra o horário da última chamada bem-sucedida, o número de erros consecutivos, o texto do erro mais recente e o momento em que as coisas quebraram.

Em outras palavras, o servidor detecta a partir das próprias estatísticas que a Wildberries quebrou ou desativou um endpoint — e avisa você antes de você esbarrar nisso no trabalho. Ao lado da seção sobre limites e datas de desativação de endpoints, esta é a sua continuação prática: aquela seção lista o que a WB anunciou, esta captura o que a WB fez silenciosamente.

Você pode ver isso no painel ou chamar wb_degradations direto do chat.

JSON para monitoramento externo

Tudo o que é visível para um humano também é legível por uma máquina:

Assim, o servidor pode ser integrado ao Uptime Kuma, Zabbix ou qualquer outro sistema de monitoramento, e você fica sabendo de um token morto antes que o assistente avise.

Orçamento de contexto

Duas coisas são pagas em tokens: definições de ferramentas, carregadas uma vez por sessão, e respostas de ferramentas, pagas a cada chamada. Ambas foram medidas em uma conta de vendedor real, em vez de estimadas — scripts/collect_corpus.py tira um instantâneo das ferramentas somente leitura (PII mascarada antes de qualquer coisa ser gravada em disco; o corpus fica fora do repositório), scripts/measure_corpus.py informa o custo.

Definições. 197 ferramentas custam 17 700 tokens com uma única loja configurada, ante 27 460. As descrições têm uma frase cada, shop_id é removido dos esquemas quando existe apenas uma loja (o servidor preenche), e campos de esquema vazios não são serializados.

Respostas. O problema real acabou sendo um punhado de payloads gigantes:

O que o servidor faz a respeito:

• view: compact | full. Ferramentas pesadas retornam os campos para os quais foram chamadas; view="full" fornece a resposta bruta da API. Quais campos foram ocultados é informado na própria resposta, para que o modelo saiba o que pode pedir.
• Sinal de truncamento. Quando exatamente limit registros voltam, a resposta traz um aviso de que os dados são parciais. Sem isso, o modelo raciocina sobre uma fatia e a apresenta como o catálogo inteiro.
• Proteção de tamanho. Uma resposta que não caberia no teto de saída do cliente (MAX_MCP_OUTPUT_TOKENS, 25 000 por padrão no Claude Code) é cortada no lado do servidor, informando quantos registros ficaram de fora de quantos — em vez de ser silenciosamente truncada na chegada.
• Filtros no servidor onde a API não tem. A WB retorna a referência de comissões completa; o parâmetro subject a reduz aqui.

As notas chegam como blocos de conteúdo separados, em vez de um campo dentro do JSON: metade dos endpoints da WB retorna um array no nível superior, e envolvê-lo quebraria todos os caminhos até os dados.

Perfis de ferramentas. Um cliente sem busca de ferramentas paga pelo catálogo inteiro em cada requisição. WB_TOOLSETS mantém apenas os perfis que você usa — eles são cortados com base em tarefas de trabalho, não em seções da documentação da WB, porque auditar promoções precisa de promoções, preços e da quarentena de preços ao mesmo tempo:

O perfil core — lojas, diagnóstico, degradações, informações de token — está sempre ativo: o diagnóstico é necessário exatamente quando algo está quebrado. Perfis desativados são listados na descrição de wb_list_shops, e chamar uma ferramenta desativada responde qual perfil a contém — assim o assistente informa o motivo em vez de dizer "isso não é possível".

O Claude Code não precisa de nada disso: ele tem a busca de ferramentas ativada por padrão e carrega esquemas sob demanda. Cursor, Cline, Continue e Claude Desktop buscam tools/list inteiro — os perfis são para eles.

Decisões de design

• 202 ferramentas estreitas, não algumas genéricas. Colapsá-las em endpoints estilo action economizaria tokens de definição e mudaria a classe de falha: em vez de "não existe tal ferramenta", você obtém uma chamada errada com efeito colateral, e algumas dessas ferramentas definem preços e iniciam campanhas de anúncios.
• Despacho por dicionários, não por cadeia de ifs. NO_CLIENT_DISPATCH, CLIENT_DISPATCH e SHOP_DISPATCH mapeiam nomes para manipuladores, e um teste garante que toda ferramenta tem um e nenhum manipulador fica órfão. Com 197 ferramentas, uma cadeia de ifs apodrece silenciosamente.
• O servidor diagnostica a si mesmo. wb_diagnostics faz ping em todos os hosts da WB e executa uma requisição real leve por categoria de API; wb_degradations informa quais ferramentas funcionavam e agora falham de forma constante. As APIs do marketplace mudam sem aviso — a pergunta "é meu token ou a WB moveu o endpoint" precisa ser respondida em uma única chamada.
• compact é o padrão para ferramentas pesadas. O corpus mostrou que os campos ocultos são URLs de fotos, histórico de promoções e cronogramas de armazéns — não os dados com os quais as decisões são tomadas. A resposta informa o que foi ocultado, então nada se perde silenciosamente.
• shop_id desaparece dos esquemas com uma loja. O mesmo bloco de parâmetros repetido em 200 esquemas custava 3 400 tokens por sessão sem nenhuma informação; o servidor substitui a única loja e recoloca o parâmetro assim que uma segunda aparece.
• mcp<2 é fixado deliberadamente. A API de baixo nível 2.0 remove os manipuladores de decorador nos quais este servidor é construído; a migração é uma tarefa separada, e a fixação é documentada onde é definida, em vez de descoberta em tempo de execução.
• Os tokens são criptografados em repouso (Fernet, chave no volume de dados) e mascarados na interface; o coletor de corpus mascara dados pessoais antes de gravar um arquivo, porque pedidos e payloads de chat carregam nomes, telefones e endereços de clientes.

Como funciona

Um único contêiner Docker executando um aplicativo FastAPI que desempenha dois papéis ao mesmo tempo: um servidor MCP sobre SSE e uma pequena interface web. Um parágrafo por arquivo:

• wb_mcp/server.py — o próprio servidor MCP. A lista TOOLS de 202 objetos Tool (nome, descrição, esquema JSON de argumentos) é exatamente o que o cliente recebe em resposta a tools/list. As chamadas são roteadas por três dicionários: NO_CLIENT_DISPATCH (sem necessidade de acesso à WB), CLIENT_DISPATCH (precisa do cliente HTTP da loja) e SHOP_DISPATCH (precisa também do shop_id). O ponto de entrada stdio main() fica aqui também, para clientes que só falam stdio.
• wb_mcp/client.py — clientes HTTP para os 14 hosts da Wildberries. Um WBClient por loja, envolvendo um httpx.AsyncClient com o token; os clientes são armazenados em cache em um pool identificado por shop_id.
• wb_mcp/app.py — FastAPI: GET /sse e POST /messages para MCP, o painel, as páginas de lojas e diagnóstico, a API JSON /api/*, a verificação MCP_AUTH_TOKEN e o loop de verificação de saúde em segundo plano.
• wb_mcp/settings.py — lojas e chaves: leitura e gravação de shops.json, criptografia Fernet, migração do antigo settings.json de loja única, mascaramento de tokens para a interface. Há um fallback: se WB_API_TOKEN estiver definido, uma loja chamada default aparece.
• wb_mcp/diagnostics.py — pings nos hosts da WB, decodificação do token JWT (expiração, escopos, flag de sandbox), "sondas" — uma requisição real barata por categoria de API — e notícias da WB.
• wb_mcp/stats.py — SQLite via aiosqlite: cada chamada de ferramenta é registrada com sua duração, flag de sucesso e shop_id; isso alimenta o detector de degradação e o histórico de verificações de saúde.
• wb_mcp/templates/ — três páginas PicoCSS, sem etapa de build de frontend.

Detalhes não óbvios:

• shop_id é preenchido automaticamente enquanto houver apenas uma loja. Conveniente no dia a dia, mas no momento em que você adiciona uma segunda conta, chamadas sem shop_id começam a retornar "Укажите shop_id" ("especifique shop_id").
• Toda chamada é registrada nas estatísticas, inclusive falhas. É isso que alimenta o detector de degradação: "funcionava antes, agora falha consistentemente" é um sinal de que a WB mudou a API, não de que você cometeu um erro. Verifique wb_degradations ou o painel.
• Diagnósticos em segundo plano a cada 30 minutos fazem requisições reais à WB e consomem seus limites de taxa. Se isso atrapalhar, defina HEALTH_CHECK_INTERVAL_MIN=0 em .env.
• As respostas são retornadas como estão, o JSON bruto da WB, sem reempacotamento. Isso mantém as ferramentas previsíveis, mas relatórios grandes devem ser solicitados com filtros ou a resposta consumirá sua janela de contexto.
• POST /messages é montado como um aplicativo ASGI separado (Mount) em vez de uma rota FastAPI comum: handle_post_message envia a resposta ASGI por conta própria, e dentro de uma rota o framework a enviaria uma segunda vez — a conexão seria derrubada em todo POST. É por isso que a autorização para este endpoint é verificada manualmente dentro do aplicativo.
• A versão da biblioteca mcp está fixada em >=1.0.0,<2. O servidor é escrito contra a API de decoradores do mcp 1.x (@app.list_tools()), removida no mcp 2.0. Não eleve o limite superior em pyproject.toml: com mcp 2.x o servidor falha na inicialização com AttributeError: 'Server' object has no attribute 'list_tools'.

Variáveis de ambiente

Limites da API Wildberries

Estes são limites da própria WB, não deste servidor — mas o assistente os encontrará regularmente, e é melhor conhecê-los antecipadamente. Esta lista não foi copiada da documentação: ela vem de cinco meses de chamadas diárias em cerca de vinte contas, além do log de diagnósticos.

• GET /adv/v3/fullstats (estatísticas de publicidade) — 3 requisições por minuto, período não superior a 31 dias.
• Funil de vendas v3 — 3 requisições por minuto; o histórico dia a dia está disponível apenas para a última semana.
• /ping — 3 requisições por 30 segundos por host (os diagnósticos em segundo plano levam isso em conta).
• Qualquer resposta 4XX conta como 10 requisições contra o limite (regra em vigor desde 2026-06-04). Um parâmetro errado dentro de um loop e você fica limitado por taxa.
• reportDetailByPeriod foi removido pela Wildberries em 2026-07-15. O servidor chama finance-api; o fallback para o endpoint antigo foi removido, já que está morto de qualquer forma. O relatório de realização precisa da categoria Finance no token — sem ela você recebe um erro claro informando o que reemitir, não uma recusa opaca.
• Suprimentos FBW não podem ser criados pela API — apenas no portal do vendedor. As ferramentas wb_fbw_* são informativas.
• Um token WB dura 180 dias. wb_token_info e a página /diagnostics mostram o tempo restante.
• Um 429 da WB significa limite de taxa, não falha. Tente novamente em um minuto.

Verificado contra a documentação dev.wildberries.ru em agosto de 2026.

Referência técnica

Hosts da API Wildberries Seller

Diagnósticos

• A página /diagnostics — por loja: expiração e escopos do token, pings de todos os hosts da API WB, sondas por categoria, histórico de verificações e um botão "verificar agora".
• Verificações automáticas em segundo plano a cada HEALTH_CHECK_INTERVAL_MIN minutos.
• Detector de degradação — destaca no painel as ferramentas que pararam de funcionar.
• Ferramentas MCP: wb_diagnostics, wb_token_info, wb_degradations, wb_api_news.
• GET /api/health — resumo JSON para monitoramento externo.
• POST /api/diagnostics/run — executa uma verificação de todas as lojas agora.
• GET /api/diagnostics/<shop_id> — diagnósticos completos de uma única loja.

Estrutura do projeto

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

Implantação

Mover o servidor para uma máquina dedicada, migrar lojas, configurar inicialização automática — veja DEPLOY.md (em russo).

O mesmo servidor para Ozon

DeviceIngineering/ozon-mcp-server é a mesma ferramenta para o outro marketplace (Ozon é o outro grande marketplace da Rússia): mesma arquitetura, mesma interface web com painel e diagnósticos, mesmo tratamento de múltiplas lojas via shop_id, mesmo transporte SSE, mesmas formas de conectar clientes. Depois de configurar um, o segundo segue as mesmas instruções; apenas a porta e o conjunto de ferramentas diferem.

Eles podem rodar lado a lado em uma única máquina: portas diferentes, volumes Docker diferentes, sem conflito.

Viver no mesmo servidor também não prejudica o lado dos limites de taxa: ambos saem por um único IP, mas Wildberries e Ozon contam seus limites separadamente — são plataformas diferentes. O teto por endereço no número de contas, descrito na seção de múltiplas lojas, aplica-se dentro de cada plataforma individualmente.

Do acesso à API a um repricer funcional

Este servidor dá a um modelo acesso à conta do vendedor. Decidir qual deve ser o preço é uma tarefa separada, e o ozon-wildberries-repricer faz isso: ele mantém um preço de referência, calcula um piso de ponto de equilíbrio a partir das taxas reais de cada marketplace, remove produtos de promoções que os colocariam abaixo do custo e pode buscar um preço melhor executando um experimento controlado em vendas ao vivo.

Ele cobre Ozon, Wildberries e Yandex Market em um só lugar, e tem seu próprio plano de controle HTTP para agentes LLM — com as proteções que um modelo precisa: uma mudança de preço que dispararia a quarentena da Wildberries é distribuída em várias execuções, os preços são relidos três minutos depois porque os marketplaces relatam sucesso para mudanças que não fizeram, e vários agentes trabalhando no mesmo catálogo não podem sobrescrever as decisões uns dos outros.

Execute sem uma conta de marketplace: npm run demo cria um catálogo sintético e inicia o aplicativo.

Atualizações e suporte

A Wildberries muda sua API constantemente: endpoints são adicionados, renomeados e desativados — a seção de limites acima lista o que já foi capturado na prática. Este servidor é a ferramenta de trabalho do autor: mais de cinco meses de uso diário em cerca de vinte contas de vendedor. Ele é atualizado conforme o autor precisa — quando a próxima mudança quebra algo em suas próprias lojas, não em um cronograma. É por isso que os intervalos entre commits podem ser longos: significa que a WB não quebrou nada nesse meio tempo. Não há compromisso de prazo.

Se você precisar de uma correção urgente, escreva para d0371153@gmail.com. Issues e pull requests são bem-vindos e são revisados.

Histórico de versões: CHANGELOG.md.

Licença

MIT — veja LICENSE.

MCP Registry

Publicado no MCP Registry oficial:

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