patient-services

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context that the record must be published and that the tool works across multiple entity types, which is beyond the annotations. No contradictions detected.

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 description is a single, front-loaded sentence with no wasted words. It conveys the action, resource, and scope efficiently.

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 tool with one parameter, annotations, an output schema, and a clear description, everything needed for correct invocation is present. The tool's scope and return type are adequately covered.

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 a helpful example. The description adds meaning by clarifying that entity_id can be a clinic, doctor, or treatment, extending beyond the schema's doctor-only example.

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 clearly states the tool retrieves the full published record for a known entity_id, specifying supported entity types (clinic, doctor, or treatment). This distinguishes it from sibling get_* tools that fetch specific subsets like prices or reviews.

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?

The phrase 'for a known entity_id' implies the tool is used after a search has yielded an ID, providing clear context. It does not explicitly name alternatives, but the full-record scope contrasts with the more specific sibling tools, giving implicit usage 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 disclose readOnlyHint=true and destructiveHint=false. The description adds the substantive content being returned but does not go beyond that (e.g., no mention of response format, pagination, or edge cases). It is consistent with annotations, earning a mid-range score.

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 description is a single, front-loaded sentence that communicates the full scope without any filler or repetition. Every word 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 no-parameter, read-only tool with no output schema, the description clearly explains what is returned (schedule and problem-handling process). It is sufficient for an agent to know the tool's purpose, though it doesn't specify the format or granularity of the 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?

There are zero parameters, so the baseline for this dimension is 4. The description does not need to add parameter-level details because none exist.

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 uses a specific verb ('Returns') and clearly names the resource ('remote follow-up schedule' and 'process for handling a suspected problem'). It distinguishes itself from siblings like get_visit_information by focusing on post-discharge aftercare.

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?

The phrase 'after a patient has returned home' provides clear contextual timing for use. However, it does not explicitly name sibling tools as alternatives or exclusions, so it stops short of full usage 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 readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by enumerating the specific types of information returned, which is useful because there is no output schema. It does not contradict annotations.

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 description is a single, well-structured sentence that immediately names the action ('Returns structured facts') and the target ('Taki Dent clinic'), followed by a clear list of content categories. Every word 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?

Given zero parameters, read-only annotations, and no output schema, the description provides sufficient context for an agent to understand what the tool returns and when to select it. It could be slightly more explicit about the distinction from other info tools, but it is complete enough for a zero-input retrieval 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?

With zero parameters, the description does not need to explain parameter semantics. The baseline for 0 params is 4, and the description appropriately focuses on the output content instead.

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 clearly states the tool returns structured facts about the Taki Dent clinic and lists specific content areas (legal identity, address, contact details, languages, certifications). It distinguishes from siblings like get_doctor_profile and get_prices by focusing on the clinic entity as a whole.

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?

The description implies when to use this tool (when you need clinic-level facts) but does not explicitly state when not to use it or mention alternatives. It provides clear context without exclusions or comparative guidance against sibling 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=true and destructiveHint=false, so the description goes beyond by specifying that only 'published professional memberships' are returned and that matching supports 'known name-spelling aliases'—useful behavioral details not captured in annotations.

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 description is a single, well-structured sentence that front-loads the purpose, lists key return fields, and specifies matching criteria without any filler 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?

With one simple parameter, high schema coverage, an output schema present, and a read-only annotation, the description fully covers the necessary context. It lists typical return fields and matching methods, making it complete for this simple retrieval 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?

The input schema already fully describes the 'doctor' parameter with examples, achieving 100% coverage. The description's mention of matching by entity_id, name, or alias largely duplicates the schema, adding no significant new semantic information.

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 clearly states the tool 'Returns a clinician profile' and enumerates specific fields (title, specialty, languages, education, memberships). It distinguishes from siblings like get_clinic_profile by focusing on 'clinician' and from get_reviews_summary by listing profile attributes.

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?

The description implies when to use it: when you need a clinician profile, matched by ID, name, or alias. However, it does not explicitly mention alternatives or exclusion criteria, so usage guidance is only inferred from the tool name and content.

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 and destructiveHint=false, so the read-only nature is known. The description adds useful behavioral context by detailing what the warranty terms include (tiering, exclusions, remote-claim process), which helps an agent understand the tool's output without contradicting annotations.

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 description is a single, well-structured sentence that front-loads the core function and packs key details without redundancy. Every phrase 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 zero parameters and no output schema, the description fully covers what the tool returns and how it is organized. It is complete for a simple read-only information 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?

