Serveur MCP de la Clínica Aurora

L’agenda de la clinique publié comme serveur Model Context Protocol, pour que n’importe quel client MCP puisse prendre, déplacer et annuler des rendez-vous à travers lui. Les règles métier sont imposées sur le serveur, pas demandées dans un prompt.

Une requête initialize réussie et les capacités renvoyées par l’endpoint MCP d’Aurora

Qui a ce problème

Une intégration MCP doit séparer la proposition de modification de son écriture dans l’agenda. Le serveur lie chaque proposition à un jeton à usage unique, vérifie de nouveau les règles lors de l’écriture et enregistre la décision. Le client MCP ou le workflow qui l’entoure doit recueillir et imposer l’approbation humaine.

Mon rôle

Serveur MCP intégré à l’API de la clinique et à son moteur de politiques déterministe.

Comment l’essayer

Un navigateur ne peut pas ouvrir cet endpoint : il parle un protocole, il ne sert pas une page. Un GET renvoie 406 volontairement.
Envoyez un POST à https://aurora.pgdev.com.br/mcp avec Content-Type: application/json, Accept: application/json, text/event-stream et un appel initialize. Terminez l’initialisation avant d’appeler tools/list avec l’identifiant de session reçu.
Ou connectez un client MCP compatible à cette URL pour consulter les outils disponibles.

Les décisions que j’ai prises

Chaque écriture utilise deux appels. Le premier renvoie la proposition et un jeton à usage unique sans modifier l’agenda ; le second soumet cette opération avec le jeton et le serveur vérifie de nouveau la politique. Le jeton lie l’opération, mais ne prouve pas l’approbation d’une personne ; cette responsabilité revient au client MCP.
Les règles métier sont un moteur de politiques déterministe derrière les outils, pas des instructions dans le prompt système. Une écriture que la politique refuse revient sous forme de refus avec le code de la règle, et le modèle a pour consigne de lire ler_politica avant de promettre quoi que ce soit à qui que ce soit.
Les outils de lecture exposent la politique et les décisions enregistrées avec leur code de règle, afin que le client MCP puisse voir pourquoi une opération a été autorisée ou refusée.
C’est la même clinique que celle de la démo de chat, donc les deux peuvent être comparées côte à côte : l’une montre une personne qui parle à un agent, l’autre montre un autre agent qui se branche sur le même agenda protégé.
Version du protocole 2025-06-18, Streamable HTTP avec identifiants de session, qui tourne derrière Traefik comme service à part.

Les limites qui restent

Il ne sert que l’agenda de démonstration, le même que celui de la démo de chat, et cet agenda se réinitialise tout seul.