Veterical Vet Clinic

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral detail: an id outside the organization returns not-found, and it enumerates the returned fields. It does not discuss auth or rate limits, keeping it at 4.

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 tight sentences, front-loaded with the usage trigger, then return fields, then the error case and the exclusion. 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 one-parameter read tool with full annotation coverage, complete schema and an output schema, nothing an agent needs is missing. The named-field summary is slightly redundant against the output schema but harmless.

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 clinicId param (24-char hex pattern) is fully documented there, so the baseline is 3. The description adds only the out-of-organization not-found behavior, not format or syntax beyond the schema.

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 (retrieve one vet clinic's basic settings) and names the exact fields returned, which distinguishes it from siblings like get_clinic_availability and show_clinic_overview. An agent can tell it apart 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?

Gives a clear trigger ('when someone asks about one vet clinic's basic settings') plus an explicit exclusion ('Not for free appointment slots'). It stops short of naming the alternative tool (e.g., get_clinic_availability) for the excluded case, so a 4 rather than 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 readOnly/idempotent/non-destructive/openWorld=false. The description adds genuinely new behavioral context beyond those: the 14-day and 100-slot caps, the per-day aggregation shape (count plus first start and last end), and a privacy guarantee that no pet/owner/medical data is 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?

Three tightly packed sentences, zero filler, front-loaded with the usage trigger before the return shape and caps. Every clause earns its place.

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 simple one-parameter read tool with full annotation coverage and an output schema, the description supplies the remaining unknowns: result caps, aggregation granularity, privacy scope, and the non-booking boundary. Nothing an agent needs to call it correctly 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?

Only one parameter (clinicId) and schema coverage is 100%, so the schema already documents the 24-hex-char format. The description adds only the framing that the query is scoped to a single clinic, which is the baseline expectation when the schema does the heavy lifting.

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 (returns open online-booking slots per day for one clinic) with the scope constraint 'one clinic' and explicitly disclaims booking. An agent can distinguish it from list_calendar_events or get_clinic_schedule_summary from the description alone.

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 a clear trigger ('when someone asks when their vet clinic has free appointment slots or openings') and an explicit exclusion ('Not for booking an appointment'). It stops short of naming the sibling tool that handles the excluded case, so the agent must infer the routing.

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?

With safety already covered by readOnlyHint/idempotentHint/destructiveHint, the description adds genuinely useful behavioral facts: canceled appointments are included, results are bucketed by UTC day, the default window is 7 days, the maximum is 31 days, and counting truncates at 100. The truncation cap in particular is not derivable from the annotations or schema.

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 tight sentences: triggering condition first, then the returned data and its defaults/limits, then the exclusion. No filler and nothing buried.

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?

An output schema exists, so return shape need not be explained. Scope, defaults, hard limits, truncation behavior and the negative case are all covered, leaving no gap an agent would need to guess at before calling it.

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 clinicId format, ISO 8601 date-times and the 31-day constraint are already documented. The description restates the 7-day default and 31-day ceiling but adds no new syntax or format 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?

States a specific verb and resource: returns appointment counts per day for one clinic. It also draws a scope boundary ('Not for seeing individual appointments, pets or owners'), which lets an agent separate it from list_calendar_events and the pet/owner tools without inspecting schemas.

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 triggering condition ('when someone asks how busy their vet clinic is or how many appointments fall on each day') plus a clear exclusion. It stops short of naming the alternative tool to call instead, so it is strong but not fully routing.

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 and closed-world, so the safety profile is covered. The description adds real value beyond that by disclosing what is omitted from results ('without titles, notes or names') and that extra openings are included, though it says nothing about pagination behavior despite a cursor parameter.

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, zero filler, purpose and scope front-loaded before the exclusion. Every clause earns its place.

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 a full output schema and 100% parameter documentation, the description only needs to supply intent and boundaries, which it does. An agent has everything required to decide and call 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 coverage is 100% and every parameter (limit, cursor, startTime, endTime, clinicId) carries its own description, so the baseline is 3. The description adds no filter syntax or semantics beyond the schema.

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 (closures, holidays, blocked time) and enumerates concrete block types (holidays, vacations, sick days, meetings, courses), so an agent can instantly tell this apart from appointment-oriented siblings. The closing exclusion 'Not for appointments' sharpens the scope further.

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 an explicit trigger ('when someone asks when their vet clinic is closed or has time blocked') plus an explicit when-not ('Not for appointments'), leaving no inference needed about alternative tools.

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=false, so safety is covered. The description adds genuinely new behavioral context: a 100-row result cap and an explicit statement of what is omitted (no contact details, roles or pet data) — useful for an agent predicting the payload.

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: the use case leads, the return shape and exclusions follow. Every clause earns its place with no preamble or repetition 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?

With complete annotations and a present output schema, the description only needs to supply the trigger, scope and result boundaries — all of which it does. Nothing an agent needs to select and call this tool correctly 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% for the single clinicId parameter, including the 24-char hex pattern, so the schema carries this dimension. The description only reinforces scoping ('for one clinic') without adding format or validation detail beyond the schema; 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 states a specific verb and resource ('List... vets, nurses or assistants... bookable at their clinic') and bounds the result set ('up to 100 staff display names for one clinic'). It also carves out a clear non-use case ('Not for staff days off or vacations'), which separates it from availability/schedule siblings.

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 triggering condition ('when someone asks which vets, nurses or assistants can be booked') plus an explicit exclusion for days off/vacations. It stops short of naming the alternative tool an agent should call for those excluded cases (e.g. get_clinic_schedule_summary), so routing is implied rather than directed.

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 and closed-world, so the safety profile is covered. The description adds useful context beyond that: the specific fields returned per clinic and the default page size of 20, which tells the agent what a call yields and that results are paginated.

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 with zero filler: the use case and the id-lookup trigger come first, the returned fields and page size follow, and the exclusion closes it out. Nothing is repeated from 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 a simple paginated read tool with full schema coverage, an output schema, and annotations covering safety, the description supplies everything needed: trigger, scope, return fields, and pagination default. No gaps remain.

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 both parameters (limit, cursor) are fully documented in the schema, so the baseline is 3. The description only echoes the default of 20 per page and adds no new syntax or paging semantics.

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 ('list ... vet clinics they manage in Veterical') and names what it is not for (pets, owners, appointments), which separates it from siblings like get_clinic and list_clinic_providers. An agent can select it 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?

Gives an explicit trigger ('when someone asks which vet clinics they manage... or a clinic's id is needed') plus a clear negative scope. It stops short of naming the sibling alternative (get_clinic) for single-clinic lookups, but the intent boundary 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 declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: pagination semantics (newest first, 20 by default, cursor for the rest) and an explicit data-exclusion guarantee ('no client, pet or card data') that an agent needs for privacy-sensitive answers.

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 user-facing trigger, then the return shape, then the exclusion. Every clause carries information and nothing is repeated.

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 an output schema present and 100% parameter coverage, the description need not explain return values or filters in detail. It still covers usage trigger, aggregation granularity, pagination, and data exclusions, leaving no gap an agent would need to guess at.

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 five parameters (limit, cursor, startTime, endTime, clinicId) are fully documented in the schema. The description only restates the cursor/default-limit behavior, adding no syntax, format, or filter-combination guidance 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?

The description states a specific resource and the exact aggregation performed ('totals and counts by currency and status for one page of payments'), which also resolves the tension between the name 'list_payments' and the summary behavior implied by the title. An agent can distinguish this from sibling tools like list_subscriptions or list_procedures without opening a 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 gives an explicit trigger ('when someone asks how much their vet clinic has taken in, or how many payments succeeded, failed or were canceled') and an explicit exclusion ('Not for refunds or charging a client'). Both when-to-use and when-not-to-use are spelled out rather than implied.

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=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful non-obvious behavior: it discloses the returned fields per row (price, duration where recorded, last edit time) and the surprising omission of treatment names, which an agent would otherwise have to learn from the output schema.

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 sentences, front-loaded with the trigger, followed by the return contract and the exclusion. Every sentence carries distinct information and none restates the name, 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?

Given an output schema exists, the description needn't spell out return shapes, and it still summarizes them briefly. Combined with the annotations and fully documented parameters, an agent has enough to call this correctly; only pagination behavior (covered in the schema) is left to structured fields.

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 limit, cursor and clinicId all documented in the schema itself, so the baseline is 3. The description adds nothing about parameter formats or constraints beyond the phrase 'per catalog row', which only loosely gestures at pagination.

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 ('prices set in their vet clinic's treatment and service catalog') and pins the scope further by naming the aggregate questions it answers (lowest, highest, most recently changed). It also carves out what it is not ('the price of a specific named treatment'), so an agent can route correctly 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?

'Use this when someone asks about the prices set in their vet clinic's treatment and service catalog' gives an explicit trigger, and the closing sentence gives an explicit exclusion ('Not for the price of a specific named treatment'). Both when-to-use and when-not-to-use are present, so no inference is required.

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, and destructiveHint=false, so safety is covered. The description adds real semantic content beyond that: it enumerates the returned fields and warns that caps are limits rather than usage, which prevents a common misinterpretation. It does not discuss pagination or auth requirements, hence 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 with the usage trigger, followed by the return contract and the exclusion. Every clause carries distinct information with no repetition of the title or name.

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?

An output schema exists, so return values need not be spelled out, yet the description still summarizes them usefully. Combined with full parameter coverage, an explicit exclusion, and annotations covering the safety profile, nothing needed to call this correctly 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%, so limit, cursor, and clinicId are fully documented in the schema itself. The description adds no syntax, default, or format detail beyond the schema, which matches the baseline 3 for a schema that does the heavy lifting.

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 (list subscriptions) and immediately narrows the intent to plan, status, and plan caps. It also explicitly disambiguates from the closest sibling, list_payments, by ruling out invoices and billed amounts.

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 concrete trigger phrasing ('when someone asks which Veterical plan their clinic is on, whether it is active, or how many users, seats, patients or appointments it allows') and an explicit exclusion that reroutes to the billing sibling. Both when-to-use and when-not-to-use are present.

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 establish readOnly, idempotent, non-destructive, and closed-world. The description adds value beyond them: a hard cap of 100 clinics returned, and an explicit inventory of what is NOT included (no pet, owner, appointment, or clinical data), which prevents an agent over-trusting the payload.

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, both earning their place: the trigger and scope come first, then the return cap and exclusions. No padding or 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?

An output schema exists, so return values need no explanation, and the description still clarifies the 100-clinic cap and the deliberate absence of clinical data. The one residue is how this opening tool differs operationally from list_clinics/show_clinic_overview for the same data.

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?

The tool takes zero parameters, so the baseline is 4 by rule. The description correctly implies no filtering input is required and that the app opens with a default set of clinics.

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: opens Veterical and surfaces clinics with schedule counts, availability, and catalog prices in a sidebar. However, it does not distinguish itself from siblings that also return clinic data (list_clinics, show_clinic_overview), leaving some overlap ambiguity.

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 a clear use trigger (someone wants to open Veterical and browse) plus explicit exclusions ('Not for booking appointments, editing records or medical decisions'). It does not name the sibling tools an agent should prefer for those excluded tasks, but the when/when-not framing is strong.

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, closed-world). The description adds genuinely useful scope context beyond them: it discloses the capped catalog sampling (up to 12 prices), the fixed 7-day appointment window, and explicitly that no pet, owner or medical data is included. Not a full behavioral spec, but solid added 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?

Three tight sentences, front-loaded with the trigger condition, then the return contents, then the exclusion. Every clause carries information; nothing is 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?

An output schema exists, so return-format exposition is unnecessary; the description still summarizes the payload and its privacy boundary. Combined with complete parameter docs and full annotations, an agent has everything needed to select and invoke 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% for the single clinicId parameter, including a regex pattern and format note, so the schema carries the semantics. The description adds nothing about the id format or sourcing, which is the expected baseline-3 outcome when the schema does the heavy lifting.

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 ('quick overview or dashboard of one vet clinic') and enumerates what the card contains: appointment counts for the next 7 days, bookable staff, open booking slots, up to 12 catalog prices. It distinguishes itself from appointment-level siblings but does not clearly differentiate from get_clinic, which likely also returns clinic details.

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 explicit when-to-use ('when someone wants a quick overview or dashboard of one vet clinic') and one exclusion ('Not for a single appointment'). However, the exclusion names a concept rather than a sibling tool, and it doesn't address when to prefer get_clinic or get_clinic_schedule_summary over this dashboard view.

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