Skip to main content
Glama

Doctor reviews

pz_reviews
Read-onlyIdempotent

Retrieve paginated patient reviews for a doctor by slug, including star ratings, visit details, verified-visit status, and first-page rating and waiting-time summaries.

Instructions

Patient reviews (stars 1-5, text clipped to 400 chars, visit reason, center, verified visit), paged, plus on the first page a summary: rating averages, counts and waiting time per center.

Reviewer names and ids are never returned.

Input Schema

NameRequiredDescriptionDefault
slugYesDoctor slug (Persian, e.g. 'دکتر-هدیه-جباری-0') or URL.
sortNo'relevant' = site default.relevant
limitNo
offsetNoReviews to skip.
full_textNoDo not clip text (400 chars).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.5.0
    • changedInput schema / properties / full_text / description
      Previous value: -"True = do not clip review text (default 400 chars)."New value: +"Do not clip text (400 chars)."
    • removedInput schema / properties / limit / description
      Removed value: -"Reviews per page."
    • changedInput schema / properties / offset / description
      Previous value: -"Reviews to skip, e.g. 5 for page 2."New value: +"Reviews to skip."
    • changedInput schema / properties / slug / description
      Previous value: -"Doctor slug (Persian, e.g. 'دکتر-هدیه-جباری-0') or profile URL."New value: +"Doctor slug (Persian, e.g. 'دکتر-هدیه-جباری-0') or URL."
    • changedInput schema / properties / sort / description
      Previous value: -"'relevant' = the site's default order."New value: +"'relevant' = site default."
  2. Changed11 schema fields changedv0.3.0
    • addedInput schema / properties / full_text
      Added value: +{
      +  "default": false,
      +  "description": "True = do not clip review text (default 400 chars).",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / limit / default
      Previous value: -10New value: +5
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • changedInput schema / properties / offset / description
      Previous value: -"Reviews to skip (paging), e.g. 10 for page 2."New value: +"Reviews to skip, e.g. 5 for page 2."
    • removedInput schema / properties / offset / title
      Removed value: -"Offset"
    • changedInput schema / properties / slug / description
      Previous value: -"Doctor slug from pz_search_doctors (Persian, e.g. 'دکتر-هدیه-جباری-0') or the doctor's paziresh24.com profile URL."New value: +"Doctor slug (Persian, e.g. 'دکتر-هدیه-جباری-0') or profile URL."
    • removedInput schema / properties / slug / title
      Removed value: -"Slug"
    • changedInput schema / properties / sort / description
      Previous value: -"'relevant' = the site's default order, 'newest' first."New value: +"'relevant' = the site's default order."
    • removedInput schema / properties / sort / title
      Removed value: -"Sort"
    • removedInput schema / title
      Removed value: -"pz_reviewsArguments"
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "pz_reviewsDictOutput",
      -  "type": "object"
      -}New value: +null
  3. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description still adds real behavioral context beyond them: text is clipped at 400 chars by default, reviewer names and ids are never returned, pagination applies, and the summary appears only on the first page. It stops short of describing error behavior for an invalid slug or whether the summary aggregates all reviews versus the current page.

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?

Two short sentences with no filler; the content list and paging behavior are front-loaded before the privacy caveat. The dense parenthetical field list is slightly harder to scan than prose but every element carries information.

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 carries the return-value burden and does so well by describing review fields, the first-page summary, and the privacy exclusion. For a read-only five-parameter tool the remaining gap is minor: failure handling and the exact scope of the aggregate summary are unstated.

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 80%, so the baseline is 3, but the description goes further by explaining the default clipping behavior that the full_text flag toggles and by making the paged nature of the result explicit, which clarifies how limit/offset behave. It does not add anything about sort semantics ('relevant' is left to the schema) or slug format handling.

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?

The description names the resource precisely (patient reviews for a doctor) and enumerates the returned fields (stars 1-5, text, visit reason, center, verified visit), so an agent can tell this apart from pz_doctor or pz_center at a glance. It lacks an explicit verb such as 'get/list' and never names a sibling, which keeps it below a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the required slug and the review-oriented return shape signal 'use this when you need reviews for a specific doctor'. There is no explicit when-to-use, when-not-to-use, or pointer to an alternative (e.g. whether pz_doctor already embeds reviews), so the agent must infer the fit.

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