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

Annotations already declare the safety profile (readOnly, idempotent, non-destructive, openWorld), lowering the bar. The description adds genuine value by disclosing the return content (departments, per-doctor slug/department/specialty/insurances), which is the only place this is captured since there is no output schema. No auth or rate-limit notes, so not a 5.

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: the first defines the tool and its payload, the second gives the routing hint. Zero filler; every clause carries information.

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?

With no output schema, the description must carry the return-shape burden, and it does list the returned fields. Combined with 100% parameter coverage and annotations handling the safety profile, an agent has enough to invoke it correctly; only the exact response structure is left implicit.

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 100%, so all four parameters (slug, full_text, specialty, doctors_limit) are already documented in the schema. The description itself adds no parameter-level syntax or semantics beyond the schema, so the baseline of 3 applies.

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?

The description states a specific resource (hospital/clinic profile) and enumerates exactly what it contains: type, address, phone, website, map, about, departments and doctors. This lets an agent distinguish it from pz_search_doctors (search) and pz_doctor (single doctor) without opening any schema.

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?

It explicitly routes the agent onward ('Next: pz_search_doctors(center_id=..., sort='earliest') for its doctors by nearest free time, or pz_doctor'), and the schema's slug description names pz_search_doctors as the source. There is clear context but no explicit when-not-to-use or exclusion guidance.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the bar is lower, yet the description still adds domain behavior: `booking_off: true` means booking is disabled and you should call the phone, and `booking_opens` marks when new slots appear. That is genuine operational context beyond the structured fields, though auth/permission or rate-limit behavior is not covered.

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?

The return-content summary is front-loaded and the follow-on routing is packed into two terse clauses with backticked field names. It is dense but every sentence carries information; the field-list sentence is long but earns its length by describing the payload.

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?

