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., "@commercial-registry Find precedents about 합병 등기"
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.
대법원 사법정보공개포털의 상업등기선례 617건을 검색할 수 있는 MCP(Model Context Protocol) 서버입니다.
git clone https://github.com/musasister/mcp-commercial-registry.git
cd mcp-commercial-registry
npm installRelated MCP server: law-search-mcp
~/.claude/settings.json에 추가:
{
"mcpServers": {
"commercial-registry": {
"command": "node",
"args": ["/path/to/mcp-commercial-registry/index.js"]
}
}
}도구 | 설명 |
| 키워드로 선례 검색 (예: "주식회사", "합병", "이사") |
| 예규번호로 특정 선례 조회 (예: "제 2-116호") |
| 선례 목록 페이지별 조회 |
| 상태별/연도별 통계 조회 |
최근인기 규칙/예규/선례 > 상업등기선례 (617건)
의뢰인이 A 주식회사가 B 주식회사를 흡수합병하려고 합니다. 합병등기 신청 시 검사인의 조사보고서를 반드시 첨부해야 하나요?
"합병" 관련 상업등기선례를 검색해줘합병 관련 34건의 선례 중 제 1-244호 "회사분할합병으로 인한 설립등기신청시 검사인 등의 조사보고서 첨부여부(소극)", 제 1-227호 "주식회사의 합병등기절차" 등을 바로 확인할 수 있습니다.
소규모 주식회사에서 상근임원을 둘 수 없는 상황인데, 대표이사를 반드시 사내이사 중에서 선임해야 하는지 궁금합니다.
"대표이사 선임" 관련 선례를 찾아줘제 2-33호 "상근임원을 둘 수 없는 주식회사도 대표이사를 사내이사 중에 선임하여 등기 신청하여야 하는지 여부"를 즉시 확인하여 의뢰인에게 정확한 답변을 줄 수 있습니다.
주주총회 소집절차에 하자가 있었지만 형식적 요건을 갖춘 의사록이 있습니다. 이 의사록을 첨부하여 변경등기 신청이 가능한가요?
"주주총회" 관련 선례를 검색하고, 소집절차 하자와 관련된 것을 알려줘제 1-72호 "주주총회의 소집절차 등에 중대한 하자가 있으나 형식적 요건을 갖춘 의사록을 첨부하여 등기신청을 한 경우", 제 1-76호 "대표이사가 소집하지 아니한 전원 출석 주주총회의 적법성" 등 실무에 바로 적용 가능한 선례를 찾을 수 있습니다.
주식회사가 전환사채를 발행했고, 사채권자가 주식 전환을 청구했습니다. 전환으로 인한 변경등기 신청 시 어떤 서면을 첨부해야 하나요?
"전환사채" 관련 선례를 모두 보여줘전환사채 관련 12건의 선례를 일괄 확인할 수 있습니다. 제 2-66호 "전환사채의 전환으로 인한 변경등기 신청서의 첨부서면", 제 2-65호 "전환사채 또는 신주인수권부사채의 등기신청서에 첨부하여야 하는 최종의 대차대조표" 등으로 정확한 첨부서면 목록을 안내할 수 있습니다.
특수법인이 청산종결등기를 마쳤는데, 이후에도 청산인 명의로 인감증명 발급이 가능한지 문의가 왔습니다.
"청산" 관련 선례 중 "인감" 키워드가 포함된 것을 찾아줘제 1-413호 "특수법인의 청산종결등기 후 청산인의 인감증명발급 가부"를 즉시 확인하여 답변할 수 있습니다.
이처럼 법인등기 실무에서 자주 마주치는 질문에 대해 617건의 선례를 자연어로 빠르게 검색하고, 근거 선례 번호를 바로 확인할 수 있습니다.
MIT
예규번호로 특정 상업등기선례를 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| regNo | Yes | 예규번호 (예: 제 2-116호, 제 1-346호) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. The verb '조회' conveys a read-only lookup, which is the most important behavioral trait for a getter. However, it does not disclose not-found behavior, whether the lookup is exact-match only, or any constraints beyond the number.
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?
A single front-loaded sentence with zero filler. The core action, resource, and lookup key are all present, and the sentence earns its place for a one-parameter tool.
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 is simple (one fully documented parameter, no nested objects), so the description is largely sufficient for calling it. With no output schema and no annotations, the description could still note what is returned and what happens when the number matches nothing, leaving a modest gap.
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 coverage is 100% and the regNo property already includes a description with format examples (제 2-116호). The description merely restates that the lookup is by number, adding no new meaning beyond the schema, so the baseline 3 for high coverage 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 verb (조회/retrieve), a specific resource (특정 상업등기선례/specific commercial registration precedent), and the keying method (예규번호로/by precedent number). The explicit lookup key distinguishes this from siblings search_precedents and list_precedents, so an agent can select it correctly without opening the schema.
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 search_precedents (keyword queries) or list_precedents (browsing). The intended context — 'you already know the exact precedent number' — is only implied by the tool name and the single required parameter, never explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
상업등기선례 통계를 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. '조회합니다' conveys a read-only query, but it does not mention what statistics are returned, whether they are aggregated, or any limitations. It provides minimal but non-misleading 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundant wording. It front-loads the verb and resource, making it appropriately sized for a simple parameterless statistics query.
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 is adequate for a simple parameterless tool, but because there is no output schema, it does not explain what statistics are included or how results are presented. This is a moderate gap: an agent can invoke the tool correctly, but may not know what to expect in the response.
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 tool has zero parameters, so the input schema is empty and there is nothing meaningful to document. Per rubric, a parameterless tool gets a baseline of 4; the description adds no unnecessary parameter details.
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 ('조회합니다' – retrieves) and a distinct resource ('상업등기선례 통계' – commercial registration precedent statistics). This clearly differentiates the tool from siblings that search, get, or list precedents, so an agent can identify its purpose without opening schemas.
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?
There is no guidance on when to use get_stats versus search_precedents, get_precedent_by_number, or list_precedents. The description implies a distinct statistics use case, but it does not state when the agent should choose this tool over the alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
상업등기선례 목록을 페이지별로 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 페이지 번호 (1부터 시작, 기본: 1) | |
| pageSize | No | 페이지당 항목 수 (기본: 20) | |
| status_badge | No | 현행만 조회할지 전체를 조회할지 (기본: all) |
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 does disclose that this is a paginated listing operation ('페이지별로 조회'), implying a read-style behavior. However, it does not mention sorting, filtering behavior beyond the schema parameters, or any operational constraints.
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, focused sentence with no filler. It immediately conveys the core action and pagination scope, which is appropriately concise for a straightforward list tool.
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 schema fully covers parameters, but there is no output schema and no explanation of what fields each precedent entry contains. More importantly, it lacks guidance for choosing this tool over search_precedents, which is a significant contextual gap given the sibling tools.
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 all three parameters, and coverage is 100%. The description adds only the general pagination idea already present in the parameter names and descriptions, so it does not meaningfully enrich parameter understanding.
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 action ('조회합니다' = retrieves) and the resource ('상업등기선례 목록' = commercial registration precedent list), and adds pagination context ('페이지별로'). However, it does not explicitly differentiate this tool from the sibling search_precedents beyond the generic word '목록'.
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?
There is no guidance about when to use this tool versus the siblings, such as search_precedents or get_precedent_by_number. The description only describes what the tool does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
상업등기선례를 키워드로 검색합니다. 제목에 포함된 키워드로 검색합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 최대 검색 결과 수 (기본: 20) | |
| query | Yes | 검색할 키워드 (예: 주식회사, 합병, 이사) | |
| status_badge | No | 현행만 검색할지 전체를 검색할지 (기본: all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the important behavior that keywords are matched against the title only, but it omits other behavioral details such as default status filtering (all vs current), limit handling, or result format.
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?
Two short, front-loaded Korean sentences with no filler. The first sentence states purpose, the second clarifies the match scope, and each 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?
For a simple 3-parameter search tool with fully described schema and no output schema, the description provides the essential search-scope constraint. It lacks any mention of return structure or default behaviors, but those are either inferable from the name or covered by the 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?
Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by specifying that the 'query' keyword matches the title, which the schema does not state. It does not add detail for limit or status_badge, but those are already well documented.
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 ('검색합니다' - searches) and resource ('상업등기선례' - commercial registration precedents), then narrows the scope with '제목에 포함된 키워드로'. This clearly distinguishes it from siblings like get_precedent_by_number (number lookup) and list_precedents (browse all).
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 title-based keyword search context makes the intended use clear, but the description never explicitly states when to choose this tool over list_precedents or get_precedent_by_number. No exclusions or alternative routing are provided.
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.
v1.0.0get_precedent_by_numberget_statslist_precedentssearch_precedentsScored across 4 tools
Each tool targets a distinct operation: keyword search, retrieval by number, paginated listing, and statistics. There is no ambiguity because the action and input type clearly separate them.
All tool names follow a consistent verb_noun pattern: search_, get_, list_, get_. The style is uniform and predictable across the set.
Four tools is well-scoped for a focused commercial registry lookup service. Each tool covers a necessary access pattern without redundancy or bloat.
The domain appears to be read-only access to commercial registry precedents. The set covers search, retrieval by number, list browsing, and statistics, which fully addresses typical user needs for such a registry.
Korean business registry, corporate info, parcel tracking, validation APIs
Korean public procurement law: rule-engine rulings, statutes search, live court precedents
Korean public procurement law: rule-engine rulings, statutes search, live court precedents
Full-text search over K-IFRS/K-GAAP standards and KASB accounting Q&A for Korean accountants
