Check live availability and book therapy sessions with a Malayalam-speaking psychologist.
Scored across 6 tools
Each tool maps to a distinct lifecycle step: listing services, checking availability, creating a draft, reading status, cancelling a draft, and rescheduling. The descriptions explicitly separate the closely adjacent pairs (check_availability vs create_booking_draft, cancel_booking_draft vs reschedule_booking) by state and effect. An agent should never misselect here.
All six names follow a strict verb_noun snake_case pattern (check_availability, create_booking_draft, get_booking_status, cancel_booking_draft, reschedule_booking, list_services). The verb reliably signals the operation type and the noun the resource, with only the minor cosmetic difference that list_services omits the 'booking' qualifier.
Six tools is a tight, well-earned surface for a booking workflow — each tool covers one necessary step and nothing is redundant. No thin single-tool server, no bloat.
The full happy path is covered: discover services, check times, hold a slot, poll status, cancel an unpaid draft, and reschedule once. Gaps are deliberate and documented (paid/confirmed cancellations, refunds and the 24-hour rule route to ElloMind on WhatsApp; there is no booking lookup by phone, only by poll_key), so agents have a stated workaround but no in-band path for post-payment changes.
Cancel a draft the customer has NOT paid for: frees the held time at once and the pay link stops working. A paid or confirmed session cannot be cancelled here (refunds and the 24-hour rule are handled by ElloMind on WhatsApp).
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | the booking ref, e.g. EM-XXXX | |
| poll_key | Yes | the poll_key returned by create_booking_draft |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the description's added value is in consequences: the held time is freed at once and the pay link stops working. That is real context beyond the annotations, though it doesn't address what happens if the draft was already cancelled or already expired.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The core action and its precondition are front-loaded, with the exclusion and alternative channel following immediately after.
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 mutation with no output schema, the description covers permission/precondition, side effects and the escalation path. Only the response shape (e.g., what confirming value comes back) is left unaddressed, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters (ref, poll_key) are documented in the schema, so the baseline of 3 applies. The description adds no format or provenance detail 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+resource ('Cancel a draft') plus the exact precondition ('the customer has NOT paid for'), and distinguishes itself from reschedule_booking and create_booking_draft. An agent can tell immediately whether this is the right tool 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?
Explicitly says when to use (unpaid draft) and when not to (a paid or confirmed session), and names the alternative channel for the excluded case ('refunds and the 24-hour rule are handled by ElloMind on WhatsApp'). This is exactly the when/when-not/alternative pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Real open start times (IST) for a session type over a date range (YYYY-MM-DD, at most 14 days): days (all times) and by_psychologist (each psychologist's own times, with slug, name and role). Past times and times starting within 10 minutes are never listed. Times are not held until create_booking_draft. Use mode 'in_person' for the Kakkanad clinic (individual sessions, Teresa James). ElloMind matches clients to a psychologist: offer a specific person only when the customer asks for one (by name, or the same psychologist as before); pass psychologist to see only theirs. If this tool returns an error, never tell the customer they are fully booked.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | end date YYYY-MM-DD | |
| from | Yes | start date YYYY-MM-DD | |
| mode | No | default online | |
| psychologist | No | slug from by_psychologist (e.g. 'nithya-s'), only if the customer asked for that person | |
| session_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial traits beyond annotations: IST timezone, 14-day max range, 10-minute buffer for start times, no reservation behavior, clinic-specific mode semantics, and error-handling guidance. These enrich the agent's understanding without contradicting the read-only, idempotent 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?
Information-dense and front-loaded with purpose; each sentence adds necessary detail (output structure, constraints, mode, psychologist, error handling). No wasted language; appropriate for a tool with no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return structure (`days` and `by_psychologist` with slug, name, role), covers constraints, timezone, error handling, and domain logic. Complete for an agent to call 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 coverage is 80% (baseline 3), and the description adds meaningful constraint (14-day range) and clarifies mode and psychologist behavior beyond schema descriptions. It does not enumerate session_type values, but the schema enum covers that.
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: 'Real open start times (IST) for a session type over a date range', and distinguishes from create_booking_draft by noting times aren't held until then. An agent can identify the tool's function from the first sentence.
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?
Provides clear when-to-use context for mode (in_person for Kakkanad clinic) and psychologist (only when the customer asks for one), plus an alternative (create_booking_draft for holding times). Lacks explicit routing against other siblings like get_booking_status, but the context is strong and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hold one time with one psychologist (for 30 minutes, and never later than 15 minutes before the session) and return a single-use pay link for the customer. Call check_availability first and use one of its times. psychologist (optional): the slug of the person the customer asked for (from by_psychologist); the time is then held for that person only, or refused with 'not free'. Without it ElloMind assigns someone free at that time. Either way the response names the psychologist (slug, name, role), and that is who the session is booked with. Collect the customer's name, phone (with country code) and email first. Couples: also partner_2 (their own name and email or phone; each partner signs their own consent form before the first joint session). Teen (13 to 17): the contact is the parent or guardian, who pays and signs the teen consent form; also give teen_name. Also required: lead_source (how the customer found ElloMind; ai_assistant if they are booking for themselves through you and did not say) and booked_by ('customer' when the customer books for themselves, otherwise your own name). The price is set by ElloMind; you cannot set an amount. Plans: plan4, plan8 or plan12 (see list_services). In person: individual single sessions only. Every problem with the details comes back at once. Bookings close 10 minutes before the session. Limits: at most 3 unpaid drafts per phone at a time (cancel_booking_draft frees one) and 8 new drafts per hour from one network.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | default online; in_person = Kakkanad clinic | |
| name | Yes | the contact: the client, or for teen sessions the parent or guardian | |
| Yes | |||
| phone | Yes | with country code, e.g. +91 98xxxxxxxx | |
| teen_age | No | teen only, if known: 13 to 17 | |
| booked_by | Yes | 'customer' if the customer books for themselves; otherwise your name | |
| partner_2 | No | couples only: the second partner | |
| plan_code | Yes | 'single' for one session; 'plan4', 'plan8' or 'plan12' for a plan (see list_services) | |
| slot_date | Yes | YYYY-MM-DD from check_availability | |
| slot_time | Yes | HH:MM 24h IST from check_availability | |
| teen_name | No | teen only: the young person's name | |
| source_ref | No | an EM-XXXX ref the customer was given, if any | |
| lead_detail | No | required for referral (who referred them) and other | |
| lead_source | Yes | how the customer found ElloMind | |
| psychologist | No | slug (e.g. 'nithya-s'), ONLY if the customer asked for that psychologist | |
| session_type | Yes | ||
| email_checked | No | true only after the customer confirmed an unusual email domain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-idempotent, non-destructive, so the write profile is known. The description still adds substantial behavior: the hold window (30 minutes, never later than 15 minutes before), that the pay link is single-use, that ElloMind sets the price and the agent cannot, that the psychologist may be refused with 'not free', that all validation problems return at once, and concrete rate limits (3 unpaid drafts per phone, 8 drafts per hour per network). These are real value-adds 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?
Front-loaded with the core action and the check_availability dependency, and every sentence carries operational content. It is delivered as one dense wall of text with nested asides (a reference to a 'by_psychologist' field that is not in this schema), which makes the branch conditions harder to scan than they need to be.
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 17-parameter, 9-required, nested-object mutation with no output schema, the description covers what comes back (psychologist slug, name, role; the pay link), the failure modes ('not free', batched validation errors), the temporal constraints, and the quota limits. An agent has enough to call it correctly and interpret the result.
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 88%, so the baseline is 3, and the description goes beyond it by explaining conditional semantics the schema only hints at: psychologist is the slug and, when omitted, ElloMind assigns anyone free but the response names who was assigned; lead_source defaults to ai_assistant if the customer did not say; booked_by is 'customer' for self-booking; partner_2 needs each partner's own contact and consent; teen contact must be the parent/guardian. It leaves source_ref, lead_detail, email_checked and teen_age entirely to the schema, so not a 5.
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 with scope: hold one time slot with one psychologist and return a single-use pay link. It distinguishes itself from check_availability (which supplies the time) and from cancel_booking_draft (which frees a draft), so an agent can route correctly without opening a sibling 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?
Explicit prerequisites ('Call check_availability first and use one of its times'), explicit conditional branches for psychologist / no psychologist, couples, and teen, plus a hard cutoff ('Bookings close 10 minutes before the session') and a named fallback tool (cancel_booking_draft frees a draft). Alternatives and when-not conditions are stated, not implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a booking's state to show the customer: draft (waiting for payment), confirmed (with the Meet link), paid (payment in, booking being completed), expired or cancelled; plus the psychologist, consent progress and whether the one free move has been used. It changes nothing. REQUIRES the poll_key from create_booking_draft; without it the answer is 'not found'.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | the booking ref, e.g. EM-XXXX | |
| poll_key | Yes | the poll_key returned by create_booking_draft |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so "It changes nothing" is largely redundant. What the description does add beyond structured data is valuable: the state machine semantics and the specific failure mode (missing poll_key yields "not found" rather than an error), which tells the agent to treat absence as a normal outcome. Missing was any hint about response shape beyond the listed fields.
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?
Front-loaded with the action and its use case, then the state enumeration, then the prerequisite — the highest-value constraint (poll_key required) is placed last where it reads as a warning. Three sentences, zero filler; even the parentheticals carry real meaning.
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 read-only tool with full annotations and no output schema, the description covers the action, the returnable information (state, psychologist, consent progress, free-move usage), and the auth/prerequisite condition. Nothing an agent needs in order to call it correctly, or to interpret an empty result, is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both params are already documented, and the description's only parameter-relevant statement — that poll_key comes from create_booking_draft — restates the schema's own wording ("the poll_key returned by create_booking_draft"). No added syntax, format, or edge-case guidance for ref or poll_key, so 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?
Names a specific verb and resource ("Read a booking's state") and then enumerates every possible state with a plain-language gloss for each (draft = waiting for payment, confirmed = has Meet link, etc.). This is information an agent cannot get from the schema, and it makes the tool instantly distinguishable from cancel_booking_draft or reschedule_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 customer-facing polling context ("to show the customer") plus the hard prerequisite "REQUIRES the poll_key from create_booking_draft" give clear when-to-use and when-it-fails guidance. It falls short of 5 because it never explicitly contrasts with siblings — it does not say, e.g., that cancel/reschedule are separate tools — leaving the agent to infer that this tool only observes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List session types, prices and plans for booking therapy with ElloMind. Call before creating a booking so you use a valid session_type and plan_code. Plans: 4, 8 or 12 sessions at 10, 20 or 30% off, valid 6 months, paid upfront. In-person individual sessions (Kakkanad clinic, one at a time) are priced separately.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuine business context beyond that: plan tiers and discount rates, six-month validity, upfront payment, and the separate pricing of in-person Kakkanad clinic sessions. It does not describe the response shape, but the annotations carry most of the remaining burden.
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?
Front-loaded with purpose, then the call-ordering rule, then the plan economics — a sensible information hierarchy with no filler. The plan-detail sentence is dense but earns its place by pre-empting follow-up questions about discount tiers and validity.
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 no input schema, no output schema and rich annotations, the description is the only source of return-content information, and it delivers: session types, prices, plan structures and a pricing exception. Only the exact response envelope is unspecified, which is a minor gap for a zero-parameter catalog 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 are zero input parameters, so there is nothing to document in the schema and the baseline is 4. The description does useful work by naming the output fields the agent will need downstream (session_type, plan_code), bridging into the booking call.
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 session types, prices and plans") plus the domain (booking therapy with ElloMind), which cleanly separates it from the booking-mutation siblings. An agent immediately knows this is the read-only reference catalog tool.
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?
"Call before creating a booking so you use a valid session_type and plan_code" gives an explicit sequencing precondition tied to a named sibling workflow. It stops short of naming the sibling tool (create_booking_draft) or stating when not to call it, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a CONFIRMED session to another time with the same psychologist. Allowed once per session, at no charge, when the session is 24 hours or more away. A second change counts as a cancellation and anything inside 24 hours carries the full fee, so those go to ElloMind on WhatsApp. Check the new time with check_availability (same psychologist) first. The Meet link stays the same and everyone is emailed.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | the booking ref, e.g. EM-XXXX | |
| poll_key | Yes | the poll_key returned by create_booking_draft | |
| slot_date | Yes | new date YYYY-MM-DD | |
| slot_time | Yes | new start time HH:MM 24h IST |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already flag this as destructive and non-idempotent, and the description adds substantial context beyond them: the one-change limit, fee consequences, escalation path to WhatsApp, unchanged Meet link, and email notifications. Nothing contradicts the destructive annotation.
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 core action is front-loaded, and each subsequent sentence adds a distinct rule or side effect. There is no filler despite the density of business logic.
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 destructive, non-idempotent mutation with a fully documented schema and no output schema, this covers preconditions, limits, alternatives, and post-change effects. An agent has everything needed to decide whether to call it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description goes further by implying slot_date/slot_time must be a new time with the same psychologist and should be validated via check_availability. It does not add format details for ref or poll_key, but it does constrain the new-slot parameters meaningfully.
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 ('Move') and resource ('a CONFIRMED session') and scopes it to 'the same psychologist'. This clearly distinguishes it from create_booking_draft and cancel_booking_draft without needing 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 explicit eligibility rules (once per session, >=24 hours away, no charge), says what happens otherwise (second change is a cancellation, inside 24 hours goes to WhatsApp/ElloMind), and names check_availability as the required prerequisite for the new time.
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.
cancel_booking_draft2 fields changedInput schema / properties / poll_key / maxLengthAdded value: +64Input schema / properties / ref / maxLengthAdded value: +20check_availability3 fields changedInput schema / properties / from / maxLengthAdded value: +10Input schema / properties / psychologist / maxLengthAdded value: +64Input schema / properties / to / maxLengthAdded value: +10create_booking_draft18 fields changedInput schema / properties / booked_byAdded value: +{
+ "description": "'customer' if the customer books for themselves; otherwise your name",
+ "maxLength": 100,
+ "type": "string"
+}Input schema / properties / email / maxLengthAdded value: +200Input schema / properties / email_checkedAdded value: +{
+ "description": "true only after the customer confirmed an unusual email domain",
+ "type": "boolean"
+}Input schema / properties / lead_detailAdded value: +{
+ "description": "required for referral (who referred them) and other",
+ "maxLength": 200,
+ "type": "string"
+}Input schema / properties / lead_sourceAdded value: +{
+ "description": "how the customer found ElloMind",
+ "enum": [
+ "whatsapp",
+ "instagram",
+ "facebook",
+ "google",
+ "youtube",
+ "website",
+ "referral",
+ "returning_client",
+ "ai_assistant",
+ "other"
+ ],
+ "type": "string"
+}Input schema / properties / name / maxLengthAdded value: +200Input schema / properties / partner_2 / properties / email / maxLengthAdded value: +200Input schema / properties / partner_2 / properties / name / maxLengthAdded value: +200Input schema / properties / partner_2 / properties / phone / maxLengthAdded value: +40Input schema / properties / phone / maxLengthAdded value: +40Input schema / properties / psychologist / maxLengthAdded value: +64Input schema / properties / slot_date / maxLengthAdded value: +20Input schema / properties / slot_time / maxLengthAdded value: +20Input schema / properties / source_refAdded value: +{
+ "description": "an EM-XXXX ref the customer was given, if any",
+ "maxLength": 120,
+ "type": "string"
+}Input schema / properties / teen_age / maximumPrevious value: -9007199254740991New value: +120Input schema / properties / teen_age / minimumPrevious value: --9007199254740991New value: +0Input schema / properties / teen_name / maxLengthAdded value: +200Input schema / requiredPrevious value: -[
- "session_type",
- "plan_code",
- "slot_date",
- "slot_time",
- "name",
- "phone",
- "email"
-]New value: +[
+ "session_type",
+ "plan_code",
+ "slot_date",
+ "slot_time",
+ "name",
+ "phone",
+ "email",
+ "lead_source",
+ "booked_by"
+]get_booking_status2 fields changedInput schema / properties / poll_key / maxLengthAdded value: +64Input schema / properties / ref / maxLengthAdded value: +20reschedule_booking4 fields changedInput schema / properties / poll_key / maxLengthAdded value: +64Input schema / properties / ref / maxLengthAdded value: +20Input schema / properties / slot_date / maxLengthAdded value: +20Input schema / properties / slot_time / maxLengthAdded value: +20cancel_booking_draftcheck_availability2 fields changedInput schema / properties / modeAdded value: +{
+ "description": "default online",
+ "enum": [
+ "online",
+ "in_person"
+ ],
+ "type": "string"
+}Input schema / properties / psychologistAdded value: +{
+ "description": "slug from by_psychologist (e.g. 'nithya-s'), only if the customer asked for that person",
+ "type": "string"
+}create_booking_draft6 fields changedInput schema / properties / modeAdded value: +{
+ "description": "default online; in_person = Kakkanad clinic",
+ "enum": [
+ "online",
+ "in_person"
+ ],
+ "type": "string"
+}Input schema / properties / name / descriptionAdded value: +"the contact: the client, or for teen sessions the parent or guardian"Input schema / properties / partner_2Added value: +{
+ "description": "couples only: the second partner",
+ "properties": {
+ "email": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "phone": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name"
+ ],
+ "type": "object"
+}Input schema / properties / psychologistAdded value: +{
+ "description": "slug (e.g. 'nithya-s'), ONLY if the customer asked for that psychologist",
+ "type": "string"
+}Input schema / properties / teen_ageAdded value: +{
+ "description": "teen only, if known: 13 to 17",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Input schema / properties / teen_nameAdded value: +{
+ "description": "teen only: the young person's name",
+ "type": "string"
+}get_booking_status1 field changedInput schema / properties / poll_key / descriptionPrevious value: -"the poll_key returned by create_booking_draft; required to retrieve the Meet link"New value: +"the poll_key returned by create_booking_draft"reschedule_bookingcreate_booking_draft2 fields changedInput schema / properties / plan_code / descriptionAdded value: +"'single' for one session; 'plan4', 'plan8' or 'plan12' for a plan (see list_services)"Input schema / properties / plan_code / enumPrevious value: -[
- "single",
- "starter5",
- "preferred9",
- "committed11"
-]New value: +[
+ "single",
+ "plan4",
+ "plan8",
+ "plan12"
+]check_availabilitycreate_booking_draftget_booking_statuslist_servicesFind kids' and teens' mental health clinicians, check availability, get booking links and costs.
Search India's credential-verified therapist directory: read-only, public, checkable registrations.
Find wellbeing sessions with independent practitioners: free times, prices and booking links.
Published consultation details, live availability and booking handoff for Russian-language sessions.
Add one secure layer between your agents and this server.
