Skip to main content
Glama

Place reviews

bl_reviews
Read-onlyIdempotent

Retrieve a page of Balad place reviews, newest first, with star ratings and rating breakdown; use page numbers to continue when more reviews exist.

Instructions

Get one page of user reviews of a place on Balad, newest first, with stars and the rating breakdown.

id comes from bl_search or bl_nearby. 10 reviews per page; when more is true, call again with page+1. bl_place already includes the first few reviews.

Input Schema

NameRequiredDescriptionDefault
idYesPlace id from bl_search or bl_nearby, e.g. 4Dvh6E79N49I2j.
pageNoPage number, 10 reviews per page, newest first (1-100).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the bar is lower; the description still adds genuinely new behavior: 10 per page, newest-first ordering, and a `more` flag driving pagination. It does not cover failure modes (invalid id, empty results, page > 100), which keeps it at 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?

Four short, front-loaded sentences: what it returns, where the id comes from, pagination mechanics, and the sibling alternative. No filler, and the most decision-relevant facts (payload and provenance of `id`) come first.

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?

For a 2-parameter read tool with full schema coverage and rich annotations, the description supplies everything still missing: return contents, ordering, page size, and the continuation condition. An output schema would normally cover returns, but here the description names the key fields (stars, rating breakdown, `more`) adequately.

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; the description goes slightly beyond by tying `page` to the `more` signal ('call again with page+1'), which is a usage rule the schema cannot express. It otherwise restates the schema's '10 reviews per page, newest first' phrasing.

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?

States a specific verb and resource ('Get one page of user reviews of a place on Balad') plus the ordering and payload ('newest first, with stars and the rating breakdown'). It also distinguishes itself from sibling bl_place, which 'already includes the first few reviews', so an agent can route without opening schemas.

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?

Explicitly says where the required `id` comes from (bl_search or bl_nearby), gives the continuation rule ('when `more` is true, call again with page+1'), and names the alternative (bl_place) that already returns some reviews. That covers when to use, how to continue, and when not to use.

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