anteos-booking
Server Details
Book medical appointments with French doctors by specialty and city via AI agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Anteos-Health/anteos-mcp
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 10 of 10 tools scored.
Most tools have clearly distinct purposes, but find_next_available and get_available_slots both relate to finding free slots, which could cause confusion. However, detailed descriptions differentiate their use cases (general search vs specific doctor/date).
All tool names follow a consistent verb_noun pattern in snake_case, e.g., book_appointment, cancel_appointment, search_doctors. No mixing of conventions.
With 10 tools, the server covers the essential operations of a booking system without being overly numerous or sparse. Each tool serves a distinct and necessary function.
The tool set supports the full appointment lifecycle: booking, cancellation, rescheduling, slot searching, doctor discovery, and token management. No obvious gaps for the intended domain.
Available Tools
10 toolsbook_appointmentAInspect
Prend un rendez-vous pour un patient chez un médecin Anteos. Le rendez-vous est immédiatement confirmé dans l'agenda du médecin.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date du rendez-vous au format YYYY-MM-DD (ex: "2026-04-20") | |
| time | Yes | Heure du rendez-vous au format HH:MM (ex: "14:30") | |
| motif | No | Motif de la consultation (optionnel, ex: "Suivi traitement", "Renouvellement ordonnance") | |
| doctor_id | Yes | Identifiant du médecin (obtenu via search_doctors) | |
| patient_dob | Yes | Date de naissance du patient au format YYYY-MM-DD. Obligatoire. | |
| patient_sex | Yes | Sexe du patient : M (Masculin), F (Féminin) ou autre. Obligatoire. | |
| patient_email | Yes | Email du patient — OBLIGATOIRE. Utilisé pour l'envoi de la confirmation et des rappels de rendez-vous. | |
| patient_phone | No | Téléphone du patient (optionnel — format: 0612345678 ou +33612345678) | |
| patient_lastname | Yes | Nom de famille du patient (en majuscules de préférence) | |
| patient_firstname | Yes | Prénom du patient | |
| send_confirmation_email | No | Envoyer un email de confirmation au patient avec des liens de gestion du RDV. Défaut: true. Passer false si votre plateforme envoie sa propre confirmation. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations: it reveals that the appointment is immediately confirmed in the doctor's agenda, indicating a non-readOnly, non-idempotent write operation. Annotations (all false) are consistent, and no contradictions.
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 concise sentences in French, front-loaded with the core action. No unnecessary words, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters and no output schema, the description is adequate but lacks details on return values (e.g., what is returned on success/error) and potential constraints like duplicate booking or time slot conflicts. The schema covers required fields, but the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters with clear details. The tool description does not add further parameter meaning beyond what the schema already provides. 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 states the specific action: booking an appointment for a patient with an Anteos doctor, and that it is immediately confirmed in the doctor's agenda. This distinguishes it from siblings (cancel_appointment, get_appointment, search_doctors) with a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use instructions are provided. The description does not mention prerequisites like obtaining doctor_id via search_doctors or compare with siblings. The purpose is implied but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cancel_appointmentADestructiveIdempotentInspect
Annule un rendez-vous existant. L'annulation est définitive. Requiert le appointment_token reçu lors de la réservation (book_appointment).
| Name | Required | Description | Default |
|---|---|---|---|
| appointment_id | Yes | Identifiant unique du rendez-vous à annuler | |
| appointment_token | Yes | Token de sécurité reçu dans la réponse de book_appointment. Révoqué définitivement après annulation. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. Description adds 'cancellation is final', reinforcing the irreversibility. No contradictions. Good addition but could mention side effects like notifications.
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, no filler, front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with one parameter and thorough annotations, the description is complete. It explains the action and finality, which suffices. No output schema necessary.
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% with a clear parameter description. The description adds no additional meaning beyond what the schema already provides, so 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?
Description clearly states the tool cancels an existing appointment, with the verb 'cancel' and resource 'appointment'. It distinguishes from siblings: book_appointment (create), get_appointment (read), search_doctors (search).
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?
Description implies finality ('cancellation is final'), suggesting use only when certain. However, it lacks explicit when-to-use or when-not-to-use guidelines, and no alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_next_availableARead-onlyIdempotentInspect
Cherche les prochains créneaux disponibles sur une période, pour un ou plusieurs médecins filtrés par spécialité et/ou ville. À préférer à get_available_slots quand l'utilisateur demande "quand est-ce que X est libre" ou "y a-t-il un RDV disponible cette semaine". Retourne au maximum max_slots créneaux par médecin pour ne pas surcharger le contexte.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Ville (ex: "Paris"). Ignoré si doctor_id est fourni. | |
| days | No | Nombre de jours à couvrir depuis from_date (défaut: 7, max: 30) | |
| doctor_id | No | Chercher uniquement pour ce médecin (obtenu via search_doctors). Court-circuite specialty et city. | |
| from_date | Yes | Date de début de la recherche au format YYYY-MM-DD | |
| max_slots | No | Nombre maximum de créneaux retournés par médecin (défaut: 5, max: 20) | |
| specialty | No | Spécialité médicale (ex: "neurologue", "cardiologue"). Ignoré si doctor_id est fourni. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Les annotations indiquent déjà readOnlyHint, idempotentHint, destructiveHint. La description ajoute le comportement de limitation du nombre de créneaux (max_slots) par médecin pour éviter de surcharger le contexte, ce qui est une information utile supplémentaire.
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?
Deux phrases concises: la première énonce l'action et les filtres, la seconde donne le contexte d'utilisation et une limitation comportementale. Aucun mot superflu.
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?
Le description couvre le but, les critères de sélection par rapport à un sibling, et une contrainte de résultat. Il manque peut-être une mention explicite du retour multiple par médecin, mais cela est implicite. Compte tenu de l'absence de output schema, c'est suffisant.
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?
La couverture des paramètres dans le schema est de 100%. La description mentionne l'effet de 'max_slots' (limite par médecin), ce qui enrichit légèrement la sémantique. Toutefois, les descriptions du schema sont déjà explicites.
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?
Le verbe 'cherche' et la ressource 'créneaux disponibles' sont clairs. La description distingue ce tool de 'get_available_slots' en précisant les cas d'usage (demandes comme 'quand est-ce que X est libre').
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?
La phrase 'À préférer à get_available_slots quand...' donne une directive explicite sur quand utiliser ce tool plutôt que son sibling, avec des exemples concrets de requêtes utilisateur.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_appointmentARead-onlyIdempotentInspect
Récupère les informations et le statut d'un rendez-vous. Requiert le appointment_token reçu lors de la réservation (book_appointment) — ce token prouve que l'appelant représente le patient concerné.
| Name | Required | Description | Default |
|---|---|---|---|
| appointment_id | Yes | Identifiant unique du rendez-vous (obtenu via book_appointment) | |
| appointment_token | Yes | Token de sécurité reçu dans la réponse de book_appointment. À stocker côté client et à transmettre ici pour prouver l'identité du patient. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds minimal context ('status') but does not contradict 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?
Single sentence, front-loaded with verb and object, no wasted words.
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?
Simple tool with one parameter and no output schema. Description explains what is retrieved (info and status). Adequate for complexity; slight gap on error handling or return format but acceptable.
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 covers appointment_id fully (100% coverage). Tool description adds no extra parameter meaning beyond what schema provides. 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?
Description clearly states the verb 'récupère' (retrieves) and resource 'informations et statut d'un rendez-vous' (information and status of an appointment). It distinguishes from siblings: book_appointment creates, cancel_appointment cancels, search_doctors searches doctors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The schema description of appointment_id says 'obtenu via book_appointment', implying the ID comes from booking, but overall usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_available_slotsARead-onlyIdempotentInspect
Retourne les créneaux disponibles pour un médecin à une date donnée. À appeler avant book_appointment pour proposer des options concrètes au patient plutôt que de réserver à l'aveugle.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date au format YYYY-MM-DD (ex: "2026-05-10") | |
| doctor_id | Yes | Identifiant du médecin (obtenu via search_doctors) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, making the behavioral profile transparent. The description adds no new behavioral details beyond the purpose, so it meets the baseline but does not exceed it.
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 concise sentences: the first states the core purpose, the second provides usage guidance. No extraneous information, perfectly 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?
While the description covers purpose and usage, it does not describe the output format (no output schema). Given the tool's simplicity and the presence of sibling tools, the description is minimally complete but could benefit from specifying the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage, including format for date and source for doctor_id. The description adds no additional semantic meaning, so it earns the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns available slots for a doctor on a given date, using a specific verb and resource. It also distinguishes itself from siblings by advising to call before book_appointment, ensuring the agent knows its role in the workflow.
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 when to use the tool: before book_appointment, to offer concrete options to the patient. This provides clear guidance and differentiates from alternative tools, enhancing decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_doctor_profileARead-onlyIdempotentInspect
Retourne le profil complet d'un médecin : coordonnées, secteur conventionnement, carte vitale, tiers payant, téléconsultation, langues, description, diplômes, expertises, avis patients Anteos (note, résumé IA), et créneaux disponibles sur les 7 prochains jours. À appeler après search_doctors pour aider le patient à choisir son médecin.
| Name | Required | Description | Default |
|---|---|---|---|
| doctor_id | Yes | Identifiant du médecin (champ "id" retourné par search_doctors) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. The description adds behavioral context such as including slots for the next 7 days and patient reviews, which go beyond annotations. No contradictions.
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?
Description is a single sentence that front-loads the core purpose, but is somewhat lengthy due to listing many fields. It is informative and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no output schema, the description is fairly complete, listing all returned data categories. It could benefit from mentioning response structure or edge cases, but overall adequate.
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?
Input schema has 100% coverage with a clear description for doctor_id. The tool description does not add additional parameter semantics beyond what the schema already provides, so a baseline score 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 clearly states it returns the complete profile of a doctor, listing many specific fields. It also explicitly states the tool should be called after search_doctors, distinguishing it from sibling tools like search_doctors or get_appointment.
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 explicitly says 'À appeler après search_doctors pour aider le patient à choisir son médecin,' providing clear when-to-use guidance. However, it does not explicitly mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_my_appointmentsARead-onlyIdempotentInspect
Liste les rendez-vous créés par cette clé partenaire. Utile pour récupérer l'état après un crash ou un redémarrage de l'agent, ou pour vérifier les RDV en cours sans stocker les tokens côté client.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Nombre de résultats par page (défaut: 20, max: 100) | |
| offset | No | Décalage pour la pagination (défaut: 0) | |
| status | No | Filtrer par statut temporel : "upcoming" (par défaut), "past" ou "all" | upcoming |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context by specifying scope (appointments by partner key) and use cases. It does not contradict annotations and enriches understanding.
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, no wasted words. Front-loaded with purpose and efficiently provides usage guidance. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 optional params, no output schema), the description covers scope and use cases well. It could mention what fields are returned, but annotations and schema largely compensate. Overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add parameter details beyond what the schema provides. It remains adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists appointments created by a specific partner key, distinguishing it from siblings like book_appointment or cancel_appointment. It provides specific use cases such as recovering after crash or checking ongoing appointments.
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 explicitly explains when to use this tool: after a crash or agent restart, or to check ongoing appointments without storing tokens client-side. This gives clear usage context and implies when not to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reschedule_appointmentAInspect
Reporte un rendez-vous existant vers un nouveau créneau. L'opération est atomique : l'ancien RDV est annulé et le nouveau est créé en une seule transaction, évitant qu'un autre agent prenne le créneau cible entre les deux. Un nouveau appointment_token est émis — l'ancien est révoqué définitivement.
| Name | Required | Description | Default |
|---|---|---|---|
| new_date | Yes | Nouvelle date au format YYYY-MM-DD | |
| new_time | Yes | Nouvelle heure au format HH:MM | |
| appointment_id | Yes | Identifiant du rendez-vous à reporter | |
| appointment_token | Yes | Token de sécurité reçu lors de la réservation initiale |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses essential behavioral traits: atomicity (two operations in one transaction), cancellation of old appointment, creation of new one, token revocation and issuance. These details go well beyond the provided annotations (readOnlyHint=false, destructiveHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each adding critical information. The main action is front-loaded, and no extraneous content exists.
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 complexity (4 required params, atomic operation, token management) and absence of output schema, the description covers the core behavior and token lifecycle. It could mention failure handling or return value, but overall is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description adds extra semantic context for 'appointment_token' by explaining it will be replaced and the old one revoked, which is not in the schema description. Other parameters are well documented in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reschedules an existing appointment to a new slot, using specific verb 'reporter' and resource 'rendez-vous'. It distinguishes from siblings like cancel_appointment and book_appointment by combining cancel+create in one atomic 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?
The description explains the atomic nature and token replacement, implicitly guiding when to use this vs performing separate cancel and book. However, it does not explicitly state 'use this instead of cancel-then-book'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resend_appointment_tokenAIdempotentInspect
Renvoie par email au patient le lien de gestion de son rendez-vous. À utiliser si le appointment_token n'est plus disponible côté client. Le token n'est jamais renvoyé dans la réponse — uniquement par email au patient.
| Name | Required | Description | Default |
|---|---|---|---|
| patient_email | Yes | Email du patient enregistré lors de la réservation. Doit correspondre exactement. | |
| appointment_id | Yes | Identifiant unique du rendez-vous |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral info beyond annotations: 'Le token n'est jamais renvoyé dans la réponse — uniquement par email au patient'. Annotations indicate idempotentHint=true and destructiveHint=false, which align with description. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each serving a purpose: stating action, usage condition, and behavioral constraint. No unnecessary words.
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, description covers that the token is not returned. It lacks details on response structure, but for a simple action this is adequate. Sibling tools provide context.
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. Description does not add parameter-specific details beyond what the schema already provides, but the context of resending via email is implied.
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?
Description uses specific verb 'Renvoie par email' and specific resource 'le lien de gestion de son rendez-vous', clearly indicating the tool resends an appointment management link via email. It distinguishes from sibling tools like book_appointment, cancel_appointment, get_appointment, and search_doctors.
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 states when to use: 'À utiliser si le appointment_token n'est plus disponible côté client'. This provides a clear trigger condition, though no explicit when-not-to-use or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_doctorsARead-onlyIdempotentInspect
Recherche des médecins Anteos par spécialité et/ou ville. Retourne les médecins avec disponibilités, secteur conventionnement et informations pratiques. Utilisez get_doctor_profile avec le champ id pour obtenir le profil complet d'un médecin (avis patients, diplômes, langues, tarifs).
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Ville où rechercher (ex: "Paris", "Lyon") | |
| limit | No | Nombre maximum de résultats par page (défaut: 10, max: 50) | |
| offset | No | Décalage pour la pagination (défaut: 0). Utiliser limit+offset pour naviguer au-delà de la première page. | |
| specialty | No | Spécialité médicale (ex: "médecin généraliste", "dermatologue", "cardiologue") | |
| available_from | No | Si fourni, ne retourne que les médecins ayant au moins un créneau libre à partir de cette date (YYYY-MM-DD). Utile pour filtrer d'emblée sur la disponibilité. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds the constraint that only doctors with external appointment booking are returned, which is valuable context beyond 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 concise sentences, front-loaded with the core purpose and followed by an important constraint. No unnecessary words.
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?
No output schema is provided, and the description does not explain the return format or pagination behavior. The limit parameter suggests pagination but is not detailed. Adequate for basic use but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds no additional meaning beyond the schema; it only paraphrases the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for Anteos doctors by specialty and/or city, with a specific constraint (only doctors with external appointment booking). This distinguishes it from sibling tools like book_appointment, cancel_appointment, get_appointment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly provide when-to-use or when-not-to-use guidance. Usage is implied from context (search before booking), but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!