khanoumi-mcp

Overview Schema Source Related Servers Discussions Admin

Browse a category, brand or tag

kh_browse

Read-onlyIdempotent

Browse and filter Khanoumi products by category, brand, or campaign tag, with price range, attributes, stock, sorting, and pagination.

Instructions

List products of a category, brand(s) or campaign tag with sorting, price range and filters.

Use for "sunscreens for oily skin under 800,000 Toman". Pass at least one of category_id (kh_categories), brands (kh_brands) or tag (kh_deals); filter ids come from kh_filters. No rating or discount sort. Next: kh_product / kh_reviews.

Input Schema

Name	Required	Description	Default
`tag`	No	Campaign tag slug from kh_deals, e.g. 'festival-js' (pink box).
`page`	No	Page number, from 1.
`sort`	No	popular = site default; cheapest / most_expensive by payable price.	popular
`limit`	No	Products per page (sponsored items are left out).
`query`	No	Optional keyword inside the listing.
`brands`	No	Brand slugs from kh_brands / kh_filters (OR), e.g. ['simple', 'cerave'].
`colors`	No	Color ids from kh_filters (OR), e.g. ['3'] (red).
`facets`	No	Attribute keys from kh_filters (AND), e.g. ['facetKey.skin-type:oily'].
`max_price`	No	Maximum payable price in Toman, e.g. 1500000.
`min_price`	No	Minimum payable price in Toman, e.g. 500000.
`category_id`	No	Category id from kh_categories or kh_search, e.g. 145 (moisturizers).
`in_stock_only`	No	Only products that can be ordered now.

Schema Changelog

Changes observed during successful MCP inspections.

Changed17 schema fields changedv0.2.0Oct 16, 2026

removedInput schema / properties / brands / title
```
Removed value: -"Brands"
```
removedInput schema / properties / category_id / title
```
Removed value: -"Category Id"
```
removedInput schema / properties / colors / title
```
Removed value: -"Colors"
```

changedInput schema / properties / facets / description

Previous value: -"Attribute filter keys from kh_filters, all must match (AND), e.g. ['facetKey.skin-type:oily']."New value: +"Attribute keys from kh_filters (AND), e.g. ['facetKey.skin-type:oily']."

removedInput schema / properties / facets / title
```
Removed value: -"Facets"
```
removedInput schema / properties / in_stock_only / title
```
Removed value: -"In Stock Only"
```
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 / query / title
```
Removed value: -"Query"
```

changedInput schema / properties / sort / description

Previous value: -"Order: popular (the site's default, most visited), cheapest / most_expensive (payable price), newest."New value: +"popular = site default; cheapest / most_expensive by payable price."

removedInput schema / properties / sort / title
```
Removed value: -"Sort"
```

changedInput schema / properties / tag / description

Previous value: -"Collection / campaign tag slug from kh_deals (the part after /tags/), e.g. 'festival-js' (pink box)."New value: +"Campaign tag slug from kh_deals, e.g. 'festival-js' (pink box)."

removedInput schema / properties / tag / title
```
Removed value: -"Tag"
```
removedInput schema / title
```
Removed value: -"kh_browseArguments"
```

changedOutput schema / (root)

Previous value: -{
-  "additionalProperties": true,
-  "title": "kh_browseDictOutput",
-  "type": "object"
-}New value: +null

First observedv0.1.0Oct 6, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the requirement to supply at least one of three anchor parameters, the absence of rating/discount sort modes, and where filter ids must be sourced from. It does not discuss pagination limits or result volume, so a 4 rather than 5.

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?

Three short sentences, all front-loaded: purpose first, then the use case and precondition, then the follow-up routing. No filler, no restatement of the title, and the 'Next:' clause is compact.

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 12-parameter, zero-required faceted browse tool with no output schema, the description covers the essential invocation rule, id provenance, and workflow hand-offs. It omits any hint about result shape or how deep pagination goes, but with annotations carrying the safety profile and the schema carrying field semantics, the remaining gap is minor.

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 description coverage is 100%, so the baseline is 3 and the schema already documents each field. The description nevertheless adds a cross-parameter rule the schema cannot express ('Pass at least one of category_id, brands or tag') plus provenance for each id type (kh_categories, kh_brands, kh_deals, kh_filters), which is genuinely additive.

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?

The description opens with a specific verb and resource ('List products of a category, brand(s) or campaign tag') and enumerates the dimensions it supports (sorting, price range, filters). An agent can tell this is a faceted listing tool rather than a keyword search. It does not explicitly name the closest sibling (kh_search) as the contrasting option, so it stops short of a 5.

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?

It gives a concrete when-to-use example ('sunscreens for oily skin under 800,000 Toman'), a hard invocation precondition ('Pass at least one of category_id, brands or tag'), and a scope limitation ('No rating or discount sort'). It also points at the follow-up tools kh_product / kh_reviews. It never states when to prefer kh_search instead, which keeps it out of 5 territory.

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, brand or tag

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools