使用国家医学委员会（National Medical Commission）的实时数据，核验声称是印度注册医生的人是否确实为注册医生——同时如实说明哪些是官方数据、哪些没有文档记录、哪些需要人工回退。使用前请先阅读"这里的核验实际是如何工作的"；这是本 README 中最重要的部分。
原语 | 名称 | 功能 |
工具 |
| 按姓名、注册号、邦医学委员会和/或年份实时搜索印度医学名册 |
工具 |
| 获取搜索结果的实时完整档案（资格、大学、附加资格） |
工具 |
| 实时查询 NMC 当前被暂停/除名医生名单 |
工具 |
| 人工回退：当实时查询失败或匹配结果不明确时，提供精确的官方搜索步骤 |
工具 |
| 将链接与官方域名及已知仿冒者进行比对 |
资源 |
| 全貌——个人查询、较新的注册系统，以及两条获准的大规模自动化核验途径 |
提示词 |
| "正确核验医生"模板，依次串联实时工具、黑名单查询和资格匹配 |
Related MCP server: Doktor MCP Server
官方注册系统不向第三方提供 API——但要让这一切运转起来，其实并不需要。权威数据源是国家医学委员会的印度医学名册（IMR），公众可通过 nmc.org.in 查询。其搜索页面通过客户端 JavaScript 直接调用一个公开、无需认证的 JSON 端点（nmc.org.in/MCIRest/open/...）来渲染结果——这是通过阅读该页面自身的脚本来发现的，而非猜测。search_doctor_registration、get_doctor_profile 和 check_blacklist 调用的正是这个端点，因此它们返回的是真实的 IMR 数据：注册信息、资格、大学和当前停业状态。
本 README 的早期版本曾声称 nmc.org.in 的 robots.txt 禁止自动访问。经核查后发现这是错误的：该路径下的文件根本不是标准格式的 robots.txt——而是一个配置错误的 Apache 片段，按 User-Agent 屏蔽了一小部分具名 SEO 爬虫（Ahrefs、Majestic、Semrush 等），没有任何通用的 Disallow 指令。服务条款也并未禁止此类访问。正是这一点使得此处的实时核验变得合理，而此前并非如此。
诚实的提醒： 该端点仍然没有官方文档，也不受 NMC 支持。它可能随时改变格式、被限流或消失——背后没有任何 SLA、版本控制或支持合同。请将其视为只读、单次查询的流量，而非批量管道（这些工具刻意限制了结果数量，且从不自动翻页）。registration_lookup_guide 保留在工具集中，正是为了在实时路径失效或结果异常时作为回退方案。
一个值得了解的陷阱： 在调研过程中，nmcn.org.in——与真正的 nmc.org.in 仅一字之差——出现在"核验印度医生"搜索结果的排名中，显示 IMR 风格的搜索内容，尽管它并非由国家医学委员会运营。flag_lookalike_domain 能按名称识别出该域名，并将任何不熟悉的域名标记为"未审核"而非默认为安全。始终建议自己手动输入 nmc.org.in，而不是点击医院、中介或广告中的链接——并且请记住，看起来实时的结果也可能来自虚假网站。
如果你需要大规模自动化核验——例如为健康科技平台批量接入医生，而非逐个手动核验——还有两条途径，两者都是官方认可的（不同于上述端点），且都比周末项目要复杂得多：
Ayushman Bharat 数字使命（ABDM），医疗专业人员注册系统（HPR）。 政府官方的医生数字身份系统，提供真正的、有文档记录的 OAuth2 API 和位于 sandbox.abdm.gov.in 的沙箱环境。它面向的是作为认证健康系统集成（M1 模块）一部分的从业者注册和确认，而非匿名单次查询，因此接入是一个真正的集成项目——客户端 ID/密钥、认证、一应俱全。
商业 KYC/核验供应商（如 Surepass、IDfy）。多家公司以付费、受支持的 API 产品形式转售 NMC 支持的医生核验服务。对于生产环境来说，这可能是务实之选，但请自行评估每家供应商的实际数据来源、时效性和条款——本项目不推荐任何特定供应商。
需要 Python 3.10+ 和 uv。
./setup.sh这是一个标准的可安装包（src/doctor_verify_mcp/、pyproject.toml），而非松散的脚本。./setup.sh 运行 uv sync，它会创建 .venv（通过 .python-version 固定为 Python 3.10）并以可编辑模式安装该包及其 dev 依赖组（pytest）。如果没有 uv，请使用
python3 -m venv .venv && source .venv/bin/activate && pip install -e '.[dev]'
（如果你的 pip 版本尚不支持依赖组，请添加一个从 [dependency-groups] 到 [project.optional-dependencies] 的镜像）。
uv run mcp dev src/doctor_verify_mcp/server.py打开它打印的 Inspector URL。尝试仅用姓名调用 search_doctor_registration，然后用注册号或 state_council 缩小范围。从结果中取一个 doctor_id 传给 get_doctor_profile。尝试不带参数调用 check_blacklist 查看当前完整名单。分别用 nmcn.org.in 和 nmc.org.in 尝试 flag_lookalike_domain 并比较结果。查看 doctor-verification://official-sources 资源以获取完整信息。
安装后（可编辑模式或从构建的 wheel 安装），该包还提供一个控制台脚本，可通过 stdio 直接运行服务器（无需 Inspector，用于接入真实主机）：uv run doctor-verify-mcp。
uv build生成 dist/doctor_verify_mcp-<version>-py3-none-any.whl 和对应的 .tar.gz 源码包，可通过 pip install dist/doctor_verify_mcp-*.whl 在任何地方安装。
uv run pytest三个实时工具的测试使用开发期间捕获的 NMC 真实响应格式模拟了 HTTP 层（doctor_verify_mcp.server._http_client），因此测试套件不会在每次运行时都访问 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 结构——如需提醒，请参阅上一个项目的 README 获取确切的 JSON。
一旦你了解了所在邦委员会实际使用的注册号格式，添加一个校验注册号格式的工具——各邦差异很大，因此本项目不做猜测。
遇到新的仿冒域名时，向 KNOWN_LOOKALIKES 添加更多条目。
如果 MCIRest 端点将来改变格式或开始阻止自动化流量，实时工具会抛出明确错误并指向 registration_lookup_guide，而不是静默失败——在断定医生不存在之前，请先检查那里。
如果走 ABDM/HPR 路线，一个调用真实、有文档记录的 API（使用你自己的客户端凭据，切勿硬编码在源码中）的 verify_hpr_id 工具，将为你提供一个受支持的替代方案，替代本项目目前使用的无文档端点。
为每个邦医学委员会添加带直接链接的资源，用于 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.
