Skip to main content
Le serveur MCP Hi-Doctor est un serveur de ressources OAuth 2.1. Il ne détient aucune base de données patients qui lui soit propre : chaque appel d’outil est transmis à l’API Hi-Doctor en tant que vous, avec les autorisations de votre propre compte.

La connexion

La connexion suit un flux OAuth 2.1 standard par code d’autorisation, avec PKCE (S256). Votre client IA ne voit jamais votre mot de passe : vous le saisissez sur une page Hi-Doctor, et le client reçoit un code d’autorisation de courte durée qu’il échange contre un jeton. Le serveur publie les documents de découverte qu’un client MCP attend, si bien qu’aucune configuration manuelle n’est nécessaire : Les codes d’autorisation sont à usage unique et de courte durée. En utiliser un deux fois échoue : un code rejoué est rejeté, pas honoré.

Où un jeton peut être renvoyé

Chaque client enregistré reçoit un client_id signé qui lie l’URI de redirection exacte avec laquelle il s’est enregistré. Au moment de l’autorisation, l’URI redirect_uri demandée doit correspondre exactement à cette liaison.
C’est la défense contre l’interception du code d’autorisation : un attaquant qui connaît votre client_id ne peut toujours pas demander que le code soit délivré à son propre serveur, parce que l’URI est scellée dans l’identifiant et vérifiée avant même que le formulaire de connexion ne s’affiche.
Les redirections en boucle locale suivent la RFC 8252 §7.3 : le port peut varier, comme l’exigent les clients de bureau, mais le reste de l’URI doit correspondre.

Les jetons

Les jetons d’accès sont des enveloppes chiffrées en AES-256-GCM, et non des identifiants bruts du back-end. Une enveloppe est liée à son audience et se voit rejetée si elle est altérée, rejouée contre la mauvaise ressource, ou présentée après l’expiration du jeton back-end qu’elle contient. Une enveloppe de rafraîchissement ne peut pas être utilisée là où une enveloppe d’accès est requise. Votre mot de passe Hi-Doctor est échangé contre un jeton à la connexion ; il n’est jamais conservé par le connecteur, jamais écrit dans un journal, et jamais transmis à l’application qui se connecte.

Les autorisations

Les outils sont regroupés, et chaque groupe exige sa propre portée : profil, consultations, messages, questionnaires, progrès, paiement. Un outil dont vous n’avez pas accordé la portée n’est pas seulement refusé, il n’est pas proposé : il n’apparaît jamais dans la liste d’outils du client. Les rôles ne se cumulent pas. Un compte reçoit exactement un catalogue d’outils, de sorte qu’un jeton de patient ne peut jamais atteindre un outil de clinicien ou de back-office. Voir Autorisations pour la liste complète des accès accordés.

Ce que le serveur refuse de laisser filtrer

  • Les corps de réponse 5xx du back-end sont entièrement écartés. Une erreur en amont renvoie un échec générique et stable, plutôt qu’une trace interne.
  • Les réponses 4xx sont filtrées selon une liste blanche de champs structurés, afin qu’une erreur puisse être exploitable sans renvoyer de données de santé dans le résultat de l’outil.
  • Les arguments de chemin ne peuvent pas sortir de l’hôte d’API configuré ni de son préfixe de version.
  • La limitation de débit est indexée sur le jeton, et non sur un en-tête qu’un appelant pourrait remodeler pour obtenir un nouveau quota.

Le paiement

Le connecteur ne manipule jamais de données de carte bancaire. hidoctor_checkout_create renvoie un lien vers la page de paiement hébergée par Stripe, et les changements de carte, de formule et d’adresse de facturation ont lieu dans le portail de facturation Stripe. Aucun outil n’accepte de numéro de carte, et tout assistant qui vous en demande un ne parle pas à Hi-Doctor.

Les limites cliniques

Aucun jeton, quel qu’il soit, ne peut approuver une consultation, émettre ou modifier une ordonnance, ou changer une dose. Ces actions ne sont pas exposées du tout par le serveur MCP : elles ne sont pas protégées derrière une portée, elles sont tout simplement absentes. L’éligibilité médicale est appliquée par le back-end Hi-Doctor au moment de l’envoi du questionnaire. Un assistant ne peut pas pré-approuver un patient, et renvoyer le questionnaire avec des réponses différentes ne contourne pas le contrôle.

Signaler un problème

Écrivez à hello@hi-doctor.ai en détaillant le problème. Si vous pensez que des données de santé sont exposées, indiquez-le dans l’objet du message afin qu’il soit traité en priorité.