DoctorVerify — ein MCP-Server zur Verifizierung indischer Ärzte

Überprüft, ob jemand, der behauptet, ein registrierter indischer Arzt zu sein, tatsächlich einer ist – mithilfe von Live-Daten der National Medical Commission – und bleibt dabei ehrlich darüber, was genau offiziell ist, was undokumentiert ist und was ein manueller Fallback ist. Lies den Abschnitt „So funktioniert die Überprüfung hier tatsächlich“, bevor du das Tool benutzt; er ist der wichtigste Teil dieser README.

Inhalt

Related MCP server: Eka MCP Server

So funktioniert die Überprüfung hier tatsächlich

Das offizielle Register bietet Dritten keine API – das muss es aber auch nicht, damit das hier funktioniert. Die maßgebliche Quelle ist das Indian Medical Register (IMR) der National Medical Commission, das der Öffentlichkeit unter nmc.org.in durchsuchbar ist. Die eigene Suchseite des Registers ruft einen öffentlichen, nicht authentifiziertt JSON-Endpunkt (nmc.org.in/MCIRest/open/...) direkt aus JavaScript im Browser auf, um Ergebnisse darzustellen – das wurde entdeckt, indem man das Skript dieser Seite gelesen hat, nicht durch Raten. search_doctor_registration, get_doctor_profile und check_blacklist rufen denselben Endpunkt auf und liefern daher echte IMR-Daten: Registrierung, Qualifikation, Universität und den aktuellen Suspensionsstatus.

Eine frühere Version dieser README behauptete, die robots.txt von nmc.org.in verbiete automatisierten Zugriff. Das wurde geprüft und stellte sich als falsch heraus: Die Datei unter diesem Pfad ist überhaupt keine robots.txt im Standardformat – sie ist ein falsch konfigurierter Apache-Ausschnitt, der eine kurze Liste namentlich genannter SEO-Crawler (Ahrefs, Majestic, Semrush, ...) per User-Agent blockiert, ohne eine allgemeine Disallow-Direktive. Auch die Nutzungsbedingungen verbieten das nicht. Das ist der Grund, warum Live-Verifizierung hier inzwischen vertretbar ist, wo sie es vorher nicht war.

Die ehrliche Einschränkung: Dieser Endpunkt ist undok einmal by NMC undokumentiert und nicht unterstützt. Er kann seine Form ändern, ein Rate-Limit bekommen oder ohne Ankündigung verschwinden – dahinter stehen keine SLA, keine Versionierung und kein Supportvertrag. Behandle ihn als reinen Lese-Datenverkehr mit einzelnen Abfragen und nicht als Massen-Pipeline (diese Tools begrenzen die Ergebniszahl und blättern nie automatisch Seiten um, bewusst). registration_lookup_guide bleibt genau deshalb im Toolset als Fallback, wenn der Live-Pfad kaputt ist oder ein Ergebnis falsch aussieht.

Eine echte Falle, die du kennen solltest: Bei der Recherche tauchte nmcn.org.in auf – ein Buchstabe entfernt vom echten nmc.org.in – und rankte bei Suchen nach „verify Indian doctor“,wobei es IMR-artige Inhalte zeigte, obwohl es nicht von der National Medical Commission betrieben wird. flag_lookalike_domain erkennt genau diese Kombination beim Namen und kennzeichnet alles andere Unbekannte als „ungeprüft“, statt es als sicher anzunehmen. Gib nmc.org.in immer sicherheit lieber selbst ein, als einem Link aus einem Krankenhaus, von einem Agent term oder einer Anzeige zu folgen – und denke daran: Ein scheinbar Live-Ergebnis kann trotzdem von einer Fake-Seite stammen.

Wenn du automatisierte Verifizierung im größeren Maßstab brauchst – etwa um viele Ärzte in eine Gesundheitstechnik-Plattform aufzunehmen, statt einen einzelnen von Hand zu prüfen – gibt es zwei weitere Wege, beide offiziell abgesegnet (anders als der Endpunkt oben) und beide aufwandiger als ein Wochenendprojekt:

1. Ayushmanbharat Digital Mission (ABDM), Healthcare Professional Registry (HPR). Das eigene digitale Identitätssystem der Regierung für Ärzte, mit echter, dokumentierter OAuth2-API und einer Sandbox unter sandbox.abdm.gov.in. Es ist dafür gebaut, Behandler im Rahmen einer akkreditierten Gesundheitsinternen Integration (Modul 1) zu registrieren und zu bestätigen – nicht anonyme Eabfragen. Das Onboarding ist ein echtes Integrationsprojekt: Client-ID/Secret, Zertifizierung und so weiter.

