DoctorVerify — un servidor MCP para verificar médicos indios

Verifica que alguien que afirma ser un médico indio registrado realmente lo sea, mediante datos en vivo de la National Medical Commission —manteniendo la sinceridad sobre exactamente qué es oficial, qué no está documentado y qué es un respaldo manual. Lee «Cómo funciona realmente la verificación aquí» antes de usarlo; es la parte más importante de este README.

Qué hay aquí

Related MCP server: Eka MCP Server

Cómo funciona realmente la verificación aquí

El registro oficial no publica una API para terceros — pero no necesita hacerlo para que esto funcione. La fuente autoridad es el Indian Medical Register (IMR) de la National Medical Commission, consultable por el público en nmc.org.in. La propia página de búsqueda llama directamente a un endpoint JSON público y sin autenticación (nmc.org.in/MCIRest/open/...) desde el JavaScript del lado del servidor para mostrar los resultados; algo descubierto al leer el script de esa página, no mediante adivinanzas. search_doctor_registration, get_doctor_profile y check_blacklist llaman al mismo endpoint, por lo que devuelven datos reales del IMR: registro, titulación, universidad y estado de suspensión actual.

Una versión anterior de este README afirmaba que robots.txt de nmc.org.in deshabilitaba el acceso automatizado. Se comprobó y resultó incorrecto: el archivo en esa ruta no es un robots.txt con formato estándar —es un fragmento de Apache mal configurado que bloquea una lista breve de rastreadores de SEO concretos (Ahrefs, Majestic, Semrush, ...) por User-Agent, sin directiva general Disallow. Los Términos de Uso tampoco lo prohíben. Eso es lo que hizo que la verificación en vivo fuera razonable aquí, cuando antes no lo era.

La advertencia honesta: este endpoint sigue sin estar documentado ni recibir soporte oficial del NMC. Podría cambiar de forma, sufrir límites de tasa o desaparecer sin previo aviso; no hay SLA, versionado ni contrato de soporte detrás. Trátalo como tráfico de solo lectura, de una sola consulta, no como una tubería masiva (las herramientas limitan el número de resultados y nunca pagan a propósito). registration_lookup_guide se mantiene en el set de herramientas específicamente como respaldo cuando falla la ruta en vivo o un resultado parece incorrecto.

Una trampa real que vale la pena conocer: durante mi investigación, nmcn.org.in —a solo una letra del real nmc.org.in— aparecía posicionado para búsquedas de "verificar médico indio", mostrando contenido tipo IMR aunque no es operado por la National Medical Commission. flag_lookalike_domain detecta ese caso por nombre y marca cualquier otra cosa no conocida como no revisada, en lugar de asumir que es segura. Siempre prefiere escribir nmc.org.in antes de hacer clic en un enlace de un hospital, agente o anuncio; y recuerda que un resultado que parece en vivo también puede venir de un sitio falso.

Si necesitas verificación automatizada a escala —por ejemplo, integrar muchos médicos en una plataforma de salud, no comprobar uno a mano— hay dos vías más, oficialmente admitidas (a diferencia del endpoint anterior), y ambas más pesadas que un proyecto de fin de semana:

1. Ayushman Bharat Digital Mission (ABDM), Healthcare Professional Registry (HPR). El propio sistema de identidad digital del gobierno para médicos, con una API OAuth2 real y documentada, y un sandbox en sandbox.abdm.gov.in. Está diseñado para registrar y confirmar médicos como parte de una integración acreditada en sistemas de salud (el módulo M1), no para consultas anónimas de una vez, por lo que el onboarding es un proyecto de integración real: cliente/secret, certificación, todo.

2. Vendedores de KYC/verificación comerciales (por ejemplo Surepass, IDfy). Varias empresas reempaquetan la verificación de médicos respaldada por NMC como un producto de API pagado y con soporte. Puede ser la opción pragmática para producción, pero debes evaluar la fuente de datos real, la actualización y los términos de cada proveedor tú mismo: este proyecto no respalda ninguno.

