How do I use mcp-rona?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-rona search for DEWALT drills" 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.

mcp-rona

by sstepanovvl

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

mcp-rona

License: PolyForm Noncommercial 1.0.0 Node MCP

A Model Context Protocol server for RONA (rona.ca). It exposes RONA's catalogue — product search, product detail, online availability and a store finder — to MCP clients such as Claude and Cursor.

Unofficial. This project is not affiliated with, endorsed by, or sponsored by RONA inc. It reads publicly available endpoints of rona.ca for personal, noncommercial use. Respect RONA's terms of service and use responsibly.

Tools

Tool	Description
`rona_search`	Product search / listings by keyword. Returns products (SKU, name, brand, model, rating, category, URL, image), total count, facets and sort options. Keywords that map to a category page fall back to a best-effort product list.
`rona_product`	Full product card by SKU: name, brand, model, description, image, rating, barcode, category path, URL and online availability.
`rona_store_availability`	Online purchasability (inventory status) of a SKU.
`rona_stores`	Find stores nearest a Canadian postal code (geocoded) or to latitude/longitude — id, name, banner, address, phone, coordinates, distance (km), time zone, URL and opening hours.

`rona_search`

Param	Type	Default	Notes
`query`	string	—	Search keyword (required).
`lang`	`en` \| `fr`	`en`	Language for facet labels.
`sort`	`relevance` \| `price-asc` \| `price-desc` \| `rating` \| `newest` \| `best-sellers`	`relevance`	Sort order.
`page`	int ≥ 1	`1`	1-indexed page.
`pageSize`	int (1–60)	`24`	Results per page.
`brand`	string	—	Filter by a brand facet value, e.g. `DEWALT`.

`rona_product`

Param	Type	Default	Notes
`sku`	string	—	Product SKU / item number (required), e.g. `00277649`.
`lang`	`en` \| `fr`	`en`	Response language.

`rona_store_availability`

Param	Type	Default	Notes
`sku`	string	—	Product SKU / item number (required).
`lang`	`en` \| `fr`	`en`	Response language.

`rona_stores`

Param	Type	Default	Notes
`postalCode`	string	—	Canadian postal code, e.g. `M5V 2T6`. Geocoded to coordinates.
`latitude` / `longitude`	number	—	Alternative to `postalCode`.
`lang`	`en` \| `fr`	`en`	Language for store URLs.
`limit`	int (1–50)	`10`	Max stores to return.

The store locator geosorts by coordinates only, so a postal code is first geocoded via api.zippopotam.us (free, no key). Distance is reported by RONA's API, with a local haversine fallback.

Related MCP server: mcp_canadiantire

A note on prices and store stock

RONA does not expose unit prices or real-time per-store stock (quantities, aisle/bay) through its public APIs:

Prices are guest-gated (the price endpoint returns no value without a session).
Real-time per-store inventory sits behind a DataDome JavaScript challenge that a headless client cannot solve.

So price is reported as null, and availability is limited to online purchasability (Available / Unavailable). Search, product detail and the store finder are fully functional.

How it talks to RONA

rona.ca is behind Cloudflare, which gates requests on both the HTTP version and the client's TLS (JA3) fingerprint. Node's native HTTP stack (fetch/undici) gets 403; only curl --http2 is allowlisted, so every request shells out to curl. No cookies are required for the public endpoints used here.

Surface	Host	Used for
Constructor.io	`tvbajuset-zone.cnstrc.com`	search, product lookup
App API (BFF)	`www.rona.ca/v2/api`	store finder
WebSphere Commerce REST	`www.rona.ca/wcs`	online availability

Requirement: curl with HTTP/2 support must be on PATH (standard on macOS and most Linux distros).

Build & run

npm install
npm run build
npm start          # runs the MCP server on stdio

Quick smoke test of the search layer:

node --input-type=module -e 'import {search} from "./dist/search.js"; console.log(await search({query:"drill", pageSize:3}))'

Inspect with the MCP Inspector:

npm run inspect

Connecting a client

Add to your MCP client config (e.g. Claude Desktop claude_desktop_config.json), pointing at the built entrypoint:

{
  "mcpServers": {
    "rona": {
      "command": "node",
      "args": ["/absolute/path/to/mcp_rona/dist/index.js"]
    }
  }
}

Project layout

