Click on "Install 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 Selver.ee for you. Search products, build a shopping cart, and open it in your browser ready for checkout - all from a conversation with Claude.
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 Selver.ee for matching products
Picks the best options (handles weight-based goods correctly)
Builds a guest cart on selver.ee
Opens Chrome with the cart visible, ready for you to log in and pay
No credentials leave your machine. selver-mcp never sees your Selver.ee password.
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 (chicken by kg, spinach by weight step), 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)
Open a terminal and run:
git clone https://github.com/martparve/selver-mcp.git ~/selver-mcp
cd ~/selver-mcp
npm install
npm run buildThis downloads the code, installs dependencies, and compiles it. Takes about a minute.
claude 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. One command:
claude mcp add chrome-devtools --scope user -- npx -y chrome-devtools-mcp@latestA skill tells Claude how to use both MCPs together automatically. Without it, you'd need to remind Claude to open the browser after building the cart.
mkdir -p ~/.claude/skills/selver-cart
cp ~/selver-mcp/skills/selver-cart/SKILL.md ~/.claude/skills/selver-cart/SKILL.mdClose any running Claude Code session and start a new one. The MCPs are now available.
In a new Claude Code chat, type:
Lisa mulle Selverist 2 pätsi musta leiba ja ava cart
or in English:
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:
git clone https://github.com/martparve/selver-mcp.git ~/selver-mcp
cd ~/selver-mcp
npm install
npm run buildmacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
If the file doesn't exist, create it.
Open the config file in any text editor and paste this (if you already have other MCPs, merge the mcpServers section):
{
"mcpServers": {
"selver-mcp": {
"command": "node",
"args": ["/Users/YOUR_NAME/selver-mcp/dist/index.js"]
},
"chrome-devtools": {
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest"]
}
}
}Important: replace /Users/YOUR_NAME/selver-mcp with the actual path where you cloned the repo. On Windows this might be something like C:\\Users\\YourName\\selver-mcp - note the double backslashes.
Claude Desktop doesn't read ~/.claude/CLAUDE.md or auto-discover ~/.claude/skills/ the way Claude Code does. Without the workflow in context, Claude Desktop will open an empty cart page instead of the real cart.
The fix is Claude Desktop's memory feature: you paste the instructions into a chat and ask Claude to save them. Memories persist across all future conversations.
Restart Claude Desktop first (so the new MCPs are loaded), then in a new chat paste:
Please save the following as a memory so you always follow it when I shop at Selver.ee:
When the user wants to shop at Selver.ee, always use BOTH
selver-mcp(server-side cart) andchrome-devtools(browser) together. Neither alone is enough.After
add_to_cartreturns acart_token, do all four steps in the browser:
Open
https://www.selver.eeviamcp__chrome-devtools__new_pageRun
evaluate_script:localStorage.setItem('shop/cart/current-cart-token', JSON.stringify('<CART_TOKEN>'))Navigate to
https://www.selver.ee/cartRun this replay snippet (skip items already in
cartItemsto avoid doubled qty):async () => { const store = document.getElementById('app').__vue__.$store; const token = JSON.parse(localStorage.getItem('shop/cart/current-cart-token')); const serverItems = (await fetch(`/api/cart/pull?cartId=${token}&storeCode=et`).then(r => r.json())).result; for (const it of serverItems) { if (store.state.cart.cartItems.find(i => i.sku === it.sku)) continue; const variant = await store.dispatch('cart/getProductVariant', { serverItem: it }); if (variant) await store.dispatch('cart/addItem', { productToAdd: variant, forceServerSilence: true }); } await store.dispatch('cart/syncTotals', { forceServerSync: true }); }For weight-based products (
weight_stepnot null),qtymust be a multiple ofweight_step(e.g. 0.3, 0.6, 0.9...). Integer qty on weight goods fails with "Toote samm on muutunud".
Claude Desktop will confirm the memory was saved. From the next message onwards, it will follow this workflow automatically for any Selver request.
Full reference including pitfalls is in skills/selver-cart/SKILL.md in this repo.
In a new chat:
Lisa mulle Selverist 2 pätsi leiba ja ava cart
Claude Desktop should search, add, open Chrome with the cart populated, and tell you to log in. 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 four tools: search_products, add_to_cart, view_cart, remove_from_cart. 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.
Just search, don't commit:
Mis on praegu Selveris odavaim kuivtoit?
Remove items:
Võta kurk ostukorvist välja.
Start fresh:
Tühjenda mu Selveri cart.
Use Estonian search terms for best results: leib (bread), piim (milk), muna (egg), kana (chicken)
Cart persists between conversations - pick up tomorrow where you left off
For weight-based goods (cucumber, meat, vegetables sold by kg), Claude will automatically figure out valid quantities (e.g. 0.3 kg increments)
"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 skill handles this automatically. If you skipped the skill install, remind Claude: "use chrome-devtools to replay the server cart items via cart/getProductVariant and cart/addItem with forceServerSilence: true".
"Toote samm on muutunud" error when adding weight goods
The product is sold in fixed kg increments (e.g. 0.3 kg). Use valid multiples: 0.3, 0.6, 0.9... Claude should handle this automatically; if not, tell it the product's weight_step.
npm command not found
You haven't installed Node.js. See the Prerequisites section above.
claude command not found
Claude Code CLI isn't installed or isn't on your PATH. Check the Claude Code docs for installation.
When there's a new version:
cd ~/selver-mcp
git pull
npm install
npm run buildThen restart Claude Code or Claude Desktop.
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.
Everything below is for people who want to understand the internals or contribute.
Tool | Description |
| Search Selver.ee by query. Returns products with prices, nutrition, stock status, and |
| Add products to a guest cart by SKU. Returns server error messages verbatim (e.g. |
| View cart contents and total. |
| Remove products from cart by SKU. |
selver-mcp builds a Selver guest cart via the server API, but viewing and checking out that cart in the browser requires more than just opening selver.ee/cart. Selver's Vue Storefront SPA:
Isolates localStorage per origin, so the cart token can't be injected from outside the selver.ee page
In default guest mode, treats the local (empty) cart as authoritative and ignores the server's items - even though its own API call returns them
After add_to_cart returns a cart_token, instruct Claude to run these steps via chrome-devtools-mcp:
Step 1: Navigate to https://www.selver.ee (establishes the origin), then run:
localStorage.setItem('shop/cart/current-cart-token', JSON.stringify('<CART_TOKEN>'));Step 2: Navigate to https://www.selver.ee/cart.
Step 3: Run this snippet (pulls server items and replays them through the SPA's own add-to-cart flow with forceServerSilence: true, so no duplicate API calls). Note the SKU-existence check before each addItem - without it, items already in cartItems get their qty added (e.g. 0.6 kg cucumber becomes 1.2 kg) because cart/addItem is a merge-qty operation, not replace:
const store = document.getElementById('app').__vue__.$store;
const token = JSON.parse(localStorage.getItem('shop/cart/current-cart-token'));
const serverItems = (await fetch(`/api/cart/pull?cartId=${token}&storeCode=et`).then(r => r.json())).result;
const added = [], skipped = [], mismatched = [];
for (const serverItem of serverItems) {
const existing = store.state.cart.cartItems.find(i => i.sku === serverItem.sku);
if (existing) {
if (Math.abs(existing.qty - serverItem.qty) > 1e-4) {
mismatched.push({ sku: serverItem.sku, client_qty: existing.qty, server_qty: serverItem.qty });
} else {
skipped.push(serverItem.sku);
}
continue;
}
const variant = await store.dispatch('cart/getProductVariant', { serverItem });
if (variant) {
await store.dispatch('cart/addItem', {
productToAdd: variant,
forceServerSilence: true,
});
added.push(serverItem.sku);
}
}
await store.dispatch('cart/syncTotals', { forceServerSync: true });Returns {added, skipped, mismatched}. If mismatched is non-empty, client and server disagree on qty for some SKU - call cart/updateItem with the server qty or ask the user.
Why this works: getProductVariant fetches the full product record and merges in the server's item_id / quote_id. addItem with forceServerSilence: true runs the SPA's full client-side add logic (setting internal flags, triggering reactivity) without calling the server add endpoint - since the items are already there.
add_to_cart / remove_from_cart mutate the server cart only. A browser already open on selver.ee/cart has its own Vuex state that won't update automatically.
After add_to_cart - run the orchestration snippet above (replays new server items through cart/addItem).
After remove_from_cart - run:
const store = document.getElementById('app').__vue__.$store;
const skusToRemove = ['<SKU1>', '<SKU2>'];
for (const sku of skusToRemove) {
const item = store.state.cart.cartItems.find(i => i.sku === sku);
if (item) await store.dispatch('cart/removeItem', { product: item });
}npm install # install dependencies
npm run build # compile TypeScript to dist/
npm test # run unit tests (36 tests)
npm run dev # watch modesrc/
├── index.ts # MCP server entry point (stdio transport)
├── tools/ # MCP tool handlers (Zod schemas, response formatting)
│ ├── search.ts # search_products
│ └── cart.ts # add_to_cart, view_cart, remove_from_cart
├── selver/ # Selver.ee HTTP layer (reusable, no MCP deps)
│ ├── client.ts # SelverClient: search + guest cart API
│ ├── parser.ts # Nutrition string parsing (Estonian comma decimals)
│ └── types.ts # Product, CartItem, etc.
└── storage/
└── cart-token.ts # Read/write ~/.selver-mcp/cart.jsonAdd 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
