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., "@delhaize-mcp list my recent Delhaize receipts and save any new ones"
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 unofficial Model Context Protocol server that lets an AI assistant fetch your own Delhaize (Belgium) till receipts and this week's promotions, using its own headless browser, without driving your everyday browser and without ever seeing your password.
Unofficial and not affiliated with or endorsed by Delhaize. It reads only your own account, at your request, the way you would read it yourself. Check that your use fits Delhaize's terms of use, keep the request rate low, and do not use it to collect other people's data.
Tool | What it does | Writes |
| Is the saved login still valid? | nothing |
| Lists recent receipts and flags which are not in your record yet | nothing |
| Saves the image of each new receipt |
|
| Saves the missing photos of receipts already in your record |
|
| Saves the raw pages of the weekly promotions listing |
|
It never transcribes items, never edits your record, and never handles your password. It only puts files on disk. Reading the images and recording them is left to you or your assistant, ideally with a check that each receipt's lines sum to its printed total.
Receipts are identified by (date, store, total), so nothing is fetched twice.
Related MCP server: Frisco MCP
Python 3.10+
A Delhaize account with receipts linked to your loyalty card
pip install delhaize-mcp
python3 -m playwright install chromiumThis gives you two commands: delhaize-mcp (the MCP server) and delhaize-receipts (the same actions from the command line).
Log in once. A browser window opens, and you sign in yourself:
delhaize-receipts loginThe session is saved in ~/.delhaize-mcp/profile (or set DELHAIZE_PROFILE). Later runs reuse it headlessly. If it lapses, run login again. That folder holds your session cookies: never commit or share it.
Choose a data folder (optional). By default everything is written to ~/.delhaize-mcp/data. Set DELHAIZE_DATA_DIR to use another folder. Your record of receipts is receipts_all.json in that folder, a JSON list such as:
[{"date": "2026-08-11", "store": "Delhaize Centre", "total": 11.11, "image": "photos/2026-08-11.jpeg"}]image is optional. A receipt without an existing image is what backfill looks for.
Connect it to your assistant.
Claude Code:
claude mcp add delhaize-receipts -- delhaize-mcpClaude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"delhaize-receipts": {
"command": "delhaize-mcp",
"env": {"DELHAIZE_DATA_DIR": "/path/to/your/data"}
}
}
}If the app cannot find delhaize-mcp, use its full path (which delhaize-mcp shows it).
The same actions work without an assistant:
delhaize-receipts status
delhaize-receipts list --months 1 # this month and last
delhaize-receipts fetch --months 1
delhaize-receipts backfill --months 3
delhaize-receipts promosDelhaize renders each receipt as an image inside a client-side app, so the server lets the real page render in a headless Chromium (Playwright) and reads the finished page, exactly as a person would. All parsing rules (French dates, euro amounts, de-duplication, file naming) live in src/delhaize_mcp/core.py, which has no browser dependency and is fully unit-tested.
No browser or network needed:
python3 tests/test_core.py
python3 tests/test_server.pyNothing leaves your machine except the normal page requests to delhaize.be.
No password is read or stored. The login is a browser profile you create yourself.
Your login and data live in ~/.delhaize-mcp, outside the code, so they never end up in a repository.
Built against the French-language Belgian site (delhaize.be/fr). Page changes on Delhaize's side can break it; the parsers are deliberately forgiving, and the tools report what they missed rather than failing silently.
The promotions capture saves raw page data only; interpreting it is up to you.
MIT. See LICENSE.
Check whether the saved Delhaize browser profile is still logged in.
Returns {logged_in: bool, message: str}. If logged_in is false, the user must
run delhaize-receipts login once to refresh the session; this server
cannot and must not perform the login itself.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return structure (logged_in, message), the consequence of being logged out (user must run a separate command), and a critical constraint: the server cannot and must not perform the login itself. This is valuable behavioral context beyond a simple status check.
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 sentences, each front-loaded with the key information. No redundancy; every sentence adds a distinct piece of information: purpose, return shape, and prerequisite action.
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 annotations, no output schema, and zero parameters, the description is complete enough for an agent to use correctly. It explains what the tool does, what it returns, and what to do if the session is invalid. No critical gaps for a simple status-check 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?
There are zero parameters, so the baseline is 4. The description correctly implies no inputs are needed, and it documents the response shape, which compensates for the lack of an output 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?
States a specific verb and resource: check whether the saved Delhaize browser profile is still logged in. An agent can distinguish this from siblings like list_receipts or fetch_promotions, which are about data retrieval, not session validity.
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?
Implies the tool should be used before operations that require an authenticated session, and the description explicitly states a prerequisite: if logged_in is false, the user must run 'delhaize-receipts login'. It doesn't explicitly name which siblings require this check, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the missing PHOTOS of Delhaize receipts that are already in the record
but have no image. A receipt lacks a photo when its record has no existing
image path and no matching file is already in receipts_backfill/.
Not read only: it writes image files into receipts_backfill/. It never edits receipts_all.json and never uses receipts_inbox, so nothing is ingested twice. Each file is named ' ' so it pairs with its receipt.
Returns {missing, found, saved:[...], missed:[...], not_in_window:[...], next_step}.
| Name | Required | Description | Default |
|---|---|---|---|
| months_back | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and meets it: it declares this is not read-only, states exactly what is written (image files into receipts_backfill/) and what is deliberately left untouched, and explains the side-effect-free rationale (no double ingestion). It even documents the file naming convention used for pairing.
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?
Front-loads the core action and condition, then layers on safety constraints and the return shape in three tight paragraphs. Slightly longer than strictly needed but every clause carries operational meaning.
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?
No output schema exists, and the description compensates by enumerating the return keys ({missing, found, saved, missed, not_in_window, next_step}). The only real omission is the unexplained `months_back` parameter, which leaves the time-window semantics undefined.
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 single parameter `months_back` has 0% schema description coverage and is never mentioned in the description, so the agent has no idea it controls the lookback window. This is the one place the description fails to compensate for the schema gap.
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?
States a specific verb and resource ('Save the missing PHOTOS of Delhaize receipts') and defines the exact condition ('record has no existing `image` path and no matching file in receipts_backfill/'). This is enough to separate it from siblings like delhaize_fetch_new_receipts and delhaize_fetch_promotions.
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?
Explains precisely when the tool applies (receipt exists but lacks a photo) and explicitly scopes out adjacent operations ('never edits receipts_all.json and never uses receipts_inbox'). It does not name a sibling alternative for cases that don't qualify, so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the images of any NEW Delhaize receipts (this month and the previous
months_back months) into receipts_inbox, ready for the existing pipeline.
Not read only: it writes image files into receipts_inbox. It is non destructive: it never overwrites, never deletes, and never edits receipts_all.json. A receipt already present in receipts_all.json is skipped.
After it runs, the images can be read (by the assistant or any OCR) and recorded in receipts_all.json by your own process; checking that the lines sum to the printed total before recording is strongly recommended.
Returns {new_count, saved:[{date, store, total, path}], missed:[...], next_step}.
| Name | Required | Description | Default |
|---|---|---|---|
| months_back | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it declares 'Not read only: it writes image files', enumerates the non-destructive guarantees (never overwrites, never deletes, never edits receipts_all.json), and notes that already-recorded receipts are skipped. This is unusually rich behavioral disclosure, with only auth/permission notes absent.
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 purpose and scope are front-loaded in the first sentence, followed by behavioral guarantees and return shape. It is slightly verbose in the downstream-recording guidance, but each sentence carries actionable content.
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?
Despite a sparse schema (one optional param, no description), no annotations, and no output schema, the description supplies the write semantics, skip logic, and even the return keys {new_count, saved, missed, next_step}. An agent has enough to invoke it correctly, though auth requirements are unaddressed.
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 0% and the parameter has no description, but the description compensates by explaining months_back as 'the previous months_back months' relative to the current month, giving the agent the semantic meaning the schema lacks.
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?
States a specific verb (save images), a precise resource (NEW Delhaize receipts), a scope (this month plus the previous months_back months), and a destination (receipts_inbox). The 'NEW ... receipts_all.json is skipped' qualifier clearly separates it from siblings like delhaize_list_receipts and delhaize_backfill_images.
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?
Context is implied: it fetches only new receipts and prepares them for the existing pipeline, and it advises reading images and recording them afterward. However, it never explicitly says when to prefer this over delhaize_backfill_images or delhaize_list_receipts, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read this week's public Delhaize promotions listing (store context from the saved profile) and save each page's raw data into promos_inbox//.
Not read only: it writes JSON files into promos_inbox. It never edits anything else and never judges products; parsing the capture is left to your own code.
Returns {pages, tiles, api_bodies, out_dir, stopped, next_step}.
| Name | Required | Description | Default |
|---|---|---|---|
| max_pages | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a decent job: it flags 'Not read only', names the exact write target (JSON files in promos_inbox/<today>/), and bounds the side effect ('never edits anything else and never judges products'). It lacks detail on auth requirements and rate limiting/network 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?
Tight and front-loaded: purpose and destination directory come first, followed by the write-behavior caveat and the return shape. Every sentence carries information, though the inline return-shape enumeration is somewhat bullet-like prose.
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?
Since there is no output schema, spelling out the return object ({pages, tiles, api_bodies, out_dir, stopped, next_step}) is necessary and helpful, and the write destination is explicit. Auth prerequisites and pagination semantics for max_pages remain unaddressed.
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 description coverage is 0% and the single parameter max_pages (default 40) is never explained in the description. The mention of 'each page' and a 'stopped' return field hints at pagination but does not clarify what max_pages controls or what happens when it is reached, so the description fails to compensate for the coverage gap.
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?
States a specific verb (read/fetch) and a specific resource (this week's public Delhaize promotions listing) plus the side effect (saving raw page data into promos_inbox/<today>/). The resource domain is unambiguous against siblings like delhaize_list_receipts or delhaize_fetch_new_receipts, which deal with receipts rather than promotions.
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?
Gives clear context for when it applies: use it to read the current week's public promotions using store context from the saved profile, and it explicitly scopes responsibility by saying parsing/judging products is left to the caller's own code. It stops short of naming alternatives or stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Delhaize receipts for the current month and the previous months_back
months, flagging which are not yet in receipts_all.json.
Read only: opens nothing and writes nothing. Use this to preview before fetching. months_back=1 (the default) covers this month and last, which is enough to catch a month boundary.
Returns {count, new_count, receipts:[{date, store, total, points, savings, is_new}]}.
| Name | Required | Description | Default |
|---|---|---|---|
| months_back | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it declares "Read only: opens nothing and writes nothing," plus the is_new flag semantics relative to receipts_all.json. It does not discuss auth requirements or rate limits, but the side-effect profile is unambiguous.
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 short blocks, front-loaded with scope and the read-only guarantee, then the default rationale, then the return shape. No sentence is filler.
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?
Although no output schema and no annotations exist, the description covers both gaps by describing the returned object keys and the read-only nature. A brief note on what remains untouched (e.g., that fetch is a separate step with its own side effects) would make it fully self-contained.
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 0% and the single parameter has no schema description, so the description must compensate. It does: months_back is defined as extending the window backward and the default of 1 is explained as covering this month and last to catch a month boundary.
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 opening sentence states a specific verb (list), resource (Delhaize receipts), scope (current month plus months_back), and a distinctive behavior (flagging receipts absent from receipts_all.json). It is clearly separable from siblings like delhaize_fetch_new_receipts and delhaize_fetch_promotions.
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?
"Use this to preview before fetching" gives an explicit use context that routes the agent toward the fetch sibling, and the note that months_back=1 catches a month boundary explains the default. There is no explicit when-not-to-use statement, keeping it just below a 5.
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.0delhaize_auth_statusdelhaize_backfill_imagesdelhaize_fetch_new_receiptsdelhaize_fetch_promotionsdelhaize_list_receiptsScored across 5 tools
Each tool targets a distinct action in the receipts lifecycle, but delhaize_fetch_new_receipts and delhaize_backfill_images both 'fetch receipt images' and could be confused at first glance; the descriptions do clarify (new receipts vs. missing photos for existing records).
All tools share the delhaize_ prefix in consistent snake_case, mostly following a verb_noun pattern (list_receipts, fetch_new_receipts, backfill_images, fetch_promotions). delhaize_auth_status is a minor deviation using a noun-style status name rather than an action verb.
Five tools is well-scoped for a focused receipts/promotions workflow, with each tool earning its place (auth check, preview, two distinct fetch operations, promotions fetch). No redundant or filler tools.
The surface covers the key read/write lifecycle: connectivity check, listing, fetching new receipts, backfilling missing images, and capturing promotions. There is no tool to view/search the existing receipts_all.json corpus or to record entries, though the design intentionally offloads recording to the assistant.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Automate any website: discover, run and create browser scripts that work behind logins.
