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., "@mon-marche-mcp Search for 'lait demi-écrémé' and add 1 to cart"
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.
An MCP server that lets an AI assistant search the mon-marché catalog and build a grocery basket from a few instructions. It is a thin, pure-HTTP client over mon-marché's internal API (the Keplr commerce platform) and Constructor.io search — no browser automation.
It deliberately stops at the cart: there is no checkout or payment tool. You review the basket and pay yourself on the website.
Tool | Purpose | Auth |
| Search the catalog (name, slug, price, bio/anti-gaspi) | none |
| Resolve a slug to its article id + SKU | none |
| Set the quantity of one product (by slug) | sign-in |
| Build a whole basket in one call | sign-in |
| Show lines and total | sign-in |
| Remove a line by article id | sign-in |
| Empty the cart (does not delete it) | sign-in |
| List most frequently ordered products | sign-in |
| List bookable delivery slots for the saved address | sign-in |
| Attach a slot — creates the cart | sign-in |
Related MCP server: Mercadona MCP Server
A cart can only hold products once a delivery slot is attached. Authentication is automatic from the env credentials (it uses a bearer token and a session cookie). Follow this sequence:
Find products — my_usual_products (frequently ordered) and/or search_products.
Pick a slot — list_delivery_slots, choose a slotId.
Create the cart — set_delivery_slot(slotId). This creates the cart (or updates the
slot on an existing one) and is required before adding products. Skipping it makes
add_to_cart / add_many_to_cart fail with 404 "Le panier est introuvable".
Add products — add_to_cart / add_many_to_cart (by slug).
Confirm — view_cart.
Checkout and payment are intentionally not automated — review and pay on the website.
npm install
cp .env.example .env # fill in MM_EMAIL / MM_PASSWORD
npm run buildThe account in .env must already have a delivery zone/address configured on the website —
the cart is tied to that.
npm run dev # tsx, reads .env
# or
npm run build && npm start{
"mcpServers": {
"mon-marche": {
"command": "node",
"args": ["/absolute/path/to/mon-marche-mcp/dist/server.js"],
"env": {
"MM_EMAIL": "you@example.com",
"MM_PASSWORD": "your-password"
}
}
}
}Var | Required | Default |
| for cart ops | — |
| for cart ops | — |
| no |
|
| no | public key from the site bundle |
No payment. By design. The assistant fills the cart; you check out manually.
Unofficial API. mon-marché has no public API; this calls the same endpoints the website uses. It may change without notice — keep usage personal, single-account, and low-rate, and review your basket before paying. This may run against the site's terms of service; use at your own discretion.
Cart shape. The authenticated cart is normalized in src/client.ts (normalizeCart).
The upstream API uses cents; tools expose euros. Line quantity comes from
quotation.count, unit price from itemPrice, cart total from
price.quotation.preauthorization (includes shipping + prep fee).
clear_cart only empties. There is no endpoint to fully delete a cart — DELETE /api/cart clears the contents but the cart shell and its delivery slot persist for the
period. So the GET /api/cart → 404 ("no cart") state cannot be reproduced once a cart
exists; set_delivery_slot then just updates the slot instead of creating a new cart.
Reverse-engineered from the site's JS bundle and confirmed live. Base
https://www.mon-marche.fr.
Operation | Call |
Sign in |
|
Search |
|
Resolve product |
|
Usual products |
|
Saved addresses |
|
Delivery slots |
|
Create/set delivery |
|
Add one |
|
Add many |
|
View cart |
|
Empty cart |
|
Payment |
|
MIT. Note: this license covers only this project's code. It grants no rights to mon-marché's API, data, or trademarks, and does not override the site's terms of service.
Build a basket in one call. Each item is a product slug + quantity. Slugs are resolved to article ids and added via the bulk endpoint. Returns per-item status. Requires sign-in AND an existing cart: call set_delivery_slot first, otherwise this fails with 404 'Le panier est introuvable'.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Products to add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses internal behavior: slugs resolved to article IDs, uses bulk endpoint, returns per-item status, and failure condition (404). No annotations provided, so description carries the burden well.
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: first states purpose, second adds critical context. No redundancy.
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 one parameter and no output schema, the description covers prerequisites, behavior, and error condition completely. No gaps.
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 covers 100% of parameters but description adds meaning: 'Each item is a product slug + quantity' clarifies the structure beyond the schema's minimal 'Products to add' description.
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: 'Build a basket in one call' with multiple items specified by product slug and quantity. This is specific, distinct from the sibling add_to_cart which likely adds a single product.
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 states prerequisites: 'Requires sign-in AND an existing cart: call set_delivery_slot first, otherwise this fails with 404.' Provides clear guidance on when to use it and what not to do.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the quantity of one product in the cart (adds it if absent). Accepts a product slug from search_products. Requires sign-in AND an existing cart: call set_delivery_slot first, otherwise this fails with 404 'Le panier est introuvable'.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug from search_products | |
| quantity | No | Quantity to set (default 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the mutative action (set quantity), the add-if-absent behavior, and the prerequisite condition. It could additionally mention idempotency or effects on other cart items, but overall it is transparent.
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?
Three concise sentences with no wasted words. The first sentence front-loads the core purpose, followed by input sourcing and prerequisites. Every sentence 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 no output schema and only two parameters, the description covers purpose, prerequisites, failure mode, and input sourcing. It does not mention return behavior, but that is not critical for this simple tool. Nearly complete.
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 baseline is 3. The description adds meaning by specifying that 'slug' must come from 'search_products' and that 'quantity' is the value to set (not merely add), going beyond the schema descriptions.
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 verb 'Set' and resource 'quantity of one product in the cart' with the added detail that it adds the product if absent. It distinguishes itself from sibling tools like 'add_many_to_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?
Explicitly mentions that the tool accepts a product slug from 'search_products' and requires sign-in and an existing cart, with a prerequisite call to 'set_delivery_slot'. It also warns of a specific failure condition (404 error), providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove all products from the cart.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action without disclosing side effects, reversibility, or confirmation requirements. 'Remove all' implies destructiveness but lacks depth.
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 sentence, front-loaded, no unnecessary words. Efficient and clear.
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 tool, the description is adequate. It could mention that the action is destructive, but the purpose is clear. Output schema is absent, but not critical for this action.
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 has no parameters, so the input schema is complete. The description adds no parameter information, but none is needed. Baseline is high due to zero parameters and 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 action 'Remove all products from the cart', which is a specific verb+resource. It distinguishes from siblings like remove_from_cart (removes one product) and add_to_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?
No guidance on when to use this tool versus alternatives like remove_from_cart. The description only states the action without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a product slug (from search_products) to its article id and SKU. The article id is what the cart uses.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug from search_products |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description clarifies the tool is a read operation resolving a slug to identifiers. It does not mention any side effects, which is acceptable for a lookup tool.
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, no redundant words. Efficiently conveys purpose and output.
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 lookup with one parameter, the description fully covers input, output (article id, SKU), and usage context. No additional information needed.
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 already describes the 'slug' parameter (100% coverage). Description adds value by linking it to 'search_products', enhancing contextual meaning.
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 the tool resolves a product slug to article id and SKU, with specific verb 'resolve' and resource 'product slug'. It distinguishes from siblings by indicating its output is used by 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 specifies that the slug comes from 'search_products', implying correct usage context. However, it does not explicitly state when not to use this tool or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return bookable future delivery slots (id, start, end, order-until deadline, zone) for the account's first saved address. A slot must be set before the cart can hold products.
| 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 bears the full burden. It discloses that the tool returns slots for the account's first saved address, implying read-only behavior. However, it does not disclose potential edge cases (e.g., no address saved) or authentication requirements. The description is adequate but not extra transparent.
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 two efficient sentences. The first sentence delivers the core purpose and output fields. The second sentence adds essential prerequisite context. No extraneous words.
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 (no parameters, no output schema), the description is sufficiently complete. It specifies what is returned (fields) and the scope (first saved address). Minor details like error handling or default behavior could be added but are 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?
The tool has zero parameters, and schema description coverage is 100%. The description does not need to add parameter information. According to guidelines, baseline for 0 parameters is 4, and the description meets this without deficiencies.
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 that it returns bookable future delivery slots with specific fields (id, start, end, order-until deadline, zone) and specifies the context (first saved address). However, it does not explicitly differentiate from sibling tools like set_delivery_slot, which is a closely related tool.
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 noting that a slot must be set before the cart can hold products, which is a prerequisite hint. However, it does not provide explicit when-to-use guidance, alternative tools, or exclusions. The connection to the sibling tool set_delivery_slot is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the account's most frequently ordered products (name, slug, category, price). Useful to reorder or to filter by category (e.g. fruits). Requires sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals it is a read-only operation (returns data), requires authentication, and specifies returned fields. No contradictions or hidden behavior.
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 that front-load the main purpose and provide additional context immediately. No wasted words.
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 zero-parameter tool with no output schema, the description fully covers what the tool returns, its use case, and a prerequisite. Complete given the simplicity.
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 exist; baseline is 4 per guidelines. Description adds no param info, but schema coverage is 100% and no param details are needed.
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 it returns 'the account's most frequently ordered products' with specific fields (name, slug, category, price), distinguishing it from sibling tools like 'get_product' (single product) or 'search_products' (full search).
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?
States it is 'useful to reorder or to filter by category', providing usage context, and mentions 'requires sign-in' as a prerequisite. Does not explicitly exclude alternatives but is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a line by its article id (the id field from view_cart) by setting its quantity to 0.
| Name | Required | Description | Default |
|---|---|---|---|
| articleId | Yes | Article id from view_cart |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the mechanism ('by setting its quantity to 0') but omits important details such as what happens if the article ID is not found, whether the operation is reversible, or any side effects like cart state changes.
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 sentence with 20 words, efficient and to the point. No wasted words.
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 covers the core action but lacks behavioral details (e.g., error handling, idempotency) that would make it fully informative. It is adequate but not exhaustive.
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 parameter is fully described in the schema. The description adds 'the `id` field from view_cart', which largely echoes the schema's description. At baseline 3, the description provides no significant additional meaning beyond the schema.
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 explicitly states the verb 'Remove' and resource 'a line by its article id', clearly identifying the specific action on a single item in the cart. It includes a specific reference to the `id` field from view_cart, making the operation unambiguous.
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 for removing a single product by its article ID but provides no explicit guidance on when to choose this over alternative tools like clear_cart or add_to_cart. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the mon-marché catalog by free text. Returns product name, slug (used by other tools), price in euros, and bio/anti-gaspi flags.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text query, e.g. 'lait demi-écrémé' | |
| limit | No | Max results (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that it returns product name, slug, price, and bio/anti-gaspi flags, and notes slug usage. However, it omits details like pagination, ordering, or query behavior (e.g., fuzzy search).
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, clear and to the point. No extraneous information. Every sentence 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?
Given no output schema, description adequately explains return fields. Low complexity with 2 parameters. Could mention sorting or default behavior, but overall sufficient for a search tool.
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%, baseline is 3. Description adds context about return fields but no additional semantics for parameters beyond what the schema already provides (e.g., example values or constraints).
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 it searches the mon-marché catalog by free text and returns specific fields like product name, slug, price, and flags. It distinguishes from sibling tools like get_product which likely retrieves a single product, and cart tools.
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 explains it's for free-text search and lists returned data, implying its use case. However, it lacks explicit when-to-use vs alternatives (e.g., get_product for exact lookup) or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach a delivery slot (id from list_delivery_slots) to the cart. This creates the cart if it does not exist yet, which is required before adding products. No payment.
| Name | Required | Description | Default |
|---|---|---|---|
| slotId | Yes | Slot id from list_delivery_slots |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that using this tool may create the cart and that no payment is involved, going beyond defaults. No annotations existed, so description carries full burden.
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, front-loaded with purpose, no wasted words. Every sentence 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?
Fully explains function, side effect (cart creation), prerequisite relationship, and financial implication (no payment). Complete for a single-param tool with no output schema.
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 covers slotId description fully (100%), and the tool description only restates it. No added meaning beyond schema.
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 attaches a delivery slot to the cart, creates the cart if needed, and positions it as a prerequisite for adding products. This uniquely identifies its role among 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 states it is required before adding products, giving clear usage context. Lacks explicit when-not-to-use but effectively conveys necessity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current cart: lines (id, name, quantity, unit price) and total.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It states 'Return' which implies read-only behavior with no side effects, providing adequate transparency for this simple retrieval 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 sentence that front-loads the action and returns, with no unnecessary words. Every part is essential.
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 no output schema, the description fully specifies the return values (lines with fields and total), making the tool's behavior complete and predictable.
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?
There are no parameters (schema coverage 100%), so the description adds no parameter info, but this is appropriate. Baseline of 4 is justified for zero-parameter tools.
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 ('Return the current cart') and specifies the returned data structure ('lines (id, name, quantity, unit price) and total'), distinguishing it from sibling tools like add_to_cart or clear_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 usage for viewing the cart, which is straightforward given no parameters and a clear purpose. While no explicit alternatives or exclusions are provided, the context is sufficient for a simple getter tool.
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_many_to_cartadd_to_cartclear_cartget_productlist_delivery_slotsmy_usual_productsremove_from_cartsearch_productsset_delivery_slotview_cartScored across 10 tools
Each tool has a clear, distinct purpose: search, product lookup, cart operations (add, remove, clear, view), delivery slot management, and usual products. Even the two add-to-cart tools serve different needs (single vs bulk), well explained in descriptions.
Most tools follow verb_noun pattern (e.g., search_products, view_cart), but 'my_usual_products' breaks the imperative style, being a descriptive possessive phrase. Otherwise consistent snake_case and verb use.
10 tools cover the full cycle of a grocery ordering workflow: product search, cart management, delivery slot selection, and reordering. No redundancy, each tool earns its place.
Covers core shopping steps (search, cart, slot) but lacks checkout or payment tools, which are essential for a complete ordering flow. Without them, the set feels incomplete for real-world use.
Turn any shopping list into a ready-to-checkout grocery cart across 26 European supermarkets.
AI-agent product catalog: search, lookup & purchase routing over verified merchant data.
AI shopping gateway for product search, inventory, carts, and merchant-hosted checkout.
Agentic commerce gateway: discovery, search, checkout across Shopify/Woo/Odoo/PrestaShop.
