See your dental clinic's free slots, dentists, treatment prices and how busy each day is.
Scored across 9 tools
The atomic tools (get_clinic, get_clinic_availability, get_clinic_schedule_summary, list_calendar_events, list_clinic_providers, list_procedures, list_clinics) each target a clearly distinct resource. The two aggregate tools (show_clinic_overview and open_dododentist) partly re-expose data from the atomic tools, but descriptions distinguish one-clinic dashboard vs. cross-clinic interactive sidebar well enough.
All tools use snake_case with a consistent verb prefix (get_, list_, open_, show_) followed by a noun/resource. get_clinic, get_clinic_availability, get_clinic_schedule_summary and the list_* family form a predictable pattern with only trivial deviation in the proper-noun tool open_dododentist.
Nine tools is well-scoped for a read-only clinic-information server. Each tool covers a distinct slice (setup, availability, schedule counts, calendar blocks, providers, procedures, clinics list) plus two convenience aggregates, with no redundant filler.
For a read-only informational surface the coverage is solid: practice metadata, availability, schedule density, closures, staff, prices, list, plus overview and UI entry points. There is no create/update/booking capability, but this is explicitly out of scope, leaving only minor gaps like per-appointment or per-patient drill-down.
Use this when someone asks about one dental practice's setup, such as its currency, language or timezone. Returns the practice's name, currency, default language, timezone and last edit time. Not for free appointment times.
| Name | Required | Description | Default |
|---|---|---|---|
| clinicId | Yes | Practice id: 24 lowercase hexadecimal characters |
| Name | Required | Description |
|---|---|---|
| clinic | Yes | Administrative practice metadata only; opening hours, staff, patient and appointment data are not included. Null when not found. |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds only the returned field list, which is also captured by the available output schema, and omits auth, rate-limit, or pagination behavior, so it adds little beyond the structured metadata.
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: a when-to-use clause, a result summary, and an exclusion. Every sentence is front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-record lookup with complete schema coverage, an output schema, and safety annotations, the description supplies the trigger, output scope, and sibling exclusion needed to call it correctly. It only misses explicit differentiation from show_clinic_overview among the 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?
The single clinicId parameter is fully documented in the schema at 100% coverage, including the 24-character hex pattern. The description adds no extra semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('one dental practice's setup') and enumerates the data returned (currency, language, timezone), so the agent knows exactly what the call retrieves. It also distinguishes this tool from the availability sibling by excluding 'free appointment times'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear trigger ('Use this when someone asks about...') and an explicit exclusion ('Not for free appointment times'), which routes availability questions elsewhere. It does not name the alternative tool, so the guidance stops short of full routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks when their dental practice has free appointment times or the next available slot. Returns each open online-booking slot's start and end, grouped by day, for the next days with openings: up to 7 days and 100 slots (no patient or dentist details). Not for booking or holding a slot.
| Name | Required | Description | Default |
|---|---|---|---|
| clinicId | Yes | Practice id: 24 lowercase hexadecimal characters |
| Name | Required | Description |
|---|---|---|
| days | Yes | One row per day with open online-booking slots, in date order, holding at most 100 slots in total. Slot times only; patients, dentists, treatments and clinical data are never included. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: a 7-day and 100-slot cap on results, day-grouping of output, and that no patient or dentist details are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: trigger, return shape with explicit limits, and exclusion. The most important routing information 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?
With annotations covering safety and an output schema covering return structure, the description only needs to add scope and limits – which it does. An agent has everything needed to call this correctly and not mistake it for a booking 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?
There is a single parameter (clinicId) and schema description coverage is 100%, with the pattern '^[0-9a-f]{24}$' already documented. The description adds nothing about the parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete verb and resource – returning open online-booking slots grouped by day – and the title reinforces it. It is clearly distinguishable from siblings like get_clinic_schedule_summary or list_calendar_events because it is scoped to bookable availability windows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear triggering condition ('when someone asks when their dental practice has free appointment times or the next available slot') and an explicit exclusion ('Not for booking or holding a slot'). It does not name the sibling tool that handles booking, so the routing is clear but not fully closed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks how busy their dental practice is or how many appointments are booked each day. Returns appointment counts per UTC day for one practice, whatever their status, for the next 7 days by default and at most 31 days; counting stops at 100. Not for counting cancellations or seeing who is booked.
| Name | Required | Description | Default |
|---|---|---|---|
| endTime | No | End of the range as an ISO 8601 date-time, after startTime and at most 31 days later; defaults to 7 days after the start | |
| clinicId | Yes | Practice id: 24 lowercase hexadecimal characters | |
| startTime | No | Start of the range as an ISO 8601 date-time; defaults to now |
| Name | Required | Description |
|---|---|---|
| days | Yes | One row per UTC day that has appointments, canceled ones included, counting only appointments the signed-in account can view. Aggregate counts only: appointment identifiers and times, patient information, procedures, diagnoses and notes are never returned. |
| range | Yes | |
| appointmentCount | Yes | |
| appointmentCountIsLowerBound | Yes | True when more than 100 appointments fall in the range |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description goes further by disclosing that counts include every appointment status, that days are grouped by UTC, and that counting truncates at 100. The 100-cap is a real behavioral limit an agent would otherwise miss. It does not describe the shape of the returned summary, but an output schema 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?
Two dense sentences: the first leads with the usage trigger, the second packs scope, defaults, limits and exclusions. No wasted clauses and the most decision-relevant information (what it counts, what it excludes) 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?
For a read-only aggregate with an output schema, the description covers everything an agent needs: when to call it, the range defaults and ceiling, the truncation cap, timezone semantics, and what it is not for. Nothing material is left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents clinicId format, ISO 8601 date-times, and the 7-day default/31-day max for the range. The description's restatement of those defaults adds little beyond the schema, with the 100-count cap and UTC-day grouping being the only genuinely new semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('returns appointment counts per UTC day for one practice') and scopes it precisely: all statuses, 7-day default, 31-day max, 100-count cap. It also differentiates itself from the counting of cancellations or booking detail, so an agent can separate it from siblings like get_clinic_availability or list_calendar_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use trigger ('when someone asks how busy their dental practice is or how many appointments are booked each day') and an explicit exclusion ('Not for counting cancellations or seeing who is booked'). It stops short of naming the sibling tool that should be used instead, so the routing is clear but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks when their dental practice is closed, or when a dentist or chair is blocked for holidays, courses, meetings or maintenance. Returns each block or extra opening with start, end, all-day flag, scope and type (no titles or notes). Not for patient appointments.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Blocks per page, from 1 to 100; defaults to 20 | |
| cursor | No | The nextCursor of the previous page with the same filters; absent for the first page | |
| endTime | No | Only blocks ending before this ISO 8601 date-time | |
| clinicId | No | Only this practice (24 lowercase hexadecimal characters); every practice when absent | |
| startTime | No | Only blocks starting at or after this ISO 8601 date-time |
| Name | Required | Description |
|---|---|---|
| nextCursor | Yes | Cursor for the next page; null on the last page |
| calendarEvents | Yes | Non-appointment calendar blocks, earliest first. Event identifiers, staff and chair references, titles, notes and patient links are never returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description correctly spends its words on content behavior: it discloses the returned fields and, notably, that titles and notes are withheld. That "no titles or notes" caveat is real added value an agent cannot get from the annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: trigger first, return shape second, exclusion last. Every sentence earns its place with no repetition of schema or 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?
With an output schema, rich annotations, and full parameter coverage, the description only needs to route the agent and set scope expectations, which it does. It even pre-empts a likely question (missing titles/notes) that the output schema alone would not explain.
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 five documented parameters (limit, cursor, startTime, endTime, clinicId), so the schema carries the semantics. The description adds no date-format or pagination guidance beyond what the schema already states, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a concrete resource (closures, holidays, blocked chair time) with a clear list verb and scope (blocks and extra openings, not appointments). It clearly excludes patient appointments, which separates it from appointment-oriented siblings, though it never names an alternative like get_clinic_availability for scheduling questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this when someone asks when their dental practice is closed" gives an explicit trigger, and "Not for patient appointments" sets a when-not boundary. It does not, however, point to the tool an agent should use instead for appointments or general availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks which dentists, dental nurses or assistants patients can book at their practice. Returns up to 100 staff display names for one practice (no contact details or roles). Not for staff holidays or days off.
| Name | Required | Description | Default |
|---|---|---|---|
| clinicId | Yes | Practice id: 24 lowercase hexadecimal characters |
| Name | Required | Description |
|---|---|---|
| providers | Yes | Display names of staff with a dentist (doctor), nurse or assistant role. Staff identifiers, contact details, role records and clinical data are never returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, read-only, idempotent call, so the bar is lower. The description still adds real context: a 100-result cap, single-practice scope, and the fact that contact details and roles are omitted from the response.
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 with zero filler: trigger first, then the return shape and limit, then the exclusion. 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?
An output schema exists, so return values need no further explanation, yet the description still summarizes what comes back (display names, up to 100). For a one-parameter read tool, nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the clinicId format is fully documented in the schema, including its 24-character hex pattern. The description's 'for one practice' only hints at the single-practice scoping the parameter implies, adding little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (list staff who take bookings at a practice) and enumerates the roles covered (dentists, dental nurses, assistants). It also distinguishes itself from adjacent schedule tools by ruling out holidays/days off, so an agent can select it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ('use this when someone asks which dentists... patients can book') plus an explicit exclusion ('not for staff holidays or days off'). It stops short of naming the sibling tool that should handle holidays, so routing is implied rather than fully resolved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks which dental practices they run in DodoDentist, or a practice's id is needed. Returns each practice's id, name, currency, default language and timezone, 20 per page by default. Not for looking up a patient or appointment.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Practices per page, from 1 to 100; defaults to 20 | |
| cursor | No | The nextCursor of the previous page of this listing; absent for the first page |
| Name | Required | Description |
|---|---|---|
| clinics | Yes | Dental practices in the signed-in organization, administrative metadata only. Patient, appointment and clinical records are never returned. |
| nextCursor | Yes | Cursor for the next page; null on the last page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds useful behavior beyond that: the returned fields, the default page size of 20, and that results are paginated — context the annotations do not carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the trigger condition, followed by return contents and the exclusion. No filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety and an output schema covering return shape, the description is nearly complete: it names the returned fields (redundant with the output schema but harmless), the pagination default, and the exclusions. Only the paging mechanism (using cursor from the previous response) is left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (limit, cursor) are fully documented in the schema, which sets the baseline at 3. The description echoes the 20-per-page default but adds no detail about cursor semantics or page-size limits 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?
States a specific verb and resource ('list your dental practices') and scopes it to practices the user runs in DodoDentist, with a secondary use case (retrieving a practice id). It also explicitly excludes adjacent resources (patients, appointments), so an agent can separate it from the get_clinic family.
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 triggering condition ('when someone asks which dental practices they run, or a practice's id is needed') and an explicit when-not ('not for looking up a patient or appointment'). It stops short of naming the sibling tool to use for a single practice (get_clinic), so routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks what their dental practice charges for a treatment, such as a cleaning, filling, crown or whitening. Returns catalog treatment names with price and last edit time, alphabetically, 50 per page by default. Not for a patient's treatment history or tooth chart.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Treatments per page, from 1 to 100; defaults to 50 | |
| cursor | No | The nextCursor of the previous page with the same filters; absent for the first page | |
| clinicId | No | Only this practice (24 lowercase hexadecimal characters); every practice when absent |
| Name | Required | Description |
|---|---|---|
| nextCursor | Yes | Cursor for the next page; null on the last page |
| procedures | Yes | Treatment catalog entries in name order. Patient-linked treatments, tooth charts, diagnoses and record identifiers are never returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the safety profile is covered; the description adds value beyond that by disclosing sort order (alphabetical), default page size (50 per page), and return fields. It stops short of describing rate limits or cursor expiry, but it is well beyond the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with zero filler: the trigger leads, the return shape follows, and the exclusion closes. Every sentence earns its place and the most important information 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?
With an output schema present, return values need not be spelled out, yet the description still sketches them. Combined with annotations covering safety and a fully documented schema, nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (limit, cursor, clinicId) are already documented in the schema; the description only restates the 50-per-page default. The phrase 'their dental practice' loosely implies clinicId filtering but adds no syntax or format detail. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific use case ('what their dental practice charges for a treatment') and the resource returned (catalog treatment names with price and last edit time). It cleanly distinguishes from the sibling tools, none of which concern treatment pricing, so an agent can select it without inspecting others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger ('when someone asks what their dental practice charges') and explicit exclusions ('Not for a patient's treatment history or tooth chart'), which helps routing. It does not name a specific alternative tool to use for those excluded cases, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants to open DodoDentist and browse their clinics, aggregate schedule counts, booking availability and procedure prices in an interactive sidebar. Returns up to 100 clinics to start from (no patient records, individual appointments, contact details or clinical data). Not for booking appointments, editing records or medical decisions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| truncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds useful scope beyond that: returns up to 100 clinics, and excludes patient records, contact details and clinical data. It doesn't describe sidebar interaction behavior further, but the added boundary context is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: use case, return scope/limit, and exclusions. Front-loaded with the triggering intent.
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?
Output schema exists, so return values needn't be explained. The description covers intent, scope limits, and exclusions fully enough to call this zero-parameter UI-opening 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?
Zero parameters, so the baseline is 4 per the rubric. The schema and description agree there is nothing to pass; the description compensates by explaining what the zero-arg call returns.
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 action (open DodoDentist and browse clinics/schedules/availability/prices in an interactive sidebar) with clear scope. A sibling like list_clinics clearly differs because this is about opening the app view.
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?
Explicitly names when to use it and three exclusions: 'Not for booking appointments, editing records or medical decisions.' This routes the agent away from the wrong tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants a quick overview or dashboard of one dental practice. Returns an overview card with the practice's details, appointment counts for the next 7 days, how many staff take bookings, open online-booking slots and up to 12 treatment prices (no patient or clinical data). Not for a single patient or appointment.
| Name | Required | Description | Default |
|---|---|---|---|
| clinicId | Yes | Practice id: 24 lowercase hexadecimal characters |
| Name | Required | Description |
|---|---|---|
| clinic | Yes | Administrative practice metadata; null when the practice was not found. The overview never includes individual appointment records, patient information, diagnoses, treatment details, notes or other clinical data. |
| procedures | Yes | |
| scheduleDays | Yes | |
| providerCount | Yes | |
| scheduleRange | Yes | |
| procedureCount | Yes | |
| appointmentCount | Yes | |
| availabilityDays | Yes | |
| availableDayCount | Yes | |
| availableSlotCount | Yes | |
| providerCountIsLowerBound | Yes | |
| procedureCountIsLowerBound | Yes | |
| appointmentCountIsLowerBound | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real context: the exact scope of the payload, the 7-day window, the 12-price cap, and the reassurance that no patient or clinical data is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: trigger first, returned payload second, exclusion last. 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?
With one required parameter, full schema coverage, an output schema, and rich annotations, the description supplies everything an agent needs: when to pick it, what it returns, and what it does not cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single clinicId parameter (24-char hex pattern) is fully documented in the schema. The description only implies the single-practice scope via 'one dental practice' and adds no format or constraint detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('quick overview or dashboard of one dental practice') and enumerates the returned content (practice details, 7-day appointment counts, bookable staff, open slots, up to 12 prices), which meaningfully distinguishes it from the fuller get_clinic. It does not name the sibling tools directly, so routing is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear trigger ('when someone wants a quick overview or dashboard') and an explicit exclusion ('Not for a single patient or appointment'). Alternatives such as get_clinic or get_clinic_schedule_summary are not named, so the agent must infer which sibling to prefer for detail-heavy requests.
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.
open_dododentistget_clinic2 fields changedInput schema / properties / clinicId / descriptionPrevious value: -"Clinic id (24-character hex)"New value: +"Practice id: 24 lowercase hexadecimal characters"Output schema / properties / clinic / descriptionAdded value: +"Administrative practice metadata only; opening hours, staff, patient and appointment data are not included. Null when not found."get_clinic_availability2 fields changedInput schema / properties / clinicId / descriptionPrevious value: -"Clinic id (24-character hex)"New value: +"Practice id: 24 lowercase hexadecimal characters"Output schema / properties / days / descriptionAdded value: +"One row per day with open online-booking slots, in date order, holding at most 100 slots in total. Slot times only; patients, dentists, treatments and clinical data are never included."get_clinic_schedule_summary5 fields changedInput schema / properties / clinicId / descriptionPrevious value: -"Clinic id (24-character hex)"New value: +"Practice id: 24 lowercase hexadecimal characters"Input schema / properties / endTime / descriptionPrevious value: -"Range end as an ISO 8601 value; defaults to seven days later"New value: +"End of the range as an ISO 8601 date-time, after startTime and at most 31 days later; defaults to 7 days after the start"Input schema / properties / startTime / descriptionPrevious value: -"Range start as an ISO 8601 value; defaults to now"New value: +"Start of the range as an ISO 8601 date-time; defaults to now"Output schema / properties / appointmentCountIsLowerBound / descriptionAdded value: +"True when more than 100 appointments fall in the range"Output schema / properties / days / descriptionAdded value: +"One row per UTC day that has appointments, canceled ones included, counting only appointments the signed-in account can view. Aggregate counts only: appointment identifiers and times, patient information, procedures, diagnoses and notes are never returned."list_calendar_events9 fields changedInput schema / properties / clinicId / descriptionPrevious value: -"Filter by clinic id"New value: +"Only this practice (24 lowercase hexadecimal characters); every practice when absent"Input schema / properties / cursor / descriptionPrevious value: -"Opaque cursor from a prior result"New value: +"The nextCursor of the previous page with the same filters; absent for the first page"Input schema / properties / endTime / descriptionPrevious value: -"Only events ending before this ISO 8601 time"New value: +"Only blocks ending before this ISO 8601 date-time"Input schema / properties / limit / descriptionAdded value: +"Blocks per page, from 1 to 100; defaults to 20"Input schema / properties / startTime / descriptionPrevious value: -"Only events starting at or after this ISO 8601 time"New value: +"Only blocks starting at or after this ISO 8601 date-time"Output schema / properties / calendarEvents / descriptionAdded value: +"Non-appointment calendar blocks, earliest first. Event identifiers, staff and chair references, titles, notes and patient links are never returned."Output schema / properties / calendarEvents / items / properties / effect / descriptionAdded value: +"BLOCK removes bookable time; OPEN adds hours on a normally closed time"Output schema / properties / calendarEvents / items / properties / scope / descriptionAdded value: +"CLINIC: the whole practice; PROVIDER: one or more staff; SEAT: one chair"Output schema / properties / nextCursor / descriptionAdded value: +"Cursor for the next page; null on the last page"list_clinic_providers2 fields changedInput schema / properties / clinicId / descriptionPrevious value: -"Clinic id (24-character hex)"New value: +"Practice id: 24 lowercase hexadecimal characters"Output schema / properties / providers / descriptionAdded value: +"Display names of staff with a dentist (doctor), nurse or assistant role. Staff identifiers, contact details, role records and clinical data are never returned."list_clinics4 fields changedInput schema / properties / cursor / descriptionPrevious value: -"Opaque cursor from a prior result"New value: +"The nextCursor of the previous page of this listing; absent for the first page"Input schema / properties / limit / descriptionAdded value: +"Practices per page, from 1 to 100; defaults to 20"Output schema / properties / clinics / descriptionAdded value: +"Dental practices in the signed-in organization, administrative metadata only. Patient, appointment and clinical records are never returned."Output schema / properties / nextCursor / descriptionAdded value: +"Cursor for the next page; null on the last page"list_procedures6 fields changedInput schema / properties / clinicId / descriptionPrevious value: -"Filter by clinic id"New value: +"Only this practice (24 lowercase hexadecimal characters); every practice when absent"Input schema / properties / cursor / descriptionPrevious value: -"Opaque cursor from a prior result"New value: +"The nextCursor of the previous page with the same filters; absent for the first page"Input schema / properties / limit / descriptionAdded value: +"Treatments per page, from 1 to 100; defaults to 50"Output schema / properties / nextCursor / descriptionAdded value: +"Cursor for the next page; null on the last page"Output schema / properties / procedures / descriptionAdded value: +"Treatment catalog entries in name order. Patient-linked treatments, tooth charts, diagnoses and record identifiers are never returned."Output schema / properties / procedures / items / properties / price / descriptionAdded value: +"Price in the practice's currency"show_clinic_overview2 fields changedInput schema / properties / clinicId / descriptionPrevious value: -"DodoDentist clinic id to render"New value: +"Practice id: 24 lowercase hexadecimal characters"Output schema / properties / clinic / descriptionAdded value: +"Administrative practice metadata; null when the practice was not found. The overview never includes individual appointment records, patient information, diagnoses, treatment details, notes or other clinical data."get_clinicget_clinic_availabilityget_clinic_schedule_summarylist_calendar_eventslist_clinic_providerslist_clinicslist_proceduresshow_clinic_overviewSee your clinic's free slots, doctors, rooms, service prices and how busy each day is.
See your vet clinic's free slots, vets, service prices, payments and how busy each day is.
See your salon's free slots, appointments, stylists, services, clients, quotes and payments.
See your gym's open slots, services, how busy each day is and your payment totals.
Add one secure layer between your agents and this server.