Skip to main content
Glama
sepehr071

digikala-mcp

by sepehr071

Find categories

dk_categories
Read-onlyIdempotent

Find Digikala category codes and main-category IDs by searching Persian names or English codes, or list subcategories by parent ID for product and best-seller lookups.

Instructions

Find category codes for dk_category_products and main-category ids for dk_best_sellers.

query matches the Persian name or English code (Persian finds more: 'لپ تاپ' finds the laptop leaf, 'laptop' does not); parent_id lists children; neither lists the main categories. A category with subcategories mixes in accessories: browse its product leaf.

Input Schema

NameRequiredDescriptionDefault
limitNoMax categories to return.
queryNoWords in the category name or code, e.g. 'هدفون' or 'laptop'.
parent_idNoList the sub-categories of this category id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.4.0
    • changedInput schema / properties / limit / default
      Previous value: -40New value: +25
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • removedInput schema / properties / parent_id / title
      Removed value: -"Parent Id"
    • changedInput schema / properties / query / anyOf
      Previous value: -[
      -  {
      -    "minLength": 2,
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "maxLength": 100,
      +    "minLength": 2,
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedInput schema / properties / query / title
      Removed value: -"Query"
    • removedInput schema / title
      Removed value: -"dk_categoriesArguments"
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "dk_categoriesDictOutput",
      -  "type": "object"
      -}New value: +null
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds genuinely useful behavior beyond them: Persian queries match more terms than English codes, and parent_id/query never surface main categories. The accessory-mixing caveat for categories with subcategories is real operational context.

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 a short first sentence and the rest is dense with semicolon-separated rules rather than filler. Slightly compressed but every clause carries information; minor awkwardness in the wrapped formatting.

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?

No output schema exists, yet the description still explains what is returned (category codes for dk_category_products, main-category ids for dk_best_sellers) and the matching rules. The one remaining gap is that it names the 'main categories' limitation without offering a path to retrieve them.

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% (baseline 3), but the description adds meaning the schema lacks: a Persian-vs-English matching asymmetry with a concrete example, and the fact that parent_id lists children whereas query/parent_id together still omit main categories.

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 and resource ('Find category codes ... main-category ids') and immediately connects the output to the two siblings that consume it (dk_category_products, dk_best_sellers), so an agent can distinguish this lookup tool from the product-listing tools without opening a schema.

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?

Gives concrete per-parameter routing: query matches name/code, parent_id lists children, and 'neither lists the main categories' flags a limitation. It also implicitly routes the agent to browse the product leaf for accessories, but no explicit sibling alternative is named as a fallback for the main-category gap it calls out.

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