Configurar

Requiere Python 3.10+ y uv.

./setup.sh

Este es un paquete instalable de verdad (src/doctor_verify_mcp/, pyproject.toml), no un script suelto. ./setup.sh ejecuta uv sync, que crea .venvs (fijado a Python 3.10 mediante .python-version) e instala el paquete, además de su dependencia dev (pytest) en modo editable. Si no tienes uv usa esta alternativa: python3 -m venv .venv && source .venv/bin/activate && pip install -e '.[dev]' (añade un espejo desde [dependency-groups] a [project.optional-dependencies] demasiado). Si tu versión de .pip aún no entiende los grupos de dependencias.

Ejecutarlo

uv run mcp dev src/doctor_verify_mcp/server.py

Abre la URL del Inspector que imprime. Prueba search_doctor_registration con solo un nombre, luego céntralo con un número de registro o state_council. Toma un doctor_id de los resultados y pásalo a get_doctor_profile. Prueba check_blacklist con sin argumentos para ver la lista completa actual. Prueba flag_lookalike_domain con nmc.org.in y con nmc.org.in y compara. Comprueba el recurso doctor-verification://official-sources para ver el panorama completo en un solo.

Una vez instalado (en modo editable o desde una wheel compilada), el paquete también expone un script de consola que ejecuta el servidor directamente sobre stdio (sin Inspector, para conectarlo a un host real): uv run doctor-verify-mcp.

Compilarlo

uv build

Produce dist/doctor_verify_mcp-<versión>-py3-none-any.whl y un sdist .tar.gz correspondiente, instalables en cualquier lugar con pip install dist/doctor_verify_mcp-*.whl.

Probarlo

uv run pytest

Las pruebas de las tres herramientas en vivo simulan la capa HTTP (doctor_verify_mcp.server._http_client) con las formas de respuesta reales del NMC capturas durante el desarrollo, para que la suite no a nc.org... etc.

Conectarlo a un host real

¿Construyendo una integración real (por ejemplo, dándole esto a un flujo de registro/onboarding de médicos)? Consulta INTEGRATION.md para recibir la referencia completa de herramientas, un flujo de verificación recomendado, el contrato de gestión de errores y las peculiaridades conocidas del endpoint.

Mismo esquema que cualquier servidor MCP local: un host ejecutar tu servidor como proceso hijo por stdio, por lo que cada host necesita el mismo comando de inicio con una ruta absoluta. Una vez el paquete instalado, nuestra jugada más limpia script de consola doctor-doctor en lugar apuntando directamente a server.py.

Claude Desktop: uv run mcp install src/doctor_verify_mcp/server.py, luego cierra y vuelve a abrir la aplicación.

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) y VS Code (.vscode/mcp.json) siguen la misma forma de command/args —mira el README del proyecto anterior si necesitas recordatorio del JSON exacto.

Extender esto

• Añade una herramienta que valide la forma de un número de registro una vez sepas el formato que usa tu state council, varían lo suficiente entre estados como para este proyecto no debe adivinar uno.

• Añade más entradas a KNOWN_LOOKALIKES según se vayan encontrando.

• Si endpoint MCIRest cambia de forma o empieza a bloquear tráfico automatizado, las herramientas en vivo actuarán adecuadamente lanzando un error claro que apuntan a registration_lookup_guide en lugar no fallar en silicio: revisa allí primero antes de asumir que no existe un médico no existe.

• Si optas por la ruta ABDM/HPR, una herramienta verify_hpr_id que consulte la API real y documentada (con tus propias credenciales de cliente, nunca absurdas en el código) te daría una alternativa con soporte al endpoint no documentado que usa este proyecto.

• Añade un recurso por cada State Medical Council con enlaces directos, para casos en que el IMR no aparezca ningún resultado y el respaldo sea comprobar directamente el sitio del council estatal.