Skip to main content
Glama
vertical-mcp

kolas-mcp

by vertical-mcp
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

@vertical-mcp/kolas-mcp

MCP server for Korea's KOLAS (Korean Laboratory Accreditation Scheme) — the national accreditation body under KATS (국가기술표준원) that accredits calibration, testing, inspection, medical-testing, reference-material-production, and proficiency-testing organizations under ISO/IEC 17025, ISO/IEC 17020, ISO 15189, ISO 17034, and ISO/IEC 17043.

한국인정기구(KOLAS) 공개 포털(knab.go.kr)과 공공데이터포털(data.go.kr) 데이터셋을 MCP 서버로 래핑한 패키지. 교정·시험·검사·의료시험·표준물질생산·숙련도시험 인정기관을 Claude·Cursor 등 MCP 호환 클라이언트에서 바로 조회할 수 있다.

Tools

Tool

Description

search_accredited_labs

Search accredited labs by free-text query and category (CALIBRATION / TESTING / INSPECTION / MEDICAL / REFERENCE / PROFICIENCY / ALL). No API key required.

get_lab_details

Full detail for a single lab by accreditation number (e.g. KT001) — scope of accreditation, history, contact. No API key required.

get_kolas_statistics

Annual accreditation counts per category (dataset 15054300). Requires KOLAS_SERVICE_KEY from data.go.kr.

Related MCP server: Korean Patent MCP (KIPRIS)

Quick start

1. (Optional) Register for a data.go.kr ServiceKey

The live lab-search tools work without any API key. A key is only required for get_kolas_statistics, which pulls annual aggregate data from data.go.kr.

To enable statistics:

  1. Sign up at https://data.go.kr

  2. Apply for dataset 15054300 (산업통상자원부_기술표준통계_한국인정기구(KOLAS) 인정현황)

  3. Copy the issued ServiceKey into the KOLAS_SERVICE_KEY env var.

2. Install

npx @vertical-mcp/kolas-mcp

Or install globally:

npm install -g @vertical-mcp/kolas-mcp
kolas-mcp

3. Configure your MCP client

Claude Desktop (claude_desktop_config.json)

{
  "mcpServers": {
    "kolas-mcp": {
      "command": "npx",
      "args": ["-y", "@vertical-mcp/kolas-mcp"],
      "env": {
        "KOLAS_SERVICE_KEY": "your-optional-data.go.kr-key"
      }
    }
  }
}

Cursor (.cursor/mcp.json)

{
  "mcpServers": {
    "kolas-mcp": {
      "command": "npx",
      "args": ["-y", "@vertical-mcp/kolas-mcp"]
    }
  }
}

Smithery-hosted (coming soon)

When the Smithery hosted deploy is live, register the session-scoped kolasServiceKey via Smithery's config UI — no local env var needed.

Environment variables

Variable

Required

Description

KOLAS_SERVICE_KEY

Optional

data.go.kr ServiceKey for dataset 15054300 (annual statistics). Not required for live lab search.

Examples

List Korean calibration labs with "length" in their scope

search_accredited_labs({
  query: "길이",
  category: "CALIBRATION",
  page: 1,
  page_size: 20
})

Look up a single testing lab by accreditation number

get_lab_details({ accreditation_no: "KT001" })

Annual accreditation counts for 2023

get_kolas_statistics({ year: "2023" })

Accreditation-number prefix cheat sheet

Prefix

Category

Standard

KC

Calibration (교정)

ISO/IEC 17025

KT

Testing (시험)

ISO/IEC 17025

KI

Inspection (검사)

ISO/IEC 17020

KM

Medical testing (의료시험)

ISO 15189

KR

Reference material producer (표준물질생산)

ISO 17034

KP

Proficiency testing provider (숙련도시험)

ISO/IEC 17043

The server infers category from this prefix automatically when you pass an accreditation number.

Development

git clone https://github.com/vertical-mcp/kolas-mcp.git
cd kolas-mcp
npm install
npm run build
npm start

Scripts

  • npm run dev — watch mode via tsx

  • npm run build — compile to dist/

  • npm run typecheck — no-emit type check

  • npm run clean — remove dist/

Data source caveats

search_accredited_labs and get_lab_details parse HTML from https://www.knab.go.kr. KOLAS may redesign the portal; if selectors break, open an issue. The statistics endpoint is the more stable path — data.go.kr datasets are versioned and backwards-compatible.

Roadmap

  • v0.1 — search_accredited_labs, get_lab_details, get_kolas_statistics (this release)

  • v0.2 — list_accreditation_fields (scope taxonomy), get_scope_by_field (reverse lookup: which labs cover ISO method X?), calibration-lab search via kasto.or.kr

  • v0.3 — APLAC/ILAC MRA cross-reference, neighboring-country accreditation bodies (JAB Japan, CNAS China)

Legal / attribution

  • Data sources:

  • This package is an unofficial community wrapper. It is not affiliated with or endorsed by KATS, KOLAS, or MOTIE.

  • Please respect the source portals' rate limits — scraping is courteous and sparse by default.

License

MIT © 2026 Yongbum Kim

Available Tools

3 tools
get_kolas_statisticsA

