Returns the clinic's WhatsApp contact deep link, pre-filled with a consultation-request message in the requested language.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language code (en, de, ar, tr, ru, fr, pl); defaults to en |
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| meta | Yes | ||
| evidence | Yes |
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 covered. The description adds behavioral context by noting the link is 'pre-filled with a consultation-request message in the requested language,' which is not inferable from the schema or annotations. This enriches the agent's understanding of the tool's 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 description is a single, front-loaded sentence that immediately states the verb and object, with no filler. Every phrase earns its place by specifying the return value and the language-dependence of the message.
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 optional parameter, an output schema, and comprehensive annotations, the description is adequately complete. It clearly states what is returned and the key variable (language). It does not mention edge cases like invalid language codes, but the schema's default and existing annotations make this a minor gap.
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 provides 100% coverage for the sole parameter 'language' with a description and default value. The description's mention of 'requested language' aligns with the parameter but adds no new semantic information beyond the schema. Baseline 3 is appropriate given the high schema 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 ('Returns') and names the exact resource ('WhatsApp contact deep link'), including the pre-filled consultation-request message and language parameter. This clearly distinguishes it from sibling tools like get_clinic_profile or get_visit_information, which return different 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 the tool is for retrieving a WhatsApp contact deep link, but it does not explicitly state when to use it over alternatives or provide exclusions. Unlike the high-calibration example, it does not name any sibling tool for comparison or mention 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.
Add one secure layer between your agents and this server.
Each get_* tool targets a distinct information domain (clinic profile, doctor profile, prices, reviews, etc.), but the generic 'fetch' overlaps with the specific getters, creating minor ambiguity.
Most tools follow a get_* pattern, but 'fetch' breaks the convention, and 'search' and 'request_callback' deviate from the get_ prefix, resulting in an inconsistent style.
With 12 tools, the set is well-scoped for a patient services server, covering information retrieval and contact actions without bloat.
The server covers the core patient journey: researching treatments, clinic info, prices, reviews, visit logistics, and initiating contact via callback or WhatsApp. A potential gap is direct appointment booking, but the contact mechanisms compensate.
