Проверяет, действительно ли человек, утверждающий, что он зарегистрированный индийский врач, является таковым, используя живые данные National Medical Commission — при этом честно указывая, что является официальным, что недокументированным, а что ручным запасным вариантом. Прочитайте раздел «Как на самом деле работает проверка здесь» перед использованием; это самая важная часть этого README.
Примитив | Имя | Что делает |
Инструмент |
| Живой поиск по Indian Medical Register по имени, регистрационному номеру, государственному медицинскому совету и/или году |
Инструмент |
| Живой полный профиль (квалификация, университет, дополнительные квалификации) для одного совпадения из поиска |
Инструмент |
| Живая проверка текущего списка отстранённых/исключённых врачей NMC |
Инструмент |
| Ручной запасной вариант: точные официальные шаги поиска на случай, если живой поиск не сработает или совпадение неоднозначно |
Инструмент |
| Проверяет ссылку на соответствие официальному домену и известным имитаторам |
Ресурс |
| Полная картина — индивидуальный поиск, более новый реестр и два официально разрешённых пути для автоматизированных проверок в масштабе |
Промпт |
| Шаблон «правильно проверьте этого врача», связывающий живые инструменты, затем чёрный список, затем сопоставление квалификации |
Related MCP server: Doktor MCP Server
Официальный реестр не публикует API для третьих сторон — но для работы этого ему и не нужно. Авторитетным источником является Indian Medical Register (IMR) от National Medical Commission, доступный для публичного поиска на nmc.org.in. Его собственная страница поиска вызывает публичный неаутентифицированный JSON-эндпоинт (nmc.org.in/MCIRest/open/...) напрямую из клиентского JavaScript для отображения результатов — это было обнаружено при чтении скрипта самой страницы, а не угадыванием. search_doctor_registration, get_doctor_profile и check_blacklist вызывают тот же эндпоинт, поэтому возвращают реальные данные IMR: регистрацию, квалификацию, университет и текущий статус отстранения.
Более ранняя версия этого README утверждала, что robots.txt на nmc.org.in запрещает автоматический доступ. Это было проверено и оказалось неверным: файл по этому пути вообще не является robots.txt в стандартном формате — это неправильно настроенный фрагмент Apache, блокирующий короткий список поименованных SEO-краулеров (Ahrefs, Majestic, Semrush, ...) по User-Agent, без общей директивы Disallow. Условия использования этого тоже не запрещают. Именно это изменение сделало живую проверку здесь оправданной, тогда как раньше она таковой не была.
Честное предостережение: этот эндпоинт по-прежнему не документирован и не поддерживается NMC. Он может изменить формат, получить ограничение частоты запросов или исчезнуть без уведомления — за ним нет SLA, версионирования или контракта на поддержку. Относитесь к нему как к трафику только для чтения с одиночными запросами, а не как к конвейеру массовой загрузки (эти инструменты намеренно ограничивают количество результатов и никогда не выполняют автоматическую пагинацию). registration_lookup_guide остаётся в наборе инструментов именно как запасной вариант на случай, если живой путь сломается или результат выглядит неверным.
Реальная ловушка, о которой стоит знать: во время исследования этого проекта nmcn.org.in — на одну букву отличающийся от настоящего nmc.org.in — всплывал в результатах поиска по запросам «проверить индийского врача», показывая контент в стиле IMR, хотя не управляется National Medical Commission. flag_lookalike_domain распознаёт его по имени и помечает всё остальное незнакомое как непроверенное, а не предполагает, что оно безопасно. Всегда предпочитайте самостоятельно вводить nmc.org.in, а не переходить по ссылке из больницы, от агента или из рекламы — и помните, что даже внешне «живой» результат может исходить с поддельного сайта.
Если вам нужна автоматизированная проверка в масштабе — например, онбординг множества врачей в health-tech платформу, а не ручная проверка одного — есть ещё два пути, оба официально одобренные (в отличие от эндпоинта выше), и оба более масштабные, чем проект на выходные:
Ayushman Bharat Digital Mission (ABDM), Healthcare Professional Registry (HPR). Собственная государственная система цифровой идентификации врачей с настоящим документированным OAuth2 API и песочницей на sandbox.abdm.gov.in. Она предназначена для регистрации и подтверждения практикующих врачей в рамках аккредитованной интеграции с системой здравоохранения (модуль M1), а не для анонимных разовых запросов, поэтому онбординг — это настоящий интеграционный проект: client ID/secret, сертификация и всё такое.
Коммерческие KYC/верификационные провайдеры (например, Surepass, IDfy). Несколько компаний перепродают проверку врачей на основе NMC как платный поддерживаемый API-продукт. Это может быть прагматичным выбором для продакшена, но оцените фактический источник данных, свежесть и условия каждого провайдера самостоятельно — этот проект не поддерживает какой-либо конкретный.
Требуются Python 3.10+ и uv.
./setup.shЭто полноценный устанавливаемый пакет (src/doctor_verify_mcp/, pyproject.toml), а не просто отдельный скрипт. ./setup.sh запускает uv sync, который создаёт .venv (закреплённый за Python 3.10 через .python-version) и устанавливает пакет вместе с его группой зависимостей dev (pytest) в режиме editable. Если у вас нет uv, используйте запасной вариант: python3 -m venv .venv && source .venv/bin/activate && pip install -e '.[dev]' (добавьте зеркальное соответствие [dependency-groups] → [project.optional-dependencies], если ваша версия pip ещё не понимает dependency groups).
uv run mcp dev src/doctor_verify_mcp/server.pyОткройте URL Inspector, который он выведет. Попробуйте search_doctor_registration только с именем, затем сузьте поиск с помощью регистрационного номера или state_council. Возьмите doctor_id из результатов и передайте его в get_doctor_profile. Попробуйте check_blacklist без аргументов, чтобы увидеть полный текущий список. Попробуйте flag_lookalike_domain с nmcn.org.in и с nmc.org.in и сравните. Проверьте ресурс doctor-verification://official-sources, чтобы увидеть полную картину в одном месте.
После установки (в режиме editable или из собранного wheel) пакет также предоставляет консольный скрипт, который запускает сервер напрямую через stdio (без Inspector, для подключения к реальному хосту): uv run doctor-verify-mcp.
uv buildСоздаёт dist/doctor_verify_mcp-<version>-py3-none-any.whl и соответствующий .tar.gz sdist, устанавливаемый где угодно с помощью pip install dist/doctor_verify_mcp-*.whl.
uv run pytestТесты для трёх живых инструментов мокают HTTP-слой (doctor_verify_mcp.server._http_client) с реальными формами ответов NMC, сохранёнными во время разработки, поэтому набор тестов не обращается к nmc.org.in при каждом запуске.
Создаёте реальную интеграцию (например, встраиваете это в поток регистрации/онбординга врачей)? Смотрите INTEGRATION.md — там полная справочная информация по инструментам, рекомендуемый процесс проверки, контракт обработки ошибок и известные особенности живого эндпоинта.
Та же схема, что и для любого локального MCP-сервера: хост запускает ваш сервер как дочерний процесс через stdio, поэтому каждому хосту нужна одна и та же команда запуска с абсолютным путём. После установки пакета консольный скрипт doctor-verify-mcp — самый чистый вариант запуска вместо того, чтобы указывать хостам на server.py напрямую.
Claude Desktop: выполните uv run mcp install src/doctor_verify_mcp/server.py, затем полностью закройте и снова откройте приложение.
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) и VS Code (.vscode/mcp.json) используют ту же структуру command/args — если нужно напоминание, точный JSON смотрите в README предыдущего проекта.
Добавьте инструмент, который проверяет форму регистрационного номера, когда вы узнаете формат, который фактически использует ваш государственный медицинский совет, — они достаточно различаются между штатами, поэтому этот проект не угадывает единый формат.
Добавляйте новые записи в KNOWN_LOOKALIKES по мере обнаружения.
Если эндпоинт MCIRest когда-либо изменит формат или начнёт блокировать автоматический трафик, живые инструменты уже сейчас выбрасывают понятную ошибку, отсылающую к registration_lookup_guide, а не молча падают, — сначала проверяйте там, прежде чем предполагать, что врача не существует.
Если вы пойдёте по пути ABDM/HPR, инструмент verify_hpr_id, вызывающий настоящий документированный API (с вашими собственными учётными данными клиента, никогда не захардкоженными в исходном коде), даст вам поддерживаемую альтернативу недокументированному эндпоинту, который этот проект использует сегодня.
Добавьте ресурс для каждого государственного медицинского совета с прямыми ссылками на случаи, когда IMR не показывает результат и запасной вариант — напрямую проверить сайт совета конкретного штата.
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.
