Sanovia — medici e professionisti sanitari in Italia

Server Details

Find Italian doctors and health practitioners: profile, services, prices, free booking slots.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-24 13:14
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.1/5.0

Scored 2026-09-24 12:55 across 4 tools

Disambiguation4/5

Each tool has a clearly identifiable role: search, profile, visit types, and availability slots. There is minor overlap between get_doctor_profile and get_visit_types since both mention services with duration/price, but the descriptions clarify that the former is a general profile while the latter focuses on bookable visit types and payment conditions.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern: get_availability, get_doctor_profile, get_visit_types, search_doctors. Search is a different verb but still fits the same structural convention, so there are no mixed naming styles.

Tool Count5/5

Four tools is appropriate for a read-only healthcare directory and availability server. Each tool serves one step in the user journey: find doctors, inspect a profile, see bookable services, and check free time slots.

Completeness4/5

The surface covers the main discovery flow well: search, profile details, visit types, and availability. Booking is intentionally excluded and delegated to booking_url, but there is no way to search by doctor name directly or filter availability across multiple doctors, which are minor gaps.

Available Tools

4 tools

get_availabilityOrari liberi / Free time slotsA

Read-onlyIdempotent

Inspect

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. Non prenota: per prenotare il paziente usa booking_url. / Free start times for online booking, day by day (max 14 days). Shows free times only, never who booked. Does not book: the patient books at booking_url.

ParametersJSON Schema

Name	Required	Description
`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).
`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.

Output Schema

ParametersJSON Schema

Name	Required	Description
`days`	Yes
`from`	Yes
`location`	Yes
`free_slots`	Yes
`booking_url`	Yes
`other_locations`	Yes

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool's safety profile is covered. The description adds the meaningful privacy context that it 'never shows who booked' and explicitly clarifies it does not perform booking. This goes beyond the annotations but doesn't add much more behavioral detail like timezone or pagination behavior, though those are partly covered by the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, information-dense sentences in both languages, with the core purpose front-loaded first. Each sentence earns its place: it states the resource, clarifies the privacy boundary, and routes booking to booking_url. There is no filler or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no missing context for an agent to use it correctly: the purpose is clear, the parameter schema is fully described, annotations declare read-only/idempotent behavior, and an output schema exists so return values don't need explanation. The only routing hint, booking_url, is included, and the boundary against showing private booking data is explicitly stated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are already fully documented with types, defaults, and constraints. The description's mention of 'max 14 days' repeats the schema's days maximum and adds no new parameter semantics. Therefore, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the resource: free start times for online booking, day by day, with a 14-day limit. It also adds a negative boundary ('never who booked', 'does not book') that prevents confusion with a booking action. It does not explicitly name sibling tools (get_doctor_profile, get_visit_types, search_doctors), but the resource is distinct enough to make purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear context ('free start times for online booking') and explicitly says that booking must happen at booking_url, so the agent knows not to use this tool for booking. However, it does not explicitly distinguish this tool from the sibling tools such as get_visit_types, leaving that differentiation implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_doctor_profileProfilo del professionista / Practitioner profileA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

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`).

Output Schema

ParametersJSON Schema

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

TDQS

A4.2/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

get_visit_typesTipi di visita e prezzi / Visit types and pricesA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

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.

Output Schema

ParametersJSON Schema

Name	Required	Description
`location`	Yes
`booking_url`	Yes
`visit_types`	Yes

TDQS

A4.1/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

search_doctorsCerca professionisti / Search practitionersA

Read-onlyIdempotent

Inspect

Cerca medici e professionisti sanitari italiani iscritti a Sanovia per specialità e/o città. Elenca solo chi ha pubblicato sia il sito sia la pagina di prenotazione online. Non prenota: restituisce il link di prenotazione. / Search Italian doctors and health practitioners on Sanovia by specialty and/or city. Lists only practitioners who published both their website and their online booking page. Does not book; returns the booking link.

ParametersJSON Schema

Name	Required	Description
`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, es. «cardiologo», «fisioterapista». / Specialty or profession.

