Skip to main content
Glama
sdziupin
by sdziupin
README.md
# rozetka-mcp

**English** | [Українська](./README.uk.md)

[![CI](https://github.com/sdziupin/rozetka-mcp/actions/workflows/ci.yml/badge.svg)](https://github.com/sdziupin/rozetka-mcp/actions/workflows/ci.yml)
[![Live Rozetka smoke](https://github.com/sdziupin/rozetka-mcp/actions/workflows/live-smoke.yml/badge.svg)](https://github.com/sdziupin/rozetka-mcp/actions/workflows/live-smoke.yml)

Browser-free MCP server for **Rozetka.ua**.

It uses Rozetka's public-facing JSON backends directly. There is **no Playwright, Chromium, Bright Data, browser profile, cookie jar, GUI automation or search-engine dependency**.

> **Status: alpha / reverse-engineered integration.** Rozetka does not publish these buyer/catalog endpoints as a supported public API. Endpoint shapes and anti-bot policy can change.

## What is reliable

The core path uses endpoints that are live-tested from GitHub Actions:

- `search.rozetka.com.ua` — product search, product ids, filters, category suggestions
- `product-api.rozetka.com.ua` — product description and characteristics

Some richer Rozetka hosts such as `xl-catalog-api.rozetka.com.ua`, `common-api.rozetka.com.ua`, and the storefront itself can return a Cloudflare managed challenge from datacenter IPs. Rich catalog hydration is therefore **best-effort only** and never required for the core tools to return safely.

## MCP tools

- `rozetka_search_products` — search products, filters/sort, optional best-effort rich hydration
- `rozetka_get_product` — product id/URL lookup plus description and characteristics by default
- `rozetka_get_products` — resolve up to 60 product ids; rich hydration when available, safe id fallback otherwise
- `rozetka_list_filters` — live filter metadata for a query
- `rozetka_list_categories` — category suggestions for a query from the search API
- `rozetka_resolve_url` — product/category URL → id, offline
- `rozetka_saved_search_list`
- `rozetka_saved_search_create`
- `rozetka_saved_search_run`
- `rozetka_saved_search_delete`

## Install from npm

After the first npm release, no clone/build step is needed.

### npx

```bash
npx -y rozetka-mcp
```

### Global install

```bash
npm install -g rozetka-mcp
rozetka-mcp
```

### MCP configuration

```json
{
  "mcpServers": {
    "rozetka": {
      "command": "npx",
      "args": ["-y", "rozetka-mcp"]
    }
  }
}
```

## Install from source

Requirements: Node.js 20+.

```bash
git clone https://github.com/sdziupin/rozetka-mcp.git
cd rozetka-mcp
npm install
npm run check
npm test
npm run build
npm start
```

Development:

```bash
npm run dev
npm run smoke
npm run pack:check
```

Source checkout MCP config:

```json
{
  "mcpServers": {
    "rozetka": {
      "command": "node",
      "args": ["/absolute/path/to/rozetka-mcp/dist/index.js"]
    }
  }
}
```

## Search example

```json
{
  "query": "Deye SE-F16-C",
  "min_price": 40000,
  "max_price": 80000,
  "seller": "rozetka",
  "sort": "price_asc",
  "limit": 20
}
```

Use `rozetka_list_filters` first for category-specific attributes, then pass the exact Rozetka filter keys/values through `filters`.

Some high-level queries can be converted by Rozetka into a category redirect instead of a product list. In that case the tool returns `navigate_to` rather than pretending it found products.

## Configuration

```bash
ROZETKA_LANGUAGE=ua
ROZETKA_COUNTRY=UA
ROZETKA_FRONT_TYPE=xl
ROZETKA_HTTP_TIMEOUT_MS=15000
ROZETKA_HTTP_RETRIES=2
```

Advanced endpoint overrides are available in `.env.example`.

## CI

`.github/workflows/ci.yml` validates:

- TypeScript typecheck
- unit tests
- production build
- npm package dry-run
- built CLI entrypoint
- Docker image build

`.github/workflows/live-smoke.yml` validates the real Rozetka core API path on pushes that affect runtime behavior, on manual dispatch, and weekly.

The live smoke intentionally tests only the public search/product endpoints that this package promises as its reliable core. Cloudflare-protected optional hydration is fail-soft and is not treated as a release blocker.

## Branch and release flow

Development happens on `devel`. `main` is the release branch.

Normal flow:

```text
feature work
   ↓
devel
   ↓  PR
main
   ↓  automatic release
GitHub Release + npm
```

A PR into `main` must contain a package version that is not already published on npm. Before opening or merging the release PR, bump the version on `devel`:

```bash
npm run version:patch
# or
npm run version:minor
npm run version:major
```

Commit that version change to `devel`. CI checks that the version is still available on npm.

The release workflow only accepts automatic releases from commits associated with a merged `devel → main` pull request. A direct push to `main` fails the main-policy check and is refused by the release workflow.

### npm publishing secret

The repository must have this GitHub Actions repository secret:

```text
NPM_TOKEN=<npm automation/publish token>
```

The token is exposed to npm only as `NODE_AUTH_TOKEN` inside the publish step and is never committed.

On every valid merge into `main`, `.github/workflows/publish.yml`:

1. verifies the commit came from a merged `devel → main` PR
2. installs dependencies
3. typechecks
4. runs unit tests
5. builds the runtime
6. validates the npm tarball
7. runs the live Rozetka smoke test
8. publishes the version from `package.json` to npm when not already published
9. creates the matching GitHub Release `vX.Y.Z`

The workflow is retry-safe: if npm publishing succeeded but GitHub Release creation failed, a rerun skips the existing npm version and creates the missing Release.

### GitHub branch protection

The repository includes a one-shot admin helper for the only settings GitHub does not expose to this connector:

```bash
bash scripts/configure-github.sh
```

Run it with a GitHub CLI login/token that has repository administration permission. It sets `devel` as the default branch and applies hard protection to `main`.

Recommended hard protection for `main`:

- require a pull request before merging
- require CI checks: `test`, `docker`, `release-version`, and live smoke
- require the branch to be up to date
- block force pushes
- block branch deletion
- keep `devel` as the normal/default working branch

The repository workflows additionally enforce the release policy in CI so a direct `main` push cannot publish a release.

## Buyer account actions

Authenticated buyer features are intentionally **not implemented**:

- wishlist mutation
- cart mutation
- order history
- checkout/payment
- messages

They should only be added after a stable HTTP flow is independently verified. This project will not emulate them with Playwright/Chromium.

## Operational model

- browser-free HTTP only
- no credentials required for marketplace tools
- no checkout/payment automation
- retries only for network errors, HTTP 429 and 5xx
- maximum batch size: 60 product ids
- Cloudflare-protected enrichment fails soft
- description/characteristics use the independently live-tested product API
- no claim that reverse-engineered endpoints are an official Rozetka API

## References

The implementation was cross-checked against community Rozetka integrations including `2BAD/rozetka`, `ALERTua/rozetka_api`, and `joshua-light/rozetka-mcp`, then implemented as a small TypeScript MCP-native client.

## License

MIT

TDQS

B3.3/5.0

Scored across 10 tools

Disambiguation4/5

Most tools target distinct resources or actions, but get_product vs get_products and get_product vs resolve_url for URL inputs create mild overlap. Descriptions generally clarify boundaries, so misselection risk is low but not zero.

Naming Consistency3/5

All names use snake_case with a rozetka_ prefix, which is good. However, product tools follow verb_noun (get_product, search_products, list_filters) while saved-search tools follow noun_verb (saved_search_list, saved_search_create, saved_search_delete, saved_search_run), creating a clear mixed convention.

Tool Count5/5

10 tools are well-scoped for a product search/catalog and saved-search wrapper. The set covers core retrieval, search support, URL resolution, and saved-search lifecycle without excessive or trivial tools.

Completeness4/5

The surface covers search, single/batch product fetch, filters, categories, URL resolution, and saved-search create/list/run/delete. Minor gaps remain: no update/rename for saved searches and no dedicated category-browse operation beyond search.

Maintenance

ActivityMaintained
ResponsivenessNo issues