2. Kommerzielle KYC-/Verifizierungsanbieter (z. B. Surepass, IDfy). Mehrere Unternehmen verkaufen NMC-gestützte Arzt/Arztprüfung als bezahltes, unterstütztes API-Produkt. Das kann für den Produktionsbetrieb die pragmatischen Wahl sein, aber bewerte selbst die tatsächliche Datenquellen, Aktualität und Bedingungen jedes Anbieters – dieses Projekt empfiehlt keinen bestimmten.

Setup

Erfordert Python 3.10+ und uv.

./setup.sh

Das ist ein echtes installierbares Paket (src/doctor_verify_mcp/, pyproject.toml), nicht nur ein loses Skript. ./setup.sh führt uv sync aus, was .venv erzeugt (über .python-version auf Python 3.10 gepinnt) und das Paket samt seiner dev-Abhängigkeitsgruppe (pytest) im Editor-Modus installiert. Ohne uv als Fallback niemand python3 -m venv .venv && source .venv/bin/activate && pip install -e '.[dev]' (einen [dependency-groups]-zu-[project.optional-dependencies]-Spiegel hinzufder, falls deine Pip-Version noch keine Dependency-Gruppen versteht).

Ausführen

uv run mcp dev src/doctor_verify_mcp/server.py

Öffne die Inspector-URL, die das Kommando ausgibt. Probiere dort search_doctor_registration nur mit einem Namen und schränke dann mit Registriernrung und/oder state_council ein. Nimm eine doctor_id aus den Ergebn und übergeb sie an get_doctor_profile. Rufe check_blacklist ohne Argumente auf, um die komplette aktuelle Liste zu sehen. Rufe flag_lookalike_domain mit nmcn.org.in und mit nmc.org.in auf und vergleiche. Schau dir die Ressource doctor-verification://official-sources an, um das Gesamtbild an einem Ort zu haben.

Sobald das Paket installiert ist (editable oder über ein gebautes Wheel), steht es mit eigener Konsolen-Skript bereit, das den Server direkt über stdio ausführt (ohne Inspector, zum Einbinden in einen echten Host): uv run doctor-verify-mcp.

Builden

uv build

Erzeugt dist/doctor_verify_mcp-<version>-py3-none-any.whl und ein passendes .tar.gz-sdist, installierbar überall mitBeast pip install dist/doctor_verify_mcp-*.whl.

Testen

uv run pytest

Die Tests für die drei Live-Tools mocken die HTTP-Schicht (doctor_verify_mcp.server._http_client) mit echten Antwortstrukturen des NMC, die während der Entwicklung aufgezeichnet wurden, damit die Suite nicht bei jedem Lauf nmc.org.in aufruft.

Zusammen mit einem echten Host

Möchtest du eine echte Integration bauen (etwa dieses in einen Arzt-Erfassungs-/Onboarding-Ablauf verdrahten)? Dann wirf einen Blick auf INTEGRATION.md für die vollständige Tool-Referenz, einen empfohlenen Verifizierungsablauf, den Fehlerbehandlungsvertrag und bekannte Spezialitäten der Live-Endpunkte.

Gleiches Muster wie bei jedem lokalen MCP-Server: Ein Host läuft deinen Server als Kindprozess über stdio, also braucht jeder Host denselben Startbefehl mit absolutem Pfad. Sobald das Paket installiert ist, ist das Consolen-Skript doctor-verify-mcp das sauberste Startziel, statt Hosts direkt auf server.py zu verweisen.

Claude Desktop: uv run mcp install src/doctor_verify_mcp/server.py, danach die Anwendung vollständig beenden und neu öffnen.

Claude Code:

claude mcp add doctorverify -- uv run --with "mcp[cli]" mcp run /absolute/path/to/src/doctor_verify_mcp/server.py

Cursor (.cursor/mcp.json) und VS Code (.vscode/mcp.json) nutzen dasselbe command/args-Format – if du brauchst there. Beispiel JSON, schau in die README des vorherigen Projekts.

Erweitern

• Füge ein Tool hinzu, das die Form einer Registrierungsnummer validiert, sobald du das Format kennst, das dein State Medical Council tatsächlich verwendet. Die Form variiert von Bundesstelle zu Bundesstelle so stark, dass diese Projekt keine Vermeinung anbietet.

