Skip to main content
Glama

adidas_product_review_topics

Read-only

Adidas review topics for one product model: the topics its customer reviews can be filtered by, commonly satisfaction, comfort, color, purchase, fit, appearance, quality and style. Feed a topics[].topic value back to adidas_product_reviews as its topic argument to read only the reviews about that aspect. The vocabulary is per model rather than a fixed list, so read it per model instead of hard-coding it. model_number is the Adidas model number (e.g. SAMBAU2312) from an adidas_search result's products[].model_number field -- NOT the SKU in products[].id. A model with no reviews, including an unrecognized model_number, returns an empty list rather than an error. The label field is a display form of topic, not translated text: Adidas returns the same English values for every locale here.

Input Schema

NameRequiredDescriptionDefault
localeNoLocale accepted for consistency with the reviews endpoint. Allowed values: cs_CZ, da_DK, de_AT, de_CH, de_DE, el_GR, en_AE, en_AU, en_CA, en_GB, en_IE, en_IL, en_IN, en_NZ, en_PH, en_SG, en_US, en_ZA, es_AR, es_CL, es_CO, es_ES, es_MX, es_PE, fr_BE, fr_CA, fr_CH, fr_FR, id_ID, it_CH, it_IT, ja_JP, ko_KR, nl_BE, nl_NL, pl_PL, pt_BR, pt_PT, ru_RU, sk_SK, sv_SE, th_TH, tr_TR, zh_HK, zh_TW. Defaults to en_US. Note Adidas returns the same English topic labels regardless of this value.
model_numberYesAdidas model number, from an adidas_search result's products[].model_number field

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / locale / description
      Added value: +"Locale accepted for consistency with the reviews endpoint. Allowed values: cs_CZ, da_DK, de_AT, de_CH, de_DE, el_GR, en_AE, en_AU, en_CA, en_GB, en_IE, en_IL, en_IN, en_NZ, en_PH, en_SG, en_US, en_ZA, es_AR, es_CL, es_CO, es_ES, es_MX, es_PE, fr_BE, fr_CA, fr_CH, fr_FR, id_ID, it_CH, it_IT, ja_JP, ko_KR, nl_BE, nl_NL, pl_PL, pt_BR, pt_PT, ru_RU, sk_SK, sv_SE, th_TH, tr_TR, zh_HK, zh_TW. Defaults to en_US. Note Adidas returns the same English topic labels regardless of this value."
    • addedInput schema / properties / model_number / description
      Added value: +"Adidas model number, from an adidas_search result's products[].model_number field"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, it discloses error behavior ('a model with no reviews, including an unrecognized model_number, returns an empty list rather than an error') and a non-obvious data trait ('The label field is a display form of topic, not translated text'). These are exactly the behaviors an agent could not infer from structured fields.

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 and the topics list are front-loaded, and every sentence carries non-redundant information (usage routing, vocabulary volatility, model_number sourcing, error behavior, label caveat). It is a dense but slightly long block with no headers or line breaks.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not explain return shape, and it still covers parameter sourcing, error behavior, and downstream usage. Nothing an agent needs to call this correctly is missing.

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 already 100%, so the baseline is 3. The description adds genuinely useful meaning by disambiguating model_number from the products[].id SKU and giving a concrete example (SAMBAU2312). The locale semantics are largely restated from the schema, so this stops short of 5.

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?

The description opens with a precise verb+resource phrase ('Adidas review topics for one product model') and immediately scopes it as the filter vocabulary for that model. It is trivially distinguishable from the sibling adidas_product_reviews, which it explicitly points to.

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?

It states exactly how the output is consumed: 'Feed a topics[].topic value back to adidas_product_reviews as its topic argument.' It also gives an exclusion-style rule: do not hard-code the vocabulary, read it per model.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.