Skip to main content
The Hi-Doctor MCP server is an OAuth 2.1 resource server. It holds no patient database of its own — every tool call is forwarded to the Hi-Doctor API as you, with your own account’s permissions.

Signing in

Connecting runs a standard OAuth 2.1 authorization-code flow with PKCE (S256). Your AI client never sees your password: you enter it on a Hi-Doctor page, and the client receives a short-lived authorization code that it exchanges for a token. The server publishes the discovery documents an MCP client expects, so no manual configuration is needed: Authorization codes are single-use and short-lived. Redeeming one twice fails — a replayed code is rejected, not honoured.

Where a token can be sent back

Every registered client is issued a signed client_id that binds the exact redirect URI it registered with. At authorization time the requested redirect_uri must match that binding exactly.
This is the defence against authorization-code interception: an attacker who knows your client_id still cannot ask for the code to be delivered to their own server, because the URI is sealed into the identifier and verified before the sign-in form is ever shown.
Loopback redirects follow RFC 8252 §7.3 — the port may vary, as desktop clients require, but the rest of the URI must match.

Tokens

Access tokens are AES-256-GCM encrypted envelopes, not bare backend credentials. An envelope is bound to its audience and is rejected if it is tampered with, replayed against the wrong resource, or presented after the backend token it wraps has expired. A refresh envelope cannot be used where an access envelope is required. Your Hi-Doctor password is exchanged for a token at sign-in and is never stored by the connector, never written to a log, and never passed to the connecting application.

Permissions

Tools are grouped, and each group requires its own scope — profile, consultations, messages, questionnaires, progress, payment. A tool whose scope you did not grant is not merely refused, it is not offered: it never appears in the client’s tool list. Roles do not stack. An account gets exactly one tool catalogue, so a patient token can never reach a clinician or back-office tool. See Permissions for the full grant list.

What the server refuses to leak

  • Backend 5xx bodies are discarded entirely. An upstream error returns a stable, generic failure rather than an internal trace.
  • 4xx responses are filtered to an allowlist of structured fields, so an error can be actionable without echoing patient data back through the tool result.
  • Path arguments cannot escape the configured API host or its version prefix.
  • Rate limiting is keyed on the token, not on a header that a caller could reshape to get a fresh bucket.

Payment

The connector never handles card details. hidoctor_checkout_create returns a link to Stripe’s own hosted checkout, and card, plan and billing-address changes happen in the Stripe billing portal. There is no tool that accepts a card number, and any assistant asking you for one is not talking to Hi-Doctor.

Clinical limits

No token, of any kind, can approve a consultation, issue or alter a prescription, or change a dose. Those actions are not exposed by the MCP server at all — not gated behind a scope, simply absent. Medical eligibility is enforced by the Hi-Doctor backend when a questionnaire is submitted. An assistant cannot pre-approve a patient, and re-submitting with different answers does not bypass the check.

Reporting a problem

Email hello@hi-doctor.ai with the details. If you believe patient data is exposed, say so in the subject line so it is triaged first.