tesco-ie
Read-only search of the Tesco Ireland (tesco.ie) grocery catalogue, returning product names, brands, EUR prices, unit prices, promo labels and product URLs. Supports single queries or batched queries (up to 10 per call) with count/offset pagination; basket, login and checkout operations are intentionally not supported.
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., "@tesco-iesearch Tesco Ireland for milk, bread and free range eggs"
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.
tesco-ie-grocery-mcp
MCP server and CLI for the Tesco Ireland (tesco.ie) grocery catalogue.
Phase 1 is read-only: product search with names, brands, EUR prices, unit prices, promo labels and product URLs. No account is needed for this phase.
Not supported, by design: basket, delivery slots, login and checkout. Verified 2026-10-25, tesco.ie requires the user's own account even to add an item to the basket (an anonymous "Add" redirects to the login page), and placing an order always stays with the user in their own browser. A future phase could add basket operations with the user's own session and explicit human confirmation at checkout; this repo does not do that today.
Why the extraction approach
Tesco has no public developer API for groceries (the historical Tesco Labs
developer portal is gone). The tesco.ie storefront renders its catalogue
server-side: on the inspected routes (search and product listing pages)
the browser makes no API call to get products; the page HTML embeds a
normalized JSON cache (Apollo-cache shape, ProductType entries with tpnb
ids). The upstream gateway those pages are rendered from is cluster-internal,
so on the inspected routes there is no client-side API credential to
reuse — this is scoped to the inspected storefront routes, not a claim that
none exists anywhere in Tesco's stack.
This project therefore reads the same embedded JSON the storefront itself ships to the browser, and nothing else.
Related MCP server: Kroger MCP Server
Anti-bot posture
The storefront is fronted by Akamai: plain HTTP clients (curl, node fetch)
get 403 even with a browser User-Agent (verified 2026-10-25). This project
fetches pages with a real Chromium via Playwright and enforces a 2 s minimum
gap between page loads. It ships no anti-bot bypass: no fingerprint
spoofing, no CAPTCHA solving, no aggressive retrying.
Status (2026-10-25): experimental prototype, not a demonstrated live
connector. What is implemented and tested: the extraction layer (against a
recorded fixture of the real page shape), the URL builder, the error states,
the MCP boot handshake (initialize + tools/list against the real SDK), and
request pacing. What is NOT demonstrated: a successful end-to-end live fetch.
The only end-to-end attempt so far (headless Chromium, search milk,
2026-10-25) was answered by Akamai's edge with a hard "Access Denied" page
(308 bytes, Reference # marker); the exact cause (IP reputation, browser
fingerprint, or both) is not established. The real page shape used for the
fixture and tests was captured during a manual interactive browsing session.
Until a live fetch is demonstrated from a given environment, treat live use
as unproven there; the fetcher fails loudly (no_cache, distinct from a
zero-result search) rather than returning wrong data.
Install and use
npm install
npx playwright install chromium # one-time browser download
# CLI (each argument is a separate query; quote multi-word terms)
npx tesco-ie search "milk"
npx tesco-ie search --count 10 "milk" "bread" "free range eggs"
# MCP (stdio), e.g. from Claude Code:
claude mcp add tesco-ie -- node /path/to/tesco-ie-grocery-mcp/src/server.mjsMCP tools:
Tool | Scope |
| Search tesco.ie catalogue. Single |
Batched queries run sequentially through the process-wide pacing floor
(MIN_INTERVAL_MS, 2 s, enforced in the fetcher; the test suite guards the
constant, it does not measure live spacing). Each query returns its own
status (ok, no_cache, fetch_error) so one blocked or failed search
never sinks the rest of the batch.
Development
npm test # node:test, extraction against a recorded fixtureLegal and etiquette
Unofficial project, not affiliated with or endorsed by Tesco. Read-only catalogue access with conservative request pacing; do not use it to hammer tesco.ie. Product data belongs to Tesco; use it within their site terms.
Acknowledgements: the multi-country grocery-provider pattern and the per-country viability notes that motivated this repo come from open-supermarkets (MIT) and the provider evaluation notes in uk-grocery-cli.
Available Tools
1 toolsearch_productsA
Search the Tesco Ireland (tesco.ie) grocery catalogue. Accepts one query or a batch of up to 10 queries (one per shopping-list item) run sequentially with conservative pacing. Returns, per query, matching products with name, brand, price in EUR, unit price, promo label and product URL, or an explicit status when the fetch was blocked or failed. Read-only; no account needed. Basket and checkout are NOT supported: tesco.ie requires the user's own account, and ordering always stays with the user.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Results per page for single-query mode (1-48, default 24). | |
| query | No | Single product search text, e.g. 'milk'. | |
| offset | No | Pagination offset for single-query mode (default 0). | |
| queries | No | Batch mode: up to 10 queries in one call. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so well: read-only, no account required, conservative pacing, explicit failure/blocked statuses, and unsupported basket/checkout actions. These details are directly relevant to safe and correct invocation.
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 front-loaded, efficient, and well structured. Each sentence adds useful information about scope, return fields, limitations, or behavior without unnecessary repetition.
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 there are no annotations and no output schema, the description sufficiently explains return fields and failure statuses. It also covers account requirements and operational limits, leaving no significant gaps for calling the tool correctly.
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 count, offset, query, and queries are already documented. The description adds useful semantic context for batch mode by explaining that queries can represent shopping-list items and are run sequentially with conservative pacing.
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 states a specific verb and resource: searching the Tesco Ireland grocery catalogue. It also clarifies single-query and batch modes, making the tool’s role unambiguous even without 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?
It explicitly covers when to use single-query versus batch mode, including batch size limits and shopping-list usage. It also clearly states when the tool is not appropriate by excluding basket and checkout operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.2.0- First observed
search_products
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of misselection between competing options. Its purpose (read-only grocery catalogue search with batched queries) is stated unambiguously in the description.
The single name `search_products` follows a clean verb_noun snake_case convention and clearly signals both action and resource. With one tool there is no risk of convention drift.
A single tool is thin for a grocery domain, even if the batch-query parameter stretches its reach across a whole shopping list. The author deliberately excluded basket/checkout, so the narrow surface is defensible but still borderline.
Search covers the core read-only workflow, including batch queries, pricing, promos, unit prices, and explicit failure statuses. Minor gaps remain (no product-detail lookup by URL/ID, no category browsing or store/availability info), which an agent can work around.
Maintenance
Related MCP Connectors
Live search across 250,000+ verified UK and Canada retail deals. Read-only, no auth required.
Search ~8.5M products from 2,500+ Central European e-shops. Semantic, keyword, GTIN lookup.
Federated commerce search across independent WooCommerce merchants. Keyless, read-only MCP server.
Search and read the aicoolies catalog of AI and developer tools via a remote MCP knowledge graph.
Related MCP Servers
- AlicenseCqualityCmaintenanceA Model Context Protocol server enabling product searches across e-commerce platforms, price history tracking, and product specification-based searches using natural language prompts.290 PyPI19MIT
- AlicenseNot gradedqualityDmaintenanceAllows Large Language Models to interact with Kroger's grocery services, enabling product search, store lookup, and cart management through the Model Context Protocol.3MIT
- FlicenseAqualityAmaintenanceA Model Context Protocol server for real-time Swiss grocery shopping that searches and compares products across 8 major Swiss retailers (Migros, Coop, Aldi, Denner, Lidl, Farmy, Volgshop, Otto’s), normalizes per-unit prices, surfaces promotions, computes optimal multi-store shopping plans, and works with any MCP-compatible client without API keys or accounts.27132 npm37-
- AlicenseNot gradedqualityDmaintenanceEnables semantic and full-text search over the official Model Context Protocol registry to discover MCP servers for integration.10Apache 2.0