law-ontology-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3.4/5 across 8 of 8 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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?
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
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 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
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: 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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
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 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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/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 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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
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 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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/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 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.
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: '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.
Usage Guidelines3/5
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.
Behavior2/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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/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: '특정 법령의 상세 정보를 조회합니다' (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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/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 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.
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 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.
Usage Guidelines3/5
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.

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:

[![law-ontology-mcp MCP server](https://glama.ai/mcp/servers/wintenboy/law-ontology-mcp/badges/card.svg)](https://glama.ai/mcp/servers/wintenboy/law-ontology-mcp)

Score Badge

Copy to your README.md:

[![law-ontology-mcp MCP server](https://glama.ai/mcp/servers/wintenboy/law-ontology-mcp/badges/score.svg)](https://glama.ai/mcp/servers/wintenboy/law-ontology-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/wintenboy/law-ontology-mcp'

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