Skip to main content
Glama
u1ch1

WB MCP Server

by u1ch1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

WB MCP Server

MCP-сервер (Model Context Protocol) для доступа к данным продавца Wildberries: список карточек товаров и отзывы покупателей. Написан на TypeScript, работает через stdio-транспорт и использует официальные Wildberries API.

Что такое MCP

MCP — это открытый протокол для подключения AI-ассистентов к внешним источникам данных и инструментам. Проще говоря, MCP позволяет таким приложениям, как Claude Desktop, вызывать ваши локальные программы и через них получать актуальную информацию — например, список товаров или отзывы из Wildberries.

Этот сервер реализует два MCP-инструмента:

  • get_products(limit, offset) — возвращает список карточек товаров продавца через Wildberries Content API.

  • get_product_reviews(nmId) — возвращает отзывы покупателей на товар по его nmId через Wildberries Feedbacks API.

Related MCP server: marketplaces-mcp-ru

Установка

npm install
cp .env.example .env   # вписать свой WB_API_KEY
npm run build

Подключение к Claude Desktop

Добавьте сервер в конфигурацию claude_desktop_config.json:

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "wb-mcp-server": {
      "command": "node",
      "args": ["/полный/путь/к/wb-mcp-server/dist/index.js"],
      "env": {
        "WB_API_KEY": "ваш_токен_продавца_Wildberries"
      }
    }
  }
}

Демо-режим и ограничения

Без WB_API_KEY сервер запускается и отвечает на initialize/tools/list, но вызовы get_products/get_product_reviews возвращают ошибку с понятным сообщением вместо падения. Это демонстрационный проект: код реализует правильную структуру запросов к официальному Wildberries API (Bearer-токен, эндпоинты Content/Feedbacks API), но не проверялся на реальном аккаунте продавца — для этого нужен собственный API-ключ.

Как это проверено

Сервер запущен как дочерний процесс, и через stdio отправлены реальные JSON-RPC запросы: initialize (успешный handshake), tools/list (обе схемы инструментов возвращаются корректно), tools/call для get_products без ключа (корректно возвращает isError: true с понятным сообщением, а не падает).

Available Tools

2 tools
get_product_reviewsA

Возвращает отзывы покупателей на товар по его nmId из Wildberries Feedbacks API.

ParametersJSON Schema
NameRequiredDescriptionDefault
nmIdYesИдентификатор товара (nmId) в Wildberries.

TDQS

A3.5/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 explaining behavior. It only says reviews are returned, without disclosing pagination, response format, authentication needs, rate limits, or error behavior.

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 concise sentence with no filler. It front-loads the primary action and identifies the key identifying parameter and API source.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter read tool, the description is adequate to understand what the tool does. However, with no output schema and no annotations, it would be more complete if it indicated what a returned review contains or whether results are paginated.

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 already fully documents nmId, including its type and meaning, so schema coverage is 100%. The description adds no parameter details beyond confirming that reviews are fetched by nmId.

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 a specific action: returns customer reviews for a product using its nmId from the Wildberries Feedbacks API. It also distinguishes itself from the sibling get_products by focusing on reviews rather than product data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used when reviews for a specific nmId are needed, and it names the source API. However, it gives no explicit guidance on when to choose this over get_products, nor any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_productsA

Возвращает список карточек товаров продавца из Wildberries Content API. Параметры limit и offset работают как в классической пагинации.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitYesКоличество товаров для возврата (положительное число).
offsetNoСколько товаров пропустить от начала списка (неотрицательное число). По умолчанию 0.

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool returns a list and that limit/offset behave like classic pagination, which is useful. However, it does not mention ordering, edge cases, maximum limits, or error behavior, leaving some uncertainty.

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 two sentences with no filler. The first sentence front-loads the primary purpose, and the second adds essential pagination context succinctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (2 parameters, no output schema, no annotations), the description covers the essential operational details: source API, action (return list), and pagination semantics. It omits minor details like ordering or return structure, but these are not critical for a basic invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds relational meaning by explaining that limit and offset work together as classic pagination, which goes beyond the individual schema descriptions and helps the agent understand how to construct paged requests.

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 uses a specific verb ('Возвращает') and a clear resource ('список карточек товаров продавца из Wildberries Content API'), stating exactly what the tool returns. It also differentiates from the sole sibling, get_product_reviews, by focusing on product cards rather than reviews.

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?

There is no explicit guidance on when to use this tool versus get_product_reviews, nor any exclusions or conditional routing. The pagination note provides context but not usage direction, leaving the agent to infer applicability from the purpose statement.

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_reviews
    • First observedget_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

A3.7/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are clearly distinct: one retrieves product cards, the other retrieves customer reviews for a specific product. There is no overlap in purpose or target resource.

Naming Consistency5/5

Both tools follow a consistent 'get_<plural_noun>' pattern, making the naming predictable and uniform.

Tool Count3/5

With only two tools, the set feels minimal but not unreasonable for a narrow product-and-reviews scope. However, given the generic 'WB MCP Server' name implying broader Wildberries coverage, two tools is on the thin side.

Completeness2/5

The server exposes only read operations for products and reviews, with no coverage of other common Wildberries seller resources (orders, stocks, prices, etc.) and no lifecycle operations. Significant gaps exist for any seller-facing workflow beyond basic listing and review retrieval.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • marketplaces-mcp-ru

    hehca42y1900
    A
    license
    Not graded
    quality
    C
    maintenance
    Connects AI assistants to Wildberries and Ozon seller accounts for real-time access to sales, stocks, prices, finances, and reviews through official APIs.
    MIT

  • mcp-wb

    hollowmountain
    F
    license
    Not graded
    quality
    C
    maintenance
    Connects Claude to Wildberries customer interactions—reviews, questions, and chats—enabling reading, drafting, and sending responses with explicit confirmation and audit logging.
    -

  • marketplace-mcp

    bssoft2b
    A
    license
    A
    quality
    C
    maintenance
    Enables AI agents to read and work with Wildberries, Ozon, and Yandex Market seller accounts through typed tools, multi-account support, unified data schemas, rate limiting, audit, and encrypted credential storage.
    17
    53 npm
    MIT