With no output schema, the description compensates well by enumerating the returned fields and interpreting the booking-related flags. Full read-only annotations cover the safety profile, so an agent has nearly everything needed to call it correctly; only some field semantics (e.g., rating averages, user_center_id) remain unstated.

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 100% and the schema already documents both parameters in detail (slug format with an example, and full_text's default 1200-char clipping). The description adds no additional parameter-level meaning, so the baseline 3 applies.

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?

The description names a specific resource (full profile of one doctor) and enumerates exactly what is returned: specialties, about, rating averages, insurances, online visit channels/pricing, and per-center details with services. This clearly distinguishes it from the search/list siblings and lets an agent know it is the single-entity detail endpoint.

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?

It gives explicit downstream routing: the service's center_id/user_center_id/service_id 'feed pz_free_days, pz_free_slots and pz_visit_price' and 'Next: pz_reviews, pz_first_available'. That is strong chain guidance, though it never states the inverse condition (e.g., use pz_search_doctors first to obtain a slug, or when not to call this).

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds real behavioral context beyond them by disclosing the no-query listing mode, but it never mentions that answers are clipped at 1500 characters by default, which materially affects what the agent receives.

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 short sentences, front-loaded with the resource and its scope, followed by the one mode-switching behavior worth knowing. Every sentence earns its place with no redundancy.

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 a read-only FAQ retrieval tool with complete schema coverage and no output schema, the description covers domain, trigger condition and the no-query mode. The only notable omission is any hint that long answers are truncated unless full_text is set, which is left entirely to the schema.

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 100%, so limit, query and full_text are already fully documented in the schema (including Persian examples and the empty-list behavior). The description only restates the query-less listing mode, adding no new parameter semantics — the correct baseline of 3.

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?

Names a specific resource (the official Paziresh24 FAQ) and enumerates the content domains it covers: booking, cancelling/moving, online visits, payment and refunds. That is enough to separate it from the sibling data-lookup tools (pz_search_doctors, pz_visit_price, pz_holidays), though no sibling is named 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?

"Use for 'how do I ...' questions about the site" gives a clear trigger condition, and "Without a query it lists the questions only" describes a distinct browse mode. There is no explicit when-not guidance or named alternative, but the usage context is unambiguous.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely new context: that it answers a yes/no bookability question, returns the nearest slot, and expresses results in Tehran time.

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 short sentences, front-loaded with the core answer (can this doctor be booked now), followed by scope and the sibling routing hint. No filler.

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 a single-param, no-output-schema read tool with rich annotations, the description covers what comes back and when to reach for it. The phrase "per center" is mildly ambiguous given the tool accepts only a doctor slug.

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?

Only one parameter and schema coverage is 100%, with the schema already documenting the slug format (Persian slug or profile URL). The description adds nothing about the slug, so the baseline of 3 applies.

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+resource: reports whether a doctor is bookable now plus the nearest free slot, and scopes it to in-person, online and per-center with an explicit time zone. It also positions itself against siblings (pz_free_days / pz_free_slots), so an agent can tell it apart without opening another schema.

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?

"A quick check before pz_free_days / pz_free_slots" gives explicit ordering guidance and names the alternative tools it precedes. It stops short of stating when NOT to use it (e.g. when you already know the date window and should go straight to free_slots).

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

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

Annotations already declare a safe, read-only, idempotent, open-world read, so the bar is lower. The description adds genuine behavioral context beyond that: the booking window span (often 6-8 weeks) and that weekly days off and holidays are factored in, which explains why some days are absent from results.

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 tight sentences with zero waste: purpose and scope first, then the workflow pointer. Front-loaded and easy to scan.

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?

With annotations covering the safety profile, all three params documented in the schema, and no output schema required, the description supplies the needed purpose and continuation. Minor gap: no hint about result shape or volume for a window that can span weeks.

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 100%, and the schema already states where each id comes from (pz_doctor, search card). The description's 'Ids from pz_doctor' largely repeats the schema rather than adding new meaning, so baseline 3 is appropriate.

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 resource (days with a free appointment) scoped to one service at one center across the entire booking window, and names pz_free_slots as the follow-on. It clearly separates itself from pz_free_slots, though it leaves the distinction from pz_first_available unstated.

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?

Provides a workflow chain: ids come from pz_doctor, and pz_free_slots should be called next to get times for chosen days. This gives clear context for when to invoke it, but no explicit when-not/tie-breaking guidance against other availability siblings.

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

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

Annotations already declare this a safe, idempotent read. The description adds non-obvious value: the timezone and time format of results, and the fallback behavior that `next_free_day` supplies a next date when the range yields nothing.

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?

Front-loads what the tool returns, then the id provenance and the empty-result fallback. Tight overall, with no redundant sentences, though the trailing fragment about next_free_day reads slightly disjointed.

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?

With no output schema, the description usefully characterizes the return shape (per-day start times in Tehran HH:MM) and the fallback field. It covers what an agent needs to call and interpret the tool, missing only pagination or rate-limit behavior.

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 100%, so the schema already documents the id patterns, date formats and the 14-day cap on date_to. The description only restates the general 'one service at one center, for a date range' framing, adding nothing beyond schema detail.

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 resource (free appointment start times), a precise format (Tehran HH:MM), and the scope (per day, one service at one center, over a date range). It is immediately distinguishable from pz_free_days, which returns days rather than start times.

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?

Explains where the required ids come from (pz_doctor or a search card) and routes the agent to pz_free_days to discover which days to query. That is clear workflow context, though there is no explicit statement of when not to use this tool or a hard exclusion.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered. The description still adds non-obvious behavioral context: that Fridays are deliberately omitted and that results carry Persian/Hijri naming, which an agent must know before treating the list as complete.

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?

Three short lines: purpose, scope/return, caveat, usage trigger. Nothing is redundant and the resource is stated in the first clause, so the agent can act on the opening sentence alone.

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 a two-parameter lookup with no output schema, the description supplies the return fields (Persian name, Hijri date) and the Friday caveat, which is enough to interpret results. It stops short of describing ordering or response shape, but nothing critical for correct invocation is missing.

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 100%, with both date parameters documented including format and the one-year span limit, so the schema carries the semantics. The description only restates 'between two dates' and adds no format or boundary detail beyond it, which is the baseline 3.

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?

Names a specific resource (official Iranian public holidays and occasions) with an explicit scope (between two dates) and return payload (Persian name, Hijri date), so an agent knows exactly what it gets. It does not name or differentiate itself from the closest sibling (pz_free_days), which is the only thing keeping it off a 5.

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?

Gives an actionable workflow trigger: 'Use before suggesting appointment days,' which tells the agent where this fits relative to scheduling siblings. It states one exclusion ('Fridays are not listed') but offers no explicit when-not or named alternative tool, 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.

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds value by disclosing the returned content (kind, slug, clean URL), which is important since there is no output schema. Minor gap: no statement about failure behavior for unrecognized or non-paziresh24 URLs.

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 short sentences, zero filler, with the input action front-loaded and the routing hint second. Nothing redundant with the title or schema.

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 a single-parameter URL parser with no output schema, the description covers the essential facts: input source (pasted link), encoded result fields, and the follow-up tools. An agent has everything needed to call it correctly.

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 100% and the single 'url' parameter is fully documented in-schema with length bounds and example path formats. The description adds nothing about parameter syntax beyond the schema, so the baseline 3 applies.

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+resource ('turn a paziresh24.com link into...') and enumerates the outputs: kind ('doctor' or 'center'), slug, clean URL. This clearly differentiates it from the sibling search/lookup tools, which take queries rather than URLs.

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?

'Use when the user pastes a link' gives an explicit trigger condition, and 'Next: pz_doctor or pz_center' names the downstream alternatives an agent should route to based on the returned kind. The agent knows both when to call it and what to do afterwards.

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

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

The annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the 400-character clip on review text, that the summary appears only on the first page, and the privacy guarantee that reviewer names and ids are never returned.

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, tightly front-loaded on the payload contents, with the privacy note last. The parenthetical list is dense but every item is load-bearing; nothing is redundant.

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?

With no output schema, the description carries the burden of describing the return shape, and it does so field-by-field including the first-page-only summary. Minor gap: it does not say how many total reviews exist or how to detect the last page, which matters for a paged tool.

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 coverage is 100%, so sort/limit/offset/full_text semantics are already documented in the schema and the 3 baseline applies. The description reinforces the clip behavior tied to full_text but adds no syntax, ranges or pagination math beyond what the schema states.

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?

The description states precisely what is returned: patient reviews with stars, clipped text, visit reason, center and verified-visit flag, plus a first-page summary of averages, counts and waiting times. It is clearly distinguishable from the doctor/center/search siblings by resource (reviews), though it never names them for contrast.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives among the twelve sibling tools. The reader must infer from the 'slug' parameter that this is invoked on a doctor profile; nothing in the description says so.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds genuinely new behavioral context by enumerating the returned doctor-card fields — slug, url, image, rating, insurances, first free in-person/online slots — and noting that online_visit appears only when offered with price in Toman, which matters because there is no output schema. It does not mention rate limits or pagination behavior.

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?

The opening sentence is front-loaded with verb, resource and facets, and the follow-up routing line is compact. The middle sentence listing card fields is dense but each field earns its place given the absence of an output schema.

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 a 12-parameter, all-optional search tool with no output schema, the description covers the filter surface, the return shape, and the next-step tools, which is close to sufficient. Minor gaps remain around paging/sorting semantics and total-result behavior, but those are largely covered by the schema.

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 100%, so each parameter is already fully documented in the schema itself. The description only restates the facet list and the service_id dependency, adding no syntax or format detail beyond what the schema provides; the baseline of 3 applies.

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?

The first sentence gives a specific verb (Search) plus resource (doctors) and enumerates the exact filter facets — city, specialty, name, visit type, gender, degree — including the alternate mode (hospitals and clinics). It also names the sibling tools this feeds into (pz_doctor, pz_free_days, pz_free_slots), so an agent can place it in the pipeline 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.

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

It supplies concrete routing context: 'Next: pz_doctor, or pz_free_days / pz_free_slots,' and the conditional 'a missing service_id comes from pz_doctor.' That tells the agent when to follow up, though it never states when to prefer an alternative (e.g. pz_first_available) or when not to use this search.

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

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 real behavioral context beyond them: it is a slug-resolution step, it returns slug-bearing lists, and one completion should be reused as a downstream `text` value.

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 the transformation and followed by the ordering instruction. No filler.

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?

With no output schema, the description responsibly sketches the return shape (cities, specialties with slugs, completions). Minor ambiguity remains: it references a `text` argument that belongs to pz_search_doctors rather than this tool, which could momentarily confuse an agent.

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 coverage is 100% and both params are documented (the `query` description even enumerates city/specialty/name forms), so the schema does the heavy lifting. The description only adds that outputs become arguments for another tool, not new meaning for `query` or `limit`.

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 concrete transformation ('turn words into pz_search_doctors arguments') and enumerates exactly what comes back: cities, specialties with slugs, and query completions. This clearly distinguishes it from the sibling pz_search_doctors it feeds.

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?

Gives an explicit trigger ('Call first when you lack the city or specialty slug') and the follow-up step ('Next: pz_search_doctors'). The agent knows both when to use it and where to go afterwards.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real behavioral value: the composition of the returned invoice and the degenerate zero-price case for office visits. It does not cover failure modes (e.g. what happens if the IDs don't match) or pagination/response shape, but for a simple read that is a minor gap.

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 short sentences, no filler, and the payoff (what you get back) is stated before the caveat about when the result is useless. Every clause carries information.

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?

With no output schema, the description correctly takes on the burden of describing return values, and the annotations cover safety. What remains thin is provenance guidance — where to obtain the three required IDs — though the schema descriptions partially cover this.

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 100% and each of the three IDs is already documented in the schema, including the '5532' = online visit mapping. The description's center_id '5532' remark largely restates the schema, adding no syntax or sourcing detail beyond it, so the baseline 3 applies.

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?

The description names the resource (price of one service) and itemizes the exact outputs: fee, VAT, payable total, and the refund-on-cancel setting. No sibling tool deals with pricing, so there is no ambiguity to disambiguate.

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?

It gives a clear usage signal — 'Most useful for online visits (center_id 5532)' — and warns that office visits 'usually show 0,' which is effectively a when-not-to-trust-the-result condition. It stops short of naming an alternative tool or stating prerequisites, so it is context rather than full routing.

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