• Füge weitere Einträge zu KNOWN_LOOKALIKES a, sobald du auf sie triffst.

• Falls der MCIRest-Endpunkt jemals seine Form ändert oder automatisierten Zugruff blockiert, zeigen die Live-Tools bereits einen klaren Fehler, der auf registration_lookup_guide verweist, anstatt still zu scheitern – hör dort zuerst nach, bevor du ansetzt, es gäbe eine Ärzt:in nicht.

• Falls du den ABDM/HPR-Weg gehst, würde dir ein verify_hpr_id-Tool, das die echte, dokumentierte API aufruft (mit deinen eigenen Client-Zugangsdaten, niemals fest im Quellcode), eine unterstützte Alternative zu den heute undokumentiert nutzten in diesem Projekt geben.

• Füge eine Ressource pro State Medical Council hinzu, mit direkten Links zu zufalle, wenn das IMR kein Ergebnis anzeigt. Meld dich dann direkt über die Website des jeweiligen State Council nach dem den Fall zu prüfen.

Wait, there is a random bullet " *."? Let's clean final bullet list: should be no extra bullet. Need ensure only 4 bullets? Actually original has 5 bullets. Let's list:

1. Add a tool that shapes...

2. Add to knowns...

3. if endpoint changes...

4. if ABDM...

5. Add a resource per council...

So final should have 5 bullets, no extra "* ".

Better to write:

• Füge ein Tool hinzu...

• Füge weitere Einträge...

• Wenn der MCIRest-Endpunkt...

• Wenn du den ABDM/ABDM-HPR-Weg nimmst...

• Füge eine Ressource pro State Medical Council mit Direktlinks hinzu...

That's 5. The "fifth" is for cases...

OK.

Need ensure "Cursor" and "VS Code" mention .cursor/mcp.json? The source uses prototype backticks. We must keep code. The sentence "se the previous project's README for the exact JSON if you need a reminder." We can translate.

Potential issue: "Cursor (.cursor/mcp.json) and VS Code (.vscode/mcp.json) follow the same command/args shape — see the previous project's README for the exact JSON if you need a reminder." In our translation, I misspoke "that he global JSON" but we'll adjust.

Let's rephrase: "Und Cursor (.cursor/mcp.json) und VS Code (.vscode/mcp.json) nutzen dieselbe command/args-Form – finde ein genaues JSON in der README des vorherigen Projekts, falls noch einmal erinnert werden will."

Ok.

Need the final German not include "German" "P" etc.

Let's now produce final answer.

One more detail: In "Verifies that someone claiming to be a registrierter indischer Arzt actually is one" The phrase "Registrierter indischer Arzt" is fine.

