Find Canadian dentists; send an appointment request or book with a connected practice.
Scored across 15 tools
Most tools have clearly distinct purposes, and the booking/request flows are well separated. However, list_public_booking_slots vs list_xona_booking_slots and list_public_booking_services vs list_xona_booking_services could be confused at a glance, and get_canadian_dental_practice overlaps somewhat with answer_dental_practice_question on factual evidence.
All tool names follow a consistent snake_case verb_noun pattern with clear domain qualifiers, such as list_xona_booking_slots, confirm_xona_booking, and get_dental_action_status. There are no mixed casing styles, vague verbs, or unpredictable naming deviations.
Fifteen tools is at the upper end of the ideal range, but each tool represents a distinct workflow step or data source needed by the dental gateway. The count feels intentional rather than bloated, covering discovery, public widgets, Xona booking, requests, and action status.
The core patient journey is well covered: find a practice, read availability, hold and confirm a booking, start and confirm a request, and check action status. The main gap is the lack of a cancellation or update path for confirmed bookings or in-flight requests after they are no longer abandonable.
Release the held time and drop the patient's details when the patient no longer wants it, at any step before it is booked. It never cancels a booked appointment. Calling again returns the same result.
| Name | Required | Description | Default |
|---|---|---|---|
| action_id | Yes |
| Name | Required | Description |
|---|---|---|
| reason | No | |
| outcome | No | |
| practice | Yes | |
| action_id | Yes | |
| next_step | Yes | |
| booking_url | No | |
| continue_url | No | |
| confirmation_sms | No | |
| appointment_start | No | |
| appointment_start_local | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation Contradiction: the description says it 'drops the patient's details,' which is a destructive/removal operation, while annotations declare destructiveHint=false. The description does add idempotency information, but the direct conflict with the destructive flag makes the tool's behavior ambiguous for an agent.
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 sentences each carry distinct information: the action, the scope of applicability, and idempotency. There is no filler, repetition, or unnecessary detail.
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 has one required parameter and an output schema, so return-value documentation is already handled. The main gap is that the description does not explain how to obtain action_id, but the behavioral boundaries and idempotency are otherwise well 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 0% and the description never mentions the only parameter, action_id. The agent can infer it refers to an action identifier, but there is no guidance connecting it to a prior step such as hold_xona_booking_slot or list_dental_practice_actions.
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: it releases held time and drops patient details for a booking that is not yet booked. The boundary 'before it is booked' and the contrast 'never cancels a booked appointment' clearly distinguish it from sibling tools like confirm_xona_booking.
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 when-to-use condition ('when the patient no longer wants it, at any step before it is booked') and an exclusion ('never cancels a booked appointment'). It does not name an alternative tool explicitly, but the workflow boundary is sufficiently explicit for routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answer a bounded factual question from the selected practices' evidence. Unknown is returned explicitly; missing data is never inferred as no.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| practice_slugs | Yes |
| Name | Required | Description |
|---|---|---|
| answers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, covering safety. The description adds valuable behavioral context: 'Unknown is returned explicitly; missing data is never inferred as no.' This clarifies handling of missing data, which is not in annotations, so it adds real 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 with zero waste. The main purpose is front-loaded, and the behavioral caveat follows. No redundancy or 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?
Given the output schema exists and the input schema defines the topic enum, the description is fairly complete. It explains the unknown-handling behavior but does not elaborate on practice_slugs or topic categories, though those are largely covered by the schema. Minor gap on usage guidance, but not critical for a read-only QA 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 description coverage is 0% – the description does not mention the two parameters at all. The topic parameter has an enum but no descriptions, and practice_slugs is self-explanatory, yet the description provides no guidance on how to populate them. Since coverage is low, the description should compensate but only weakly implies a bounded question set.
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 clear verb+resource: 'Answer a bounded factual question from the selected practices' evidence.' It differentiates from siblings like search_canadian_dentists and get_canadian_dental_practice by focusing on evidence-based QA. Not a tautology and not vague.
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 (answering factual questions about selected practices) but gives no explicit alternatives or exclusions. Among many booking/action siblings, this tool is clearly distinct, but the description does not name them 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.
Send the started request to the clinic after the patient reads back their code and agrees to consent_text. The outcome is a delivered, held or failed request, never a confirmed booking. Calling again with the same action_id returns the same outcome and sends nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| action_id | Yes | ||
| consent_version | Yes | ||
| preferred_window | Yes | When the patient is free, in their words | |
| service_category | Yes | ||
| verification_code | Yes |
| Name | Required | Description |
|---|---|---|
| action | Yes | |
| outcome | Yes | |
| next_step | Yes | |
| receipt_url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds material behavioral detail beyond the annotations: it discloses that outcomes are 'delivered, held or failed' rather than a confirmed booking, and it spells out idempotent behavior ('Calling again with the same action_id returns the same outcome and sends nothing'). This complements the idempotentHint annotation and gives the agent a concrete mental model of side effects.
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 deliver the core action, a precondition, the outcome space, and idempotency behavior with zero filler. Every clause adds operational value and the most important constraint is front-loaded.
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 output schema exists, the description covers the essential context: precondition, outcome states, and repeat-call behavior. The main gap is not mapping 'consent_text' to the consent_version parameter and not explaining what distinguishes delivered, held, and failed outcomes, though that may be covered by the output 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 only 17%, so the description carries more responsibility. It does add meaning to verification_code ('their code'), consent_version ('consent_text'), and action_id ('Calling again with the same action_id'), but it references non-existent term 'consent_text' instead of mapping clearly to consent_version, and it does not help with note, service_category, or preferred_window beyond what the schema already 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 names a specific verb ('Send'), a precise resource ('the started request'), and a target ('to the clinic'), with the precondition 'after the patient reads back their code and agrees to consent_text.' It also clearly distinguishes itself from a booking confirmation by stating the outcome is 'never a confirmed booking,' which separates it from the sibling confirm_xona_booking.
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: after a request has been started and after the patient verifies their code and consents. It also excludes booking confirmation as a purpose. However, it does not explicitly name an alternative tool or state a when-not-to-use condition beyond 'never a confirmed booking,' so the guidance is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step 2 of 2. Book the held time with the details from step 1, once the patient has tapped the email link and the text link and agrees to consent_text. If a link is still untapped it books nothing and says which. Xona finds an existing patient itself; when it cannot tell, it returns the practice's booking page instead of guessing. Calling again returns the same outcome.
| Name | Required | Description | Default |
|---|---|---|---|
| action_id | Yes | ||
| consent_version | Yes |
| Name | Required | Description |
|---|---|---|
| reason | No | |
| outcome | Yes | |
| practice | Yes | |
| action_id | Yes | |
| next_step | Yes | |
| booking_url | No | |
| continue_url | No | |
| booking_steps | No | |
| confirmation_sms | No | |
| appointment_start | No | |
| appointment_start_local | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover idempotency, but the description adds meaningful behavioral nuance: it books nothing and reports which link is untapped, and it returns the practice's booking page when patient identity is ambiguous rather than guessing. This goes beyond the structured hints and helps the agent anticipate failure modes.
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 compact and front-loaded with the step context. Each sentence adds operational value: the precondition, the partial-failure behavior, the ambiguity fallback, and the idempotent outcome. No filler or repetition beyond what is useful.
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 action with an output schema, the description covers the workflow, failure cases, and retry behavior. The main gap is parameter mapping, which affects the parameter_semantics dimension; otherwise the behavioral picture 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 description coverage is 0% and the description never mentions action_id or consent_version. It loosely refers to 'details from step 1' and 'consent_text', but an agent cannot map these to the required parameters with any confidence. The description fails to compensate for the schema's lack of descriptive text.
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: 'Book the held time' and explicitly frames this as 'Step 2 of 2', distinguishing it from hold_xona_booking_slot and abandon_xona_booking. This makes the tool's role in the workflow immediately clear.
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 clear when-to-use context: only after the patient has tapped both links and agreed to consent_text. It also explains the no-op condition when links are untapped. It doesn't explicitly name alternative tools, but the 'Step 2 of 2' framing and sibling set make the intended sequencing clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one public dental practice profile, fact evidence, citations, and current public actions.
| Name | Required | Description | Default |
|---|---|---|---|
| practice_slug | Yes |
| Name | Required | Description |
|---|---|---|
| actions | Yes | |
| practice | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that it returns fact evidence, citations, and current public actions, which is useful behavioral context beyond the annotations. No contradiction found.
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?
One concise sentence that front-loads the core action ('Get one public dental practice profile') and then lists the included components. No unnecessary words; structure is optimal.
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 single parameter, the presence of an output schema, and annotations that cover safety, the description provides adequate context. It enumerates the return content (profile, evidence, citations, actions) and implies the identifier. It does not explain error handling, but for a simple get operation with schema available, this is sufficient.
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 0%, and the description does not explicitly mention practice_slug. However, the single parameter is clearly the identifier implied by 'Get one public dental practice profile.' The description adds no explicit parameter guidance, but the parameter's purpose is self-evident from its name and the tool's purpose, so it is marginally sufficient.
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 'Get' with a resource 'public dental practice profile' and enumerates the content (fact evidence, citations, current public actions). This clearly distinguishes from sibling tools like search_canadian_dentists (search) and list_dental_practice_actions (list actions), so an agent knows exactly what this tool returns.
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 retrieving a single practice by slug, but does not explicitly state when to use it versus alternatives like search or list tools. It lacks exclusions or conditions, so an agent must infer from context. This is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the exact outcome of an expiring dental action. Handoff, request, and confirmed booking outcomes remain distinct.
| Name | Required | Description | Default |
|---|---|---|---|
| action_id | Yes |
| Name | Required | Description |
|---|---|---|
| action | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral nuance ('exact outcome', distinct outcome categories), but does not elaborate on lifecycle behavior or failure cases. It does not contradict the 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 short sentences, front-loaded with the primary verb and resource. Every phrase adds value, especially the second sentence clarifying that outcome types remain distinct.
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-only, idempotent tool with an output schema and strong annotations, the description is mostly complete. It could better define 'expiring dental action' or explicitly state that it applies only to such actions, but an agent can likely proceed with minimal ambiguity.
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 0%, so the description needed to compensate by explaining action_id and how it relates to the outcome. It does not mention the parameter at all; only the schema's name and length constraints provide any meaning, leaving the parameter semantics mostly implicit.
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 verb ('Read') and resource ('outcome of an expiring dental action'), and adds useful scope by saying handoff, request, and confirmed booking outcomes remain distinct. It does not explicitly name a sibling alternative, but the purpose is unambiguous among the listed 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?
The description implies when to use the tool: when the exact outcome of an expiring dental action is needed. However, it gives no explicit when-not-to-use guidance or alternatives, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step 1 of 2. Hold one open time with all of the patient's details and email the patient a link to tap; tapping it texts them a second link. Ask for every detail before calling. Nothing is booked yet.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | The chosen slot's date exactly as list_xona_booking_slots returned it | |
| note | No | ||
| last_name | Yes | ||
| first_name | Yes | ||
| service_id | Yes | ||
| date_of_birth | Yes | ||
| guardian_name | No | Required when the patient is under 16 | |
| patient_email | Yes | The patient's own email; the first link goes there | |
| patient_phone | Yes | The patient's mobile number; the second link is texted there once the email link is tapped | |
| practice_slug | Yes | ||
| slot_fingerprint | Yes |
| Name | Required | Description |
|---|---|---|
| practice | Yes | |
| action_id | Yes | |
| next_step | Yes | |
| consent_text | Yes | |
| continue_url | No | |
| verification | Yes | |
| booking_steps | Yes | |
| consent_version | Yes | |
| hold_expires_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a significant side effect beyond the annotations: it 'email[s] the patient a link to tap' and tapping it texts them a second link, so the agent knows calling this tool will contact the patient. It also clarifies the state boundary with 'Nothing is booked yet'. No contradiction exists; the mutation implied by holding a slot aligns with readOnlyHint: false and destructiveHint: false.
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?
Four short sentences with the core action front-loaded ('Step 1 of 2. Hold one open time...'). Every sentence earns its place: flow position, core function plus side effect, precondition, and a clarifying statement about what has not yet happened. Zero waste.
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 description covers the multi-step placement, the side-effectful email/text behavior, and the precondition, which is substantial for an 11-parameter tool. Since an output schema exists, return values don't need description coverage. The main gap is hold lifecycle details (expiry or what happens if the patient never taps the link), but that doesn't block correct 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?
With only 36% schema coverage, the description partially compensates: the two-link mechanism explains why patient_email and patient_phone are required and their distinct roles, and 'all of the patient's details' groups the personal-info parameters. However, practice_slug, service_id, and slot_fingerprint remain undocumented in both the schema and description, so the gap isn't fully closed.
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: 'Hold one open time with all of the patient's details' plus the email/text link flow. 'Step 1 of 2' and 'Nothing is booked yet' position it against confirm_xona_booking as the hold phase rather than the booking phase. This is specific, non-tautological, and clearly distinguishes it from sibling tools.
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?
'Step 1 of 2' provides explicit sequencing context, and 'Ask for every detail before calling' is a concrete precondition telling the agent when it is ready to invoke the tool. It doesn't explicitly name alternatives or exclusion cases, but the two-step framing and the 'Nothing is booked yet' caveat give clear situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List current public booking, request, form, call, and website actions for a dental practice in preference order.
| Name | Required | Description | Default |
|---|---|---|---|
| practice_slug | Yes |
| Name | Required | Description |
|---|---|---|
| actions | Yes | |
| practice_slug | Yes |
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 fully covered. The description adds no extra behavioral context such as authentication needs, rate limits, or data freshness guarantees beyond the word 'current'. It does not contradict annotations, but it adds minimal value over the structured hints.
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, efficient sentence that front-loads the action ('List') and then specifies the resource and ordering. Every word contributes to understanding the tool's purpose. No fluff 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?
Given there is an output schema, return values are covered. The description states what is listed and the ordering, which is useful. However, it lacks any usage context, prerequisites (e.g., a valid practice_slug), or alternative guidance. For a simple list operation, the absence of these details is acceptable, but the parameter explanation gap makes it incomplete.
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 0%, so the description must compensate for the sole parameter, practice_slug. However, the description does not mention or explain this parameter at all. While the parameter name is self-explanatory, there is no guidance on how to obtain or format the slug, nor any indication of required format beyond the schema constraints. The description fails to compensate for the low 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 clearly states a specific verb ('List') and resource ('current public booking, request, form, call, and website actions for a dental practice'). It enumerates the action types and specifies the ordering ('preference order'), making it distinct from siblings that focus on services or slots. An agent can easily tell this from list_public_booking_services or list_xona_booking_slots.
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 does not explicitly mention when to use this tool versus alternatives or provide exclusions. The purpose itself implies usage for listing actions, but no alternatives are named or conditions given. An agent must infer from the resource type, which is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read services from a clinic's already-prepared supported public booking widget. Provider locators remain server-owned.
| Name | Required | Description | Default |
|---|---|---|---|
| action_id | Yes |
| Name | Required | Description |
|---|---|---|
| services | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds context that the data comes from an 'already-prepared' widget and that provider locators are server-owned, which is meaningful behavioral scope. It does not contradict the annotations, but it also does not disclose much beyond those hints.
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 short and front-loaded with the core operation. The second sentence about provider locators is cryptic but brief. There is no filler, though the wording could be clearer about what 'server-owned' means for the caller.
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 annotations covering the safety profile, the description does not need to explain return values or read-only semantics. It states the operation and one scope limitation, but it omits action_id semantics and sibling-tool routing, leaving the definition minimally adequate rather than 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 description coverage is 0%, and the description never explains action_id or how it maps to the clinic's widget. The phrase 'a clinic's ... widget' gives an indirect clue that the parameter identifies the relevant action/widget, but the agent must infer this from context rather than being told explicitly.
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 operation ('Read services') and the target ('a clinic's already-prepared supported public booking widget'), so an agent can tell it lists public booking services. It does not explicitly contrast with sibling tools like list_xona_booking_services or list_public_booking_slots, but the 'public booking widget' qualifier provides useful scope.
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 or when-not-to-use guidance is provided. The description never mentions alternatives or exclusions, so an agent cannot confidently select this tool over sibling list tools based on the description alone. The public-widget phrasing only weakly implies the intended context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read public availability from a supported clinic widget for one service and UTC window. This does not hold or book a slot.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| start | Yes | ||
| action_id | Yes | ||
| service_id | Yes |
| Name | Required | Description |
|---|---|---|
| slots | Yes | |
| use_tool | No | |
| action_id | No | |
| practice_slug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the core safety profile is covered. The description adds useful behavioral context beyond annotations by clarifying that this is a non-reserving, read-only availability lookup and that the window is UTC.
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 with no filler. The core behavior and the non-booking caveat are front-loaded, making the tool easy to scan and understand quickly.
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 read-only tool with rich annotations and an output schema, the description covers the essential behavior. It omits where action_id comes from and does not reference related setup tools like list_public_booking_services, but overall the agent has enough to 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 description adds some meaning beyond the raw schema: 'one service' clarifies service_id, and 'UTC window' clarifies start/end semantics. However, action_id is not explicitly explained; it is only implied by 'supported clinic widget.' With 0% schema description coverage, more field-level guidance would be expected.
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 operation ('Read public availability') and the resource scope ('from a supported clinic widget for one service and UTC window'). It also explicitly differentiates itself from booking tools by noting it does not hold or book a slot.
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 provides clear context: use this to read public availability for a single service over a specified UTC window. It also rules out holding/booking behavior, but it does not name alternative sibling tools or explicitly state when not to use this tool versus list_xona_booking_slots or hold_xona_booking_slot.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the services a practice that connected its schedule to Xona books online. Use it where list_dental_practice_actions marks the Xona booking route as completes_in_conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| practice_slug | Yes |
| Name | Required | Description |
|---|---|---|
| practice | Yes | |
| services | Yes | |
| next_step | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds useful behavioral context by defining a precondition: the practice must have connected its schedule to Xona, and the tool is tied to a specific route state from list_dental_practice_actions. No contradiction with annotations exists.
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 two sentences with no filler. It fronts the core action and resource, then adds the precise triggering condition, making it immediately scannable.
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, read-only list tool with an output schema and strong annotations, the description provides the essential trigger context and scope. Nothing critical is missing for an agent to 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 0%, but there is only one parameter, practice_slug, whose meaning is implied by the title and description referencing 'a practice'. The description does not explicitly document the slug format or that it identifies the connected practice, so it provides only minimal compensation for the missing schema description.
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 ('List') and a specific resource ('the services a practice that connected its schedule to Xona books online'), and it distinguishes this tool from the sibling list_public_booking_services by scoping to connected practices. The title reinforces the same distinction.
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 gives an explicit trigger: use this tool where list_dental_practice_actions marks the Xona booking route as completes_in_conversation. It does not explicitly name alternatives or exclusions, so it stops just short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List open times at a connected practice for one service between date_from and date_to (inclusive, at most 8 weeks out). Returns the closest ten to preferred_time (else a balanced spread) plus the earliest open time, with a reason when empty. Each slot has a slot_fingerprint and date for hold_xona_booking_slot. Nothing is held.
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | Yes | Last day to search (inclusive); at most 56 days after date_from and 8 weeks from today | |
| date_from | Yes | First day to search, in the practice's time zone | |
| doctor_id | No | Restrict to one provider, using a doctor_id a previous slot listing returned | |
| service_id | Yes | ||
| practice_slug | Yes | ||
| preferred_time | No | The patient's preferred local start time, 24-hour HH:MM; slots closest to it come first |
| Name | Required | Description |
|---|---|---|
| slots | Yes | |
| reason | No | |
| earliest | No | |
| practice | Yes | |
| next_step | Yes | |
| time_zone | Yes | |
| service_id | Yes | |
| booking_url | No | |
| effective_to | Yes | |
| instructions | No | |
| effective_from | Yes | |
| date_correction | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior, and the description goes further: 'Nothing is held' explicitly states no side effects. It also discloses selection behavior (closest ten else balanced spread plus earliest open time) and the empty-result reason, which are meaningful behavioral details beyond the 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?
Three dense sentences with no filler. The core action and date constraint are front-loaded, followed by return behavior and the workflow hook to hold_xona_booking_slot. Every sentence 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?
The description is complete for a read-only listing tool: it covers date constraints, selection algorithm, empty behavior, output identifiers, and the no-hold guarantee. With annotations and an output schema present, there is no critical missing context for an agent to select and invoke the tool 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 67%, so the description is expected to add meaning. It adds inclusive date-range semantics, the 8-week maximum, the preferred_time ranking behavior, and maps 'one service' to service_id and 'connected practice' to practice_slug. It does not elaborate on doctor_id beyond the schema's existing explanation.
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 open times at a connected practice for one service between date_from and date_to'. It clearly distinguishes this from public slot listing and from holding a slot, making the tool's purpose unambiguous.
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 gives clear context by saying each slot has a slot_fingerprint and date for hold_xona_booking_slot, signaling this tool is the read-only precursor to holding. It does not explicitly say when to prefer this over list_public_booking_slots, but the 'connected practice' framing implies the intended internal booking workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare an expiring, attributed dental action and return a visible patient review URL. This does not submit patient data or claim a booking.
| Name | Required | Description | Default |
|---|---|---|---|
| capability | Yes | ||
| practice_slug | Yes |
| Name | Required | Description |
|---|---|---|
| action | Yes | |
| next_step | Yes | |
| manual_review_required | Yes | |
| conversational_next_tool | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety hints (all false), so the description carries the full burden. It adds useful behavioral context: it does not submit patient data or claim a booking, and the action is expiring and attributed. However, it does not disclose other side effects (e.g., whether a record is created, if it is reversible, or permission requirements). This is partial transparency.
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 exactly two sentences: the first states the core action and output, the second clarifies non-behaviors. It is front-loaded with the primary purpose and contains zero redundant wording. This is an efficient, well-structured description.
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 moderate complexity (2 parameters, many siblings, no annotation guidance), the description is incomplete. It lacks usage context (when to use vs alternatives), parameter selection guidance, and fuller behavioral disclosure. While the output schema likely covers return details, the description alone does not equip an agent to select or invoke this tool confidently among 15 siblings.
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 0%, meaning the schema has no parameter descriptions. The tool description does not mention either parameter (practice_slug or capability) or explain how to choose a capability. The enum values are self-explanatory but there is no guidance on selection or constraints. The description fails to compensate for the missing schema documentation.
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 ('prepare'), the resource ('an expiring, attributed dental action'), and the result ('return a visible patient review URL'). It also explicitly excludes what it does not do ('does not submit patient data or claim a booking'), which helps distinguish it from sibling tools like start_dental_request or confirm_dental_request.
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 preparation rather than execution, but it does not explicitly state when to use this tool over alternatives. It mentions what it does not do, which gives a hint, but there is no direct guidance on selection criteria or mention of sibling tools. Given the large sibling list, this is a moderate gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search evidence-backed public profiles in the Canadian dental directory by name or place, and filter by a service, a language, published weekend or evening hours, and a booking route you can use now. Each row says which published fact matched and when it was read. No login or clinic membership is required.
| Name | Required | Description | Default |
|---|---|---|---|
| open | No | Published hours: open that day, or closing at/after 18:00 on some day | |
| limit | No | ||
| query | No | ||
| booking | No | A route the agent can use now: the clinic's online booking page, its request form, an appointment request Xona delivers, a phone number, or any of these | |
| service | No | A service the clinic's own site lists: cleaning, implants, invisalign, emergency, kids, root canal, whitening … | |
| language | No | A language the clinic's own site lists | |
| locality | No | ||
| province | No | ||
| postal_code | No |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| results | Yes | |
| projection | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds meaningful context beyond those: results are 'evidence-backed public profiles,' each row reports which published fact matched and when it was read, and no login is required. This gives the agent useful expectations about result provenance and access without contradicting the 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?
Three sentences carry all essential information: the search scope and filters, the output row behavior, and the authentication requirement. The purpose is front-loaded and every sentence earns its place with 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?
Given nine optional parameters, an output schema, and read-only annotations, the description covers search inputs, access requirements, and result-row behavior without needing to restate the output schema. It leaves minor ambiguity about how filters combine and whether at least one search criterion is expected, so it is strong but not exhaustive.
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 only 44%, and the description compensates by mapping 'by name or place' to query/locality/province/postal_code and 'service, language, published weekend or evening hours, booking route' to the filter parameters. It adds semantic meaning to enum values, such as published hours and a route usable now, though it does not detail every parameter like 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?
The description opens with a specific verb ('Search') and names the exact resource: evidence-backed public profiles in the Canadian dental directory. It enumerates the search axes (name/place, service, language, published hours, booking route) and thus distinguishes this discovery tool from sibling retrieval or booking tools like get_canadian_dental_practice and list_public_booking_slots.
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 clearly implies a search/discovery context: it explains what can be searched and notes that 'No login or clinic membership is required,' which is useful usage framing. It does not explicitly name alternatives or exclusion criteria, so it stops short of a full when/when-not guide, but the context is clear enough for an agent to select this tool for finding dentists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an appointment request that Xona emails to the selected clinic, without leaving the conversation. Xona emails the patient a code to confirm their address; nothing reaches the clinic yet. Use it where list_dental_practice_actions marks xona_email_appointment_request as completes_in_conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| patient_name | Yes | The patient's name as they typed it | |
| patient_email | Yes | The patient's own email; the code goes there | |
| practice_slug | Yes |
| Name | Required | Description |
|---|---|---|
| action | Yes | |
| practice | Yes | |
| next_step | Yes | |
| consent_text | Yes | |
| verification | Yes | |
| consent_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations all false and no readOnly/destructive/idempotency hints, the description carries the transparency burden. It discloses non-obvious behavior: the patient receives a confirmation code by email, the request is not sent to the clinic yet, and the whole flow happens 'without leaving the conversation.' It does not discuss repeat-call effects or failure modes, but the core side effects are clear.
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 sentences carry all essential information, with the action and key constraint front-loaded. There is no redundant restatement of the input schema or annotation fields.
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 moderately complex, but the description covers when to use it, what side effects occur, and the key distinction that the clinic is not contacted. An output schema exists to cover return values, and practice_slug is the only thin spot across all required inputs.
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 67%; patient_name and patient_email are already documented in the schema, and the description only lightly reinforces them ('the code goes there'). practice_slug lacks a schema description and is only glossed as 'the selected clinic' in the first sentence. This partially compensates but does not fully explain how to obtain or format the slug.
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 opens with a specific verb and resource ('Start an appointment request') and immediately differentiates this from the request-confirmation step by stating 'nothing reaches the clinic yet.' It also references the matching action name (xona_email_appointment_request), so an agent can distinguish it from siblings like confirm_dental_request.
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 gives an explicit trigger condition: 'Use it where list_dental_practice_actions marks xona_email_appointment_request as completes_in_conversation.' This tells the agent when to invoke this tool and ties it to a sibling discovery tool, leaving no ambiguity about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
abandon_xona_bookinganswer_dental_practice_questionconfirm_dental_requestconfirm_xona_bookingget_canadian_dental_practiceget_dental_action_statushold_xona_booking_slotlist_dental_practice_actionslist_public_booking_serviceslist_public_booking_slotslist_xona_booking_serviceslist_xona_booking_slotsprepare_dental_practice_actionsearch_canadian_dentistsstart_dental_requestFind and book doctor, dentist & nurse appointments. 2M+ providers by insurance & cost in the US.
Find local services, check live availability, and book real appointments with consent.
Discover local services and availability, then create, track, reschedule, or cancel bookings.
Find participating local service providers and book live appointment times.
Add one secure layer between your agents and this server.