Skip to main content
Glama

Price history & price check

get_price_history
Read-only

Price history and price check for a product sold in India, from CheapestInIndia's price tracking: current price, lowest and highest price ever (with dates), lowest in the last 7/30/90 days, how often the price changes, a price chart, and a factual verdict on where today's price sits. Use it for 'is ₹X a good price for ?', 'price history of ', 'lowest price of ', 'was it cheaper before?' and 'should I buy now or has it been lower?'. Pass the product name as query (e.g. 'JBL Flip 6') — the best-matching listing is used and other listings are returned so you can switch — or an exact id from another tool. Shown to the user as a price-history card with a chart. The verdict describes the past only — never present it as a forecast.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_price_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoCheapestInIndia product id (from search_products, get_product or lookup_product_by_url)
queryNoProduct name, brand + model if known, e.g. 'JBL Flip 6' or 'Samsung 55 inch Crystal 4K TV'

Output Schema

NameRequiredDescriptionDefault
historyYes
productYes
matchedQueryNoThe query used to pick this listing
otherListingsNoOther listings for the query (other stores, sizes or models) — pass one's id to switch

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuine behavior beyond that: free-text resolution to a best-matching listing, alternate listings returned for switching, user-facing presentation as a price-history card with a chart, and the important caveat that the verdict describes the past only and must never be presented as a forecast.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads what is returned, then usage triggers, then parameter guidance, then presentation and the forecast caveat. Every sentence earns its place. The output enumeration is dense and could be trimmed slightly, which keeps it from a 5.

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?

For a read-only lookup tool with an output schema present, the description still supplies everything needed to call and interpret it: return contents, query/id resolution semantics, result switching, presentation form, and the retrospective-verdict caveat. No gap that would lead to misuse.

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%, with both params documented including the id pattern and name examples. The description reinforces the query-versus-id decision and gives product-name examples, but adds no syntax or constraint detail beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.

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?

States a specific verb/resource pair (price history and price check for a product sold in India) and enumerates the concrete outputs: current price, all-time low/high with dates, 7/30/90-day lows, change frequency, chart, and verdict. This is distinguishable from siblings like search_products or get_product, which supply the id rather than the historical analysis.

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 lists the triggering utterances ('is ₹X a good price', 'was it cheaper before?', 'should I buy now'). It also names the two input paths, query or exact id from another tool, and explains what happens when a query is used: the best match is analyzed and other listings are returned so the agent can switch. Nothing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources