Skip to main content
Glama

Paziresh24 FAQ

pz_faq
Read-onlyIdempotent

Answers how-to questions about Paziresh24 booking, cancelling or moving appointments, online visits, payments, and refunds, and lists FAQ questions when no query is given.

Instructions

Answers from the official Paziresh24 FAQ: how booking works, cancelling or moving an appointment, online visits (channels, prescriptions), payment and refunds.

Without a query it lists the questions only. Use for "how do I ..." questions about the site.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax answers.
queryNoTopic words in Persian, e.g. 'لغو نوبت' (cancel), 'استرداد' (refund), 'ویزیت آنلاین' (online visit). Empty = list every question.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so safety is covered. The description adds behavior beyond them: the empty-query browse mode and the fact that answers are drawn from an official FAQ corpus (authoritative, site-scoped). Minor gap: nothing about answer length or result limits beyond the schema's default.

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 sentences plus a topic parenthetical, all front-loaded: purpose first, browse-mode caveat second, usage rule last. Nothing redundant with the schema.

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?

Output schema exists, annotations are rich, and both parameters are fully documented, so the description need not explain returns. Remaining minor gap is that it does not hint at result-shape/limit interplay, but that is adequately handled by the schema.

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% and the schema itself documents the Persian topic-word format and that empty query lists all questions, so the description only echoes the empty-query behavior. Baseline 3 applies when the schema carries the parameter semantics.

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+resource ('Answers from the official Paziresh24 FAQ') and enumerates the covered domains (booking, cancel/move appointment, online visits, payment/refunds). No sibling tool (doctor search, prices, slots, holidays) does FAQ answering, so the agent can route without opening the schema.

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?

Explicitly scopes use to '"how do I ..." questions about the site', and adds the no-query browse mode ('Without a query it lists the questions only'). Clear usage context, though it never names a sibling alternative for overlapping informational queries.

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