Skip to main content
Glama

Product reviews

kh_reviews
Read-onlyIdempotent

Read customer reviews for a product, newest first, with verified-buyer flags and photos. Use as a quality check before recommending.

Instructions

Read customer comments on a product, newest first, with a verified-buyer flag and photos.

Use as a quality check before recommending. Text is cut to 400 characters (ends with …) unless full_text=true. No star ratings per comment: the average is in kh_product.

Input Schema

NameRequiredDescriptionDefault
pageNoPage number, from 1, newest first.
limitNoReviews per page.
productYesSlug from kh_search / kh_browse (e.g. 'golden-rose-sheer-bright-lipstick-112222') or numeric id.
full_textNoDo not cut review text to 400 characters.
with_photosNoOnly reviews that include customer photos.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.2.0
    • addedInput schema / properties / full_text
      Added value: +{
      +  "default": false,
      +  "description": "Do not cut review text to 400 characters.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / limit / default
      Previous value: -20New value: +10
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • removedInput schema / properties / page / title
      Removed value: -"Page"
    • changedInput schema / properties / product / description
      Previous value: -"Product slug from kh_search / kh_browse (e.g. 'golden-rose-sheer-bright-lipstick-112222') or the numeric product id (e.g. '112222')."New value: +"Slug from kh_search / kh_browse (e.g. 'golden-rose-sheer-bright-lipstick-112222') or numeric id."
    • removedInput schema / properties / product / title
      Removed value: -"Product"
    • removedInput schema / properties / with_photos / title
      Removed value: -"With Photos"
    • removedInput schema / title
      Removed value: -"kh_reviewsArguments"
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "kh_reviewsDictOutput",
      -  "type": "object"
      -}New value: +null
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish the safe read-only, idempotent profile, so the bar is lower. The description still adds real value beyond them: text is truncated to 400 characters unless full_text=true, truncated text ends with '…', and per-comment star ratings are deliberately absent (average lives in kh_product). These are non-obvious data-shape facts an agent needs, though it stops short of describing pagination behavior or the full review field set.

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?

Two tight paragraphs, zero filler. The core purpose is front-loaded in the first sentence, and the operational caveats (truncation, missing ratings, when to use it) follow in a compact second block. Every sentence earns its place.

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?

With no output schema, the description dutifully describes the return shape (comments, newest-first ordering, verified-buyer flag, photos) and flags the data limitation around star ratings. Combined with 100% schema coverage for parameters and read-only annotations, an agent has enough to call it correctly, though the per-review field list is not fully enumerated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters are already documented in the schema. The description reinforces ordering ('newest first') and the full_text truncation semantics but adds no new syntax or format guidance. Baseline 3 is appropriate when the schema carries the parameter burden.

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?

States a specific verb and resource: 'Read customer comments on a product, newest first, with a verified-buyer flag and photos.' This clearly identifies the tool as the reviews fetcher and is hard to confuse with kh_search or kh_browse. It does not explicitly position itself against an alternative reviews tool, but the resource is unique enough that differentiation is implicit.

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?

'Use as a quality check before recommending' gives a concrete usage scenario rather than leaving it implied. It also points to kh_product for average star ratings, steering the agent to the right source for that data. There are no explicit when-not conditions or named alternatives for the review-fetching itself, so it falls short of a 5.

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