The tool has zero parameters, so the baseline is 4. The description correctly adds no parameter-specific details since there are none; the schema already confirms no inputs are required.

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 uses a specific verb 'Returns' and identifies the resource 'clinic's warranty terms' with concrete details (tiered by treatment material, exclusions, remote-claim process). This clearly distinguishes it from sibling tools like get_prices or get_aftercare_information.

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?

The description implies when to use this tool: whenever warranty/guarantee information is needed. It does not explicitly name alternatives or exclusions, but the context is clear and the sibling list shows other tools address different topics.

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 and destructiveHint=false, covering the safety profile. The description adds that prices are 'published' and in GBP/EUR, which is useful context, but it doesn't disclose additional behavioral traits like pagination, exact-match filtering, or handling of invalid treatment IDs. It adds some value without contradicting annotations.

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?

A single sentence that is front-loaded with the action ('Returns') and resource, with no filler or redundant information. Every word contributes to understanding the tool's purpose.

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?

The tool is simple with one optional parameter and an output schema present (so return values need not be described). The description covers the core purpose and data format (currencies, per-treatment). It could mention behavior when no filter is provided, but given the low complexity and rich schema/annotations, it is sufficiently complete.

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%, with the 'treatment' parameter fully described in the schema. The description's 'per treatment' aligns with the filter but adds no new meaning beyond the schema. Baseline of 3 is appropriate 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?

The description uses the specific verb 'Returns' and clearly identifies the resource as 'the clinic's published treatment prices, with currency scope (GBP and EUR) and per-treatment granularity. This distinguishes it from siblings like get_treatments (which likely lists treatments) and get_clinic_profile.

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?

The description implies usage when prices are needed, but provides no explicit comparison to alternatives or exclusions. It doesn't say when not to use it or whether siblings like get_treatments would be more appropriate in other scenarios. Usage is implied rather than stated.

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 readOnlyHint=true and destructiveHint=false, reducing the need for safety disclosure. The description adds useful context that the data is 'sourced from the live Google Business Profile,' implying real-time data rather than cached output. This contributes beyond the structured annotations.

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 description is a single, well-formed sentence that front-loads the action with 'Returns.' It contains no irrelevant details and earns its place entirely.

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 zero-parameter read-only tool with no output schema, the description adequately communicates the primary output: review count and average rating. It lacks explicit details about the rating scale (e.g., 1-5) and data types, but these are generally inferred from 'Google review rating.' The simplicity of the tool mitigates the need for more.

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 has zero parameters, so the schema provides no parameter semantics. The baseline for zero parameters is 4. The description adds meaning by specifying what the tool returns (review count and average rating), though it does not explain any parameter constraints since none exist.

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 clearly states the verb 'Returns' and the specific resource: the clinic's Google review count and average rating. It distinguishes itself from sibling tools like get_clinic_profile by focusing narrowly on review metrics.

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?

The description implies usage when a user needs review count and average rating, but it does not explicitly state when to use this tool over siblings or when not to use it. No exclusions or alternatives are mentioned, so guidance is only implicit.

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 indicate read-only and non-destructive behavior. The description adds that the list includes canonical URLs, which is useful context, but doesn't disclose other behavioral details like ordering, pagination, or whether the list is exhaustive.

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 description is a single, well-structured sentence that begins with the main verb and conveys all necessary information without unnecessary words. It 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 zero-parameter, read-only list tool, the description sufficiently conveys the return content (treatments with canonical URLs). Although no output schema exists, the description is adequate for its simplicity.

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?

With zero parameters, the baseline for parameter semantics is 4. The description has no need to explain parameters, and the schema trivially covers them all. No additional parameter information is required.

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 uses a specific verb 'Lists' and clearly identifies the resource ('treatments offered by the clinic'), while adding a distinctive detail ('canonical page URL'). This clearly differentiates it from sibling tools like get_prices or get_clinic_profile.

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?

The description implies usage (listing treatments) but provides no explicit when-to-use or alternatives. Given the tool's simplicity, it's acceptable but lacks clear guidance on when to choose this over search or other related 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?