Output Schema

ParametersJSON Schema

Name	Required	Description
`doctors`	Yes
`truncated`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral detail beyond annotations: it lists only practitioners who published both website and booking page, and it returns the booking link rather than performing a booking. This is valuable non-obvious behavior not available from 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficient and front-loaded: it opens with the resource and purpose, then states the filtering criteria, then clarifies the non-booking behavior. The bilingual duplication doubles length but is intentional for an Italian-context tool and contains no filler or tangential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple search tool with three fully documented parameters, a complete output schema, and safety annotations, the description covers all necessary usage context: what is searched, what filtering is applied, and what the tool returns (a booking link, not actual booking). No critical information is missing for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with city, specialty, and limit all described inline. The description reinforces the city/specialty search dimensions but adds no parameter-level semantics beyond what the schema already provides. Baseline 3 is appropriate given full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Search Italian doctors and health practitioners on Sanovia', with explicit search dimensions of specialty and/or city. It also clarifies scope by stating it does not book but returns the booking link, clearly distinguishing it from the booking-related sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly conveys when to use it: when searching for practitioners by specialty and/or city and needing practitioners who have both a website and a booking page. It does not explicitly name alternatives like get_availability or get_doctor_profile, but the 'Does not book' clarification provides useful exclusions, and the search-vs-detail distinction with siblings is implied clearly enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesSep 24, 2026

Changedget_availability1 field changed

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"
+}

Changedget_doctor_profile1 field changed

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"
+}

Changedget_visit_types1 field changed

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"
+}

Changedsearch_doctors1 field changed

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"
+}

4 tool updatesSep 24, 2026
- First observedget_availability
- First observedget_doctor_profile
- First observedget_visit_types
- First observedsearch_doctors

Related MCP Connectors

Cup24.it Availability A
it.cup24
Search private healthcare appointment availability across Cup24.it: services, doctors, clinics.
Health & Wellness Biology & Medicine
52
vital-care-finder
io.github.apatzer
Find and book doctor, dentist & nurse appointments. 2M+ providers by insurance & cost in the US.
Biology & Medicine
1
Vitena Directory A
care.vitena
Search Vitena's public directory of bookable health and wellness professionals
Health & Wellness
31
MediMo
uk.co.medimo
Find and book UK private physiotherapy, osteopathy and chiropractic clinics, with live availability.
Health & Wellness Calendar Management Location Services
1

Related MCP Servers

healthcare
Biology & Medicine Search
tgdn
A
license
Not graded
quality
B
maintenance
Enables finding doctors in Romania by county, speciality, language, name, and weekly availability, with fuzzy name matching and nearby-county fallback.
Updated 9 days ago (2026-09-15 18:54 UTC)
24 npm
MIT
Doctolib MCP
Biology & Medicine Health & Wellness
arvernesmotion
A
license
Not graded
quality
C
maintenance
Enables querying Doctolib's public data to find practitioners, retrieve all available appointment slots in a geographic area, access practice details, and receive alerts when new slots open.
Updated a day ago (2026-09-23 12:35 UTC)
MIT
Doktor MCP Server
Health & Wellness Search Biology & Medicine
VanguardiaAI
A
license
A
quality
D
maintenance
Enables AI assistants to search the doktor.mx directory for over 56,000 verified doctors and medical specialists across Mexico. It provides tools for verifying professional licenses, finding specialists by symptoms or conditions, and checking medical insurance compatibility.
Updated 6 months ago (2026-03-28 03:37 UTC)
10
33 npm
MIT
doctolib-mcp
Calendar Management Health & Wellness
esinecan
F
license
Not graded
quality
C
maintenance
MCP server for Doctolib that enables searching practitioners, checking availability, and booking or canceling appointments across Doctolib Germany, France, and Italy.
Updated 2 months ago (2026-08-05 20:32 UTC)
1
-

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?