HARBEZ WB Feedbacks — MCP connector

Wildberries reviews and questions come straight into the Claude chat — for you and your employees, from any device in the organization. Seller API tokens live only in the server environment: they are not in the correspondence, not on laptops, not in project files.

Claude (проект «Коммерческий отдел»)
        │  HTTPS, streamable HTTP, персональный Bearer-ключ
        ▼
   Caddy (TLS, Let's Encrypt)
        │
   MCP-сервер (Docker, слушает только внутри сети compose)
        │  токены WB из .env
        ▼
   feedbacks-api.wildberries.ru

What it can do

Requests to WB are throttled, review texts are truncated to 600 characters, wb_feedbacks_stats returns only aggregates — so as not to burn through context.

Related MCP server: wildberries-finances-mcp-server

Deployment on a VPS

You need: a VPS with Ubuntu/Debian, a subdomain with an A-record pointing to it, root at the start.

# 1. На ВПС под root — пользователи, фаервол, Docker, клон репозитория
git clone git@github.com:Albertharbez/mcp-wb.git /srv/wb-mcp
bash /srv/wb-mcp/deploy/setup-vps.sh albert <логин-сотрудника>

# 2. Заполнить /srv/wb-mcp/.env (шаблон — .env.example)
#    MCP_DOMAIN, WB_TOKEN_*, MCP_CLIENT_KEYS

# 3. Поднять
cd /srv/wb-mcp && docker compose up -d --build
curl https://<MCP_DOMAIN>/healthz     # -> {"ok":true}

Code updates later — deploy/update.sh: does git pull, rebuilds, starts up and checks /healthz, and on failure shows logs.

WB tokens are created in each seller account: Settings → API Access → the "Questions and Reviews" category. One account — one token.

Two people working on one VPS

• A separate SSH user for each person, key-only login, passwords and root login disabled. No shared account — otherwise you can't see who did what.

• Both in the wb group (project directory /srv/wb-mcp, setgid — new files inherit the group) and docker (to start and inspect the service).

• .env — 640 root:wb: both can read it, no outsiders on the server.

• Code is edited via git, not live on the server: git pull in deploy/update.sh.

• A personal MCP_CLIENT_KEYS per person, not a shared one. Logs show who made requests; on termination — delete the line and restart, no WB token rotation.

Connecting to Claude

Claude → Settings → Connectors → Add custom connector: URL https://<MCP_DOMAIN>/mcp, header Authorization: Bearer <personal key>. The organization owner connects it — then the connector is available to the department from any device. On the enterprise plan, custom connectors may first need to be enabled in the organization settings.

Security

• Tokens only in the server env. They don't end up in git (.gitignore), don't appear in tool responses, and are replaced with a placeholder in the account toString.

• Authentication is fail-closed: empty MCP_CLIENT_KEYS — the server won't start. Open mode only with explicit MCP_ALLOW_NO_AUTH=true and only for localhost.

• Three paths are exposed: POST /mcp, GET /healthz (no details), GET /status (details, behind a key). Everything else — 404 at the Caddy level.

• The server itself doesn't publish its port externally: the only entry point is through Caddy.

• Publishing answers is the only irreversible operation: destructiveHint, confirm=true, and the WB_ALLOW_WRITES kill switch on the server.

• A token that has already been sent in correspondence is considered compromised. Revoke it.

What was fixed during deployment

Verified and not verified

• Syntax and logic of the edits have been reviewed; tsc --noEmit and running were not performed — the machine where the work was done has no Node. The first build run is on the VPS (docker compose up -d --build), where tsc will also run inside the image.

• Calls to WB with live tokens were not tested. After filling in .env, check with wb_feedbacks_unanswered_count — the cheapest call.

• Verify the field composition and limits before production: https://dev.wildberries.ru (the "Reviews and Questions" section).