coles-woolworths
This server allows AI assistants to search and compare product information from Coles and Woolworths supermarkets in Australia.
Product Search: Search for products at both retailers using specific queries
Price Comparison: Compare prices and retrieve product details from both supermarkets
Store Selection: Optionally specify a Coles store ID to search within a particular store
Result Control: Limit the number of products returned in search results
Supports environment variable configuration for API keys and other settings through .env files
Provides repository access for cloning and installing the MCP server
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., "@coles-woolworthsfind the price of milk at Coles and Woolworths"
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.
Coles and Woolworths MCP Server
An experimental Model Context Protocol (MCP) server implementation that allows AI assistants to search for product information from Australia's major supermarkets: Coles and Woolworths. This server exposes product search functionality through the MCP protocol, making it easy for AI assistants to retrieve product pricing and details.
Demo
Use with Claude Desktop
https://github.com/user-attachments/assets/0af3b07a-578a-4112-acfe-e7a7eee31161
Related MCP server: Katzilla MCP
Features
Product Search: Search for products at both Coles and Woolworths supermarkets
Price Comparison: Get pricing information from both retailers in a consistent format
Store Selection: Search specific Coles stores using store IDs
Result Limiting: Control how many products are returned in search results
Quick Start for Claude Desktop, Cursor, and other clients
Clone this repository
git clone https://github.com/hung-ngm/coles-woolworths-mcp-server.gitNavigate to the project directory
cd coles-woolies-mcpInstall the prerequisites
Configure your MCP client to use this server (see Integrating with MCP Clients)
Installation
Prerequisites
Python 3.8 or higher
The
uvpackage manager
Installing uv
uv is a fast Python package installer and resolver. To install:
macOS/Linux:
curl -LsSf https://astral.sh/uv/install.sh | shWindows:
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"Setup
Clone the repository and navigate to the project directory
Use
uvto install dependencies:
# Install dependencies
uv pip install fastmcp requests python-dotenvConfiguration
The server uses the following environment variables:
COLES_API_KEY: API key for accessing the Coles API (required for Coles product searches)
You can set these variables in a .env file in the project directory.
Running the Server
To run the Coles and Woolworths MCP server directly using uv:
uv run main.pyBy default, the server runs with stdio transport for MCP client integration.
Integrating with MCP Clients
Claude Desktop Configuration
To use the Coles and Woolworths MCP server with Claude Desktop:
Locate your Claude Desktop configuration file (usually
claude_desktop_config.json)Add the following configuration to the
mcpServerssection:
{
"mcpServers": {
"coles-woolies-mcp": {
"command": "uv",
"args": [
"run",
"--with",
"fastmcp",
"--with",
"requests",
"--with",
"python-dotenv",
"fastmcp",
"run",
"/full/path/to/coles-woolies-mcp/main.py"
]
}
}
}Replace /full/path/to/coles-woolies-mcp/main.py with the absolute path to your main.py file.
Restart Claude Desktop for the changes to take effect
Cursor IDE Configuration
To integrate with Cursor IDE:
Open your Cursor configuration file
Add the following to the
mcpServerssection:
{
"mcpServers": {
"coles-woolies-mcp": {
"command": "uv",
"args": [
"run",
"--with",
"fastmcp",
"--with",
"requests",
"--with",
"python-dotenv",
"fastmcp",
"run",
"/full/path/to/coles-woolies-mcp/main.py"
]
}
}
}Available Tools
The Coles and Woolworths MCP server exposes the following tools:
get_coles_products: Search for products at Coles supermarkets with optional store selectionget_woolworths_products: Search for products at Woolworths supermarkets
Example Usage in Claude
You can use the tools in Claude like this:
Could you check the price of Cadbury chocolate at both Coles and Woolworths?Claude will then use the appropriate tools to search for the products and return the results.
Requirements
Python 3.8 or higher
fastmcp package
requests package
python-dotenv package
MCP-compatible client (Claude Desktop, Cursor, etc.)
Available Tools
2 toolsget_coles_productsC
Search for products at Coles.
Args:
query: The product search query.
store_id: The Coles store ID to search in.
limit: Maximum number of products to return.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| store_id | No | 0584 | |
| limit | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a search operation but doesn't describe what happens when no results are found, whether results are paginated, what authentication might be required, rate limits, or what the return format looks like. For a search tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 appropriately sized and well-structured with a clear purpose statement followed by parameter explanations. The bullet-point format for parameters is efficient. However, the first sentence could be more specific (e.g., 'Search for grocery products at Coles supermarkets'), and the parameter descriptions could be slightly more 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?
For a search tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (product names, prices, availability?), error conditions, authentication requirements, or how results are ordered. The sibling tool context isn't leveraged to provide comparative guidance, leaving significant gaps for an AI agent.
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 description lists all three parameters with brief explanations, but the input schema has 0% description coverage. The description adds basic semantic meaning (e.g., 'The product search query' for 'query'), but doesn't provide format details, constraints, or examples. It compensates somewhat for the schema's lack of descriptions but doesn't fully address the coverage gap, earning a baseline score.
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 as 'Search for products at Coles' - a specific verb ('Search') and resource ('products at Coles'). It distinguishes from the sibling tool 'get_woolworths_products' by specifying the retailer. However, it doesn't explicitly mention what type of search this is (e.g., text-based product search vs. category browsing), which prevents a perfect score.
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. While the sibling tool name suggests a different retailer (Woolworths), the description doesn't mention this alternative or provide any context about when to choose Coles over Woolworths. There's no information about prerequisites, constraints, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_woolworths_productsC
Search for products at Woolworths.
Args:
query: The product search query.
limit: Maximum number of products to return.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions searching but doesn't describe what the search returns (e.g., product details, pricing, availability), whether it requires authentication, rate limits, or error conditions. This leaves significant gaps in understanding the tool's 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?
The description is appropriately sized with a clear purpose statement followed by parameter details. It's front-loaded with the main function and uses a structured format for parameters, though the 'Args' section could be integrated more smoothly into the narrative flow.
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 complexity of a product search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the return values look like (e.g., product list format), error handling, or contextual constraints like availability by region, making it inadequate for full understanding.
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 description includes an 'Args' section that lists and briefly describes both parameters ('query' and 'limit'), adding meaning beyond the input schema which has 0% description coverage. However, it doesn't provide details like query syntax examples, limit constraints, or default behavior, leaving some semantic gaps.
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 with a specific verb ('Search') and resource ('products at Woolworths'), making it immediately understandable. However, it doesn't explicitly differentiate from its sibling tool 'get_coles_products' beyond the brand name, which is implied but not stated as a distinguishing factor.
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. There's no mention of the sibling tool 'get_coles_products' or any context about when Woolworths-specific searches are appropriate versus other product search options.
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. Dates show when Glama detected each change.
2 tool updates
- First observed
get_coles_products - First observed
get_woolworths_products
TDQS
The two tools have clearly distinct purposes: one searches products at Coles, the other at Woolworths. Their names explicitly differentiate the target retailer, eliminating any ambiguity about which tool to use for each store.
Both tools follow an identical verb_noun pattern: get_<retailer>_products. This consistent naming convention makes it easy to understand and predict tool functionality across the set.
With only two tools, the server feels under-scoped for a grocery shopping assistant. While the tools cover basic product search, there are no tools for cart management, checkout, store location, or price comparison between retailers, making the surface too thin for practical use.
The toolset is severely incomplete for grocery shopping. It lacks essential operations like adding items to a cart, viewing cart contents, checking out, finding nearby stores, or comparing prices across Coles and Woolworths. Agents will hit dead ends after product searches.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
One API for public web data across social, directories and real estate, as clean JSON.
Reddit: Reddit Data API offers streamlined access to Reddit’s public data, like posts, comments.
Data APIs SEC Event Intelligence API for SEC API/EDGAR filings, OpenAPI, MCP, A2A at data-apis.com.
Public data API with ML enrichment — SEC EDGAR, FRED, NOAA, EPA, USGS. 404 endpoints.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides cryptocurrency market data using the CoinGecko API21MIT
- AlicenseAqualityNot gradedmaintenanceUnified API for Government Data and Web Scraping100-
- FlicenseNot gradedqualityDmaintenanceVerified hyper-local data API for the Florida Keys. Raccoon data covering charters, marinas, restaurants, and local knowledge missing from Google Maps and TripAdvisor.-
- AlicenseNot gradedqualityCmaintenanceWraps the HealthData.gov CKAN API to provide access to health data without authentication.15MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hung-ngm/coles-woolworths-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server