tb_brandsRetrieve all brand IDs for a selected category to enable brand-filtered product searches. Provide a category ID and optional name text to get matching brands for tb_search.
All brands of a category with their ids (for tb_search brand=).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| search | No | Name contains this text. | |
| category | Yes | Category id, e.g. 94 (mobile phones); see tb_filters. |
Changes observed during successful MCP inspections.
v0.2.0Input schema / properties / category / descriptionPrevious value: -"Torob category id, e.g. 94 (mobile phones). Find ids with tb_filters or tb_category."New value: +"Category id, e.g. 94 (mobile phones); see tb_filters."Input schema / properties / search / descriptionPrevious value: -"Keep brands whose name contains this text."New value: +"Name contains this text."v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds only the scoping fact (results are per-category) and the id-passthrough purpose; it says nothing about the limit/pagination behavior implied by the default of 60 and max of 100.
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?
A single short sentence that front-loads the resource and its scope, with the integration hint second. Nothing is redundant, though the terseness edges toward under-specification rather than crispness.
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 simple read-only lookup with rich annotations, no output schema, and mostly documented parameters, the description covers what the tool returns (brands plus ids) and why. The only material gap is the undocumented limit parameter and the resulting pagination behavior.
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 67%: category and search are documented in the schema, while limit has no description anywhere. The tool description adds no parameter-level detail beyond implying that category drives the result set, so it neither compensates for the undocumented limit nor adds meaning over the schema.
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 names a specific resource (brands), scopes it to a category, and states the return payload (brand ids). That distinguishes it from siblings like tb_filters or tb_search — this is a lookup that feeds one of them — though it never explicitly contrasts itself with tb_filters, which also returns taxonomy data.
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?
The parenthetical '(for tb_search brand=)' gives a concrete chaining hint: call this to obtain the id value that tb_search expects for brand. There is no explicit when-not guidance and no mention of tb_filters as the place to discover category ids, so the agent must infer the workflow entry point from the schema rather than the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.