CheapestInIndia

Search products

search_products

Read-only

Search CheapestInIndia for products sold in India, with live prices from Amazon, Flipkart, Croma, Reliance Digital, Myntra, Nykaa and other Indian retailers. Use it for any shopping question about products in India: prices, where to buy, options under a budget. For 'is ₹X a good price' or price history of a named product, call get_price_history with query directly. Results are ordered category-first: real products before accessories, stores mixed. Put the brand in the query ('samsung 55 inch tv'). Returns products (price, MRP, discount, store, image, buy link, price-history page) and facets (stores, categories, price range). The results are shown to the user as product cards automatically, with a link to all results on CheapestInIndia. Next steps: get_price_history to judge a price, compare_products to compare 2–4 items; render_product_results only to show a hand-picked subset.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search_products"
  }
}

Input Schema

Name	Required	Description
`page`	No	Page number (default 1)
`sort`	No	Default relevance. price_asc = cheapest first
`query`	Yes	What the user is shopping for, e.g. 'jbl flip 6'
`stores`	No	Only these retailers, e.g. ['amazon.in', 'flipkart.com']
`per_page`	No	Results per page (default 10, max 20)
`max_price`	No	Maximum price in INR
`min_price`	No	Minimum price in INR
`category_ids`	No	Category group ids from browse_categories or a previous search's facets

Output Schema

Name	Required	Description	Default
`page`	Yes
`query`	Yes
`total`	Yes
`facets`	Yes
`hasMore`	Yes
`products`	Yes
`searchPageUrl`	Yes
`correctedQuery`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the read-only, non-destructive annotations, the description explains result ordering, that real products come before accessories, that stores are mixed, and that results are automatically shown to the user as product cards. That display behavior is operationally important because it tells the agent not to call render_product_results for ordinary searches.

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 with purpose and usage, then moves through routing, ordering, query formulation, return contents, display behavior, and next steps. The length is justified by the number of sibling tools and the need to prevent misuse of render_product_results and get_price_history.

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?

The tool has a rich schema, an output schema, and annotations, and the description fills in the behavioral and routing context those structured fields do not cover. It is complete enough for an agent to decide when to search, how to form the query, what will be returned, and what to do next.

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 the schema already carries most parameter meaning. The description still adds useful query guidance by advising the agent to put the brand in the query, and it links facets to stores, categories, and price range, which helps with follow-up filtering.

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: search products sold in India with live prices from named retailers. It clearly distinguishes this from get_price_history for price-history and price-judgment questions, so an agent can route correctly without opening the schema.

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 says to use this for shopping questions about products in India, including prices, where to buy, and budget options. It also gives a clear exclusion: for 'is ₹X a good price' or price history of a named product, call get_price_history instead, and it names follow-up tools for comparison and rendering.

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

All CheapestInIndia tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?