This server provides business registration verification and status checks via National Tax Service (NTS) data.
validate_business: Verify whether a business registration number matches the given details (start date, representative name, etc.) and get validity status (일치/불일치) plus business status if matched.
check_business_status: Look up the current operating status of up to 100 business registration numbers (active, dormant, closed) and count matches.
batch_validate_businesses: Validate multiple business registrations in a single request (up to 100) with detailed validity results and statuses.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nts-business-verification 사업자등록번호 120-88-00767 상태 조회해줘"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
한국 공공데이터 API 를 MCP(Model Context Protocol) 서버로 제공한다. Claude Desktop, Claude Code 등 MCP 클라이언트에서 국민연금 사업장과 고용·산재보험 현황, 사업자등록 상태, 나라장터 입찰, 기업 재무제표·법인번호·주식시세, DART 전자공시·재무제표, 대통령 연설문, MSDS 화학물질 정보를 바로 조회할 수 있다.
Koomook/data-go-mcp-servers(Apache-2.0, 2025-09 이후 정지)를 기반으로 mcp SDK 2.x 에 맞춰 재정비한 것이다. 툴 이름과 파라미터는 원저장소와 호환된다.
서버 | 기관 / 데이터 | 툴 |
국민연금공단 — 사업장 가입내역 (+ 법정동코드 조회, 고용·산재보험 현황) |
| |
국세청 — 사업자등록 진위확인·상태 |
| |
조달청 — 나라장터 입찰·낙찰·계약 |
| |
금융위원회 — 기업 재무제표 (+ 법인번호 조회·기업 개요·주식시세) |
| |
대통령기록관 — 연설문 |
| |
안전보건공단 — MSDS |
| |
금융감독원 — DART 전자공시 (기업 개황, 공시 목록·원문, 재무제표) |
|
서버 7개, 툴 36개, 공공 API 11종. 모든 툴은 조회 전용이며, 실패는 MCP 오류 결과(isError)로 전달된다. 한 서버가 API 여러 개를 쓰는 경우(nps 3, fsc 3)는 각각 활용신청이 필요하다 — 표는 api-keys.md. dart-disclosure 만 data.go.kr 이 아닌 OpenDART 키를 쓴다.
Related MCP server: korea-business-verify
처음이라면 → 시작하기 (코드·터미널 없이 10분).
요약: data.go.kr 인증키 발급·활용신청 → data-go-mcp-desktop.mcpb 를 Claude Desktop 설정 → 확장 프로그램에 끌어다 놓고 키 입력 → 질문.
서버를 골라 쓰거나 설정 파일로 등록하려면:
uv 설치
data.go.kr 인증키(Decoding) 발급 후 쓰려는 API 에 활용신청 → docs/guide/api-keys.md
Claude Desktop 설정(claude_desktop_config.json)에 추가:
{
"mcpServers": {
"nts-business-verification": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/hichang4u/data-go-mcp-servers#subdirectory=src/nts-business-verification",
"data-go-mcp.nts-business-verification"
],
"env": { "API_KEY": "<data.go.kr 인증키>" }
}
}
}다른 서버는 nts-business-verification 을 서버명으로 바꾸면 된다. dart-disclosure 만 "env": { "DART_DISCLOSURE_API_KEY": "<OpenDART 인증키>" } (data.go.kr 키와 별개, api-keys.md 4절). 전부를 한 프로세스로 띄우는 all-servers, Claude Code, Cline, Smithery(smithery mcp add hichang4u/data-go-mcp), clone 해서 쓰는 방법은 docs/guide/installation.md.
> 사업자등록번호 120-88-00767 상태 조회해줘
계속사업자, 부가가치세 일반과세자 …사용 | 시작하기 · 설치·클라이언트 설정 · API 키·활용신청 · 문제 해결 · 서버별 툴 레퍼런스 |
개발 | CONTRIBUTING · 아키텍처 · 새 서버 추가 · 테스트 · 릴리스 |
이력 |
git clone https://github.com/hichang4u/data-go-mcp-servers && cd data-go-mcp-servers
uv sync --dev --all-packages
cp .env.example .env # API_KEY (data.go.kr), DART_DISCLOSURE_API_KEY (OpenDART) 채우기 — 실호출 테스트용
uv run pytest # 334 tests; 실호출은 -m integration
uv run ruff check src scripts tests && uv run pyright src scripts tests
uv run python scripts/check_apis.py # 11개 API 생존·권한 확인Python 3.10+, mcp>=2.2. CI 는 ubuntu/windows × 3.10/3.13 에서 pytest, ruff, pyright 를 필수로 돌린다.
Apache-2.0. 원저작물 저작권 표시는 NOTICE 와 각 패키지의 LICENSE 에 유지한다. 이 프로젝트는 data.go.kr 및 각 기관과 무관하며, 데이터 이용은 각 API 의 이용약관을 따른다.
여러 사업자등록정보를 한 번에 진위확인합니다. Batch validate business registrations.
Returns request_count, valid_count, results[] (business_number, valid, valid_msg, status).
| Name | Required | Description | Default |
|---|---|---|---|
| businesses_json | Yes | JSON 배열 문자열, 최대 100개. 각 항목 필수: b_no, start_dt, p_nm. 선택: p_nm2, b_nm, corp_no, b_sector, b_type, b_adr. 예: [{"b_no": "1234567890", "start_dt": "20200101", "p_nm": "홍길동"}] |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, so the description does not need to re-assert safety. It adds useful behavioral detail by disclosing the exact return shape: request_count, valid_count, and results[] with business_number, valid, valid_msg, and status. It does not mention external API dependency or rate limits, but the read-only annotation lowers the burden.
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 short and front-loaded with the core purpose. The Korean/English duplication is slightly redundant, but the content is compact and the return-structure line is useful and not padded.
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?
Given the single parameter, full schema coverage, and existing output schema, the description provides enough context: it names the batch scope, the input as JSON, and the key return fields. It could be more explicit about when to use single vs batch, but that gap belongs to usage guidance rather than completeness.
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?
Schema description coverage is 100%, and the schema already documents the required and optional fields plus an example. The description itself adds no additional parameter semantics beyond the schema, so the baseline score of 3 applies.
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 operation—'Batch validate business registrations'—and reinforces it in Korean as validating multiple business registration records at once. This clearly distinguishes it from the singular sibling validate_business and from check_business_status by emphasizing batch verification.
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 implies usage when multiple business registrations need validation at once, but it does not explicitly state when to prefer the single-record sibling validate_business or check_business_status. No exclusions or alternative routing are provided beyond the 'batch' connotation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
사업자등록 상태를 조회합니다. Check business registration status.
Returns request_count, match_count, businesses[] (status_code 01: 계속사업자, 02: 휴업자, 03: 폐업자; 미등록 번호는 tax_type 에 안내 문구가 온다).
| Name | Required | Description | Default |
|---|---|---|---|
| business_numbers | Yes | 사업자등록번호 목록, 쉼표 구분, 최대 100개 (하이픈 허용) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and openWorldHint=true already in the annotations, the description adds meaningful behavioral context by revealing return fields and the meaning of status_code values (01, 02, 03). It also discloses the special behavior for unregistered numbers via tax_type. This goes beyond what the annotations alone provide, though it does not mention rate limits or auth requirements.
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 short and front-loaded with the purpose, followed by useful return-value semantics. The bilingual repetition ('사업자등록 상태를 조회합니다' and 'Check business registration status') is slightly redundant, but every other sentence contributes meaningful information.
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?
Given a single well-documented parameter, an output schema, and read-only/open-world annotations, the description covers what matters: purpose, status-code meanings, and the unregistered-number edge case. The main completeness gap is the lack of sibling-tool routing guidance, but that does not block correct invocation.
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 input schema already documents the sole parameter fully: comma-separated business numbers, max 100, hyphens allowed. The description does not add any additional parameter-level semantics beyond what the schema provides, so the high schema coverage baseline of 3 applies.
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 clearly states the tool's purpose with a specific verb and resource: '사업자등록 상태를 조회합니다' / 'Check business registration status.' It also signals what kind of result the caller gets through status_code semantics. It does not explicitly distinguish this from sibling tools like validate_business or batch_validate_businesses, so it misses the top score.
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?
No guidance is given about when to use this tool versus validate_business or batch_validate_businesses. There are no conditions, exclusions, or prerequisites stated. The agent must infer the difference from the tool name and sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
사업자등록정보 진위확인을 수행합니다. Validate business registration information.
Returns business_number, valid (01: 일치, 02: 불일치), valid_msg, status (일치 시 상태 정보).
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | Yes | 개업일자 YYYYMMDD (하이픈 허용) | |
| corp_number | No | 법인등록번호 13자리 | |
| business_name | No | 상호 | |
| business_type | No | 주종목명 | |
| business_number | Yes | 사업자등록번호 10자리 (하이픈 허용) | |
| business_sector | No | 주업태명 | |
| business_address | No | 사업장주소 | |
| representative_name | Yes | 대표자성명 | |
| representative_name2 | No | 대표자성명2 (외국인 한글명) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation read-only and open-world, and the description adds helpful behavioral context by explaining the valid code semantics (01=match, 02=mismatch) and that status is present on match. There is no contradiction with the annotations, and no hidden side effects are obscured.
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 sentences, front-loads the main purpose, and includes only the most decision-relevant output semantics. The bilingual repetition is compact and does not waste space.
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?
With a fully described 9-parameter schema, an output schema, and read-only annotations, the description covers the core call behavior and result meanings. The only notable gap is not explicit guidance about when to prefer this tool over its siblings, but the singular validation scope is largely inferable.
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 input schema gives 100% per-parameter descriptions (business_number 10 digits, start_date YYYYMMDD, etc.), so the description does not need to repeat them. It adds no extra semantic meaning beyond the schema, which matches the baseline for full schema coverage.
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 opens with a specific action and object: performing business-registration authenticity verification ('사업자등록정보 진위확인을 수행합니다'). It also states the key output distinction (valid=01 match, 02 mismatch), which clearly differentiates this single-validation tool from siblings like batch_validate_businesses and check_business_status.
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 clearly indicates this is for validating business registration info, and the returned valid/status fields imply a single-record check. However, it never explicitly states when to choose validate_business over batch_validate_businesses or check_business_status, leaving the routing mostly to inference from the tool name.
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.0batch_validate_businessescheck_business_statusvalidate_businessScored across 3 tools
validate_business and batch_validate_businesses are clearly distinguished by single vs. batch operation, and check_business_status focuses on status lookup. Some minor overlap exists because validate_business also returns status information, but the purposes are distinct enough for an agent to select correctly.
All tool names follow a consistent verb_noun snake_case pattern. validate_business, check_business_status, and batch_validate_businesses use clear, predictable naming with appropriate verb choices for each action.
Three tools is well-scoped for the business verification domain. Each tool covers a distinct need: single validation, status lookup, and batch validation, with no redundant or superfluous entries.
The domain of business registration verification is fully covered: individual validation, batch validation, and status checks. No obvious missing operations or dead ends exist for the stated purpose.
Verify Korean business registration numbers (National Tax Service) — KYB for Korean counterparties …
Korean ID document verification and PII masking APIs
Korea-native MCP gateway: Korean commerce, payments, messaging, gov & finance APIs for AI agents.
LatAm Validate MCP — validate Latin-American banking and tax identifiers.
