Find Italian doctors and health practitioners: profile, services, prices, free booking slots.
Scored across 5 tools
The tools form a clear pipeline from search to booking, but get_doctor_profile and get_visit_types both return service details with duration and price, creating a minor overlap that could confuse an agent about which to use for pricing or service information.
All names use consistent snake_case with a predictable verb_noun pattern (get_, search_, request_), making the tool set easy to parse and remember.
Five tools are well-scoped for the domain: search, profile, visit types, availability, and booking request. Each tool earns its place without redundancy or bloat.
The surface covers the essential patient journey from discovery to booking initiation, but lacks tools for managing or cancelling bookings and for searching by doctor name or listing all specialties/cities.
Orari di inizio liberi per la prenotazione online di un professionista, giorno per giorno (massimo 14 giorni). Mostra solo gli orari liberi, mai chi ha prenotato. Indica visit_type per avere solo gli orari in cui quella visita ci sta. Non prenota: per l'orario scelto dai al paziente il link di booking_urls di quel giorno (pagina di prenotazione con sede, giorno, orario e tipo di visita già scelti; il paziente inserisce i suoi dati e conferma), altrimenti booking_url. / Free start times for online booking, day by day (max 14 days). Shows free times only, never who booked. Pass visit_type to get only the times that visit fits. Does not book: for the chosen time give the patient that day's booking_urls link (the booking page with location, day, time and visit type preselected; the patient enters their details and confirms), otherwise booking_url.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Codice pubblico del medico restituito da search_doctors (campo `code`). / The doctor's public code from search_doctors (`code`). | |
| days | No | Numero di giorni (default 7, max 14). / Number of days. | |
| from | No | Primo giorno AAAA-MM-GG (default oggi, fuso Europe/Rome). / First day YYYY-MM-DD (default today, Europe/Rome). | |
| visit_type | No | Opzionale ma consigliato: il nome esatto di un tipo di visita da get_visit_types (stessa sede). Con il nome, solo gli orari in cui quella visita (con la sua durata) è prenotabile. / Optional but recommended: the exact visit type name from get_visit_types (same location); only start times where a visit of that length fits are returned. | |
| location_ref | No | Opzionale: numero della sede (location_ref) da get_doctor_profile. Senza, la sede principale. / Optional location number (location_ref) from get_doctor_profile; defaults to the primary location. |
| Name | Required | Description |
|---|---|---|
| days | Yes | |
| from | Yes | |
| location | Yes | |
| free_slots | Yes | |
| visit_type | No | |
| booking_url | Yes | |
| other_locations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly/idempotent/non-destructive), and the description adds real substance beyond them: a 14-day ceiling, that only free times are returned and never the booker's identity, and that each day's output carries booking_urls with preselected context. It stops short of pagination or empty-result behavior, so not a 5.
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-loads what the tool returns, then the no-booking constraint, then the parameter hint. The bilingual duplication inflates length, but no sentence is padding — the structure is clean and 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?
With an output schema present and annotations covering safety, the description supplies exactly the missing pieces: return-shape landmarks (booking_urls/booking_url) and the intended downstream workflow. An agent needs nothing further 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 100%, so baseline is 3, but the description adds meaning the schema can't: visit_type must be the exact name from get_visit_types for the same location, and it filters by duration-fits semantics rather than simple equality. That is genuine added value over the field descriptions.
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 concrete verb+resource (free start times for online booking) with scope (day by day, max 14 days) and explicitly disambiguates itself from booking behavior. An agent can distinguish it from search_doctors/get_visit_types/get_doctor_profile without opening any 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 a clear when-not ('Non prenota') plus the alternative workflow: hand the patient the booking_urls link for the chosen slot, falling back to booking_url. It also says when to pass visit_type (to restrict to times a visit of that duration fits). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Profilo pubblico di un professionista: specialità, iscrizione all'Albo, sedi, orari, prestazioni con durata e prezzo (null = prezzo non indicato o non mostrato online), valutazione verificata, link al suo sito e alla prenotazione. Non prenota. / Public profile: specialty, professional registration, locations, opening hours, services with duration and price (null = price not stated or not shown online), verified rating, links to their website and booking page. Does not book.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Codice pubblico del medico restituito da search_doctors (campo `code`). / The doctor's public code from search_doctors (`code`). |
| Name | Required | Description |
|---|---|---|
| code | Yes | |
| name | Yes | |
| rating | Yes | |
| services | Yes | |
| site_url | Yes | |
| locations | Yes | |
| specialty | Yes | |
| booking_url | Yes | |
| registration | Yes | |
| opening_hours | Yes | |
| practice_name | Yes | |
| online_booking | Yes | |
| profession_types | Yes | |
| external_site_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive behavior, so the bar is lower. The description adds valuable context beyond annotations: `null = price not stated or not shown online` clarifies data semantics, and 'Does not book' clarifies the operational boundary. This helps an agent interpret results correctly 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?
The description is front-loaded with 'Public profile' and uses a compact, dense comma-separated list of fields. The bilingual repetition doubles length without adding information for an English-only agent, but it is still focused and every substantive detail serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with an output schema, the description is complete: it enumerates all major fields, explains null pricing semantics, and clarifies that booking is not performed. Sibling tools and the code source are known from context/schema, so nothing essential 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%, and the sole `code` parameter is already well documented in the schema as the doctor's public code from search_doctors. The description adds no parameter-level detail, but given the high schema coverage, the baseline of 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 names a specific verb/resource ('Public profile of a professional') and enumerates the exact content: specialty, registration, locations, hours, services with duration/price, rating, and links. The closing 'Does not book' disambiguates it from booking-related actions, and the field list clearly separates it from sibling tools like get_availability or get_visit_types.
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 makes clear this tool is for retrieving a public practitioner profile and explicitly states what it does not do ('Does not book'). The schema adds that the `code` comes from search_doctors, which implies a workflow. However, the description itself does not explicitly name alternative tools or say when to prefer them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tipi di visita prenotabili online da un professionista, con durata, prezzo in euro (null = prezzo non indicato o non mostrato online, NON gratuito) e se il pagamento è online. Non prenota. / Visit types bookable online, with duration, price in EUR (null = price not stated or not shown online, NOT free) and whether payment is online. Does not book.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Codice pubblico del medico restituito da search_doctors (campo `code`). / The doctor's public code from search_doctors (`code`). | |
| location_ref | No | Opzionale: numero della sede (location_ref) da get_doctor_profile. Senza, la sede principale. / Optional location number (location_ref) from get_doctor_profile; defaults to the primary location. |
| Name | Required | Description |
|---|---|---|
| location | Yes | |
| booking_url | Yes | |
| visit_types | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable behavioral context beyond annotations: null price means 'not stated or not shown online, NOT free', and the tool does not perform booking. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences in bilingual form deliver the core purpose, return attributes, null semantics, and non-booking behavior with no wasted content. Key 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?
Given the output schema exists, annotations cover read-only/idempotent behavior, and the schema documents all parameters, the description fills remaining gaps (null price meaning, no booking side effect). 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%: both parameters (code and location_ref) are fully described in the input schema, including defaults and relationships to search_doctors/get_doctor_profile. The description does not need to add parameter detail, so a 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 clearly identifies the resource: visit types bookable online, with duration, price in EUR, and online-payment flag. The explicit 'Does not book' distinguishes it from booking-related actions and makes the tool's scope unambiguous to an agent.
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 you need visit types and prices for a doctor) and states a notable exclusion ('Does not book'). However, it does not explicitly name sibling tools or describe conditions for choosing this over get_availability or search_doctors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invia una richiesta di prenotazione per un orario libero. Non prenota subito: Sanovia manda al paziente un'email con un link valido 30 minuti; la visita esiste solo quando il paziente la conferma dalla pagina Sanovia (accetta Termini e Privacy e, se previsto, paga online). L'orario non è bloccato fino alla conferma. Chiedi al paziente SOLO nome, cognome ed email: non inviare mai dati sanitari, sintomi, telefono o codice fiscale. Usa un time di free_slots da get_availability per la stessa sede e lo stesso visit_type. / Sends a booking request for a free time. It does not book: Sanovia emails the patient a link valid for 30 minutes; the visit exists only once the patient confirms on the Sanovia page (accepting Terms and Privacy and, when required, paying online). The time is not held until then. Ask the patient ONLY for first name, last name and email: never send health data, symptoms, phone number or tax code. Use a time from get_availability's free_slots for the same location and visit_type.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Codice pubblico del medico restituito da search_doctors (campo `code`). / The doctor's public code from search_doctors (`code`). | |
| date | Yes | Giorno AAAA-MM-GG (fuso Europe/Rome), come in free_slots. / Day YYYY-MM-DD (Europe/Rome), as in free_slots. | |
| time | Yes | Orario di inizio HH:MM, uno di free_slots per quel giorno. / Start time HH:MM, one of that day's free_slots. | |
| Yes | Email del paziente: riceverà il link di conferma. / Patient's email: the confirmation link goes there. | ||
| language | No | Lingua dell'email (default it). / Email language (default it). | |
| last_name | Yes | Cognome del paziente (solo lettere). / Patient's last name (letters only). | |
| first_name | Yes | Nome del paziente (solo lettere). / Patient's first name (letters only). | |
| visit_type | No | Il nome esatto di un tipo di visita da get_visit_types (stessa sede). Obbligatorio se il medico ne pubblica. / The exact visit type name from get_visit_types (same location). Required when the doctor publishes any. | |
| location_ref | No | Opzionale: numero della sede (location_ref) da get_doctor_profile. Senza, la sede principale. / Optional location number (location_ref) from get_doctor_profile; defaults to the primary location. |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| time | Yes | |
| status | Yes | |
| location | Yes | |
| price_eur | Yes | |
| slot_held | Yes | |
| visit_type | Yes | |
| expires_in_min | Yes | |
| requires_approval | Yes | |
| requires_online_payment | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the whole asynchronous lifecycle: Sanovia emails the patient a link valid 30 minutes, the slot is not held until confirmation, and payment/Terms acceptance may gate the visit. It also warns against sending health data, symptoms, phone or tax code — none of which is derivable from readOnlyHint/openWorldHint/idempotentHint.
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 and waste-free per sentence: the negative statement of what the tool does NOT do comes second, before operational rules. The main cost is the Italian/English duplication, which roughly doubles length, though it is a deliberate i18n choice rather than padding.
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 9-parameter, non-idempotent mutation with an output schema, the description supplies everything an agent needs to call it correctly: source of the time value, location/visit_type coupling, PII restrictions, and the deferred-confirmation model. Return values are covered by the output schema, so nothing material 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 coverage is 100%, so the baseline is 3; the description earns above that by adding cross-parameter semantics the schema cannot express — that 'time' must be one of that day's free_slots for the same location and visit_type, and that only name/surname/email are legitimate patient inputs. It doesn't restate field formats, which the schema already handles.
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 precise verb+resource ('Invia una richiesta di prenotazione') and immediately negates the obvious misreading: 'Non prenota subito' — the visit exists only after patient confirmation. This distinguishes it cleanly from any sibling that merely offers slots (get_availability) and from a real booking action.
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 tells the agent which sibling output feeds this tool ('Usa un time di free_slots da get_availability per la stessa sede e lo stesso visit_type'), names the constraints (same location, same visit_type), and states a hard data-collection rule ('Chiedi al paziente SOLO nome, cognome ed email'). When-to-use and what-not-to-send are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cerca medici e professionisti sanitari italiani iscritti a Sanovia per specialità e/o città. Elenca solo chi ha la pagina di prenotazione online e un sito pubblicato: il proprio, oppure quello della struttura (poliambulatorio, centro) in cui riceve — in quel caso site_url è il sito della struttura. Non prenota: restituisce il link di prenotazione. / Search Italian doctors and health practitioners on Sanovia by specialty and/or city. Lists only practitioners with an online booking page and a published website: their own, or that of the structure (clinic) they practise in — then site_url is the structure's site. Does not book; returns the booking link.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Città della sede, es. «Bologna». / City of the practice. | |
| limit | No | Massimo risultati (default 10, max 20). / Max results. | |
| specialty | No | Specialità o professione, in italiano: la disciplina («Cardiologia», «Odontoiatria», «Medicina Generale», «Fisioterapia», «Osteopatia») oppure il professionista («cardiologo», «dentista», «medico di base», «fisioterapista», «osteopata»). / Specialty or profession, in Italian: the discipline (e.g. «Cardiologia») or the practitioner noun (e.g. «cardiologo»). |
| Name | Required | Description |
|---|---|---|
| doctors | Yes | |
| truncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description still adds real value beyond that: entries are constrained to practitioners with a live booking page and published site, site_url may actually point to the clinic rather than the practitioner, and the tool returns a booking link rather than booking. This is meaningful behavioral context, though rate limits/caching are unmentioned.
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 scoping and non-booking constraint are front-loaded and each sentence earns its place. The cost is full bilingual duplication, which is redundant for a single-language agent consumer, so it is efficient but not maximally tight.
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, and it already clarifies the notable site_url semantics and the listing constraint. It is essentially complete for calling the tool correctly; only the absence of sibling routing leaves a small 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 description coverage is 100% and all three parameters (city, specialty, limit) are documented inline with examples and constraints. The description only restates the specialty-and-city filtering, adding no syntax or behavior beyond the schema, 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 names a specific verb (search/list) and resource (Italian doctors and health practitioners on Sanovia) and bounds the scope to specialty and/or city. It also disambiguates against siblings like get_availability and get_doctor_profile by stating it does not book and only returns a booking link, and it specifies the inclusion filter (only practitioners with a booking page and published website).
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: find practitioners filtered by specialty and/or city, and explicitly notes it does not perform bookings. However, it never names the sibling alternatives (get_doctor_profile, get_availability) or states when a caller should prefer them, so the routing guidance stops short of explicit exclusions.
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.
request_bookingget_availability4 fields changedInput schema / properties / visit_typeAdded value: +{
+ "description": "Opzionale ma consigliato: il nome esatto di un tipo di visita da get_visit_types (stessa sede). Con il nome, solo gli orari in cui quella visita (con la sua durata) è prenotabile. / Optional but recommended: the exact visit type name from get_visit_types (same location); only start times where a visit of that length fits are returned.",
+ "type": "string"
+}Output schema / properties / free_slots / items / properties / booking_urlsAdded value: +{
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+}Output schema / properties / free_slots / items / requiredPrevious value: -[
- "date",
- "slots"
-]New value: +[
+ "date",
+ "slots",
+ "booking_urls"
+]Output schema / properties / visit_typeAdded value: +{
+ "properties": {
+ "duration_min": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "duration_min"
+ ],
+ "type": "object"
+}search_doctors1 field changedInput schema / properties / specialty / descriptionPrevious value: -"Specialità o professione, es. «cardiologo», «fisioterapista». / Specialty or profession."New value: +"Specialità o professione, in italiano: la disciplina («Cardiologia», «Odontoiatria», «Medicina Generale», «Fisioterapia», «Osteopatia») oppure il professionista («cardiologo», «dentista», «medico di base», «fisioterapista», «osteopata»). / Specialty or profession, in Italian: the discipline (e.g. «Cardiologia») or the practitioner noun (e.g. «cardiologo»)."get_availability1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "booking_url": {
+ "type": "string"
+ },
+ "days": {
+ "type": "number"
+ },
+ "free_slots": {
+ "items": {
+ "properties": {
+ "date": {
+ "type": "string"
+ },
+ "slots": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "date",
+ "slots"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "from": {
+ "type": "string"
+ },
+ "location": {
+ "properties": {
+ "city": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "location_ref": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "location_ref",
+ "name",
+ "city"
+ ],
+ "type": "object"
+ },
+ "other_locations": {
+ "items": {
+ "properties": {
+ "city": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "location_ref": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "location_ref",
+ "name",
+ "city"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "location",
+ "other_locations",
+ "from",
+ "days",
+ "free_slots",
+ "booking_url"
+ ],
+ "type": "object"
+}get_doctor_profile1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "booking_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "code": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "external_site_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "locations": {
+ "items": {
+ "properties": {
+ "address": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "city": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "location_ref": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "online_booking": {
+ "type": "boolean"
+ },
+ "phone": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "name",
+ "online_booking"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "name": {
+ "type": "string"
+ },
+ "online_booking": {
+ "type": "boolean"
+ },
+ "opening_hours": {
+ "items": {
+ "properties": {
+ "day": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "from": {
+ "type": "string"
+ },
+ "location": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "location",
+ "day",
+ "from",
+ "to"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "practice_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "profession_types": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "rating": {
+ "properties": {
+ "average": {
+ "type": "number"
+ },
+ "count": {
+ "type": "number"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "registration": {
+ "properties": {
+ "number": {
+ "type": "string"
+ },
+ "province": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "services": {
+ "items": {
+ "properties": {
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "duration_min": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "price_eur": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "remote": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "name",
+ "duration_min",
+ "price_eur",
+ "remote",
+ "description"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "site_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "specialty": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "code",
+ "name",
+ "specialty",
+ "practice_name",
+ "profession_types",
+ "online_booking",
+ "booking_url",
+ "site_url",
+ "registration",
+ "locations",
+ "opening_hours",
+ "services",
+ "rating",
+ "external_site_url"
+ ],
+ "type": "object"
+}get_visit_types1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "booking_url": {
+ "type": "string"
+ },
+ "location": {
+ "properties": {
+ "city": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "location_ref": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "location_ref",
+ "name",
+ "city"
+ ],
+ "type": "object"
+ },
+ "visit_types": {
+ "items": {
+ "properties": {
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "duration_min": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "price_eur": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "requires_online_payment": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "name",
+ "duration_min",
+ "price_eur",
+ "requires_online_payment",
+ "description"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "location",
+ "visit_types",
+ "booking_url"
+ ],
+ "type": "object"
+}search_doctors1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "doctors": {
+ "items": {
+ "properties": {
+ "booking_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "cities": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "code": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "online_booking": {
+ "type": "boolean"
+ },
+ "practice_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "profession_types": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "site_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "specialty": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "code",
+ "name",
+ "specialty",
+ "practice_name",
+ "profession_types",
+ "online_booking",
+ "booking_url",
+ "site_url",
+ "cities"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "truncated": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "doctors",
+ "truncated"
+ ],
+ "type": "object"
+}get_availabilityget_doctor_profileget_visit_typessearch_doctorsSearch private healthcare appointment availability across Cup24.it: services, doctors, clinics.
Find verified doctors, dentists, lawyers and accountants; see free times; request a booking.
Find and book doctor, dentist & nurse appointments. 2M+ providers by insurance & cost in the US.
Find and book local businesses in Italy on Kaio: real free times, booking, online payment link.
Add one secure layer between your agents and this server.
