masterkala-mcp

Overview Schema Source Related Servers Discussions Admin

Browse a category or brand

mk_browse

Read-only

List and compare products by category, brand, or tag using sorting, price range, and filters to find items that match budget or specs.

Instructions

List the products of a category, brand or tag with sorting, price range and filters.

Use for "cheapest Bluetooth earbuds", "Xiaomi power banks between 1 and 2 million Toman". Pass exactly one of category_id / brand / tag_id (ids: mk_categories, mk_brands, mk_search; filter ids: mk_filters). No keyword or rating sort here: see mk_search / mk_reviews.

Input Schema

Name	Required	Description	Default
`page`	No	Page number, from 0.
`sort`	No	Order of the listing. In-stock items always come first.	cheapest
`brand`	No	Brand slug from mk_brands, e.g. 'mcdodo' or 'anker-fa'.
`limit`	No	Products per page.
`tag_id`	No	Tag id from a /tag/<id>/ link in mk_search pages, e.g. 22246.
`max_price`	No	Maximum payable price (final_price) in Toman, e.g. 5000000.
`min_price`	No	Minimum payable price (final_price) in Toman, e.g. 3000000.
`filter_ids`	No	Filter ids from mk_filters: 'm30' brand, 'o78' color, '117' attribute. Example: ['m30', 'o52'].
`category_id`	No	Category id from mk_categories or mk_search, e.g. 606 (Bluetooth earbuds).

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedv0.3.0Oct 17, 2026
- removedInput schema / properties / brand / title
```
Removed value: -"Brand"
```
- removedInput schema / properties / category_id / title
```
Removed value: -"Category Id"
```
- removedInput schema / properties / filter_ids / title
```
Removed value: -"Filter Ids"
```
- removedInput schema / properties / limit / title
```
Removed value: -"Limit"
```
- removedInput schema / properties / max_price / title
```
Removed value: -"Max Price"
```
- removedInput schema / properties / min_price / title
```
Removed value: -"Min Price"
```
- removedInput schema / properties / page / title
```
Removed value: -"Page"
```
- removedInput schema / properties / sort / title
```
Removed value: -"Sort"
```
- removedInput schema / properties / tag_id / title
```
Removed value: -"Tag Id"
```
- removedInput schema / title
```
Removed value: -"mk_browseArguments"
```
- changedOutput schema / (root)
```
Previous value: -{
-  "additionalProperties": true,
-  "title": "mk_browseDictOutput",
-  "type": "object"
-}New value: +null
```
First observedv0.1.0Oct 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

readOnlyHint=true already establishes this as a safe read, so the bar is lower; the description still adds a real behavioral constraint the schema does not enforce — mutual exclusivity of category_id, brand and tag_id. It does not describe return shape or pagination semantics, which is the remaining gap.

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?

Four tight sentences: purpose and scope first, worked examples second, the exclusivity constraint and id sources third, exclusions last. No filler and the most decision-relevant content is front-loaded.

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?

For a 9-parameter, zero-required, no-output-schema browse tool with only a readOnlyHint, the description covers selection rules, id provenance and alternatives to siblings. It omits result/pagination behavior, but with the schema carrying full parameter documentation the definition is largely sufficient to call it correctly.

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 baseline is 3, and the schema already documents every parameter with examples. The description goes slightly beyond by stating where each id family comes from (mk_categories, mk_brands, mk_search, mk_filters) and imposing the exactly-one-of relationship among the three selector parameters.

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 (List) and resource (products of a category, brand or tag) plus the facets it supports (sorting, price range, filters). It also explicitly separates itself from siblings by noting there is no keyword or rating sort here, pointing to mk_search / mk_reviews instead.

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?

Gives concrete triggering queries ("cheapest Bluetooth earbuds", "Xiaomi power banks between 1 and 2 million Toman") and states the hard selection rule: pass exactly one of category_id / brand / tag_id. It names the alternatives for id lookups and for keyword/rating sorting, leaving nothing to inference.

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

Deploy Server

Browse a category or brand

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools