get_reviewsNormalized reviews for one listing on one platform. One call returns one page (up to limit, max 100).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| sort | No | ||
| limit | No | ||
| country | No | ISO-3166 alpha-2 country hint (booking) — pass the search result location.country with a bare booking.com slug. | |
| language | No | ISO-639-1 code. | |
| platform | Yes | ||
| listingId | No | ||
| minRating | No |
Changes observed during successful MCP inspections.
Input schema / properties / cursorRemoved value: -{
- "type": "string"
-}Input schema / properties / countryAdded value: +{
+ "description": "ISO-3166 alpha-2 country hint (booking) — pass the search result location.country with a bare booking.com slug.",
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent and openWorld, so the description's job is to add pagination semantics — and it does, disclosing that one call returns one page and cap is 100 (a constraint the schema's `limit` does not encode). It stops short of explaining how to advance to the next page, which matters given no cursor/offset parameter exists.
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 sentences, front-loaded with what is returned and immediately followed by the paging constraint. No filler or restatement of the title.
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 an 8-parameter tool with 25% schema coverage and no output schema, the description omits how to identify a listing (url vs listingId vs platform), how to iterate pages, and what a normalized review contains. It answers the paging-size question but leaves most invocation-critical detail to guesswork.
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 description coverage is only 25% across 8 params, so the description carries heavy burden, yet it clarifies only the effective limit cap. It never explains the url-vs-listingId relationship, sort enum effects, minRating, or the booking-specific country hint — all of which remain ambiguous.
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?
States a specific verb and resource ('Normalized reviews') and narrows scope to 'one listing on one platform', which is more precise than the title. It is clearly distinct from siblings like get_listing or get_price, but never names those siblings explicitly.
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?
Usage is only implied: the tool fetches reviews for a given listing+platform, so an agent can infer it needs an identifier. There is no explicit when-to-use / when-not-to-use guidance, no mention of prerequisites (listingId vs url, country hint for booking), and no routing versus get_listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.