Skip to main content
Glama
stupidprogrammer4

digikala-mcp

List Product Sellers

list_product_sellers
Read-only

Retrieve grouped seller offers for a product by seller ID, showing price, rating, warranty, and shipment details to compare vendors.

Instructions

Group variant offers by seller ID with rating, price, warranty and shipment metadata.

Cached 60 seconds. Every variant remains separate; lead time is not a delivery promise. The endpoint's coverage does not guarantee an exhaustive list of all sellers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
product_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
sellersNo
coverageNovariants_endpoint
warningsNo
product_idYes
source_urlNo
observed_atNo
cache_ttl_secondsNo
unidentified_offersNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior4/5

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

Annotations cover read-only and open-world safety, and the description adds genuinely useful traits beyond them: a 60-second cache, the fact that every variant stays separate, that lead time is not a delivery promise, and that coverage is not exhaustive. These are exactly the caveats an agent needs when interpreting results.

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?

Purpose is front-loaded in the first sentence, with caveats following compactly in two short sentences. No padding or repetition.

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?

An output schema exists, so return fields needn't be explained, and the description's caveats about caching and non-exhaustive coverage round out the picture for a simple one-param read tool. The only real gap is any mention of the required parameter.

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

Parameters2/5

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

There is one required parameter (product_id) with 0% schema description coverage, so the description carries the full burden of explaining it — yet it never mentions the parameter or its numeric string pattern. Only one obvious param keeps this above a 1.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource+output shape: it groups variant offers by seller ID and returns rating, price, warranty and shipment metadata. This is clear enough to distinguish it from compare_product_sellers, though it never names that sibling explicitly.

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

Usage Guidelines2/5

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

The description describes behavior but gives no when-to-use guidance, no alternatives, and no exclusions. An agent is left to infer that compare_product_sellers is the comparison sibling rather than this listing tool.

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