korean-privacy-law-mcp

Server Quality Checklist

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

Latest release: v0.8.3
Disambiguation5/5
Each tool targets a distinct legal resource or operation (e.g., comparing versions, searching decisions, retrieving specific text types). Despite the large number, descriptions clearly differentiate between similar-sounding tools like compare_articles, compare_old_new, and compare_admin_rule_old_new by specifying their exact input targets.
Naming Consistency5/5
All tool names uniformly follow a verb_noun convention (e.g., search_law, get_law_text, compare_old_new, verify_pipa_citation). The naming is consistently in snake_case with no mixing of styles or vague verbs.
Tool Count3/5
With 37 tools, the server is on the heavy side. However, the server's scope (Korean privacy law research) is broad enough to warrant many specialized operations. The count is borderline but justified by the need to cover diverse legal resources and comparative functions.
Completeness5/5
The tool surface covers the full lifecycle of legal research: searching, retrieving current and historical texts, comparing versions and articles, examining decisions, appeals, constitutional decisions, English translations, term definitions, and citation verification. No obvious gaps for the domain of Korean privacy law.
Average 4.4/5 across 37 of 37 tools scored. Lowest: 3.5/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
- Last stable release on May 10, 2026
- 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 must disclose behavioral traits. It does not mention read-only nature, rate limits, authentication needs, or any side effects. The description only describes the tool's function without 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with relevant details, but it includes a parenthetical reference to an internal code (W2.5) that may not be clear to all users. It is relatively concise but could be more streamlined.
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?
For a search tool with three parameters and no output schema, the description covers the domain and usage context. It mentions follow-up tool and example keywords. However, it lacks information about pagination, result format, or any limitations, which would be useful for completeness.
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 100%, so each parameter has a description in the schema. The tool description adds example keywords and context (e.g., PIPA violations) but does not significantly enhance understanding beyond the schema's parameter descriptions. The examples are helpful but not critical.
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 search for administrative appeal precedents (행정심판 재결례 검색) from a specific source (법제처 lawSearch · target=decc). It distinguishes itself from the sibling tool get_admin_appeal_text by indicating that tool retrieves the full text. The verb '검색' and the resource are specific.
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 recommends using get_admin_appeal_text for full text after searching, providing a clear workflow. It also gives context about the types of cases covered (PIPA violations, administrative dispositions). However, it does not specify when not to use this tool compared to other search tools like search_admin_rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It accurately describes the return of hierarchical relationships and mapping sources (PIPC combined laws plus ministry mapping). No mention of destructive or auth requirements, which is acceptable for a read-only query.
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 with the main action in parentheses. Every sentence adds unique value: target service, hierarchy details, data sources, parameter advice, and follow-up steps. No wasted words.
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?
Despite no output schema, the description adequately explains what is returned (hierarchy and related laws) and includes context about data sources. It covers the main behavioral aspects for a 2-parameter tool, though the exact return structure could be more concrete.
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?
The input schema already fully describes both parameters with origins from search_law results (100% coverage). The description only adds reinforcement that mst is recommended and one parameter is needed, providing minimal additional semantic value.
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 queries related laws and subordinate administrative rules with a specific target (lsStmd) and returns hierarchical relationships. However, it does not explicitly differentiate from sibling tools like get_delegated_laws or get_intelligent_related_laws, leaving some ambiguity.
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 recommends using mst parameter and provides next-step tools (get_law_text, search_admin_rule) for text retrieval, implying this tool is for structure. But it lacks explicit guidance on when to use versus alternatives or when not to use.
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, the description carries full behavioral burden. It discloses that the tool returns a list with annex serial number, related law ID, and PDF link, and notes that PDF text extraction is only available in v1.1. It does not mention side effects, authentication, or rate limits, but for a read-only list retrieval, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a short note on next steps. It is efficiently front-loaded with the main purpose and key details, using minimal words. It could be slightly more structured, but it is still concise.
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 3 parameters, no output schema, and no annotations, the description provides sufficient context: it explains the tool's purpose, parameter usage, response fields (annex serial number, related law ID, PDF link), and suggests follow-up tools. It does not cover error handling or pagination, but for a straightforward list retrieval, it is 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 coverage is 100%, so baseline is 3. The description adds context for lawName (parent law) and explains the knd enum values (별표/서식/부칙별표/부칙서식/전체) beyond the schema's Korean names. However, it does not add significant new information beyond what is already in the schema descriptions.
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 annexes and forms for a given law (법령 별표·서식 목록), including specific filtering by kind (별표/서식/부칙). It distinguishes itself from siblings like get_law_text (which retrieves the main text) and search_admin_rule (for administrative rules).
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 explains when to use this tool: for standard forms like processing policies and consent forms (처리방침·동의서 같은 표준양식이 별표·서식에 위치). It provides next steps (사용 get_law_text for context, search_admin_rule for administrative rule annexes), but does not explicitly state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It mentions auto-summarization for long texts and the data source, but lacks details on auth requirements, rate limits, or safe read-only hint. Partial transparency.
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, with key info front-loaded: purpose, extracted fields, auto-summarization, and follow-up suggestions. Every sentence adds value.
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 retrieval tool with one parameter and no output schema, the description covers what it returns, the ID source, and auto-summarization. Could mention formatting details but sufficient for typical use.
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?
Only one parameter (id) with 100% schema coverage. The schema already explains the ID source. The description adds minor context (source, auto-summarization) but not essential beyond schema. Baseline 3 applies.
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 it extracts the full text of constitutional decisions, including case name, number, summary, etc. It also distinguishes from sibling search tools via '다음: search_constitutional_decisions로 유사 사건, intelligent_law_search로 인용 조문 검색.' The verb 'get' matches the tool name.
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 contexts (when full text is needed, auto-summarization for long texts) and suggests next steps. However, it does not explicitly state when not to use this tool versus other get_ tools for different document types.
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?
No annotations are provided, so the description carries the full burden. It describes the action (search metadata) but does not disclose any behavioral traits such as rate limits, authentication needs, or side effects. The description is adequate for a read-only search 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?
The description is concise: two sentences plus a usage pointer. It is front-loaded with the main purpose and efficiently includes key context and next steps without waste.
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?
The description covers the tool's purpose, scope, and typical use cases, and it points to subsequent tools. However, since there is no output schema, the description does not detail the metadata fields returned, which is a minor gap for completeness.
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 100%, and the description adds the same context as the schema (e.g., PIPC and ministry instructions). It does not provide additional meaning beyond what is already in the schema, so no extra value is added.
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 searches administrative rules (행정규칙 검색), specifies the target (lawSearch, target=admrul), and lists types (고시·훈령·예규). It distinguishes from siblings by noting that this tool retrieves metadata, while get_admin_rule_text and compare_admin_rule_old_new handle text and comparisons.
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 directs the agent to next tools (get_admin_rule_text and compare_admin_rule_old_new) after using this one, providing a clear workflow. However, it does not explicitly state when not to use this tool or alternatives among the many sibling search tools.
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?
No annotations provided, so description should compensate. It states 'all decisions' but doesn't mention authentication, rate limits, or read-only nature. Minimal behavioral disclosure.
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?
Description is concise, front-loaded with purpose, and efficiently covers types, domain core, and next tool without redundancy.
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?
No output schema, but description covers what data is accessible (위반 사례, 과징금, 시정조치). Could mention pagination, but not essential given schema parameters. Adequate for 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?
All 3 parameters have schema descriptions (100% coverage). Description adds example keywords but doesn't significantly extend beyond schema. Baseline 3 is appropriate.
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?
Description clearly states the tool searches PIPC decisions, lists specific types (심의·의결, 침해요인 평가, 분쟁조정), and distinguishes from sibling tool get_pipc_decision_text by mentioning full text retrieval as next step.
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?
Description indicates use case (direct check of violations, fines, corrective orders) and suggests follow-up tool. However, no explicit when-not or comparison with sibling search tools like search_privacy_cases.
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?
No annotations are provided, so the description carries the full burden. It discloses the search algorithm (BM25), chunk counts, doc_type selection, and automatic attribution. It does not explicitly state read-only nature, but being a search tool it is implied. Some behavioral aspects like rate limits or pagination are not covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with a front-loaded purpose statement, detailed doc_type breakdown, differentiation from law API, attribution notice, and sibling alternatives. Every sentence adds value, though slightly verbose in the doc_type list.
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?
There is no output schema, so the description should explain return format. It mentions automatic attribution and page info but does not specify the structure or content of results (e.g., snippets, metadata). Given the tool's complexity, this is a gap, but the detailed input schema partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds significant value by detailing each doc_type enum with counts and dates, and specifying default and max for display, beyond what the schema provides.
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 it performs BM25 search over 4 types of PIPC official guides with chunk counts and dates. It distinguishes itself from siblings by explicitly mentioning alternatives like search_privacy_cases 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (for PIPC domain-specific guides not in law API) and provides explicit alternatives for cases and law. However, it does not include explicit when-not conditions or prerequisites.
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?
No annotations are provided, so the description carries full responsibility. It mentions the target (detc) and metadata nature of results, but does not disclose behavioral traits such as rate limits, authentication, or error handling. The description gives a general sense but lacks depth.
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 plus a referral, all front-loaded with core purpose. Every sentence adds necessary information without redundancy. It is highly efficient.
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?
While the description states results are metadata about decisions (위헌·합헌·각하 등), it does not specify the exact fields or structure returned. With no output schema, more detail on return format would improve completeness. Pagination info is covered by schema but not description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds value by explaining the query parameter with example keywords ('개인정보 자기결정권', '주민등록번호') and hinting at matching logic (사건명·사건번호 매칭). This enriches the schema's basic descriptions.
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 searches for constitutional court decisions (헌법재판소 결정례) with specific types (위헌·합헌·각하) and provides an example case (99헌마513). It also distinguishes from the sibling tool get_constitutional_decision_text by directing users to retrieve full text after 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 suggests using get_constitutional_decision_text for full text after searching, providing a clear workflow. However, it does not specify when to use this tool over other search tools (e.g., search_law, search_interpretations) or state exclusions, which slightly limits guidance.
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?
No annotations are provided, so the description carries full burden. It reveals the target source (elaw) and suggests read-only behavior by describing it as a search tool, but does not explicitly state it is non-destructive, rate limits, or auth requirements. The description is adequate but could be more transparent about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and front-loaded with the core purpose. Some internal codes (W2.7, v2) may be cryptic, but overall information density is high without unnecessary fluff.
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 adequately covers usage context and next steps. It does not describe output format, but for a search tool that returns a list, this is acceptable. The description is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions. The description adds value by explaining query matching behavior (accepts English and Korean names with examples). This extra context justifies a score above the baseline 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 clearly specifies the tool's purpose: searching English versions of Korean statutes (영문 법령 검색) with targets like PIPA. It distinguishes itself by mentioning specific use cases (GDPR comparison, overseas reports) and directing to subsequent tools (get_english_law_text, compare_articles), differentiating it from sibling tools like search_law (Korean text) or compare_articles (comparison).
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 provides context for when to use the tool (searching English law translations for tasks like PIPA research or GDPR comparison) and mentions alternative workflows (use get_english_law_text for full text, compare_articles for PIPA↔GDPR comparison). It lacks explicit 'when not to use' guidance, but the context is strong.
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?
No annotations are provided, so the description must inform about behavioral traits. It clarifies that the tool returns metadata of official decisions (not full text) and points to a follow-up tool. However, it does not disclose any limits, authentication needs, or the nature of the response format, which would be helpful for a search tool.
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 very concise: two sentence fragments and a follow-up suggestion. Every part is essential, with no redundant information. It front-loads the tool's core purpose and efficiently guides usage.
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 that there is no output schema, the description should ideally specify what fields are returned in the results. It only mentions '메타' (metadata), which is vague. While it hints at the utility, it could be more complete by listing typical result fields like case number, title, date, etc.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema covers all parameters with descriptions, the tool description adds valuable context by specifying that the query matches against subject name, case number, inquiry agency, and reply agency. This goes beyond the schema's basic description of 'keyword' and enhances understanding.
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 that this tool searches for statutory interpretation cases from the Ministry of Government Legislation, specifying the resource (법제처 lawSearch, target=expc) and content (official reply metadata). It distinguishes from sibling search tools like search_law or search_admin_appeals by mentioning PIPA and enforcement ordinance application cases, and points to the follow-up tool get_interpretation_text.
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 states when to use the tool: 'when in doubt about the interpretation of provisions' and directs users to get_interpretation_text for the full text. It does not explicitly exclude other scenarios, but the context is clear enough for proper usage.
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?
No annotations are provided, so the description carries the full burden. It states the output is a flat list of mappings and implies a read-only operation, but it lacks details on authentication, rate limits, or the exact structure of the returned list. Basic behavioral transparency is present 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 is concise at a few sentences, with the main purpose front-loaded. It includes an example and actionable next steps without unnecessary verbosity. Every sentence adds value.
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 the lack of an output schema, the description explains the high-level return value (flat list of mappings) and provides an example count (59). However, it does not specify the exact fields in each mapping item, which would improve completeness. Nonetheless, for a simple tool, it is fairly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter lawId, and the description reinforces its meaning (from search_law, for delegated relations). The description adds context beyond the schema by relating it to the overall workflow, so it scores above baseline.
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 explicitly states that the tool returns delegated law relations (법령 위임조문 관계) as a flat list mapping articles of the main law to enforcement decree/rules. It specifies the source (법제처 lawService) and provides an example (PIPA with 59 delegated articles), clearly distinguishing it from siblings like get_law_text or get_three_tier.
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 provides clear context by suggesting next steps (use get_law_text for text, get_three_tier for visualization) and gives an example usage scenario. However, it does not explicitly state when not to use this tool versus 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It transparently explains AI-based semantic matching, absence of direct text matching, and output is list of article titles. Behavior is well-disclosed, though read-only nature could be more explicit.
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?
Description is three sentences: core purpose, sibling distinction, and follow-up action. Every sentence adds value, no redundancy or fluff. Ideal length for quick agent comprehension.
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?
No output schema, but description states return is list of article titles. Parameters are fully documented. Follow-up action provided. Missing details like pagination (though display parameter suggests limit), but overall sufficient for a simple recommendation 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 description coverage is 100% (all 3 parameters described). The description repeats schema info without adding significant new meaning beyond mentioning broader matching for query. Baseline 3 is appropriate as description doesn't substantially extend schema understanding.
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?
Description clearly states the tool returns AI-recommended related laws (조문 list) based on keyword semantic similarity. It distinguishes itself from sibling intelligent_law_search by noting broader matching, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description contrasts this tool with intelligent_law_search (broader matching) and advises follow-up with get_law_text(lawId) for full text. While it hints at when to use, it lacks explicit when-not-to-use instructions, resulting in good but not perfect guidance.
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?
No annotations are provided, so the description carries full responsibility. It describes the comparison operation but does not explicitly state that it is read-only or non-destructive. While the nature of the tool implies a safe query, transparency could be improved by stating that it does not modify any data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using four sentences to cover purpose, parameters, an example, and follow-up tools. It is front-loaded with the main objective. A slight improvement could be breaking into bullet points for readability, but overall efficient.
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?
No output schema is provided, and the description does not specify the return format or structure of the comparison results. While the example implies what the output looks like, explicit details (e.g., whether it's a list of mappings, fields returned) are missing, which reduces completeness for a simple tool with two parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with descriptions. The description adds context: mst must be the '본법 mst' from search_law/get_law_history, and knd values are explained with their meanings. This enhances understanding beyond the schema alone.
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 purpose: comparing three-tier delegation and citation relationships among Korean law, enforcement decree, and enforcement regulation. It specifies the data source (lawService, target=thdCmp) and provides concrete examples like PIPA §29 to 시행령 §30. The tool is distinct from siblings as no other tool explicitly offers this three-tier comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two modes (knd=1 for citation, knd=2 for delegation) with default behavior. It gives a real-world example (PIPA safety measures) and suggests subsequent steps using get_law_text and get_admin_rule_text. This provides clear guidance on when to use this tool and what to do next.
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?
No annotations are provided, so the description carries full burden. It describes the search functionality and abbreviation recognition, but does not disclose behavioral traits like rate limits, authentication, or side effects. The quirk about short law names is mentioned in the display parameter, but overall transparency is moderate.
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 purpose and efficiency. Every sentence adds value, and no extraneous information is present.
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 search tool with 4 fully documented parameters and no output schema, the description explains what the search returns (law names, metadata) and mentions abbreviation recognition. It is fairly complete, though a bit more detail on return format could help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The description adds value by explaining abbreviation recognition in both main description and query parameter. The display parameter includes a note about a quirk with short law names, which goes beyond 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 '법령 검색' (law search) with specific verb+resource, and distinguishes from siblings by pointing to get_law_text and get_related_laws for further steps. It also mentions abbreviation recognition and scope prioritization.
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 indicates when to use this tool (searching laws) and provides next steps (get_law_text, get_related_laws). It implicitly contrasts with siblings but does not explicitly state when not to use this tool.
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?
No annotations are provided, so the description must convey behavioral traits. It implies a read-only retrieval but does not explicitly state its safety, side effects, or access requirements. The description is adequate but lacks explicit disclosure of non-destructive behavior.
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 extremely concise with two sentences plus a note, no superfluous words. It front-loads the core purpose and immediately provides relevant usage 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?
For a simple retrieval tool with no output schema, the description explains usage context and parameter correctly but does not describe the output format (text/structured) or any limits. Slightly incomplete for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the mst parameter (coverage 100%), and the description adds critical context: it explains the value's origin (search_admin_rule result) and warns against confusing it with a shorter admin rule ID, thus adding meaning 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 clearly states the tool retrieves the full text of administrative rules (행정규칙 본문 조회) and specifies the source (법제처 lawService · target=admrul). It distinguishes itself from siblings by referencing search_admin_rule for obtaining the required mst parameter and suggesting a subsequent tool for comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use the mst from search_admin_rule results and warns that it differs from a shorter admin rule ID, preventing misuse. It also recommends next step compare_admin_rule_old_new, providing clear usage context.
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?
No annotations are provided, so the description must disclose behavioral traits. It states the tool compares old and new versions and highlights changes, but does not mention auth requirements, side effects, data persistence, or error handling. For a read-like operation, this is adequate but lacks detail.
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 with no extraneous content. The first sentence defines the tool's function, and the second provides usage guidance and links to related tools. It is 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 the tool's single parameter and straightforward comparison task, the description covers the main aspects: what it compares, how changes are highlighted, and a practical example. Though no output schema exists, the description outlines the output format (basic info + list of changed articles). Minimal gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'mst' is fully documented in the schema. The description adds value by explaining that both old and new mst are accepted and how to obtain them (from search_law or get_law_history). This goes beyond the schema's own description.
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 it compares old and new versions of a law, highlighting changes with `**변경**`. It specifies the target (법제처 lawService · target=oldAndNew) and gives a concrete use case (PIPA tracking). This differentiates it from siblings like get_historical_law and get_law_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (tracking changes in frequently amended laws like PIPA) and what to do next (use get_historical_law for full text, get_law_history for other comparisons). It provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses that long reasons are automatically abbreviated ('긴 이유는 자동 축약') and extracts specific fields. This adds behavioral context beyond basic function.
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?
Description is concise, front-loads core purpose, and includes usage guidance and sibling references in a well-structured manner.
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?
No output schema, but description lists output components and mentions auto-summarization of long reasons. It provides sufficient context for effective use, though response format and error handling are not covered.
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 100% with a clear parameter description. Tool description repeats the schema info but adds context that ID comes from search_interpretations results, which is helpful but not additional semantic depth.
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?
Description clearly states the tool retrieves the full text of statutory interpretation cases, listing specific components (subject, query, reply, reasons). It distinguishes from siblings by mentioning alternative tools like search_interpretations and get_law_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenario: 'when there is doubt about PIPA provision application, directly check official interpretations.' Also suggests alternatives: search_interpretations for similar cases and get_law_text for cited provisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 states the tool outputs basic info and a list of changed articles with `**변경**` highlights, which is transparent. It does not mention safety or side effects, but given it is a comparison tool, destructive actions are unlikely.
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: it states the core function, highlights key features, provides a concrete use case, and suggests next steps—all in a few sentences with no redundancy. The most important information is front-loaded.
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 the tool has no output schema, the description provides a reasonable overview of return content (basic info + changed articles list with highlights). It could be more specific about the structure but is sufficient for an agent to understand what to expect.
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 input schema has 100% coverage, and the description adds significant meaning: it explains that the mst parameter accepts both new and old serial numbers and references how to obtain it from search_admin_rule results. This goes well beyond the schema's own description.
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 compares old and new administrative rules, with parallel display and highlighted changes. It distinguishes from siblings like compare_articles and compare_old_new by specifying '행정규칙' (administrative rules) and provides a concrete use case for PIPC notice tracking.
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 gives clear context for use: tracking PIPC notice revisions. It names alternative tools (get_admin_rule_text for full text, search_admin_rule for other notices) and suggests next steps. It does not explicitly exclude other scenarios or differentiate from all siblings, but the guidance is solid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description compensates by detailing internal calls (dual lawService invocations), truncation behavior, and diff absence. Missing details on rate limits or error handling, but overall sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with purpose first, then details. Slightly wordy with technical Korean phrases but overall efficient for the complexity.
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?
With nested params and no output schema, description covers internal workflow, truncation, and usage guidance. Minor gap: no mention of return format, but sufficient for agent to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions; description adds context by explaining mst comes from search_law, jo supports both Korean and numeric formats, and efYd is time-specific. Adds value beyond 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?
Description clearly states the tool compares two legal articles side-by-side, with specific examples (PIPA §15 vs §17). It distinguishes from sibling tools like compare_admin_rule_old_new by focusing on general legal articles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use (comparing specific articles), limitations (no auto-diff, 6,000 character truncation per side), and next steps (get_law_text, search_law). Provides clear context for agent decision-making.
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?
No annotations are provided, so the description must carry the behavioral disclosure burden. It mentions the source (lawService, target=elaw) and text structure, but does not cover error handling, authentication, or data freshness. Adequate for a simple one-parameter retrieval tool, but could be more explicit.
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?
Three concise sentences that front-load the primary purpose and structure, with additional usage guidance and sibling references. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description provides sufficient context: source, structure, use cases, and related tools. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter mst. The tool description adds context by referencing its use with get_law_text, reinforcing the parameter's role. This adds marginal value beyond the schema definition.
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 that the tool retrieves English law text from the Ministry of Legislation lawService, with a specific structure (chapter/article). It distinguishes itself from siblings like get_law_text (Korean) and compare_articles (comparison).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly suggests when to use this tool (GDPR comparison, overseas reports) and recommends alternatives for related tasks (get_law_text for Korean, compare_articles for comparison).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the data source, number of cases, retrieval method (BM25 with contextual retrieval), auto-attribution, and differentiator from other APIs. It falls short of mentioning pagination behavior or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense without being verbose, covering core function, filters, differentiator, example, attribution, and sibling tool references in a logical order. Minor redundancy could be trimmed but overall 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 7 parameters, no annotations, and no output schema, the description adequately explains the tool's operation, filtering capabilities, and output characteristic (attribution). It lacks description of result format but provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining the tree filter structure, year range narrowing, and providing an example that illustrates parameter interaction, going beyond the schema definitions.
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 performs BM25 search on PIPC privacy.go.kr counseling cases and explicitly contrasts with sibling tools search_privacy_guides and search_pipc_decisions, making the purpose and differentiation unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool versus alternatives, stating to use search_privacy_guides for official guides and search_pipc_decisions for violation decisions. It also gives a concrete example query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden. It discloses the retrieval method (BM25, Contextual Retrieval), filtering capability via source_type, and automatic PIPC attribution. However, it does not mention rate limits, pagination, or result structure, which are minor gaps given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, packing key information (coverage, differentiation, filtering, attribution, alternatives) into a single paragraph. It front-loads the main purpose. Could be slightly more structured with bullet points, but it remains highly readable.
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 the tool's complexity (2,432 chunks, BM25, source filtering), the description is quite complete. It covers scope, retrieval method, filtering, attribution, and alternatives. No output schema exists, and the description omits response format, but for a search tool this is acceptable given standard expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all three parameters described. The description adds value by explaining the source_type enum values ('guide=PIPC 공식 안내서 / case=privacy.go.kr 상담사례') and providing query examples, going beyond the schema definitions.
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 purpose as a unified BM25 search over PIPC official guides and counseling cases. It explicitly differentiates from sibling tools like search_privacy_cases and search_privacy_guides by noting it is broader and includes both sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description recommends this as the first-entry search tool and explicitly suggests narrower alternatives ('다음: 더 좁은 검색은 search_privacy_cases·search_privacy_guides, 법조문은 search_law·get_law_text'). This provides clear when-to-use and when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses automatic abbreviation of long reasons, a key behavioral trait. No annotations are provided, so the description carries full burden. It specifies the source (lawService, target=decc) and extraction fields, but does not mention error handling or permissions, which is partially acceptable for a read-only tool.
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?
Single sentence packed with purpose, extraction details, behavior, and usage guidance. Every part is useful; no redundancy. The structure front-loads the main function and ends with actionable next steps.
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 the tool has no output schema, the description adequately explains what is extracted (specific fields) and mentions abbreviation behavior. However, it does not specify the output format (e.g., JSON keys) or whether the full text is returned. Still, it provides sufficient context for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'id' has a clear description in both schema and tool description. The description adds context: that the ID is a serial number from search_admin_appeals results, which is beyond the schema's description. With 100% schema coverage, baseline is 3, and the added context justifies a 4.
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?
Description explicitly states the tool extracts administrative appeals adjudication text with specific fields (case name, adjudication agency, etc.). It distinguishes from sibling tools by mentioning search_admin_appeals and get_pipc_decision_text as alternatives for different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use context (extracting adjudication details) and explicitly lists alternatives: search_admin_appeals for similar cases, get_pipc_decision_text for PIPC decisions. The phrase '다음: (next:)' offers direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses truncation limit of 12,000 characters and use of efYd for time-specific versions. No annotations provided, so burden is on description; it could mention error cases or response format but is otherwise transparent.
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?
Concise three sentences, front-loaded main purpose, then behavioral details and usage guidance. No unnecessary words.
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?
No output schema, so description must compensate. It notes results are sorted by article (조문 단위로 정렬됨) and mentions truncation. Could be more detailed on return structure, but is sufficient for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. Description adds value by explaining mutual exclusivity of mst and lawId (택1) and clarifying efYd's role for versioned queries, going beyond 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 it retrieves the full text of a law using mst or lawId, returned sorted by article. It distinguishes from sibling tools like get_law_article for specific articles, and mentions related tools for history and relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool (for full law text) and when not (for large laws truncated at 12,000 characters, recommending get_law_article for specific articles). Also suggests next steps: get_related_laws and get_law_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses that the list is a direct copy from PIPC portal (not curated by us) and that source URL is automatically attached for verification. This covers behavioral aspects like origin and verifiability. Could be improved by noting read-only nature more explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but each sentence adds value. It front-loads the main purpose and then adds nuances. Could be slightly shortened by merging some lines, but overall effective structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list retrieval tool with one parameter and no output schema, the description is comprehensive. It covers what the tool returns, its origin, its relationship to other tools, and usage sequence. No critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'category' is fully described in the schema with enum values and defaults. The description adds context by mapping enum values to actual counts (12 laws, 23 rules) and explaining what 'all' includes. This supplements schema meaningfully.
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 PIPC's official curated list of 12 laws and 23 administrative rules, distinguishes it from sectoral guides, and positions it as the entry point for PIPA domain. It also mentions the source URL attachment and relationship with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use as first entry into PIPA domain, contrasts with sectoral guides, and suggests subsequent tools (search_law, search_admin_rule, get_sectoral_related_laws) for deeper exploration. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: extraction of structured fields, auto-extraction of annex links, and automatic summarization of long text. It does not mention side effects or authentication requirements, but the disclosed behaviors are sufficient for safe use.
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 extremely concise: three sentences, front-loaded with the primary purpose, followed by details on extracted fields and usage guidance. Every sentence is informative with no redundancy.
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?
The description covers the tool's purpose, return types (structured fields), input source, and related tools. Although there is no output schema, the description compensates by listing expected fields. It is complete enough for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the 'id' parameter. The main description adds value by stating that the id comes from search_pipc_decisions results, providing crucial context 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 clearly states the tool retrieves full PIPC decision text from the legal service, extracts structured fields like case name, summary, order, reasoning, and background, and automatically extracts annex links. It distinguishes from sibling tools like search_pipc_decisions (for searching) and get_law_text (for laws).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: after searching with search_pipc_decisions to get detailed text, and for comparing with law text via get_law_text. It provides a clear next-step context, effectively guiding the agent on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 that results are grouped by matching term groups, homonyms are separated, no pagination is available, and results are truncated by maxArticles. It also gives an example (개인정보 → ~700 articles). However, it does not explicitly state that the operation is read-only or mention authentication/permission requirements, which would be helpful.
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 with the core purpose. Every sentence adds value: purpose, grouping logic, homonym handling, pagination behavior, next steps. No redundant or unclear phrases.
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 the absence of an output schema, the description explains the return type (list of articles grouped by term) and mentions the body preview behavior (200 chars if includeBody true). It provides sufficient context for the agent to understand the output format. Could be improved by explicitly listing the response fields (e.g., lawId, article number), but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context beyond the schema by explaining the purpose of maxArticles (truncation) and providing an example query (개인정보). The example illustrates how the tool behaves with a real term, adding semantic value.
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 tracks articles using specific legal terms, returns a list grouped by term, and distinguishes from sibling tools like 'get_legal_term' (definitions) and 'get_law_text' (full law text). It uses specific verbs and resources: '법령용어가 사용된 조문 추적' and '매칭 용어 그룹별로 ... 조문 목록 반환'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool (when you have a legal term keyword and need all articles containing it), what not to expect (no pagination, truncation by maxArticles), and provides follow-up tool recommendations ('다음: get_law_text ...' and 'get_legal_term').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses semantic search behavior and domain selection via search parameter. No annotations provided, but description covers primary behavioral traits for a non-destructive search tool. Lacks mention of rate limits or result set metadata.
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?
Concise, front-loaded with purpose, uses bullet-point clarity. Every sentence adds useful context without redundancy.
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?
Explains overall workflow (search then retrieve full text). Does not describe pagination parameters (display, page) in description, but schema covers them adequately. No output schema, but return format is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value beyond schema by explaining search parameter domain options and giving natural language query examples. Schema already provides good descriptions for all parameters.
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?
Clearly states it's an intelligent semantic search on clause text, distinguishes from sibling search_law that only matches law names. Provides example keywords and target agency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with search_law (law name matching) and recommends get_law_text(mst) for full text retrieval after searching. Gives clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided (0% coverage), the description fully bears the burden of disclosing behavior. It details the stepwise verification process (4-tier check), special features (as_of temporal verification, alias normalization), and output markers ([HALLUCINATION_DETECTED]). It also mentions providing accurate evidence and next-tool guidance. This is comprehensive and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but dense with information. It is structured as a single coherent paragraph with clear logical flow (purpose, method, features, output, next steps). It avoids unnecessary words and front-loads the key points. Slightly more structure (e.g., bullet points) could improve readability, but it is already concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately explains what the tool does, how it works, and what it returns (hallucination markers, evidence, next-step suggestions). It also connects to sibling tools for follow-up actions. The complexity of verifying legal citations is well-covered, and the description leaves minimal gaps for a typical use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (citation and as_of) are described in the schema (100% coverage), and the description adds valuable context: examples of accepted citation formats for 'citation' (e.g., 'PIPA §15 ① 6호', '개인정보 보호법 제15조제1항제6호'), automatic alias normalization, and an explicit example for 'as_of' ('20190601'). This goes beyond the schema's basic constraints.
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 explicitly states the tool's purpose: to verify legal citations against an actual law API to detect hallucinations. It specifies the four-tier hierarchy (law, article, paragraph, subparagraph) and gives concrete examples like 'PIPA §15 ① 6호'. This clearly distinguishes it from sibling tools like search_law or get_law_text, which are for different purposes.
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 provides clear guidance on when to use the tool: to verify citations and detect hallucinations. It also includes next-step recommendations (search_law for full name, get_law_text for text), but does not explicitly state when not to use it compared to other tools like compare_articles or search_pipc_decisions. However, the context makes the intended usage fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It explains default date range but lacks explicit read-only hint, auth requirements, or rate limits. Still, it provides useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose, then parameter details and usage tips. No unnecessary sentences or fluff.
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?
No output schema, but description adequately covers function, parameters, and usage context. Could mention return format or pagination, but remains fairly complete for a history retrieval tool.
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?
All 4 parameters are described in schema with 100% coverage, but description adds significant value: clarifies lawId vs mst, jo format flexibility and default, and date parameter defaults.
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 article change history for specific laws or articles over time, referencing the source and differentiating from sibling tools by mentioning next steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on mandatory date range with default behavior, and suggests alternative tools (get_historical_law, compare_old_new) for specific follow-up actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It details the return fields (mst, promulgation date, effective date, amendment type) and target source, but does not mention authentication or rate limits. Given the read-only nature, this is sufficient.
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 at three sentences, front-loaded with core purpose, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description clearly explains what is returned (mst, dates, amendment type) and provides usage context with sibling links, making it complete for a history-listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage; the description adds context: lawName supports exact match and abbreviations, display default 100 is adequate for all history. This adds meaning beyond the schema definitions.
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 a list of law enactment history by effective date, including current, history, and upcoming versions. It distinguishes from siblings by explicitly mentioning get_historical_law and compare_old_new for next steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance (e.g., tracking frequent amendments like PIPA) and recommends subsequent tools (get_historical_law for specific text, compare_old_new for comparison), making it clear when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses endpoint sharing with a sibling and specifies the output format (indented tree of statute hierarchy). While it doesn't detail all edge cases (e.g., depth limits), it sufficiently explains the tool's behavior for an AI agent.
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 (two sentences plus a follow-up pointer) and front-loads the core purpose and hierarchy levels. Every sentence adds value, with no redundancy. Ideal length for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description clearly explains the tree output's structure (hierarchy levels). It mentions endpoint sharing and provides next-step references, making the tool's context fully understandable for an AI agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value by indicating both parameters come from search_law results, providing origin context beyond the schema. This extra context justifies a score above the baseline 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 explicitly states the tool visualizes a hierarchy (법령 체계도) as a tree (트리 시각화), listing the layers from 법률 to 행정규칙. It also distinguishes itself from the sibling get_related_laws by noting the shared endpoint but different output format (tree vs. flat list), making the purpose very clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with get_related_laws: tree for hierarchy understanding vs. flat list for search/discovery. It also suggests follow-up tools (get_law_text, get_delegated_laws), providing clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the output includes article ranges and counts, and that it extracts from law JSON with a specific header. However, it does not mention auth requirements, rate limits, or potential size limitations for large trees. Minor omission but overall transparent.
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: a few sentences each serving a purpose. It front-loads the core function, then differentiates from siblings, and ends with usage suggestions. No redundant or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 adequately describes the output (structure with article ranges and count). It explains all three parameters, provides a concrete use case, and references related tools. It is complete for a tree/toc tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, so baseline is 3. The description adds value by clarifying that mst and lawId are alternatives (택1) and efYd is for time-point queries. This extra context justifies a 4.
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 extracts the internal table of contents (편·장·절·관) of a law, including article ranges and counts. It distinguishes itself from get_law_text (full text) and get_law_system_tree (hierarchy of laws), making the 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: for navigating large laws like PIPA to quickly decide which chapter/section to examine. It also tells when not to use it (for full text or system hierarchy) and suggests follow-up tools (get_law_text, compare_articles). This is exceptional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It clearly implies a read-only operation (retrieving text) and specifies the data source (lawService). While it doesn't explicitly state read-only or mention error handling, the purpose and usage are transparent enough for safe invocation.
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 extremely concise—3 short sentences—yet delivers purpose, usage guidance, tips, and sibling references. Every sentence provides value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema), the description fully covers what the tool does, how to use it, and its relationship to siblings. No additional information is needed for correct invocation.
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 single parameter 'mst' has a full description in the input schema, and the tool description adds critical context: it must come from get_law_history's result and represents a specific time point. This clarifies the parameter's role beyond the schema definition.
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 law text at a specific point in time ('특정 시점 법령 본문'). It distinguishes from siblings by referencing get_law_history (to obtain mst) and get_law_text (for current text).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (after get_law_history for historical versions) and when not to (use get_law_text for current text). It provides a specific use case (frequently amended laws like PIPA) and directs to next step (get_law_history to check other msts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses multiple API calls (lawSearch and lawService), behavior for multiple definitions, and effect of withDefinitions=false. Lacks explicit statement on safety or permissions.
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?
Concise and well-structured with a clear example and follow-up reference. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given schema coverage and lack of output schema, description is complete. It explains integration, behavior for multiple definitions, and provides an example.
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?
Schema coverage is 100%, and description adds context: explains each parameter's purpose, especially withDefinitions and display. Provides examples and clarifies behavior beyond 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 searches legal terms and integrates definitions from lawService. It distinguishes from sibling tools by specifying that get_term_articles is for tracking articles using the term.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool vs alternatives: '다음: get_term_articles(용어ID)로 해당 용어 사용 조문 추적.' Also clarifies the role of the withDefinitions parameter to toggle definition fetching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it indexes PIPC guides as-is (curation 0), splits official vs additional mentions, attaches sources for verification, normalizes aliases, and notes it is a starting point. This provides comprehensive 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but each sentence adds value and is front-loaded with purpose. Minor redundancy could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two simple parameters and no output schema, the description fully covers output composition (official vs additional), source attribution, and limitations. It is complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining default behavior (list sectors if unspecified), alias normalization, and the effect of include_additional, going beyond the schema descriptions.
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 it is a lookup tool for PIPC sectoral related laws, specifying 8 sectors and detailing what it returns (official laws, additional mentions). It distinguishes from siblings by naming alternative tools for unlisted sectors or cross-domain queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (as a starting point for sectoral mappings) and when not (for sectors not listed or cross-domain), directing to siblings like search_law, intelligent_law_search, get_pipc_curated_corpus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses caching behavior (24-hour cache, bypassCache flag), server-side date filtering (stdDt/endDt), large response size (1.2MB+), and automatic domain abbreviation conversion. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise for its content, front-loading the purpose. It could be slightly more structured but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 explains return values (bidirectional mapping) and covers all behavioral aspects (caching, filtering, domain aliases). The tool's complexity is well-addressed.
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?
Although schema coverage is 100% (baseline 3), the description adds significant meaning: stdDt/endDt filter on server side ignoring cache, bypassCache forces refresh, display is client-side truncation, and omitting query dumps items. This greatly aids parameter understanding.
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 is a law abbreviation dictionary from the Ministry of Legislation, performing partial matching on queries. It distinguishes itself from siblings by mentioning domain-specific abbreviation handling (e.g., '정통망법' via PRIVACY_ALIASES) and bidirectional mapping between abbreviations and full names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly describes when to use this tool (for abbreviation lookups) and contrasts it with get_law_text(mst) for full text and search_law(query) for formal search. Examples are provided to illustrate usage.
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:

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

Score Badge

Copy to your README.md:

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

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