Provides tools to search products, retrieve basket, add/update/remove items, and manage substitutions on Intermarché's online grocery platform.
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., "@mcp-intermarche-drive search for organic milk"
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.
Unofficial MCP server for Intermarché Courses / Drive. It searches the catalogue of the store selected in Intermarché and reads or updates the current basket through one visible Chromium tab.
It does not place orders. Checkout, payment, account changes, and delivery-slot booking stay on the website.
This is an early adapter for a private, undocumented web API.
TypeScript build, unit tests, MCP initialization, tools/list, and tool annotations pass locally.
Product search and basket retrieval were checked against the live Intermarché frontend on 2026-07-27.
Basket writes are covered by tests against the event contract observed in the site. The automated live smoke test is deliberately read-only, so it does not prove that every write still works after an Intermarché release.
The project is not published to npm. Install it from source.
Review the basket in the visible Intermarché tab before checkout. A green test suite cannot make an undocumented retail API stable.
Related MCP server: Frisco MCP
Intermarché puts DataDome in front of its shopping site. A separate HTTP client with copied cookies is both fragile and a poor security boundary. This server uses the browser session that the user can already see:
It attaches to Chromium over the Chrome DevTools Protocol (CDP).
It keeps one Intermarché tab on https://www.intermarche.com.
It runs window.fetch in that page, so the browser applies its own cookies and challenge state.
It serializes requests and adds a small delay between them.
If DataDome shows a challenge, the server stops retrying and tells the user to handle it in the browser.
This is not a CAPTCHA solver or a DataDome bypass. Login, store selection, challenge handling, and checkout remain visible browser actions.
The adapter does not export the browser cookie jar. Its page helper extracts only the values derived from itm_device_id and itm_usid, which Intermarché's frontend sends as request headers. Those values stay in process memory and never appear in MCP results, logs, or project files. See security boundaries for the limits of that guarantee.
The browser/CDP and throttling approach was adapted from skunkobi/mcp-leclerc-drive. The Intermarché implementation is not a renamed Leclerc client:
Area | Leclerc reference | This project |
Store | Locator tools plus a persisted store/host | Store and Drive mode come from the visible Intermarché tab |
Catalogue | Product records parsed from store HTML | JSON product endpoint under |
Basket | Form-encoded mutations and HTML cart extraction | Event-based JSON synchronization with the previous basket snapshot |
Substitutions | No separate contract | Explicit tool; additions default to refusal |
Browser target | General page target reused for the store host | One Intermarché tab, or one blank tab; unrelated tabs are left alone |
The full design review is in docs/design-review.md. Upstream attribution and license text are in NOTICE.
Tool | Reads or writes | Contract |
| Read | Reports CDP state, active store reference, delivery mode, whether a basket id was found, and visible DataDome action required. |
| Read | Searches the active store. Returns Intermarché |
| Read | Returns the complete normalized basket and total. |
| Write | Increases the current quantity by |
| Write | Sets an absolute quantity. |
| Write | Removes one product line. |
| Write | Sets substitution consent for a product already in the basket. |
product_id means the id returned by search_product or get_cart. It is normally Intermarché's itemId, not the EAN printed on the package.
Cart mutations happen as soon as the MCP client calls the tool. There is no second confirmation layer inside this server; the MCP host is responsible for its own approval UI.
Node.js 22 or newer. The server uses Node's built-in WebSocket.
A visible Chromium-family browser with CDP enabled.
A graphical desktop session. Automatic launch is not suitable for a display-less server.
An Intermarché store and the Drive withdrawal mode selected in the dedicated browser profile.
Automatic browser detection currently expects:
macOS: Google Chrome in /Applications;
Windows: Google Chrome in Program Files;
Linux: a chromium executable on PATH.
Set INTERMARCHE_CHROME_PATH when your browser lives elsewhere, such as google-chrome on Linux.
git clone https://github.com/nicolasestrem/mcp-intermarche-drive.git
cd mcp-intermarche-drive
npm ci
npm run build
npm test
npm run smokeThe repository is private, so the clone command requires GitHub access to it.
The executable entry point after the build is:
/absolute/path/mcp-intermarche-drive/dist/src/index.jsUse the built file as a local stdio server. The common JSON form is:
{
"mcpServers": {
"intermarche-drive": {
"command": "node",
"args": ["/absolute/path/mcp-intermarche-drive/dist/src/index.js"],
"env": {
"INTERMARCHE_AUTO_LAUNCH": "true"
}
}
}
}Replace the path with the real absolute path. Do not use npx mcp-intermarche-drive; there is no published package.
The server is lazy about browser startup. Starting the MCP process does not open Chromium immediately. The first tool call that needs the browser, normally browser_status, connects to CDP and launches the dedicated profile if necessary.
Start or reload the MCP client after adding the configuration.
Call browser_status. A dedicated Chromium profile should open on CDP port 9222.
In its single tab, open Intermarché if needed.
Select the intended store and the Drive withdrawal mode.
Log in if you want to use the account basket. Anonymous baskets also work when the site permits them.
Resolve any DataDome challenge in the visible tab.
Call browser_status again, then try a product search.
Keep one Intermarché tab in this profile. Multiple tabs can hold different store or basket state, and the server has no sensible way to guess which one you meant.
Set automatic launch off in the MCP environment:
{
"env": {
"INTERMARCHE_AUTO_LAUNCH": "false",
"INTERMARCHE_CHROME_PORT": "9222"
}
}Then start Chromium with a dedicated profile and a loopback-only debugging endpoint:
chromium \
--remote-debugging-address=127.0.0.1 \
--remote-debugging-port=9222 \
--user-data-dir="$HOME/.mcp-intermarche-drive/chrome" \
--no-first-run \
--no-default-browser-check \
about:blankDo not point this server at your everyday browser profile. CDP grants control over the attached tab, and the profile directory contains a persistent browser session.
Variable | Default | Meaning |
|
| Loopback CDP port. |
| platform default | Chromium or Chrome executable. |
|
| Dedicated persistent browser profile. |
|
| Launch the browser when no CDP endpoint is listening. |
|
| Unsupported for normal use; it is more likely to trigger anti-bot checks and removes manual challenge handling. |
| browser-derived | Diagnostic fallback for store discovery. It must match the store selected in the tab. It does not switch stores. |
|
| Compatibility metadata fallback reported in browser context. It does not choose the store catalogue. |
|
| Minimum delay between queued web requests. |
|
| Random delay added to the minimum. |
|
| Bounded retries for HTTP 403 and 429. |
|
| Base for exponential retry backoff. |
|
| Timeout for CDP commands and browser fetches. |
Avoid setting INTERMARCHE_PDV_REF unless browser-state discovery is broken. An override that points at another store can mix that store's API path with the basket state held by the visible tab.
CDP is account-level browser access. Keep it on 127.0.0.1; never expose port 9222 to a LAN, container bridge, tunnel, or public interface.
Use a dedicated profile only for Intermarché. Any local process that can access the CDP port or profile directory should be treated as trusted.
Browser cookies still accompany same-origin requests because the fetch runs in the page. The server does not return the cookie jar through MCP or persist cookie values itself.
The browser-state snapshot is limited to store and basket keys. Do not replace it with a dump of local storage when debugging.
Cart tools modify the real current basket. There is no checkout tool, but basket changes are still external side effects.
Use the project only with your own account and in accordance with the site's terms.
browser_status says CDP is unavailableCheck that the configured browser executable exists.
Check that another process is not using the port: change INTERMARCHE_CHROME_PORT on both the browser and MCP server if needed.
On Linux, set INTERMARCHE_CHROME_PATH=google-chrome if chromium is not installed.
On a remote or headless machine, launch the visible browser in the desktop session and use INTERMARCHE_AUTO_LAUNCH=false.
Select the store and Drive mode in the attached tab, then call browser_status again. Store selection belongs to the website. INTERMARCHE_PDV_REF is a last-resort fallback, not a replacement for the visible selection.
Stop calling tools. Bring the existing Intermarché tab to the expected page, complete any visible challenge, and wait before retrying. Do not open more tabs or increase the retry count to hammer through it.
If the browser session or login changed, restart the MCP process so cached request identifiers are rebuilt from the current page.
Close extra Intermarché tabs in the dedicated profile. Remove a stale INTERMARCHE_PDV_REF override. Confirm the store and withdrawal mode in the website before making another cart change.
Reuse the already-running CDP instance on the configured port, or close that dedicated Chromium process before starting another one. Do not reuse the same profile directory from two browser processes.
npm run typecheck
npm test
npm run smoke
npm audit --audit-level=low
npm pack --dry-runWhat these checks cover:
browser-state extraction from a narrow set of keys;
normalization of current product and basket response shapes;
absolute quantity and explicit substitution events;
serialization of concurrent cart mutations;
a real JSON-RPC initialize and tools/list exchange over stdio;
MCP read-only, idempotent, and destructive annotations.
The optional live smoke test connects to the configured browser and performs only browser_status, product search, and basket retrieval:
npm run build
INTERMARCHE_AUTO_LAUNCH=false npm run smoke:liveIt does not add or remove products. Run it manually, never as unattended public CI.
Adapter details and the revalidation checklist live in:
Intermarché can change these private endpoints or storage shapes without notice.
Store selection is manual; there are no find_stores or set_store tools.
One server instance operates one tab, one browser profile, and one active store.
The login-status field is best-effort. The website is the authority on whether the session is authenticated.
Headless operation is not a supported path.
There is no checkout, order placement, payment, slot booking, or account-management tool.
Only stdio transport is implemented.
MIT. See LICENSE for this project and NOTICE for the upstream mcp-leclerc-drive attribution and MIT license text.
Intermarché is a trademark of its respective owner. This project is unofficial and is not affiliated with or endorsed by Intermarché.
Ajoute une quantité au produit. Les substitutions sont REFUSÉES par défaut; ne les accepte que sur demande explicite de l'utilisateur.
| Name | Required | Description | Default |
|---|---|---|---|
| quantity | No | Quantité à ajouter | |
| product_id | Yes | Identifiant retourné par search_product | |
| accept_substitution | No | Autoriser un produit de substitution; false par défaut |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint false, destructiveHint false), the description reveals that substitutions are refused by default, which is a key behavioral trait. It does not contradict annotations.
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 concise sentences with no extraneous information. The key action and default behavior are front-loaded.
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 simple tool (3 params, no output schema), the description is sufficiently complete. It covers the main behavior and distinguishes from siblings. Minor omission of error handling, but not 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?
Schema coverage is 100%, but the description adds semantic value by clarifying the default behavior for accept_substitution and emphasizing that substitutions require explicit user request.
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 'adds a quantity to the product' with the specific verb 'add' and resource 'product/cart'. It distinguishes from siblings by explicitly noting that substitutions are refused by default, contrasting with set_substitution.
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 guidance on when to accept substitutions (only on explicit user request). While it doesn't explicitly list when not to use the tool, the sibling tools (update_quantity, set_substitution) imply alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vérifie la connexion à l'unique onglet Chromium Intermarché, le magasin actif et un éventuel challenge DataDome. À appeler avant les courses.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, etc. Description adds specifics about what is checked, enhancing transparency without contradiction.
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: one for purpose, one for usage. No unnecessary words, front-loaded.
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?
Simple tool with no parameters and no output schema; description covers what it does and when to use it. Fully adequate.
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?
No parameters, so description need not explain. Baseline 4 for zero params with full schema coverage.
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 checks connection, active store, and DataDome challenge, distinguishing it from product/cart siblings.
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?
Explicitly says 'À appeler avant les courses' (call before shopping), providing clear usage context. No direct alternatives, but implied by sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lit le panier complet du magasin et du mode de retrait actifs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds value by specifying it reads the 'complete' cart for active store and pickup mode, providing context beyond annotations.
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?
Single concise sentence in French that is front-loaded with the action. No wasted words; every part is informative.
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 simple read operation with no parameters and comprehensive annotations, the description is complete enough. It specifies what is read and the active scope. Lacks details on return format, but no output schema exists.
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?
Input schema has zero parameters, so description need not add parameter info. Baseline for 0 params is 4, and description does not need to compensate.
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?
Description clearly states verb 'Lit' (reads) and resource 'panier complet' (complete cart) with scope 'magasin et mode de retrait actifs' (active store and pickup mode). Distinguishes from sibling tools like add_to_cart, remove_from_cart which modify 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?
Description implies usage for viewing the cart before modifications, but does not explicitly state when to use this tool vs alternatives like search_product or browser_status. No exclusions or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retire complètement un produit du panier.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Identifiant produit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and idempotentHint=true, which the description confirms with 'completely remove'. However, the description does not add new behavioral details beyond what annotations already provide, such as behavior when product is not in the cart.
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, efficient sentence with no wasted words. It is appropriately concise for this simple tool.
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 simplicity of the tool (one parameter, no output schema, clear annotations), the description is minimally adequate but lacks information about error states or prerequisites. It could benefit from mentioning that the product must currently be in the cart.
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 already covers the single parameter 'product_id' with a description ('Identifiant produit'), achieving 100% coverage. The tool description adds no additional meaning or usage context for the parameter.
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 'Retire complètement' (completely remove) and the resource 'un produit du panier' (a product from the cart). It effectively distinguishes from sibling tools like add_to_cart and update_quantity by indicating complete removal rather than adding or modifying quantity.
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 no guidance on when to use this tool versus alternatives, nor does it specify prerequisites or conditions. It simply states the action without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche dans le catalogue du magasin Intermarché actuellement sélectionné. Retourne les identifiants stables à passer aux outils panier.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page, à partir de 0 | |
| query | Yes | Termes de recherche, ex. 'thon au naturel 80g' | |
| page_size | No | Nombre de résultats (1 à 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, openWorld, idempotent, and non-destructive hints. The description adds that it returns stable identifiers for cart tools, which is useful behavioral context beyond annotations. No contradiction.
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 concise sentences in French, front-loaded with purpose, no redundant information. Every word earns its place.
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 presence of annotations covering safety/idempotency and no output schema, the description adequately explains the tool's purpose and return value. Could mention pagination behavior or store context more explicitly, but still complete enough.
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?
Schema coverage is 100% with clear parameter descriptions (query, page, page_size). The description does not add new parameter info but explains the purpose of the output (stable identifiers). Baseline is appropriate.
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 searches the catalog of the currently selected Intermarché store and returns stable identifiers for cart tools. It distinguishes from sibling tools (cart manipulation) by specifying it's a search/read operation.
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?
Usage is implied (search before cart operations), but no explicit when-to-use or when-not-to-use guidance is provided. Siblings are all cart tools, so the distinction is clear, but alternatives or exclusions are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Active ou désactive explicitement les substitutions pour une ligne déjà présente dans le panier.
| Name | Required | Description | Default |
|---|---|---|---|
| accept | Yes | true pour accepter, false pour refuser | |
| product_id | Yes | Identifiant produit déjà dans le panier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this tool is a mutation (readOnlyHint: false), potentially destructive (destructiveHint: true), and idempotent (idempotentHint: true). The description adds that it 'explicitly' enables/disables, but does not elaborate on side effects, error conditions, or permission requirements. With annotations present, the description provides minimal extra behavioral context.
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, clear sentence that wastes no words. It is front-loaded with the action and object, making it easy for an agent to quickly understand the tool's function.
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 (2 parameters, no output schema) and the presence of informative annotations, the description adequately covers the core functionality. However, it could be more complete by mentioning what happens if the product is not in the cart or if the substitution state change fails. Minor gap but not critical for basic use.
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 already provides full descriptions for both parameters (product_id and accept) with 100% coverage. The tool description adds no additional meaning or context beyond what the schema states. Baseline score of 3 is appropriate.
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: explicitly enable or disable substitutions for a cart line. It uses a specific verb (active/désactive) and resource (substitutions for a line in cart). Among sibling tools, none handle substitutions, so it is uniquely identified.
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 usage context by specifying 'pour une ligne déjà présente dans le panier' (for a line already in the cart), but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. The context is implied but not directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fixe la quantité absolue d'un produit du panier. Une quantité de 0 le retire.
| Name | Required | Description | Default |
|---|---|---|---|
| quantity | Yes | Nouvelle quantité absolue | |
| product_id | Yes | Identifiant produit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds that quantity 0 removes the product, which is important. However, it does not detail other behavioral aspects such as whether it overwrites existing quantity or any prerequisites, leaving some gaps.
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 short, efficient sentences front-load the verb and core behavior. No waste; every word adds value.
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 tool with two parameters and no output schema, the description covers the primary behavior (absolute set and removal) and is consistent with annotations. It does not address edge cases like invalid product ID, but that is acceptable given the tool's simplicity and the annotations.
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?
Schema coverage is 100%, so the description adds meaning beyond the schema by clarifying that setting quantity to 0 removes the product. This supplements the property description of 'Nouvelle quantité absolue'.
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 sets the absolute quantity of a cart product and specifies that a quantity of 0 removes it. This distinguishes it from siblings like add_to_cart (incremental) and remove_from_cart (unconditional removal).
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 use cases (set exact quantity or remove by setting 0) but does not explicitly state when not to use it or mention alternatives like add_to_cart for incremental changes. Sibling tools provide context, but the description itself lacks direct guidance.
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. Dates show when Glama detected each change.
v0.1.0add_to_cartbrowser_statusget_cartremove_from_cartsearch_productset_substitutionupdate_quantityEvery tool has a clearly distinct purpose: browser_status checks connection, search_product looks up products, get_cart reads the cart, add_to_cart/remove_from_cart/update_quantity manage items, and set_substitution handles substitution settings. No overlap.
All tool names follow a consistent verb_noun pattern in snake_case, such as search_product, add_to_cart, get_cart. The naming is predictable and uniform.
With 7 tools, the set is well-scoped for a drive service. It covers all essential cart operations without being excessive or insufficient.
The tools cover connection check, product search, and full CRUD for cart items. Minor gaps like clearing the entire cart or switching stores are missing, but the core workflows are complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Automate any website: discover, run and create browser scripts that work behind logins.
Turn any shopping list into a ready-to-checkout grocery cart across 26 European supermarkets.
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nicolasestrem/mcp-intermarche-drive'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
