Allows Codeium's Windsurf IDE to query Korean law ontology, enabling law-related searches and analysis within the development environment.
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., "@law-ontology-mcp search for laws related to personal information protection"
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.
법제처 법령 LOD 온톨로지의 SPARQL 엔드포인트를 활용한 법령 검색 MCP 서버입니다.
git clone https://github.com/wintenboy/law-ontology-mcp.git
cd law-ontology-mcp
pip install -e .Related MCP server: LexLink
MCP 클라이언트 설정 파일에 추가:
{
"mcpServers": {
"law-ontology": {
"command": "law-ontology-mcp"
}
}
}클라이언트 | 설정 파일 경로 |
Claude Desktop (macOS) |
|
Claude Desktop (Windows) |
|
Cursor |
|
Windsurf |
|
Claude Code |
|
도구 | 설명 |
| 키워드로 법령 검색 |
| 법령 상세 정보 조회 |
| 소관부처별 법령 검색 |
| 지역별 자치법규 검색 |
| 법령 유형별 통계 |
| SPARQL 쿼리 직접 실행 |
| 법령 유형별 목록 조회 |
| 법령 온톨로지 네트워크 시각화 |
"개인정보보호 관련 법령 검색해줘"
"민법 상세 정보 보여줘"
"국방부 소관 법령 찾아줘"
"서울특별시 자치법규 검색해줘"
"법령 유형별 통계 알려줘"
"법령 온톨로지 네트워크 시각화해줘"MIT
SPARQL 쿼리를 직접 실행합니다. PREFIX는 자동 추가됩니다. 주의: FILTER에서 contains(), str(), regex(), lang() 등 문자열 함수는 서버에서 지원하지 않습니다. URI 비교만 가능합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| include_prefixes | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses two behavioral traits: automatic PREFIX addition and non-support of string functions in FILTER (only URI comparisons allowed). However, it does not state whether the tool is read-only, what SPARQL query types are allowed, or any auth/rate-limit implications, leaving significant safety behavior undisclosed.
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, stating the core purpose in the first clause and adding a crucial limitation as a clearly marked caution. Every sentence earns its place, with no redundancy or irrelevant details.
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 the core function and a significant limitation, and the output schema documents return values. However, for a tool that executes raw SPARQL, it lacks essential context: whether the endpoint supports only SELECT or also updates, whether mutations are allowed, and any safety constraints. This gap is notable given the tool's power and absence of annotations.
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 0%, so the description must compensate. It explains that PREFIX is auto-added, which relates to the include_prefixes parameter and its default true, offering some semantic value. However, it does not explain that setting include_prefixes=false disables this behavior, nor does it elaborate on the query parameter syntax beyond general SPARQL.
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 function: 'SPARQL 쿼리를 직접 실행합니다' (executes SPARQL queries directly). The term '직접' (directly) differentiates it from the sibling law-specific search tools, making its purpose as a low-level query execution tool 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?
The description implies use cases (direct SPARQL execution) but provides no explicit guidance on when to choose this over sibling tools like search_law. No alternative tools are mentioned or excluded, leaving the agent to infer the niche from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
특정 법령의 상세 정보를 조회합니다. 법령 리소스 ID(예: LSI259471, SCPB2200000130717)를 사용합니다. search_law 결과의 URI에서 ID를 추출할 수 있습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| resource_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | 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 behavioral disclosure. It explains the ID format and source but does not disclose whether the operation is read-only, what 'detailed information' includes, error behavior, or access requirements. The description is too sparse to give the agent a clear behavioral model.
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-loaded with the core purpose, and every sentence adds value. It avoids redundancy and is appropriately concise for a simple single-parameter lookup 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?
For a simple lookup with one parameter and an output schema available, the description covers the essential usage steps: what it does and how to get the required ID. It lacks details like return structure or error conditions, but given the output schema exists and the tool's low complexity, the description is sufficiently complete for an agent to invoke it correctly.
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 provides only a bare resource_id string with no description. The description compensates fully by explaining what the parameter is (법령 리소스 ID), providing concrete examples (LSI259471, SCPB2200000130717), and explaining how to obtain it from search_law results. This is strong added value 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?
The description clearly states the tool's function: '특정 법령의 상세 정보를 조회합니다' (retrieves detailed information of a specific statute), with a specific verb and resource. It also references 'search_law' for ID extraction, but does not explicitly distinguish from sibling tools like list_laws or get_statistics, so it's clear but not fully differentiated.
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 context by stating the ID can be extracted from search_law results, providing a workflow hint. However, it doesn't explicitly state when to use this tool vs alternatives, nor does it provide any exclusions or prerequisites beyond the ID source. This is implied guidance, not explicit.
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 |
|---|---|---|---|
| type | No |
| Name | Required | Description |
|---|---|---|
| result | 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 behavioral disclosure. It merely states that statistics are retrieved, without explaining the optional 'type' parameter, return format, or any other behavioral aspects.
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, making it very concise with no unnecessary words. However, the brevity results in under-specification, omitting details about parameters and behavior, which balances to an average score.
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?
Even though the tool has only one optional parameter and an output schema, the description is too vague. It does not clarify what statistics are offered or how the 'type' parameter affects results, leaving significant gaps in understanding for an agent.
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 includes an optional 'type' parameter, but the description does not mention it at all. With schema description coverage at 0%, the description was expected to compensate, but it fails to provide any meaning or usage for the parameter.
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 clear verb ('조회합니다' - retrieves) and resource ('법령 데이터 통계' - statistics of law data), effectively communicating the tool's core function. It is distinct from sibling tools like search_law or list_laws, though it lacks specificity about what kinds of statistics are returned.
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 provides no guidance on when to use this tool compared to alternatives. It does not mention any context, prerequisites, or scenarios where this tool would be preferred over sibling tools.
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 |
|---|---|---|---|
| type | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a read-only operation ('조회합니다' = retrieve/inquire), which is a behavioral trait. However, it does not disclose pagination, default limit behavior, or the possibility of returning all types when 'type' is null. The description is minimally transparent for a simple list operation.
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 sentences that directly state the purpose and key constraint. Every word contributes; no filler or redundancy. Highly concise and well-structured.
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 the core purpose and differentiation but lacks guidance on when to use this tool versus siblings like search_by_agency or search_by_region. It does not mention the optional 'type' parameter or the default limit. Given the simple nature and presence of an output schema, the description is adequate but not fully complete.
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 0%, so the description must compensate. It adds meaning for the 'type' parameter by stating list is '유형별' (by type), but does not explain the 'limit' parameter at all. The enum values in the schema partially cover type semantics, but the limit parameter remains unexplained. Thus, the description adds some value but not full compensation.
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 retrieves a list of laws by type ('법령 유형별 목록을 조회합니다') and explicitly distinguishes it from keyword search ('키워드 검색 없이 유형별 법령 목록을 가져옵니다'). This differentiates it from sibling tools like search_law, making the purpose specific and 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?
The description implies when to use the tool: when you need a list by type without keyword search. However, it does not explicitly mention alternatives or provide exclusions. The hint 'without keyword search' suggests a contrast with search_law, but no clear when/when-not guidance is given.
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 |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| agency_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior, but it only states the basic search function. It does not mention the return format, whether results are a list or detail, pagination, or any constraints beyond the agency filter. The output schema exists but is not described.
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, clear sentence with no filler words. It is front-loaded and appropriately sized for a simple search tool, earning full marks for conciseness.
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 tool has 3 parameters, no annotations, and 0% schema coverage in the description, the description is insufficient for an agent to fully understand invocation context. While the output schema may cover return values, the lack of usage guidelines and parameter semantics makes it incomplete for successful use.
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 provides no parameter information, and schema description coverage is 0%. The schema contains enums and defaults, but the description does not compensate by explaining what 'type' means (법령 vs 행정규칙) or how 'limit' works. Parameters are left to be inferred entirely from 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?
The description clearly states the tool's function: searching laws (법령) by responsible ministry (소관부처). The verb 'searches' and resource 'laws' are specific, and the agency filter distinguishes it from sibling tools like search_by_region and search_law.
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 use when searching laws by agency, but provides no explicit guidance on when to use this versus general search_law or search_by_region, nor any exclusions. This fits the 'implied usage' category.
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 | ||
| region_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral information. It only states the happy path (searches by region) and does not disclose result ordering, pagination, error behavior, or output format. The output schema exists but is not referenced 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the tool's purpose. It is front-loaded with the action and contains no redundant information, making it highly concise and well-structured.
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 absence of annotations and the 0% schema description coverage, the description is too terse to be complete. It lacks usage guidance, meaningful parameter semantics for 'limit', and behavioral context, leaving the agent to infer critical details from the schema alone.
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 0%, so the description must compensate for parameter clarity. It clarifies that region_name is the regional filter but says nothing about the 'limit' parameter or its effect. The description does not fully bridge the gap left by 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?
The description uses the specific verb '검색합니다' (searches) and clearly specifies the resource '자치법규' (local ordinances) and scope '지역별' (by region). This makes the tool's purpose immediately clear and distinguishes it from siblings like search_law and search_by_agency.
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 when to use the tool (when searching ordinances by region) but does not explicitly mention alternatives or exclusions. There is no guidance on when to prefer this over search_law or search_by_agency, leaving usage somewhat implied.
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 |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| agency | No | ||
| keyword | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the search scope (titles/provisions, all types) but does not disclose behaviors like result ordering, limits, case sensitivity, or error handling. It adds little beyond the tool's name.
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 three concise sentences, front-loaded with the core purpose. It provides useful scope information without wasted words, making it easy to parse.
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 4 parameters and an output schema, but the description only covers keyword search and broad types. It omits guidance on how the 'type', 'limit', and 'agency' parameters affect the search, and does not mention result format. It is adequate for a simple search but incomplete for the parameter richness.
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 0%, so the description must compensate. It mentions 'keyword' and lists several law types that map to the 'type' parameter, but it does not explain the 'limit' or 'agency' parameters, nor the full set of enum values. The contribution is marginal.
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 identifies the tool as a keyword-based legal search across titles and provisions, and explicitly lists searchable law types. This distinguishes it from siblings like search_by_agency or get_law_detail, which focus on specific filters or detail retrieval.
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 appropriate use cases: when you need to find laws by keyword regardless of type. It contrasts with agency/region-specific tools by stating it covers all legal types, but it does not explicitly name alternative tools or exclude scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
법령 온톨로지 네트워크를 시각화합니다. 온톨로지 스키마(클래스/프로퍼티 관계)와 법령 간 관계 네트워크를 인터랙티브 HTML로 생성합니다. 키워드를 입력하면 검색된 법령의 관계 네트워크도 함께 표시됩니다.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| keyword | No | ||
| output_path | No | ||
| open_browser | No |
| Name | Required | Description |
|---|---|---|
| result | 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. It mentions generating interactive HTML but fails to disclose side effects such as writing to a file via output_path or opening a browser via open_browser (which defaults to true). This is a significant gap since the tool can create files and launch UI, which the user should know.
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-loaded with the primary purpose, and every sentence adds value. It is concise without redundant filler, making it efficient 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?
The tool has 4 parameters, side effects (file creation, browser opening), and an output schema, but the description omits these details. It covers the main functionality but leaves out important context like how the HTML is produced, what happens with the keyword, and what the output contains, 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only vaguely mentions 'keyword' without naming parameters or explaining limit, output_path, or open_browser. It does not compensate for the low schema coverage, as no parameter semantics are provided beyond a hint that keywords can filter the visualization.
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 'visualizes the law ontology network' with a specific verb and resource. It also distinguishes itself from siblings like search_law and get_law_detail by focusing on visualization and producing interactive HTML, making its 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?
The description implies usage when network visualization is needed, and mentions keyword-based scanning for specific laws. However, it does not explicitly state when to use this tool instead of siblings, nor does it provide exclusions or alternatives. This is clear context but lacks explicit guidance.
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.0execute_sparqlget_law_detailget_statisticslist_lawssearch_by_agencysearch_by_regionsearch_lawvisualize_law_networkScored across 8 tools
Most tools have distinct purposes, but the search variants (search_law, search_by_agency, search_by_region, list_laws) could potentially be confused since they all retrieve laws with different filters. The descriptions help clarify, and execute_sparql, get_statistics, and visualize_law_network are clearly distinct.
All tool names follow a consistent verb_noun pattern using lowercase and underscores (search_law, get_law_detail, search_by_agency, etc.). The naming consistently reflects the action and target, making the API predictable.
With 8 tools, the server is well-scoped for a law ontology domain. Each tool serves a specific purpose, and there is no unnecessary bloat or overly sparse coverage.
The tool set covers the full spectrum of read-only law ontology interactions: searching, filtering by agency/region, listing by type, retrieving details, viewing statistics, running arbitrary SPARQL queries, and visualizing relationships. No obvious gaps for the stated purpose.
Korean government open data - weather, population, law search via data.go.kr
Search EU legislation, CJEU case law, and treaties; traverse CELLAR graph; browse EuroVoc concepts.
Temporal search and comparison for official Luxembourg and reviewed EU law, with provenance.
Find official Korean public datasets, agency-site menus, disclosure listings, and source URLs.