Ü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.
Primitive | Name | Funktion |
Tool |
| Live-Suche im Indian Medical Register nach Name, Registrierungsnummer, State Medical Council und/oder Jahr |
Tool |
| Live-Vollprofil (Qualifikation, Universität, Zusatzqualifikationen) für einen Treffer aus einer Suche |
Tool |
| Live-Prüfung der aktuellen Liste des NMC mit suspendierten/gestrichenen Ärzten |
Tool |
| Manueller Fallback: die exakten offiziellen Suchschritte, wenn die Live-Suche fehlschlägt oder ein Treffer unklar ist |
Tool |
| Prüft einen Link gegen die offizielle Domain und bekannte Nachahmer |
Resource |
| Die Gesamtlandschaft – Einzelabfrage, das neuere Register und die beiden offiziell gebilligten Wege für automatisierte Prüfungen im größeres Umfang |
Prompt |
| Eine Vorlage „Diesen Arzt richtig überprüfen“, die die Live-Tools, dann die Blacklist und anschließend den Qualifikationsabgleich verknüpft |
Related MCP server: Doktor MCP Server
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:
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.
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.
Erfordert Python 3.10+ und uv.
./setup.shDas 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).
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.
uv buildErzeugt 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.
uv run pytestDie 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.
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.pyCursor (.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.
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:
Add a tool that shapes...
Add to knowns...
if endpoint changes...
if ABDM...
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.
Primitive | Name | Funktion |
Tool |
| Live-Suche im Indian Medical Register nach Name, Registrierungsnummer, State Medical Council und/oder Jahr |
Tool |
| Live-Vollprofil (Qualifikation, Universität, Zusatzqualifikationen) für einen Treffer aus Sucheuchung |
Tool |
| Live-Prüfung der aktuellen Liste des NMC zu suspendierten/gestrichenen Ärzten |
Tool |
| Manueller Fallback: die exakten offiziellen Suchschritte, wenn die Live-Suche fehlschlägt oder ein Treffer mehrdeutig ist |
Tool |
| Prüft einen Link gegen die offizielle Domain und bekannte Nachahmer |
Resource |
| Die gesamte Landschaft, von Einzelabruf, das neuere Register und die beiden offiziell gebilligten Wege für automatisierte Prüfungen im größeren Umfang |
Prompt |
| Eine Vorlage „Diesen Arzt ordentlich überprüfen“, die die Live-Tools, dann die Blacklist und danach den Qualifikationsabgleich verknüpft |
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:
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.
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.
Erfordert Python 3.10+ und beim uv.
./setup.shDas 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).
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.
uv buildErzeugt 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.
uv run pytestDie 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.
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.pyCursor (.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.
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.
Check the live NMC list of suspended/struck-off doctors.
A doctor can have a completely genuine registration and still be
currently suspended -- search_doctor_registration alone won't show that,
this does. Provide a filter, or nothing to get the full current list
(nationally, this is normally only a few dozen entries).
| Name | Required | Description | Default |
|---|---|---|---|
| doctor_name | No | ||
| state_council | No | ||
| registration_number | No |
| Name | Required | Description |
|---|---|---|
| source | Yes | |
| entries | Yes | |
| is_listed | Yes | |
| query_note | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing side effects. The word 'check' implies a read-only operation, but it doesn't explicitly state that the tool makes no changes or that data is sourced live. It adds context on the nature of the data (suspended/struck-off) but stops short of explicit safety declarations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs with no fluff. The first sentence states the core purpose; the second adds differentiation and usage guidance. It is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return structure is covered. The description covers purpose, differentiation, and the optional filter behavior. It doesn't mention response size limits or failure handling, but these are minor given the simplicity and the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions already cover each parameter (doctor_name, state_council, registration_number) with brief fields. The tool description adds only the general note that filters are optional ('Provide a filter, or nothing'), which is helpful but doesn't elaborate on individual parameters. Schema coverage is listed as 0%, but the description provides some compensation via the optionality insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Check the live NMC list of suspended/struck-off doctors.' It also distinguishes the tool from a sibling, 'search_doctor_registration alone won't show that, this does,' making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use it: for checking suspension beyond registration, and mentions 'Provide a filter, or nothing to get the full current list.' It doesn't explicitly list exclusions or alternative tools, but the contrast with search_doctor_registration gives strong directional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a link is the official NMC domain or a known lookalike.
| Name | Required | Description | Default |
|---|---|---|---|
| url_or_domain | Yes |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| domain | Yes | |
| is_official | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does indicate a non-destructive classification action ('Check whether') rather than a mutation. However, it does not clarify whether the check is live, cached, or limited to a built-in list of known lookalikes, leaving the behavior only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancies. Every word contributes to communicating the tool's core purpose, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the description is nearly sufficient: an agent can infer the input and the classification task. It falls short of complete because it omits accepted input formats and any relationship to sibling tools such as check_blacklist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter url_or_domain has 0% schema description coverage, so the description must clarify the expected value. It only paraphrases it as 'link', and never states whether a bare domain, full URL with protocol, path, or subdomain is acceptable. This leaves real format ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Check whether') and a clear resource: the official NMC domain versus known lookalikes. This also distinguishes it from siblings such as search_doctor_registration and get_doctor_profile, which are about registration records rather than URL authenticity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is only implied; the description does not explain when to prefer this tool over a sibling such as check_blacklist, nor does it state when not to use it. There are no explicit scenarios or alternative routing cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full IMR profile for one specific match from search_doctor_registration.
Not a general search -- this is the live "View" detail for an
already-found doctor_id + registration_number pair, showing qualification,
college, university, and additional qualifications for a closer match
check. Deliberately excludes personal contact fields the underlying
record also contains (date of birth, phone, email, home address) --
those aren't needed to verify a registration is genuine, and returning
them would turn a verification lookup into a PII source.
| Name | Required | Description | Default |
|---|---|---|---|
| doctor_id | Yes | doctor_id from a search_doctor_registration match. | |
| registration_number | Yes | Registration number, if you have one. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| source | Yes | |
| college | Yes | |
| university | Yes | |
| parent_name | Yes | |
| qualification | Yes | |
| state_council | Yes | |
| blacklist_flag | Yes | |
| registration_date | Yes | |
| qualification_year | Yes | |
| registration_number | Yes | |
| additional_qualifications | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It transparently discloses that it deliberately excludes personal contact fields (phone, email, address) and explains the reason (to avoid turning a verification lookup into a PII source). This reveals important behavioral traits about the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized. It leads with the primary purpose, then provides essential context about usage and exclusions. No filler or redundant statements; every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool returns (qualification, college, university, additional qualifications), what it excludes (personal contact fields) and why, and when to use it. Since an output schema exists, the description need not detail return values. It is well-rounded and sufficient for an agent to decide usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters ('doctor_id from a search_doctor_registration match', 'registration_number, if you have one'). The tool description adds value by clarifying that these form a pair and are from an already-found match, reinforcing their mutual dependency, but this is a moderate addition beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool's action (Get the full IMR profile) and resource (one specific match from search_doctor_registration). It also explicitly distinguishes itself from a general search and mentions it's for an already-found pair, providing clear differentiation from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use the tool: for an already-found doctor_id + registration_number pair, to check a match more closely. It also contrasts with search_doctor_registration, indicating that this is not a general search, giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the correct, official manual steps to verify an Indian doctor's registration.
This is the fallback path: use search_doctor_registration and check_blacklist
for a real, live answer. Reach for this tool instead when those fail, look
wrong, or you'd rather double-check by hand -- it hands back exactly where
and how to search nmc.org.in yourself rather than an automated result.
| Name | Required | Description | Default |
|---|---|---|---|
| doctor_name | No | ||
| state_council | No | ||
| registration_number | No |
| Name | Required | Description |
|---|---|---|
| caution | Yes | |
| also_check | Yes | |
| search_url | Yes | |
| how_to_search | Yes | |
| fallback_navigation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It explains that this tool returns manual lookup instructions rather than an automated result, which is a meaningful disclosure of behavior. It could add more detail about how the optional inputs shape the returned steps, but the core behavior is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the primary purpose appears in the first sentence, and the fallback role and usage conditions appear immediately after. There is little wasted text and the structure supports quick agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description accurately scopes the tool, confirms it is not a live lookup, and names the relevant sibling tools. Since the parameters are optional and described in the schema, the description is complete enough for an agent to decide whether to call it, though a note on how each parameter influences the returned guide would raise it further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description itself does not add per-parameter guidance, but the input schema already describes all three optional parameters meaningfully. The parameter semantics is therefore adequate, but the description does not go beyond the schema to clarify edge cases or required formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: get the correct, official manual steps to verify an Indian doctor's registration on nmc.org.in. It also clearly differentiates itself from sibling live-lookup tools by calling itself the fallback path rather than an automated result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool versus alternatives: use search_doctor_registration and check_blacklist for real, live answers, and use this guide when those fail, look wrong, or when a manual double-check is preferred. This gives an agent actionable routing criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the live Indian Medical Register and return real matches.
Provide at least one of doctor_name or registration_number. This calls the
same public JSON endpoint nmc.org.in's own search page uses -- a real, live
lookup, not a guide. That endpoint is undocumented and unsupported by NMC,
so treat a request failure as "try registration_lookup_guide instead," not
as "the doctor doesn't exist."
Quirk worth knowing: NMC's backend 500s on any name value containing a
space (confirmed against the live endpoint -- a bug in their server, not
a validation rule of ours). A multi-word doctor_name is narrowed to its
most distinctive single word before being sent, and every match comes
back with a name_match flag so you can still tell whether the full name
actually lines up.
A registration number match alone doesn't mean the practitioner is
currently in good standing -- always also call check_blacklist.
| Name | Required | Description | Default |
|---|---|---|---|
| doctor_name | No | ||
| state_council | No | ||
| registration_number | No | ||
| year_of_registration | No |
| Name | Required | Description |
|---|---|---|
| source | Yes | |
| caution | Yes | |
| matches | Yes | |
| returned | Yes | |
| truncated | Yes | |
| query_note | Yes | |
| total_matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the endpoint is undocumented and unsupported, the backend 500s on names with spaces, the narrowing workaround, the name_match flag, and the caveat that a registration match alone doesn't imply good standing. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is multi-sentence but every sentence delivers essential information: purpose, usage constraint, failure mode, quirk, and follow-up action. It is well-structured, front-loaded with the core purpose, and avoids fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a live external dependency, undocumented endpoint, and known server bugs, the description covers all necessary operational details: error handling, input quirks, output interpretation (name_match flag), and cross-tool interactions (check_blacklist). Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for doctor_name (space handling and narrowing to a distinctive single word) and for registration_number (that a match doesn't imply good standing, requiring check_blacklist). It does not add extra meaning for state_council or year_of_registration, but the schema already provides basic descriptions. Since schema description coverage is 0%, the description compensates for the critical parameters but not all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search'), names the resource ('live Indian Medical Register'), and clarifies it returns 'real matches' rather than a guide. It explicitly contrasts with registration_lookup_guide by stating this is a live lookup, which differentiates it from that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires 'at least one of doctor_name or registration_number'. It provides clear guidance on failure handling ('treat a request failure as try registration_lookup_guide instead'), and mandates a complementary action ('always also call check_blacklist'). No ambiguity about when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_blacklistflag_lookalike_domainget_doctor_profileregistration_lookup_guidesearch_doctor_registrationScored across 5 tools
Each tool has a clearly distinct purpose: live register search, blacklist check, profile detail, manual fallback guide, and domain safety check. There is no real overlap, and the descriptions reinforce the boundaries between search, blacklist, and guide.
Most tool names follow a clear verb_noun pattern in snake_case: check_blacklist, flag_lookalike_domain, search_doctor_registration, get_doctor_profile. The one outlier is registration_lookup_guide, which is a noun phrase rather than a verb-led name, making the convention mostly but not fully consistent.
Five tools is a well-scoped set for a doctor verification server. Each tool addresses a distinct part of the verification workflow without redundancy or bloat.
The tool set covers the core verification lifecycle: live register search, blacklist screening, detailed profile retrieval, a manual fallback guide, and domain legitimacy checking. No obvious dead ends or missing operations for the stated purpose of verifying an Indian doctor's registration.
Real-time U.S. medical license verification across all 50 states + DC.
Search India's credential-verified therapist directory: read-only, public, checkable registrations.
Conselho Federal de Medicina: Cadastro, official-source lookup. Platform-hosted, pay per query with
Healthcare provider & compliance intel: NPPES lookup, OIG/SAM exclusion screening, FDA enforcement.
