Skip to main content
Glama

tesco-ie-grocery-mcp

ci License: MIT

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.mjs

MCP tools:

Tool

Scope

search_products

Search tesco.ie catalogue. Single query or batched queries (max 10 per call), with count/offset pagination. Read-only.

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 fixture

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 tool
search_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.

NameRequiredDescriptionDefault
countNoResults per page for single-query mode (1-48, default 24).
queryNoSingle product search text, e.g. 'milk'.
offsetNoPagination offset for single-query mode (default 0).
queriesNoBatch mode: up to 10 queries in one call.

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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. 1 tool updatev0.2.0
    • First observedsearch_products

TDQS

A4.7/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Allows Large Language Models to interact with Kroger's grocery services, enabling product search, store lookup, and cart management through the Model Context Protocol.
    3
    MIT
  • F
    license
    A
    quality
    A
    maintenance
    A 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.
    2
    7
    132 npm
    37
    -