Return annual KOLAS accreditation statistics — number of accredited organizations per category per year. Data source: data.go.kr dataset 15054300 (산업통상자원부_기술표준통계_한국인정기구(KOLAS) 인정현황). Requires KOLAS_SERVICE_KEY.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNo
categoryNoALL

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the data source and that the tool returns statistics. However, it does not mention response format, potential errors, or rate limits. For a simple read-only tool, the behavioral disclosure 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 consists of two concise sentences with no wasted words. It starts with the core purpose and immediately adds the data source and requirement, making it efficient and front-loaded.

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 no output schema and no annotations, the description could be more complete. It states the output is counts per category per year but omits details like response structure, pagination, or external API dependencies. It is adequate but leaves gaps for an agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only loosely connects 'per category per year' to the 'year' and 'category' parameters, but does not explain their formats, defaults, or the meaning of category values. The description adds minimal value beyond the schema's enum and pattern.

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 returns annual KOLAS accreditation statistics (number of accredited organizations per category per year) and identifies the data source. It distinguishes itself from sibling tools ('get_lab_details' and 'search_accredited_labs') by being aggregate statistics vs. details or searching.

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 explicitly mentions a required API key ('Requires KOLAS_SERVICE_KEY') as a prerequisite. It implies use for obtaining aggregate statistics, but does not explicitly state when to use this tool over siblings or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_lab_detailsA

Fetch full detail for a single KOLAS-accredited lab by accreditation number. Returns metadata (name, address, phone, contact, status), the scope-of-accreditation table, and the accreditation history (initial accreditation, renewals, extensions, suspensions). Data source: knab.go.kr.

ParametersJSON Schema
NameRequiredDescriptionDefault
accreditation_noYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses return data (metadata, scope table, history) and data source. However, it omits behavioral traits like idempotency, error handling, or potential side effects, making it adequate but not thorough.

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?

Two concise sentences: the first captures purpose and key qualifier, the second enumerates return content and data source. No redundant information; every word earns its place.

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 one required parameter, no output schema, and no annotations, the description covers the purpose, parameter, return data, and data source. It lacks error states or rate limits, but for a simple lookup tool, it is largely 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?

With 0% schema description coverage, the description must compensate. It mentions 'by accreditation number' which maps to the parameter, but does not explain the pattern or provide examples. This meets the minimum requirement but adds limited 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 uses a specific verb ('Fetch') and resource ('full detail for a single KOLAS-accredited lab') along with the retrieval key ('by accreditation number'). It clearly distinguishes from siblings (statistics, search) by focusing on a single lab's comprehensive details.

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 implies usage context: use this to get detailed info for a specific lab, while siblings handle statistics or searching. However, it does not explicitly state when not to use or provide alternatives, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_accredited_labsA

Search KOLAS-accredited laboratories by free-text query and accreditation category. Returns a paginated list of labs with accreditation number, name, category, scope fields, and validity end date. Data source: knab.go.kr (no API key needed).

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNo
categoryNoALL
pageNo
page_sizeNo

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the data source (knab.go.kr) and that no API key is needed. However, it does not mention rate limits, authentication, or error handling. For a search tool, these are less critical, but the description is adequate.

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?

Two sentences with no wasted words. The first sentence clearly states the action and criteria; the second adds return fields and data source. Front-loaded and efficient.

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, the description lists returned fields (accreditation number, name, category, scope fields, validity end date). It also notes the data source and no API key. Missing details like sorting or pagination behavior, but overall complete for a search tool.

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 coverage is 0%, so description must compensate. It explains 'query' as free-text and 'category' as accreditation category, which adds meaning beyond the enum. It implies pagination via 'paginated list' but does not explain the 'page' and 'page_size' parameters or defaults. This partial compensation yields a score of 3.

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 a specific verb ('Search'), identifies the resource ('KOLAS-accredited laboratories'), and specifies the input methods (free-text query and accreditation category). It clearly distinguishes from sibling tools like 'get_kolas_statistics' and 'get_lab_details' by focusing on searching vs. statistics or details.

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 implies usage for searching by query and category, and mentions a paginated list. While it doesn't explicitly state when not to use it, the context of sibling tools suggests appropriate usage. It could be improved by including exclusions, but it is clear enough for an agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: aggregated statistics, detailed lab info by ID, and free-text search. There is no overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (get_kolas_statistics, get_lab_details, search_accredited_labs), making them predictable and easy to understand.

Tool Count5/5

With 3 tools, the server is well-scoped for its purpose of querying KOLAS accreditation data. Each tool serves a essential function without unnecessary bloat.

Completeness4/5

The set covers search, details, and statistics, covering the main read operations. A minor gap is the lack of a tool to list available accreditation categories directly, but this is partly handled by the search tool's category parameter.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • ScienceON-MCP

    ansua79
    A
    license
    A
    quality
    B
    maintenance
    MCP server for searching Korean scientific literature, patents, reports, and more via the KISTI ScienceON API.
    17
    1
    Creative Commons Attribution Non Commercial 4.0 International

  • korean-engineering-mcp

    sonmeggy
    A
    license
    Not graded
    quality
    B
    maintenance
    This MCP server enables searching Korean construction standards (KDS/KCS), laws from the Ministry of Government Legislation, administrative rules and interpretations, and optionally local water/wastewater design manuals to generate grounded evidence packages for engineering answers.
    2
    MIT

  • narajangteo-prespec

    opendata-kr
    A
    license
    A
    quality
    A
    maintenance
    MCP server that wraps the Korean government's '나라장터 사전규격정보서비스' API, enabling natural language search and retrieval of public procurement pre-specifications through simplified tools.
    5
    63
    MIT

Latest Blog Posts

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/vertical-mcp/kolas-mcp'

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