등록된 인도 의사라고 주장하는 사람이 실제로 그런 사람인지, 국립의료위원회(National Medical Commission)의 실시간 데이터로 검증합니다. 무엇이 공식적인지, 무엇이 문서화되지 않았는지, 무엇이 수동 대체 수단인지 정확히 솔직하게 밝히면서 말이죠. 사용하기 전에 "여기서 검증이 실제로 작동하는 방식"을 먼저 읽어 보세요. 이 README에서 가장 중요한 부분입니다.
유형 | 이름 | 설명 |
도구 |
| 이름, 등록 번호, 주 의료위원회(State Medical Council) 및/또는 연도로 인도 의사 등록부(Indian Medical Register)를 실시간 검색 |
도구 |
| 검색 결과 중 일치하는 사례 하나의 실시간 전체 프로필(취득 자격, 대학교, 추가 자격) |
도구 |
| NMC가 발표한 현재 자격 정지/재명 의사 목록을 실시간으로 확인 |
도구 |
| 수동 대체 수단: 실시간 조회가 실패하거나 일치가 불투명할 때 정확한 공식 검색 단계를 안내 |
도구 |
| 링크를 공식 도메인 및 알려진 가짜 도메인과 연결하여 확인 |
리소스 |
| 전체를 조망하는 자료 — 개별 조회, 새 명부, 대규모 자동 확인에 공식적으로 허용된 두 경로 |
프롬프트 |
| 라이브 도구, 이어서 블랙리스트, 그리고 자격 일치를 연결하는 "의사를 제대로 검증하기" 템플릿 |
Related MCP server: Doktor MCP Server
공식 명부는 제삼자용 API를 공개하지 않습니다. 하지만 이 서버가 동작하는 데 그럴 필요도 없습니다. 가장 권위 있는 자료는 국림의료위원회(National Medical Commission)의 **인민 의사 명부(Indian Medical Register, IMR)**이며, 누구든 nmc.org.in에서 검색하기만 하면 됩니다. 명부의 검색 페이지는 클라이언트 측 JavaScript로 공개·인증 불필요 JSON endpoint(nmc.org.in/MCIRest/open/...)를 직접 불러 결과를 렌더링하는데, 이는 어디까지나 해당 페이지 자체의 스크립트를 확인해 찾아낸 것이지 감추고 추측한 것이 아닙니다. search_doctor_registration, get_doctor_profile, check_blacklist가 정확히 그 직 endpoint를 호출하므로 실제 IMR 데이터(registration, qualification, university, 현지 정지 상태)를 돌려줍니다.
이 README의 이전 버전은 nmc.org.in의 robots.txt가 자동 접근을 허용하지 않는다고 적었습니다. 실제로 확인해 보니 그 말이 틀렸습니다. 그 경로의 파일은 표준형식의 robots.txt가 전혀 아니며, 알려진 몇몇 SEO 크롤러(Ahrefs, Majestic, Semrush, …)의 User-Agent만 차단하고 일반적인 Disallow 지시문이 없는 misconfigured Apache 조각이었습니다. 이용약관(Terms of Use) 역시 이를 금지하지 않습니다. 이 때문에 이전에는 무리였던 live verification이 여기서는 타당해진 것으로 정리됐습니다.
정직하게 덧붙이자면: 그 endpoint는 늘 NMC가 문서화하거나 지원하지 동작하지 않으며, 형태가 바뀌거나 rate-limited 되거나 예고 없이 없어질 수도 있습니다 — 뒤에 SLA는 커녕 버전 관리나 지원 계약도 없습니다. 읽기 접근과 1회 조회 수준의 트래픽으로 보아야지, 대량 파이프라인으로 보면 안 됩니다 (이 도구들은, 의도적으로, 결과 수를 제한하고 어떤 직접 이 메일로 페이지를 넘겨하지 않습니다). registration_lookup_guide는 정확히 그 이유 때문에, 라이브 응답이 실패하거나 어색할 때 뒤받침일 수 있도록 되어 있습니다.
꼭 알아 둘 함정이 하나 있습니다: 리서치 과정에서, 실제 nmcn.org.in에서 한 글자 틀린(그러나 정말 흡사한) nmcn.org.in이 "verify Indian doctor" 검색에서 상위 노출되는 걸 확인했습니다. 그곳은 국립의료위원회가 운영하는 곳이 아닌데도 IMR식 검색 페이지 상태로 노출됩니다. flag_lookalike_domain은 그 특정 도메인을 지목해 잡아 주고, 생소 다른 어떤 대상도 "안전"이라고 속단하지 않고 "unreviewed"(검토 안 됨)로 처리합니다. 보조, "에도"의 광고 링크를 클릭하지 말고 직접 nmc.org.in을 손으로 입력하는 것이 낫습니다. 그리고 라이브처럼 보이는 결과라도 가짜 사이트에서 나왔을 수 있음을 항상 기억하세요.
규모로, 통하지는 않는 자동 본증 없 er — 이를테면 의사를 수동으로 개인별로 계속 대조여주지 않고 헬스테크 플랫폼에 올리고 싶다면 — 두 개의 다른 경로가 더 있습니다. 위의 endpoint와 달리 둘 다 공식적으로 인가된 경로 이며, 한 주말 프로젝트보다 무겁습니다:
Ayushman Bharat Digital Mission (ABDM), Healthcare Professional Registry (HPR). 정부가 의사에게 발급하는 자체 인적 신원 시스템이며, 문서화된 OAuth2 API와 sandbox.abdm.gov.in 샌드박스를 갖습니다. 이 Anonymous 1회 조회가 아니라 인증된 헬스시스템 통합 (모듈 M1)의 일부로 시민자를 등록·확인하기 위한 시스템이고, 그래서 온보딩은 진짜 통합 프로젝트입니다 — client ID/secret, 인증, 등등 처음부터 모두 갖추어야 합니다.됩니다.
Commercial KYC/verification 벤더 (예: pseudo Surepass, IDfr.
원** : 여러 회사가 NMC를 근원으로 한 의사 검증 API를 유료이고 지원되는 제품으로 판매합니다. 운영에서 지속적으로 사용한다면 현실적인 선택이 됩니다. 그룬데 각 벤더가 실제 어떤 근거와 얼마나 최신 데이터로, 어떤 이용 조건을 사용하는지는 각각 스스로 평가해야 합니다 — 이 프로젝트가 특정 업체를 특정해서 추천하지는 않습니다.
Python 3.10+와 uv가 필요합니다.
./setup.sh이 디렉토리는 잡다한 스크립트가 아니라 실제 설치 가능한 패키지입니다 (src/doctor_verify_mcp/, pyproject.toml). ./setup.sh는 uv sync를 실행하여 .venv (Python 3.10 through .python-version)를 만들고 패키지와 그 dev 의존성 그룹(pytest)을 editable mode로 설치합니다. uv가 없는 경우 python3 -m venv .venv && source .venv/bin/activate && pip install -e '.[무게]'로 대신 면됩니다. (pip 버전이 dependency groups를 사전을 이해하지 못한다면, [dependency-g] 내용을 위해 [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에 argument wor 없이 호출하여 전목록을 봄세요. flag_lookalike_domain을 nmcn.org.in을 갸재로 호출하엉니다. 그리고 비교해보고, doctor-verification//:official-sources 에서 이 모든 조망할 수 있습니다.다.
패키지가 설치되어 있다면(editable 이든 만든 wheel) console 스크립트도 제공하는데, 이 스크립트 어 ee 서버 teci to stdio 로그 영 합니다 — the 번째 setUp입니다. 여섯는: uv run doctor-verify-mcp.
uv build빌드하면 dist/doctor_verify_mcp-<version>-py3-none-anyward.whl과 함께 .tar.gz 소스 dist가 만들어지고, pip install dist/doct_verify-mcp-*.whl로 어느 환경에데 설치될 수 있습니다습니다.
uv run pytest세 개의 live tools 통한 테스트는 HTTP 층읍 (doctor_verify_mcp.server._http_client)은 개발 중에 실측한 NMC 응답을 mock하고 있기 있어서, 이 스위트가 매번 nmc.org.in을 against하지 않습니다.
실제 로 통합을 할 계획이라면 (예: 의사 등록/온보딩 흐로에 이 MCP서버를 엮결하는) — 더 단 확실 전체 도구 참ortingasion, 권장되는 verification flow, error handling 처리 응약 등 필하게 보려억면 INTEGRATION.md를 보세요.
어느 것이든 부모든 지던 MCP 서버와 같은 캥턴입니다 — 호스트가 소자의 서버를 stdio에서자식 프로세스로 실행하므로, 모든 호St에 동일한 명령억과 절대경로 실행 하면 됩니다.패키지를 설치했다면 호스트가 직접 server 를를 가리키기보단 doctor-verify-mb 콘솔 스키립트 is 대상으로 합니다.
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.pyCuroror (.ursor/msc.json)와 VS Code (.vscode/mcp.json)는 동일한 comand/args 형식을 니します. 이전합니다 if 정확한 소리가 필요하면 이전 프젝트 README를 봄낼세요.
의사면 등록 번·의 불여부 등록번호부터 형식 여부를 검증하는 도구를 충가help as s. — 주 의 위원화에 따라 형식 차가 커서 이번호 프로젝트는 임의추정은 하지 않서요.
KNOWN_LOOKALIKES를 만날 때마다 항목을 추가하세요.
MCIRest endpoint의 형식이 바거나 자동 트래을차단이 시작하면, live 도구들은 자동 습패하지 않고 registration_lookup_guide를 가르키는 명확한 에러를 일으킵니다 — 의사가 없다고 단정하기 전에 그 안내족부터 확인하세요.
ABDM/HPR 경로를 특면, 성제 조회된 API를 조회하는 verify_hpr_id 도구(데 이때 credentials 소스에 하드코딩하지 않은 사용자 설정)는 이 프로젝트가 현재 쓰고 있는 공식되지 않 은 엔드포인트에 대한 추천 대안이 되 줍니다.
각 State Council로 직체 링크를 담은 resource를 추가하.se Input — IMR에 결과가 뜨지 않고, 직접 해당 주의 council 사이트를 확인하는 폴백이 필요할 대를 대비할 수 있게요.
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.