The readOnlyHint and destructiveHint annotations already cover the safety profile. The description adds context by listing the specific data categories returned, but it doesn't disclose additional behavioral details like data freshness, potential omissions, or response formatting. This is sufficient given the low risk, but not rich.

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 description is a single, well-structured sentence that front-loads the core action and then enumerates the contents. No wasted words.

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 no-parameter, read-only informational tool, the description covers all relevant aspects: what data is returned and the purpose. With no output schema, the enumerated list provides sufficient completeness. The presence of sibling tools doesn't create ambiguity given the specific scope.

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 has zero parameters and the schema is empty. The description implicitly confirms that no inputs are needed, which aligns with the baseline 4 for parameterless tools.

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 uses the specific verb 'Returns' and identifies the resource as 'practical trip-planning facts,' listing concrete content categories (clinic location, opening hours, airport distance, transfers, accommodation, stay length, package inclusions). This clearly distinguishes it from sibling tools like get_clinic_profile and get_prices, which focus on different aspects.

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?

The description conveys a clear use case—trip planning—through the phrase 'practical trip-planning facts' and the enumerated content. However, it does not explicitly mention when to prefer this tool over siblings or provide exclusions, so it lacks the explicit guidance 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=true, and the description adds useful behavioral context: the deep link is pre-filled with a consultation-request message and the language parameter influences this message. No contradictions with annotations, and the additional detail goes beyond the safety profile.

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 description is a single, front-loaded sentence that delivers the key information efficiently. It contains no filler or redundant details, making it easy to parse.

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 the tool's simplicity (one optional parameter, no output schema), the description and schema together fully cover what the tool does and how to invoke it. There is no missing critical information for an agent to select and use 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?

The schema already describes the 'language' parameter with a list of codes and a default. The description adds meaning by explaining that the language determines the language of the pre-filled consultation message, which is not fully captured by the schema's enumeration.

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 clearly states the verb 'Returns' and the resource 'clinic's WhatsApp contact deep link', specifying that it is pre-filled with a consultation-request message. This distinguishes it from sibling tools like get_clinic_profile or request_callback, which serve different purposes.

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?

The purpose is clear enough that an agent can infer when to use this tool (to provide a WhatsApp contact link with a pre-filled message). However, it does not explicitly mention alternatives or exclusions, such as for requesting a callback via request_callback, so guidance is implicit rather than explicit.

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 mark destructiveHint=true, and the description adds 'irreversible once sent', which is specific and useful. It also adds a payload restriction ('do not include medical details'), providing context beyond the annotation. No contradiction with annotations.

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 primary action, and no redundant words. The key warnings are included without fluff, making it highly concise and well-structured.

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 tool of this complexity (5 params, destructive annotation, output schema present), the description covers core behavior, payload limits, and irreversibility. Since an output schema exists, return values need not be explained. It lacks details about next steps but is otherwise sufficient for selection and invocation.

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 low (20% – only 'consent' has a description). The description mentions 'name and contact details', which loosely maps to name/email/phone but does not elaborate on each parameter or the preferred_language enum. The schema provides structural info but the description only partially compensates for the low coverage.

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 uses a specific verb ('Requests') and a clear resource ('callback from the clinic's patient coordination team'). It distinguishes itself from all sibling tools, which are read-only (get/fetch/search), and clarifies it collects only contact information, not medical 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?

The context is clear: this is the only mutating tool among read-only siblings, so usage is implied. The description adds a guideline about what to include ('only contact information') and explicitly excludes medical details, but it does not name alternative tools or state when not to use it.

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 and destructiveHint=false, so the safety profile is known. The description adds context about what is searched (name, alias, summary text) but does not disclose behaviors like result limits, ordering, or exact matching semantics, which would be useful for a search tool.

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?

A single, precise sentence conveys the tool's purpose without redundancy. Every clause adds information, and there is no filler or repetition of schema/annotation content.

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 search tool with an output schema and strong annotations, the description is largely sufficient. It covers the search scope and return type. However, it omits potential edge-case behaviors like result pagination or ordering, which might matter in some searches, but given the simplicity, it remains complete enough.

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% with a clear description of the 'query' parameter. The tool description complements the schema by specifying the entity fields searched (name, alias, summary text), which enriches the parameter's meaning beyond the schema alone.

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 clearly identifies a specific action ('searches'), the target ('clinic, doctor, and treatment entity index'), and the search basis ('by name, alias, or summary text'). It differentiates from sibling tools like get_doctor_profile or get_clinic_profile, which are for fetching specific items, and fetch, which likely retrieves by ID.

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?

The description implies usage for finding entities when you have free-text input, and the sibling tool names suggest alternatives for direct retrieval. However, it does not explicitly state when to avoid using this tool or name an alternative, so it stops short of full exclusion guidance.

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