sh_brandsList featured official brand shops, or use a watch shop ID to get its sold brands and brand IDs for product browsing filters.
Without shop_id: featured official brand shops (browse one with sh_browse(shop_id=...)). With shop_id: the brands that shop sells, with ids for the brand_id filter of sh_browse (watch shops only).
| Name | Required | Description | Default |
|---|---|---|---|
| shop_id | No | Watch shop id, e.g. 1771: lists its brands with brand ids. |
Changes observed during successful MCP inspections.
v0.3.0Input schema / properties / shop_id / descriptionPrevious value: -"A shop id (e.g. 1771, a watch shop) to list its brands with brand ids."New value: +"Watch shop id, e.g. 1771: lists its brands with brand ids."Input schema / properties / shop_id / titleRemoved value: -"Shop Id"Input schema / titleRemoved value: -"sh_brandsArguments"Output schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "sh_brandsDictOutput",
- "type": "object"
-}New value: +nullv0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuine context beyond that: the returned data feeds sh_browse's brand_id filter, and the shop_id variant only works for watch shops, which is a real behavioral constraint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with a parallel 'Without shop_id: ... With shop_id: ...' structure that is front-loaded and wastes no words. Both sentences earn their place by describing distinct result modes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter read tool with no output schema, the description covers both invocation modes, the output content (brand shops vs. brand ids), and the downstream use of those ids. Minor gaps like pagination or result ordering are not addressed but are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is only one optional parameter, so the schema already documents shop_id. The description still adds meaning by contrasting the no-shop_id and with-shop_id result sets and noting the id output is intended for the brand_id filter, beyond the schema's 'Watch shop id, e.g. 1771'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the resource (brands) and gives distinct semantics for each mode: featured official brand shops without shop_id, and the brands a given shop sells with shop_id. It is clear about what is returned in both branches, though the verb 'lists/returns' is implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It routes the agent explicitly: browse a featured brand shop via sh_browse(shop_id=...), and use the returned ids as the brand_id filter for sh_browse. It does not cover when to prefer this over sh_shops or sh_categories, so it stops short of full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.