Skip to main content
Glama
Sign In
sepehr071

digikala-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Price history

dk_price_history
Read-onlyIdempotent

Fetch 30 days of daily Digikala buy-box prices in Toman per color or variant, including price range and two-day low, to judge whether a current price is good.

Instructions

Get ~30 days of daily buy-box prices (Toman) per color/variant, with lowest and highest.

For "is this a good price?": lowest_2_days is the lowest price held two days in a row (lowest can be a one-day dip). Days are Jalali. An unknown id gives no variants; check it with dk_product.

Input Schema

NameRequiredDescriptionDefault
product_idYesDigikala product id, the number in 'dkp-<id>' (from dk_search etc.), e.g. 20109389.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.4.0
    • removedInput schema / properties / product_id / title
      Removed value: -"Product Id"
    • removedInput schema / title
      Removed value: -"dk_price_historyArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "dk_price_historyDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real context beyond them: the ~30-day window, daily granularity, Toman currency, per-variant grouping, and the Jalali calendar basis. It also discloses the empty-result edge case for unknown ids, though it does not describe other return fields or data-freshness guarantees.

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?

Front-loads the core capability in the first sentence, then layers the interpretation hint and the error-handling note. Three short blocks, no filler, every sentence earns its place.

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?

With no output schema, the description must carry return-value meaning, and it does name lowest, highest, and lowest_2_days with their semantics. For a single-parameter read-only tool this is nearly complete; only minor details (exact window variance, additional fields) are left implicit.

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% for the single product_id parameter, so the baseline would be 3, but the description adds behavioral meaning: an unknown id yields no variants and should be validated via dk_product. That extra guidance is genuinely useful parameter-level context.

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 (Get), resource (daily buy-box prices), and scope (~30 days, per color/variant, in Toman) plus the two summary fields returned. It also routes the agent to dk_product for id validation, so it is distinguishable from sibling tools.

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?

Explicitly frames the use case ('For "is this a good price?"') and explains why lowest_2_days is the right field versus lowest for that judgment. It also names dk_product as the fallback for an unknown id. It does not, however, compare itself to pricing siblings like dk_find_cheapest or dk_deals.

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

Deploy Server

Other Tools