src/
  index.ts    MCP server + tool registration (stdio)
  rona.ts     curl --http2 transport for rona.ca + Constructor.io
  search.ts   rona_search (Constructor.io search + category-redirect fallback)
  product.ts  rona_product + rona_store_availability (catalogue + WCS availability)
  stores.ts   rona_stores (postal-code geocode → store locator)

License

PolyForm Noncommercial License 1.0.0 — free to use, modify and share for noncommercial purposes. Commercial use requires a separate license from the author.

Available Tools

4 tools

rona_productGet RONA product by SKUA

Fetch the full product card for a RONA SKU (item number): name, brand, model, description, image, rating, barcode, category path, URL, and online availability. Note: RONA does not expose unit price or per-store stock through its public APIs, so price is null.

ParametersJSON Schema

Name	Required	Description	Default
`sku`	Yes	Product SKU / item number, e.g. '00277649' (from rona_search results).
`lang`	No	Response language. Default 'en'.

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses that price is null and why, and lists output fields. However, it does not mention authorization, rate limits, or behavior on missing SKUs.

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?

Two sentences: first front-loads purpose and output fields, second adds a critical caveat. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 2 parameters and no output schema, the description lists fields and a caveat. It could detail return format but is sufficient given the simplicity.

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 description coverage is 100% (both sku and lang described). The description adds context: sku example from rona_search results and lang default, providing meaning beyond the schema.

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 clearly states the tool fetches the full product card for a RONA SKU, listing specific fields (name, brand, model, etc.). This distinguishes it from sibling tools like rona_search (search) and rona_store_availability (store stock), providing a specific verb and resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use after a search by referencing sku from rona_search results. It notes limitations (price null, no per-store stock) but does not explicitly state when not to use or name alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rona_searchSearch RONAA

Search RONA (rona.ca) for products by keyword. Returns matching products with SKU, name, brand, model, rating, category, URL and image, plus the total result count, available filters (facets) and sort options. Use page to paginate. Note: prices and live stock are not in the search index — use rona_product for a full card.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search keyword, e.g. 'cordless drill', 'paint roller'.
`lang`	No	Response language for facet labels. Default 'en'.
`sort`	No	Sort order. Default 'relevance'.
`page`	No	1-indexed page number. Default 1.
`pageSize`	No	Results per page (1-60). Default 24.
`brand`	No	Filter by brand, e.g. 'DEWALT' (from a facet value).

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description discloses important behavioral aspects: it returns search results with specific fields, does not include prices or stock, and supports pagination. No destructive side effects, and the read-only nature is implied.

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?

Three concise sentences: first covers purpose and output, second pagination, third a critical note. No redundancy, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains return fields well and notes what is missing. It references a sibling for more detail. Could mention facet usage briefly, but overall complete for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already describes all parameters adequately. The description adds limited additional meaning beyond reinforcing pagination; baseline 3 is appropriate.

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 clearly states the tool searches RONA products by keyword and lists the returned fields (SKU, name, brand, etc.) and explicitly distinguishes from the sibling rona_product by noting that prices and live stock require that tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides guidance on pagination ('Use `page` to paginate') and directs users to rona_product for full product details including prices. However, it does not explicitly address when to use store availability or other siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rona_store_availabilityCheck RONA online availability for a SKUA

Check whether a RONA SKU is available to buy online (inventory status). Note: real-time per-store stock levels and aisle/bay locations are not available from RONA's public APIs — this reports online purchasability only. Use rona_stores to find stores near a location.

ParametersJSON Schema

Name	Required	Description	Default
`sku`	Yes	Product SKU / item number, e.g. '00277649'.
`lang`	No	Response language. Default 'en'.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It clearly sets expectations by noting the tool only reports online availability and does not provide per-store data. However, it does not disclose return format, error behavior, or if any side effects exist (likely none). Still, it is transparent about its limited scope.

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?

Two sentences that front-load the main purpose, then add limitation and sibling reference. No superfluous text; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 params, no nested objects) and no output schema, the description adequately explains its purpose and limitations. However, it omits what the return value looks like (e.g., a boolean or status string). Still, it is mostly complete for effective selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds no additional parameter meaning beyond the schema's built-in descriptions. It does reinforce the SKU example, but that is already present in schema.

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 clearly states the verb 'Check' and the resource 'RONA SKU availability to buy online'. It distinguishes from siblings by specifying online purchasability only and referencing rona_stores for store-level data.

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?

Explicitly states limitations: real-time per-store stock levels are not available. Provides a sibling alternative (rona_stores) for finding stores, guiding the agent on when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rona_storesFind RONA stores near a locationA

Find RONA stores nearest to a Canadian postal code (geocoded) or to latitude/longitude. Returns, per store: id, name, banner, address, city, province, postal code, phone, coordinates, distance (km), time zone, store URL and opening hours — sorted nearest first.

ParametersJSON Schema

Name	Required	Description
`postalCode`	No	Canadian postal code, e.g. 'M5V 2T6' or 'H2W 1Y8'.
`latitude`	No	Latitude (alternative to postalCode; use with longitude).
`longitude`	No	Longitude (use with latitude).
`lang`	No	Language for store URLs. Default 'en'.
`limit`	No	Max stores to return (1-50). Default 10.

TDQS

A4.4/5.0

Behavior4/5

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 explains that the tool returns sorted store data and lists all fields, which is sufficient for a read-only query tool. It does not mention side effects, auth, or rate limits, but those are not critical for a simple store-finder.

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 consists of two concise sentences. The first sentence states the purpose and supported inputs; the second lists the output fields. No unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description sufficiently explains the tool's behavior and output given the context (no output schema). It covers the key aspects, though it could mention the limit parameter's effect or error handling. Overall, it's complete for a simple lookup tool.

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?

All 5 parameters are described in the schema (100% coverage). The description adds value by clarifying that latitude/longitude are an alternative to postalCode and that lang defaults to 'en', which goes beyond the schema.

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 clearly states the tool finds RONA stores nearest to a Canadian postal code or lat/lng, and distinguishes itself from sibling tools that focus on products, search, or availability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for finding stores by location, but does not explicitly state when not to use it or mention alternatives. The sibling names provide context, but the description could be improved with direct guidance.

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.

4 tool updatesv0.1.0Jun 23, 2026
- First observedrona_product
- First observedrona_search
- First observedrona_store_availability
- First observedrona_stores

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored 2026-06-23 07:25 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: fetching product details by SKU, searching by keyword, checking online availability, and finding nearby stores. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent 'rona_' prefix with snake_case descriptive nouns/verb+noun combinations (product, search, store_availability, stores). The pattern is uniform.

Tool Count5/5

With 4 tools, the server covers the essential capabilities for a retail product information service: search, details, availability, and store locator. The count is well-scoped and each tool earns its place.

Completeness4/5

The tool set covers the main workflows: product discovery (search), detailed info (product), store locations, and online availability. Missing features like per-store stock or pricing are due to API limitations, not tool design gaps. Minor gap: no price or category browsing.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Conduit Agentic Commerce A
app.aiconduit
Search multi-merchant supply, checkout, and track orders via MCP.
E-commerce & Retail Search
202
SeekOnMe Product Discovery
me.seekon.fast
Remote MCP server for product discovery catalog and retrieving product details.
E-commerce & Retail Search
2
commercebridge A
io.github.IsaiahDupree
Remote MCP connector for eBay, Shopify, Best Buy & Etsy marketplace data via the Commerce API
E-commerce & Retail Search
141
mcp
com.api2cart
Unified MCP server for 70+ eCommerce platforms: products, orders, customers, and more.
E-commerce & Retail CRM
1

Related MCP Servers

MCP Product Search Server
E-commerce & Retail Search
hwqlet
F
license
A
quality
D
maintenance
Enables product search functionality via MCP, allowing Claude to search products by keyword with filters, list categories, and retrieve product details.
Updated 5 months ago (2026-04-30 06:31 UTC)
3
-
mcp_canadiantire
E-commerce & Retail Location Services
sstepanovvl
F
license
A
quality
D
maintenance
Enables searching Canadian Tire's product catalogue, checking product details, store-level stock, and finding nearby stores.
Updated 3 months ago (2026-06-23 06:09 UTC)
4
-
Voila Groceries MCP
E-commerce & Retail App Automation
dearlordylord
A
license
A
quality
B
maintenance
Voila.ca groceries MCP for card management, product search and order history analysis
Updated 21 days ago (2026-08-24 17:42 UTC)
13
MIT
io.github.AndrewVG23/grocery
E-commerce & Retail Web Scraping Search
AndrewVG23
F
license
A
quality
B
maintenance
A dedicated MCP and REST service that searches grocery retailers directly and returns reviewable product links, enabling users to find products and create handoffs without adding to carts or placing orders.
Updated a month ago (2026-08-07 02:47 UTC)
7
-