The title: "DoctorVerify — ein MCP-Server zur Verifizierung indischer Ärzte" ( or "zur Überprüfung" is more natural than "Verifizierung". "Verifizierung" is technical. Use "Überprüfung". So "DoctorVerify — ein MCP-Server zur Überprüfung indischer Ärzte".

But body uses "overprüfen" many times. Fine.

"Überprüft" or "Verifiziert" as the first word. Use "Überprüft".

Now, in table "Resource" resource "landscape" translated "Gesamtlandschaft". Good.

Need maybe "Resource" in the table column "Primitive": We can translate "Resource" to "Ressource". "Prompt" stays "Prompt".

Let's final# DoctorVerify — ein MCP-Server zur Überprüfung indischer Ärzte

Überprüft, ob jemand, der behauptet, ein registrierter indischer Arzt zu sein, tatsächlich einer ist, anhand von Live-Daten der National Medical Commission — und bleibt dabei ehrlich darüber, was genau offiziell ist, was undokumentiert ist und was ein manueller Fallback ist. Lies den Abschnitt „So funktioniert die Überprüfung hier tatsächlich“, bevor du das Tool benutzt; er ist der wichtigste Teil dieser README.

Was es hier gibt

So funktioniert die Überprüfung hier tatsächlich

Das offizielle Register bietet Dritten keine öffentliche APIst – das muss es aber auch nicht, damit das hier funktioniert. Die maßgebliche Quelle ist das Indian Medical Register (IMR) der National Medical Commission, das ist für die Öffentlichkeit unter nmc.org.in durchsuchbar. Die eigene Suchseite ruft einen öffentlichen, nicht authentifizierten JSON-Endpunkt (nmc.org.in/MCIRest/open/...) direkt aus dem clientseitigen JavaScript auf, um Ergebnisse zu rendern – gefunden durch das Lesen des Skripts dieser Seite selbst, nicht durch Raten. search_doctor_registration, get_doctor_profile und check_blacklist rufen genau diesen Endpunkt auf und liefern daher echte IMR-Daten: Registrierung, Qualifikation, Universität und den aktuellen Suspendierungsstatus.

Eine frühere Version dieser README behauptete, die robots.txt von nmc.org.in verbiete automatisierten Zugriff. Das wurde geprüft und stimmt nicht: Die Datei unter dieser Stelle ist keine robots.txt.githubusercontent im Standardformat – es ist ein falsch konfigurierter Apache-Ausschnitt, der eine kurze Liste benannter SEO-Crawler (Ahrefs, Majestic, Semrush, ...) per User-Agent blockiert, ohne allgemeine Disallow-Direktive. Die Nutzungsbedingungen verbieten das ebenfalls nicht. Genau das hat es hier möglich gemacht, dass Live-Verifizierung sinnvoll ist, wo sie es vorher nicht war.

Die ehrliche Einschränkung: Dieser Endpunkt ist weiterundra von NMC undokumentiert und ununterstützt. Er kann seine Form ändern, Per Ratio begrenzt werden oder ohne Ankündigung verschwinden – dahinter stehen keine SLA, keine Versionierung, keine Supportvertrag. Behandle ihn als reinen Einzelabruf-Verkehr, nicht als Pipeline (diese Tools begrenzen die Ergebnisanzahl und schalten nie automatisch weiter, absichtlich). registration_lookup_guide ist deshalb bewusst im Tool-Tool enthalten: als Notfalllösung, wenn der Live-Pfad bricht oder ein Ergebnis falsch aussieht.

Eine echte Falle, die du kennen solltest: Während die Recherche dazu nmcn.org.in auftauchte – ein Buchstaben angrenzend von der echten nmc.org.in – und bei Suchen nach „verify Indian doctor„ rankte, anzeigen IMR-artige Inhalte, obwohl es nicht von der National Medical Commission betrieben wird. flag_lookalike_domain erkennt das Erkennungsmerkmal direkt und überprüft alles andere Unbekannte als „ungeprüft“, statt es als sicher anzunst. Bevorzuge also immer, nmc.org.in selbst einzutippen, statt einem Link von einem Krankenhaus, Agent oder Anzeige zu folgen – und erinnere: Ein scheinbares Live Ergebnis kann immer noch von einer Fake-Seite stammen.

Wenn du automatisierte Überprüfung in großem Maßstab brauchst – etwa das Einpflegen vieler Ärzte in eine Health-Tech-Plattform, statt jemanden von Hand zu prüfen – gibt es zwei weitere, offiziell abgesegnete wie beides (im Unterschied zu dem obigen Endpunkt), und beide mehr Arbeit als ein Wochenendprojekt:

1. Ayushmant Bharat Digital Mission (ABDM), Healthcare Professional Registry (HPR). Das eigene digitale Identitätssystem der Regierung für die Ärzte, mit einer echten, dokumentierten OAuth2-API und einer Sandbox unter sandbox.abdm.gov.in. Es kann Güter at für die Registrierung und Bestätigung von Leistungen in einer akkreditierten Gesundheitsplattform (das M1-Modul), nicht für anonyme Einzelabfragen. Onboarding ist ein echtes Integrationsprojekt – Client-ID/Secret, Zertifizierung, der ganze Band.

2. Kommerzielle KYC-/Verifizierungsanbieter (z. B. Surepass, IDfy). Mehrere Unternehmen verkaufen NMC-gestützte Arztverifizierung als bezahltes, unterstütztes API-Produkt. Das kann die sinnvolle Wahl für den Produktionseinsatz sein, wurde aber überlegen, dass du den tatsächlichen Stand, die Aktualität und die Konditionen jedes Anbieters selbst bewertest – dieses Projekt empfiehlt keinem bestimmten.

Setup

Erfordert Python 3.10+ und beim uv.

./setup.sh

Das ist ein ordentliches installierbares Paket (src/doctor_verify_mcp/, pyproject.toml), nicht nur ein loses Skript. ./setup.sh führt uv sync aus, das .venv (ge nau auf Version 3.10 per .python-version) erzeugt, und installiert das Paket zusammen mit seinem dev-Abhängigkeitsgruppe (pytest) im Editierbaren Modus. Ohne uv verwende den Fallback python3 -m venv .venv && source .venv/bin/activate && pip install -e '.[dev]' (und ergänze einen [dependency-groups]-zu-[project.optional-dependencies]-Spiegel, wenn deine Pip-Version dependency groups noch nicht kennt).

Ausführen

uv run mcp dev src/doctor_verify_mcp/server.py

Öffne die Inspector-URL, es ausgibt. Versuch search_doctor_registration mit nur einem Namen, und grenze das dann mit eine Registrierungsnummer oder state_council weiter ab. Eine doctor_id aus den Ergebnis über nimm und übergib es an get_doctor_profile. Probiere check_blacklist ohne Argumente aus, um die aktuelle Listen komplett zu sehen. Probiere flag_lookalike_domain mit nmcn.org.in und mit nmc.org.in aus und vergleiche. Siehe die Ressource doctor-verification://official-sources für den Gesamtüberblick an einer Stelle.

Sobald installiert (either editabel- oder in einen built wheel), bietet das Paket auch ein Konsolen-Skript, das den Server direkt über stdio startet (ohne Inspector, zum Einklinken in ein echtes Host): uv run doctor-verify-mcp.

Erstellen

uv build

Erzeugt dist/doctor_verify_mcp-<version>-py3-none-any.whl sowie das passende .tar.gz-Quellarchiv, installierbar überall mit pip install dist/doctor_verify_mcp-*.whl.

Testen

uv run pytest

Die Tests für die drei Live-Tools mocken die HTTP-Schicht (doctor_verify_mcp.server._http_client) mit den echten Antwortstrukturen des NMC, die während der Entwicklung erfasst wurden, sodass die Testsuite nicht bei jedem Lauf nmc.org.in ausrufen.

An einen echten Host anbinden

Du baust Auftrag eine echte Integration (z. B. in ein Arzt-Registrierungs-/Onboarding-System)? Dann San geschaut INTEGRATION.md – mit vollständiger Toolkitrefer, empfohlenem Prüfablauf, Fehlerbehandlungsvertrag und bekannten witrde des Live-Endpunkts.

Gleiche Muster wie bei jedem manuellen MCP-Server: Ein Host führt deinen Server als Kindprozess über stdio aus. Es braucht bei jedem Host dieselbe Startbefehl mit absolutem Pfad. Sobald das Paket installiert ist, ist doctor-verify-mcp als Konsolen-Skript die sauberstees Startziel als die Hosts direkt auf server.py zeigen.

Claude Desktop: uv run mcp install src/doctor_verify_mcp/server.py, danach die Anwendung vollständig beenden und neu öffnen.

Claude Code:

claude mcp add doctorverify -- uv run --with "mcp[cli]" mcp run /absolute/path/to/src/doctor_verify_mcp/server.py

Cursor (.cursor/mcp.json) und VS Code (.vscode/mcp.json) verwenden dieselbe command/args-Sonderform – siehe die README des vorherigen Projekts für das passende IJSON, falls du das noch mal wissen willst.

Erweitern

• Füge ein Tool hinzu, das die Form einer Registrierungsnummer validiert, sobald du das Format kennst, das dein State Medical Council wirklich verwendet – die State Councils unterscheiden sich stark genug, dass das Projekt hier keinen Rateversuch unternimmt.

• Füge weitere Einträge zu KNOWN_LOOKALIKES hinzu, wann und wie du sie findest.

• Sollte der MCIRest-Endpoint seine Form ändern oder automatisierten Datenverkehr spenden, geben die live-Tools bereits eine klar Fehlermeldung mit Verweis auf registration_lookup_guide zurück, statt still zu scheitern – schaue bittere zuerst dort, bevor du annimmst, ein Arzt existiere nicht.

• Wenn du über den ABDM/HPR-Wegführung gehst, würde dir ein verify_hpr_id-Tool, die echte, dokumentierte API aufruft (mit deinen eigenen Client-Anmeldedaten, nie hardcoded im Quellcode), eine unterstützte Alternative zu dem he le undokumentierten Endpunkt geben.

• Füge pro einzelnen State Medical Council eine Ressource mit Direktlinks hinzu, für die Fälle, in denen das IMR kein Ergebnis zeigt und im Nur das Betroffene council direkt überprüft werden sollte.