This server provides tools to search Selver.ee and manage a server-side guest cart, with optional browser synchronization via chrome-devtools.
Search Selver.ee product catalog using Estonian terms; returns prices, nutrition per 100g, and stock status.
Add products to the Selver.ee guest cart by SKU and quantity, creating a cart if none exists.
View the current Selver.ee cart contents and total price.
Remove products from the Selver.ee cart by SKU.
Cart actions are server-side only; if a browser is open on selver.ee/cart, you must also dispatch cart/addItem or cart/removeItem via chrome-devtools-mcp to keep it in sync.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@selver-mcp Add 2 black breads to my Selver cart and open it"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Let Claude shop at Estonian online grocery stores for you: Selver, Rimi, and Barbora. Search products, compare prices across stores, build a shopping cart in one or several stores, and open it in your browser ready for checkout - all from a conversation with Claude.
Coop is not included: its Tallinn, Tartu, and Pärnu e-shops run on Wolt and Bolt Food; only Haapsalu has its own web shop.
Works with: Claude Desktop, Claude Code, and any MCP-compatible client.
You tell Claude something like "add two loaves of bread and half a kg of cucumber to my Selver cart and open it" and Claude:
Searches the stores you name with each store's own search engine
Picks the best options and sizes quantities correctly (weight goods in kg, fixed steps)
Builds the cart: on Selver's servers as a guest cart; on Rimi and Barbora inside your browser tab
Opens Chrome with the cart visible, ready for you to log in and pay
Or ask "price this list in Selver and Rimi and tell me which is cheaper" and Claude runs the comparison before building anything.
No credentials leave your machine. selver-mcp never sees your store passwords. Barbora requires you to log in in the browser tab before items can be added.
Related MCP server: Frisco MCP
Once installed, you can chain selver-mcp with Claude's normal capabilities. A real session:
1. The prompt (in Estonian - works equally well in English):
Otsi netist 3 Türgi-pärast, valgurohket retsepti
Otsi Selverist vajaminevad koostisosad (kui täpne on puudu, siis asenda sobivaga)
Pane neid ostukorvi koguses, et saaksin iga rooga 5 portsionit, igas portsjonis ~50g valku
kirjuta lõplikud retseptid mulle siia chati
2. Claude's reply - real Estonian recipes with measured ingredients and steps:
3. The cart, populated and ready for checkout - opens automatically in Chrome after Claude finishes reasoning:
All in one conversation. Claude handles recipe research, ingredient mapping to real SKUs (substituting when exact matches are out of stock), weight-based quantity math, and the browser orchestration that shows you the cart ready to check out.
If you already have an AI coding agent with shell and filesystem access - Claude Code works out of the box, Claude Desktop works if you have a filesystem or shell MCP installed - the fastest install is to paste this prompt:
Please install selver-mcp from https://github.com/martparve/selver-mcp following its README. Set up both MCPs (selver-mcp and chrome-devtools) for my client, and do the post-install step for getting the cart workflow into context (skill file for Claude Code, memory for Claude Desktop). Then tell me to restart.
The agent will clone the repo, run npm install && npm run build, wire up the MCPs in your config file, and handle the workflow-in-context step appropriate for your client.
If your agent doesn't have those permissions (browser-only ChatGPT, Claude.ai web, etc.), fall back to the manual steps below.
You need Node.js 18 or newer. Check if you have it:
node --versionIf you see v18.x.x or higher, you're set. Otherwise:
macOS: easiest is Homebrew → brew install node
Windows / Linux / any OS: download from nodejs.org (pick the LTS version)
git clone https://github.com/martparve/selver-mcp.git ~/selver-mcp
cd ~/selver-mcp
npm install
npm run buildclaude mcp add selver-mcp node ~/selver-mcp/dist/index.jsselver-mcp builds your cart on Selver's servers, but to actually see and check out the cart, Claude needs a browser-control helper called chrome-devtools-mcp:
claude mcp add chrome-devtools --scope user -- npx -y chrome-devtools-mcp@latestThe server already sends the workflow to Claude Code as MCP instructions. The skill adds examples and pitfalls on top.
mkdir -p ~/.claude/skills/selver-cart
cp ~/selver-mcp/skills/selver-cart/SKILL.md ~/.claude/skills/selver-cart/SKILL.mdLisa mulle Selverist 2 pätsi musta leiba ja ava cart
or
Add 2 black breads from Selver to my cart and open it in the browser
Claude should search, add, open a Chrome window showing your cart, and tell you to log in.
Same as Claude Code step 1.
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
If the file doesn't exist, create it.
{
"mcpServers": {
"selver-mcp": {
"command": "node",
"args": ["/Users/YOUR_NAME/selver-mcp/dist/index.js"]
},
"chrome-devtools": {
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest"]
}
}
}Replace /Users/YOUR_NAME/selver-mcp with the actual path where you cloned the repo. On Windows this looks like C:\\Users\\YourName\\selver-mcp (double backslashes).
That is all. The server tells Claude Desktop the full workflow itself (MCP server instructions), so no memory or skill file is needed.
Lisa mulle Selverist 2 pätsi leiba ja ava cart
The first time MCP tools are used, Claude Desktop will ask permission - click Allow.
Ask Claude in a new chat:
What Selver tools do you have available?
Claude should list eight tools: search_products, get_products, compare_prices, add_to_cart, view_cart, remove_from_cart, clear_cart, get_browser_sync_script. Plus a bunch of chrome-devtools tools.
Build a shopping cart and open the browser:
Leia mulle Selverist 5 erinevat juustu ja ava cart brauseris.
Compare stores:
Pane see nimekiri kokku Selveris ja Rimis ja ütle, kus on odavam: 2 kanafileed, kilo tomateid, 2 täispiima.
Shop at Rimi:
Lisa Rimist 0,6 kg kurki ja 2 piima carti ja ava see.
Just search, don't commit:
Mis on praegu Selveris odavaim kreeka jogurt?
Remove items:
Võta kurk ostukorvist välja.
Start fresh:
Tühjenda mu Selveri cart.
Use Estonian search terms: leib (bread), piim (milk), muna (egg), kanafilee (chicken fillet)
The cart persists between conversations - pick up tomorrow where you left off
Weight goods (cucumber, meat, loose vegetables) are ordered in kg in fixed steps, usually 0.3 kg. Claude handles the math and the server snaps odd amounts up to the next valid step.
"The browser is already running" error
Left over from a previous session. Close any orphan Chrome windows manually, or run:
pkill -f 'chrome-devtools-mcp/chrome-profile'Cart is empty in the browser even though Claude added items
The browser step was skipped. Remind Claude: "call get_browser_sync_script and run the replay_script in the selver.ee cart tab".
"Toote samm on muutunud" error when adding weight goods
The quantity was not a multiple of the product's step. add_to_cart normally prevents this; if it appears, ask Claude to resend using the product's qty_step.
Items marked out of stock
in_stock comes from Selver's live stock service for the e-shop. Ask Claude for a substitute.
npm or claude command not found
Node.js (see Prerequisites) or the Claude Code CLI is not installed or not on your PATH.
cd ~/selver-mcp
git pull
npm install
npm run buildThen restart Claude Code or Claude Desktop. If you copied the skill file, copy it again.
Claude Code:
claude mcp remove selver-mcp
claude mcp remove chrome-devtools
rm -rf ~/selver-mcp
rm -rf ~/.claude/skills/selver-cartClaude Desktop: remove the selver-mcp and chrome-devtools entries from claude_desktop_config.json and delete ~/selver-mcp.
Your guest cart token lives at ~/.selver-mcp/cart.json. Delete that to start completely fresh.
Every tool takes a store (selver, rimi, barbora); search tools take stores.
Tool | Description |
| Search one or more stores with each store's own engine. Returns price, discount, unit price, |
| Same product record for a list of SKUs in one store. |
| Price a shopping list ( |
| Selver: puts lines in the guest cart server-side ( |
| Selver: lines and grand total. Rimi/Barbora: a read script for the tab. |
| Selver: server-side. Rimi/Barbora: returns a script for the tab. |
| Selver: steps and JavaScript that make the server cart visible in a browser. Rimi/Barbora: steps to open the store tab and read the cart. |
Store | Search | Cart | Notes (verified October 2026) |
Selver | Klevu + Vue Storefront catalog + live stock | Server-side guest cart, token held by the MCP, replayed into the SPA | Bag fee 0.50 €. Nutrition available. |
Rimi | Server-rendered search page parsed from HTML ( | Guest cart bound to an httpOnly Laravel session: in-page | Minimum order 20 €. Unavailable items show "Ei ole saadaval". |
Barbora | Product list embedded in the search page ( | No guest cart; in-page calls to | 4 € fee under 39.99 €. Many promo prices need the loyalty card. Rate-limits bursts with empty 200 pages, so requests are throttled to 2 in parallel with retries. Cart JSON shape unverified until a logged-in run. |
Coop | not supported | ecoop.ee redirects to Wolt/Bolt; Haapsalu runs WooCommerce (Store API, guest cart) and could be added on request. |
Search: the website's search box uses Klevu (POST https://eucs3v2.ksearchnet.com/cs/v2/search with a public client-side key). The Vue Storefront Elasticsearch proxy at /api/catalog/vue_storefront_catalog_et/product/_search holds the full product records (nutrition, unit prices, discounts, product_weight_step) but its q= ranking is poor, so selver-mcp uses Klevu for ranking and the catalog for details. The catalog is the fallback when Klevu is down.
Stock: the catalog index's stock fields are stale. Live availability and ordering rules come from GET /api/stock/list?skus=A,B,C (literal commas; one unknown SKU fails the whole call).
Weight goods: product_weight_step is a string ("0.30"). Quantities are in kg and must be multiples of the step, otherwise Selver answers Toote samm on muutunud (0.3).
Cart: /api/cart/{create,update,pull,delete,totals}. update without item_id adds to an existing line; with item_id it sets the quantity. pull prices exclude VAT; totals has the real numbers and the packaging fee.
Browser: the Vue 2 SPA keeps its own cart state and ignores a guest server cart. The replay script sets the token in localStorage and the store (cart/cart/SRV_TOKEN), then replays /api/cart/pull items through cart/getProductVariant + cart/addItem {forceServerSilence: true}, fixes quantities with cart/updateQuantity, removes stale lines, and calls cart/syncTotals. When the user logs in, Vue Storefront merges the guest cart into their account.
npm install # install dependencies
npm run build # compile TypeScript to dist/
npm test # unit tests against captured API fixtures (tests/fixtures)
npm run dev # watch modesrc/
├── index.ts # MCP server entry point (stdio transport)
├── core/
│ ├── types.ts # Product, StoreAdapter, ServerCartApi, BrowserCartApi
│ ├── qty.ts # quantity snapping and rounding
│ └── http.ts # throttled fetch with retries and bot-challenge detection
├── tools/
│ ├── search.ts # search_products, get_products, compare_prices
│ └── cart.ts # add_to_cart, view_cart, remove_from_cart, clear_cart, get_browser_sync_script
├── stores/
│ ├── registry.ts # store id → adapter
│ ├── selver/ # Klevu search, catalog hydration, live stock, guest cart, SPA replay script
│ ├── rimi/ # HTML search parser, in-page cart script
│ └── barbora/ # embedded-JSON search parser, in-page cart script
└── storage/
└── cart-token.ts # ~/.selver-mcp/carts.json (per-store server cart tokens)Add products to Selver.ee guest cart by SKU. Creates a new cart if none exists. Server-side only - if a browser is open on selver.ee/cart, you must ALSO dispatch cart/addItem via chrome-devtools-mcp to keep the browser in sync (see README).
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It mentions that a new cart is created if none exists ('Creates a new cart if none exists') and highlights the server-side nature and browser sync requirement. This goes beyond the bare function name and adds meaningful side-effect information. However, it doesn't mention error handling or how duplicates are treated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences with the key action front-loaded. The second sentence provides essential operational context (server-side only, browser sync) without unnecessary fluff. It earns its place and remains easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no output schema and no annotations, the description covers the essential aspects: what it does, side effect of cart creation, and the critical sync requirement. It doesn't detail error cases or return values, but those are less critical given the simplicity. The sibling tool list adds context that this is one of several cart operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description says 'by SKU' but does not explain the structure of the items array or the qty parameter. However, the input schema provides descriptions for both sku ('Product SKU (e.g. "T000089179")') and qty ('Quantity to add'), so the schema already carries the parameter explanation. The description adds only minimal emphasis on SKU, so it meets the baseline without substantial additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add products to Selver.ee guest cart by SKU.' It uses a specific verb (add), identifies the resource (Selver.ee guest cart), and specifies the method (by SKU). This distinguishes it from sibling tools like search_products, view_cart, and remove_from_cart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: it is server-side only, and if a browser is open on selver.ee/cart, the agent must also dispatch cart/addItem via chrome-devtools-mcp to keep the browser in sync. This is an explicit alternative/requirement that guides when to use this tool in conjunction with other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove products from Selver.ee cart by SKU. Server-side only - if a browser is open on selver.ee/cart, you must ALSO dispatch cart/removeItem via chrome-devtools-mcp to keep the browser in sync (see README).
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals a critical behavioral trait: the tool is server-side only and requires a browser synchronization step. This goes beyond the schema, adding essential operational knowledge. It doesn't cover other side effects, but for a simple removal tool, this is significant disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose, followed by a crucial caveat. No redundant words or filler. Every sentence earns its place, and the structure is ideal for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is largely complete. It covers the main action, the server-side scope, and a critical synchronization edge case. It doesn't explain return values, but no output schema exists and the focus is on action, not results. Minor gaps remain but nothing critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on the 'items' parameter or its structure. With schema description coverage at 0% per context signals, the description should compensate, but it doesn't mention where to find SKU or how the array should be formed. The schema does provide a description for 'sku', but the tool description adds no value beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove products'), the target ('Selver.ee cart'), and the method ('by SKU'). This is a specific verb+resource+method, and it distinguishes from sibling tools like add_to_cart, view_cart, and search_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Server-side only' and a clear conditional instruction for when a browser is open (must also dispatch cart/removeItem via chrome-devtools-mcp). This tells the agent when and how to use the tool, though it doesn't explicitly contrast with alternatives. The instruction is practical and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Selver.ee product catalog. Returns products with prices, nutrition per 100g, and stock status. Use Estonian terms for best results (e.g. "kana" for chicken, "riis" for rice, "lohe" for salmon).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20) | |
| query | Yes | Search query (Estonian preferred) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the key behavioral detail of return fields (prices, nutrition, stock status). The read-only nature is implied by 'Search', and the description adds useful context without contradicting any annotations. It doesn't mention pagination or error behavior, but for a simple search this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the action and resource, and every sentence contributes value. The language tip is useful and directly actionable for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two well-schemaed parameters and no output schema, the description provides sufficient context: purpose, return contents, and query language guidance. It is complete enough for an agent to decide when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for parameters, so baseline is 3. The description adds value beyond the schema by providing concrete Estonian query examples (e.g., 'kana' for chicken), which clarifies the language hint already present in the schema. This enrichment earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and resource ('Selver.ee product catalog'), and states exactly what is returned (prices, nutrition per 100g, stock status). This clearly distinguishes it from sibling cart tools (add_to_cart, view_cart, remove_from_cart).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (searching the product catalog) and the sibling names make it obvious this is not for cart operations. However, it does not explicitly state when to prefer this over alternatives or exclude any use cases, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View current Selver.ee cart contents and total price.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly implies a read-only operation via 'view', but adds no detail about session requirements, potential errors, or side effects (which are minimal for a view operation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates all necessary information without redundancy. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless read-only tool, the description adequately defines what the tool does and what it returns (cart contents and total price). It is complete enough given the absence of output schema or annotations, though it leaves some nuance about the exact format of 'contents' unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter information to clarify. As per guidelines, the baseline for 0 params is 4, and the description doesn't need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('view') and resource ('current Selver.ee cart contents and total price'). It distinguishes itself from siblings by focusing on viewing rather than searching or modifying the cart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to inspect the current cart and its total price. It implicitly excludes modification or search operations, though it doesn't explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0add_to_cartremove_from_cartsearch_productsview_cartScored across 4 tools
Each tool has a singular, clear purpose: searching products, adding to cart, viewing cart, and removing from cart. There is no overlap or ambiguity between the tool names and their descriptions.
All tool names follow the consistent verb_noun snake_case pattern: search_products, add_to_cart, view_cart, remove_from_cart. This makes the toolset highly predictable and easy to navigate.
With only 4 tools, this is a tightly scoped server for product search and cart management. Each tool is essential and there are no redundant or superfluous additions.
The server covers the core cart lifecycle: search, add, view, and remove. However, it lacks an update quantity or clear cart operation, which would be a natural addition for full cart management, but the existing tools are sufficient for basic workflows.
Agentic commerce gateway: discovery, search, checkout across Shopify/Woo/Odoo/PrestaShop.
Turn any shopping list into a ready-to-checkout grocery cart across 26 European supermarkets.
Product search for AI agents: Amazon + Shopify, cart-to-checkout buy path. Pay-per-call, no API key.
Search Rakuten Ichiba products and compare prices via Claude. Zero setup, no API key needed.
