Skip to main content
Der Hi-Doctor MCP-Server ist ein Resource Server nach OAuth 2.1. Er hat keine eigene Patientendatenbank — jeder Tool-Aufruf wird als Sie an die Hi-Doctor-API weitergereicht, mit den Berechtigungen Ihres eigenen Kontos.

Anmeldung

Beim Verbinden läuft ein gewöhnlicher Authorization-Code-Flow nach OAuth 2.1 mit PKCE (S256) ab. Ihr KI-Client sieht Ihr Passwort nie: Sie geben es auf einer Hi-Doctor-Seite ein, und der Client erhält einen kurzlebigen Authorization Code, den er gegen ein Token tauscht. Der Server veröffentlicht die Discovery-Dokumente, die ein MCP-Client erwartet, sodass keine manuelle Konfiguration nötig ist: Authorization Codes sind einmalig verwendbar und kurzlebig. Ein zweites Einlösen schlägt fehl — ein wiederverwendeter Code wird abgelehnt, nicht akzeptiert.

Wohin ein Token zurückgeschickt werden darf

Jeder registrierte Client erhält eine signierte client_id, die genau die Redirect-URI bindet, mit der er sich registriert hat. Zum Autorisierungszeitpunkt muss die angeforderte redirect_uri dieser Bindung exakt entsprechen.
Das ist die Verteidigung gegen das Abfangen von Authorization Codes: Wer Ihre client_id kennt, kann trotzdem nicht verlangen, dass der Code an den eigenen Server geliefert wird, weil die URI in die Kennung eingesiegelt ist und geprüft wird, bevor das Anmeldeformular überhaupt erscheint.
Loopback-Redirects folgen RFC 8252 §7.3 — der Port darf variieren, wie es Desktop-Clients brauchen, der Rest der URI muss aber übereinstimmen.

Tokens

Access Tokens sind mit AES-256-GCM verschlüsselte Umschläge und keine blanken Backend-Zugangsdaten. Ein Umschlag ist an seine Zielgruppe gebunden und wird abgelehnt, wenn er manipuliert, gegen die falsche Ressource wiederverwendet oder nach Ablauf des enthaltenen Backend-Tokens vorgelegt wird. Ein Refresh-Umschlag lässt sich nicht dort verwenden, wo ein Access-Umschlag verlangt wird. Ihr Hi-Doctor-Passwort wird bei der Anmeldung gegen ein Token getauscht und vom Connector nie gespeichert, nie protokolliert und nie an die verbindende Anwendung weitergegeben.

Berechtigungen

Die Tools sind gruppiert, und jede Gruppe verlangt ihren eigenen Scope — Profil, Beratungen, Nachrichten, Fragebögen, Fortschritt, Zahlung. Ein Tool, dessen Scope Sie nicht freigegeben haben, wird nicht bloß abgelehnt, es wird gar nicht angeboten: Es erscheint nie in der Tool-Liste des Clients. Rollen summieren sich nicht. Ein Konto hat genau einen Tool-Katalog, ein Patiententoken kann also nie ein ärztliches oder Back-Office-Tool erreichen. Die vollständige Liste steht unter Berechtigungen.

Was der Server nicht preisgibt

  • 5xx-Antworten des Backends werden vollständig verworfen. Ein Fehler weiter oben liefert eine stabile, allgemeine Fehlermeldung statt eines internen Stacktrace.
  • 4xx-Antworten werden auf eine Positivliste strukturierter Felder gefiltert, sodass ein Fehler verwertbar sein kann, ohne Patientendaten über das Tool-Ergebnis zurückzuspiegeln.
  • Pfadargumente können den konfigurierten API-Host und dessen Versionspräfix nicht verlassen.
  • Die Ratenbegrenzung hängt am Token, nicht an einem Header, den ein Aufrufer umschreiben könnte, um ein frisches Kontingent zu bekommen.

Zahlung

Der Connector verarbeitet nie Kartendaten. hidoctor_checkout_create gibt einen Link zur von Stripe gehosteten Kasse zurück, und Änderungen an Karte, Plan und Rechnungsadresse geschehen im Stripe-Abrechnungsportal. Es gibt kein Tool, das eine Kartennummer entgegennimmt, und jeder Assistent, der Sie danach fragt, spricht nicht mit Hi-Doctor.

Medizinische Grenzen

Kein Token, welcher Art auch immer, kann eine Beratung freigeben, ein Rezept ausstellen oder ändern oder eine Dosis ändern. Diese Aktionen stellt der MCP-Server überhaupt nicht bereit — sie sind nicht hinter einem Scope verborgen, sondern schlicht nicht vorhanden. Die medizinische Eignung setzt das Hi-Doctor-Backend beim Absenden eines Fragebogens durch. Ein Assistent kann niemanden vorab freigeben, und ein erneutes Absenden mit anderen Antworten umgeht die Prüfung nicht.

Ein Problem melden

Schreiben Sie mit den Einzelheiten an hello@hi-doctor.ai. Wenn Sie vermuten, dass Patientendaten offengelegt sind, schreiben Sie das in die Betreffzeile, damit es zuerst bearbeitet wird.