korea-health-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a specific resource and action: hospital search vs. hospital details, non-payment by region vs. by hospital, drug info vs. DUR safety, disease statistics, plus two clearly distinct meta-tools for discovery and execution. No overlapping purposes.
Naming Consistency4/5
Domain tools consistently follow a 'kohealth_verb_noun' pattern (e.g., search_hospital, get_hospital_info, get_drug_dur). The two meta-tools (discover_tools, execute_tool) deviate from this pattern but are clearly named and serve a different function, so the inconsistency is minor.
Tool Count5/5
With 10 tools, the server is well-scoped. It covers multiple health data domains (hospitals, non-payment, drugs, diseases) without unnecessary bloat, and each tool contributes meaningfully to the overall functionality.
Completeness4/5
The tool surface provides comprehensive coverage for the apparent domain: hospital search and detailed info, non-payment item lookup by region and hospital, drug search and DUR safety, and disease statistics. A minor gap is the lack of a tool to directly compare non-payment prices across multiple hospitals, but the existing search can partially achieve this.
Average 3.8/5 across 10 of 10 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It does add some context by noting that it includes hidden tools ('숨김 포함'), which is useful. However, it fails to disclose that invoking arbitrary tools via this proxy can have side effects, that the actual behavior is dependent on the called tool, or that return values may vary. This is a significant gap for a dynamic execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the core purpose. It front-loads the verb and resource, with no extraneous information. Perfect conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple concept, the tool is a proxy with arbitrary behavior. The description lacks information about error handling, return format, or the fact that it can invoke any registered tool, which is critical for an agent to use it safely. The schema covers parameter names but not the broader context of what happens when a tool is called or if it fails. The absence of an output schema and annotations makes this minimal description insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing clear explanations for both 'name' and 'args' parameters. The description adds no extra parameter semantics beyond restating 'by name and arguments.' Thus, it meets the baseline but adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Calls registered tools (including hidden) by name and arguments.' It identifies the specific verb (호출합니다) and resource (등록된 도구), and distinguishes it from sibling tools, which are all domain-specific health information tools. This is a general-purpose proxy tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used after discovering tools via discover_tools, nor does it explain scenarios where direct tool invocation is preferred. The only hint is in the schema parameter description for 'name', but the main description lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It lists content types and the source but does not state that this is a read-only operation, nor does it mention pagination, response structure, or any limitations. For a retrieval tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that efficiently states the action, key input, and data source. No wasted words or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description is too brief to convey expected response format or handling of large result sets. It also omits usage context relative to sibling tools, making it incomplete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all five parameters with 100% description coverage, including enums and defaults. The description adds slight context by listing example detail types (specialists, equipment, facilities) that map to the category parameter, but this is largely redundant with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed hospital information (number of specialists by department, medical equipment, facilities) using the ykiho identifier. The verb '조회' (inquiry) and specific resource differentiate it from sibling search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explain when to use this tool versus alternatives. It neither mentions that a prior search is needed to obtain ykiho nor contrasts it with siblings like search_hospital. Only the schema hint mentions using search results, but that is not in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that product name filtering happens server-side and ingredient name filtering happens client-side, which is a useful behavioral detail. However, it does not mention the read-only nature, pagination behavior, or any rate limits, though these are partially inferable from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, consisting of one sentence that states the verb, resource, and filtering options, followed by a source attribution. Every piece of information earns its place, and it is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the presence of six parameters, the description provides essential context but omits details such as return format, behavior when no filters are provided, and pagination limits. The source attribution adds credibility, but the tool would benefit from a brief note on how to use the filters together or what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions the two filter mechanisms (product and ingredient names) but adds no additional semantic meaning beyond what the parameter descriptions already provide. The schema already includes defaults and constraints for format, pageNo, numOfRows, and category.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves DUR safety information across five specified categories (병용금기, 연령금기, 임부금기, 노인주의, 효능군중복) using product name (server filter) or ingredient name (client filter). This clearly communicates the resource and the filtering mechanisms, distinguishing it from broader drug search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus sibling tools like kohealth_search_drug or kohealth_get_disease_stats. It does not state whether this should be used for investigating drug interactions or precautions, nor does it mention any exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states that it 'queries' and filters by itemKeyword. It omits the critical detail (though present in schema) that itemKeyword filtering is performed client-side after fetching results, which can affect pagination. The source attribution adds context but does not cover this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the primary purpose. Every sentence contributes to understanding the tool's function and source, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and no output schema, the description provides core purpose but lacks critical operational context such as pagination behavior, output format options (text vs json), and the server vs client-side filtering nuance. While the schema compensates for parameter details, the description alone is not fully complete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no meaningful parameter semantics beyond what the schema already provides; it merely repeats that region/type are used and itemKeyword filters. No additional parameter details are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('조회합니다' - searches) and resource ('비급여 진료 항목' - non-payment care items), scoped by region/type. It also mentions additional filtering by itemKeyword and provides the data source, making it distinct from sibling tools like kohealth_get_hospital_nonpayment which is hospital-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when searching for non-payment items by region/type and filtering by keyword, but it does not explicitly state when to use this tool versus alternatives like kohealth_get_hospital_nonpayment. There are no exclusionary statements or named alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states the tool searches and lists the types of information returned, implying a read-only query. However, it does not disclose pagination behavior, output format differences, or any potential access limitations. The schema covers pagination format, so the description adds only partial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the tool's purpose, target audience, search keys, information fields, and data source. Every word earns its place; no unnecessary detail or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does, what data fields are returned, and the data source, which is sufficient for a search tool without an output schema. Pagination and format are documented in the schema, so the description does not need to repeat them. Minor lack of explicit notes on result handling but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all six parameters (100% coverage), so the baseline is 3. The description mentions the search keys (제품명/업체명/효능 키워드) which map to itemName, entpName, and efcyQuery, but this is redundant with the schema. The mention of returned fields adds output context, but not parameter-specific semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb '검색합니다' (search) and clearly names the resource: 일반인용 의약품 정보 (consumer drug information), with explicit fields (효능, 사용법, 주의사항, 부작용, 보관법). It differentiates from siblings like kohealth_search_hospital or kohealth_get_drug_dur by focusing on general consumer drug information and citing the official source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching consumer drug info by product/company/efficacy keyword, but it does not explicitly state when to use this tool versus alternatives like kohealth_get_drug_dur (for drug utilization review) or kohealth_search_hospital. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavioral information. It discloses that the tool returns summaries and is a preparatory step for executing hidden tools, but it does not elaborate on side effects, rate limits, or the exact nature of the 'summary'. For a discovery tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that front-loads the action and resource, then adds usage context. Every word contributes value, and there is no wasted detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a single optional parameter, the description adequately conveys what the tool returns and its intended use. It omits a concrete return structure, but the stated purpose is clear enough for an agent to invoke the tool and interpret the result reasonably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not discuss the only parameter. However, the input schema fully documents 'includeExposed' with a description and default value, so schema coverage is 100%. Baseline 3 applies because the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns the name, description, and input schema summary of all registered tools ('등록된 모든 도구의 이름·설명·입력 스키마 요약을 반환합니다'). It also distinguishes itself from siblings by mentioning its role in preparing for hidden tool execution via execute_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use before calling hidden tools with execute_tool' ('숨김 도구를 execute_tool 로 호출하기 전에 사용하세요'). It gives a clear context but does not mention exclusions or alternatives, though none are apparent among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose return fields and the data source (심평원 병원정보서비스), but it does not mention pagination behavior, default output format, or what happens when no filters are provided. The linkage hint adds useful context, but some behavioral traits remain implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence front-loads the purpose, then efficiently lists return fields, linkage workflow, and source. Every clause contributes value without repetition or unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 7 parameters but no output schema or annotations, the description covers the essential workflow (search → get ykiho → pass to other tools) and return fields. It could optionally mention pagination or format behavior, but the schema handles parameter details, so the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all 7 parameters with examples and constraints (100% coverage), so baseline is 3. The description adds no new parameter-level detail beyond grouping them into categories (name/region/type/department) that are already clear from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource ('병원을 검색해') and lists concrete search dimensions (기관명/지역/종별/진료과목) and return fields (ykiho, 주소, 전화, 좌표). It also distinguishes the tool from siblings by explicitly noting that the resulting ykiho should be passed to 비급여/상세 tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: use this tool to search hospitals and obtain ykiho, then pass it to detail/non-payment tools. This implies a workflow and differentiates it from sibling tools, though it does not name exact alternative tool names or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explains the two operation modes (disease lookup vs. statistics) and the breakdown dimensions, and mentions the data items (환자수, 요양급여비). However, it does not disclose output format (text vs. json), the requirement for sickCode and year in statistics mode, or any API limitations such as pagination or rate limits. These details are partially in the schema but not in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loads the primary action, and includes only essential details (modes, breakdown dimensions, source). No filler or repetition of schema information. It is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no output schema, and no annotations. The description covers the core functionality but does not explain the response structure, how parameters combine (e.g., diseaseName filtering, pagination), or what the default output looks like. The schema fills many gaps, but with no output schema, the description should provide more detail about return formats and constraints. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful interpretation of the statType enum by mapping '조회만' to disease lookup and listing the other enum values as breakdown dimensions (성별연령/입원외래/종별/지역별). It also clarifies that sickCode is needed for statistics. This goes beyond the schema's brief per-parameter descriptions, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: query disease names/codes (statType='조회만') or retrieve medical statistics for a specific disease code broken down by gender-age, inpatient/outpatient, type, and region. It uses clear verbs (조회, 통계 조회) and identifies the resource (질병명·코드, 진료통계), distinguishing it from sibling tools focused on hospitals, drugs, and nonpayment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use the tool: for disease information/statistics from the HIRA service. It does not explicitly name alternative tools or state 'use this instead of X', but the sibling tools operate in different domains (hospitals, drugs), making the intended use unambiguous. No exclusion criteria are provided, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the data source (건강보험심사평가원), the time window (최근 1년), and the result scope (top 5 diseases + departments), which is solid behavioral context. It does not mention errors or rate limits, but the operation is clearly a read-only lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main action and object, then adds time scope and source. Every clause earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with a required ykiho and an optional format enum, the description is sufficiently complete. It states what is returned (top 5 diseases and departments), the time period, and the data source. No output schema exists, but the expected return is simple enough that this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The schema descriptions add valuable semantics: ykiho is explicitly tied to hospital search with clCd='31', and format has an enum/default. The description itself does not repeat parameter details, but the schema already provides strong guidance, earning a slight boost.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves the top 5 national-interest diseases and treatment departments for a clinic (의원) by ykiho over the past year. The verb '조회' and specific resource ('상위 5개 질병과 진료과목') make the purpose unambiguous and distinct from sibling tools like general hospital info or disease stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you have a clinic's ykiho and need its most common diseases. The parameter description adds a concrete prerequisite by directing users to kohealth_search_hospital with clCd='31' to obtain the ykiho, but there is no explicit when-not-to-use guidance or comparison to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It transparently reveals a key limitation: no server-side ykiho filter, so matching is done client-side by narrowing with hospital name and region. This is meaningful behavioral context beyond the schema, though it could also mention pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose in the first sentence and supplementary limitation/source in the second. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter lookup tool with no output schema, the description provides adequate context: hospital-specific scope, matching limitation, and data source. The format parameter in the schema covers return value semantics. It stops short of a 5 because pagination behavior and potential edge cases like multiple hospitals with the same name aren't addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are already documented. The description reinforces the region parameter's role in narrowing results but adds little new meaning beyond what the schema already states. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves non-payment items and prices for a specific medical institution by hospital name (기관별 목록). This is a specific verb+resource that distinguishes it from sibling tools like kohealth_search_nonpayment, which likely performs broader searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical guidance by noting that there is no ykiho server filter, so users should combine hospital name with region to narrow matching. This implies when to use region and improves search accuracy, though it doesn't explicitly contrast with alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dk-korea-health-mcp MCP server](https://glama.ai/mcp/servers/NSLC7779/dk-korea-health-mcp/badges/card.svg)](https://glama.ai/mcp/servers/NSLC7779/dk-korea-health-mcp)

Score Badge

Copy to your README.md:

[![dk-korea-health-mcp MCP server](https://glama.ai/mcp/servers/NSLC7779/dk-korea-health-mcp/badges/score.svg)](https://glama.ai/mcp/servers/NSLC7779/dk-korea-health-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/NSLC7779/dk-korea-health-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server