nts-taxlaw-mcp

by zisu17

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: exact lookup, keyword search for interpretations, decisions, guidance, forms, a unified search, and a research aggregator. Even the two get_tool functions target different data types (documents vs guidance). No ambiguity between tools.
Naming Consistency4/5
Most tools follow a consistent 'verb_noun' pattern: lookup_tax_document, search_tax_interpretations, get_tax_guidance, etc. The exception is tax_research, which breaks the pattern as a compound noun rather than verb_noun, creating a minor deviation.
Tool Count5/5
9 tools is well-scoped for a tax law research server. Each tool covers a distinct aspect (search, retrieve, research synthesis) without redundancy or excessive granularity, and the count feels appropriate for the domain.
Completeness4/5
The tool set covers the core research lifecycle: search for interpretations, decisions, guidance, and forms; retrieve full documents; and synthesize multi-layer research. Minor gaps include no direct 'get_decision' tool, but get_tax_document covers that, and legal text is deliberately delegated to another MCP server, making it slightly incomplete within this server's scope.
Average 4.4/5 across 9 of 9 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only says it fetches a provision and mentions identification methods, but does not disclose whether the operation is read-only, what happens if the title matches multiple provisions, or that kind and law_name are required. Missing these important behavioral details.
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 only two sentences, front-loaded with the main action and optional identification methods. Every sentence earns its place; no redundant or filler content.
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 the tool's complexity (5 parameters, output schema exists), the description is adequate but has gaps. It covers the key usage scenario (fetch by item_id/title) but omits mention of required parameters kind and law_name, and does not describe edge cases or return format. Since the output schema exists, return values need not be explained, but the missing required parameter guidance leaves room for error.
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 high (80%). The description adds meaning beyond the schema by explaining that item_id comes from search results and that title is an alternative when item_id is unknown. It clarifies the relationship between these two parameters, but does not mention revision_year or the required nature of kind/law_name, though the schema covers those.
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 it fetches a single provision from basic rulings or tax law enforcement standards, and it gives two ways to identify the provision (item_id or title). It distinguishes from search_tax_guidance but does not explicitly differentiate from other get/update siblings, so not a 5.
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 instructs to use item_id from search_tax_guidance or a title fragment, implying a typical flow of search-first-then-fetch. It provides clear context for when to use this tool but does not mention when to use alternatives or exclude other tools, so not a 5.
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 disclosure burden. It reveals key behavioral traits: the layer-by-layer evidence collection algorithm, the authorityLevel tagging mechanism for distinguishing legal effect, an explicit no-legal-conclusion guarantee (anti-hallucination), and the companion-tool suggestion. It falls short only on operational details like pagination, rate limits, or partial-failure behavior—minor gaps for a read-only research tool.
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?
Three information-dense sentences with zero filler—the hierarchy, the authorityLevel mechanism, the scope caveat, and the companion-tool pointer are all load-bearing. The only deduction is structural: it's a heavy wall of text with no front-loading, bolded critical caveat aside, making it denser to parse than strictly necessary.
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 complex tool with 6 parameters and a multi-layer research model, the description covers the essential context: the layered pipeline, the distinction between statutes/interpretations/decisions, the authorityLevel mechanism, and the no-judgment behavioral guarantee. The output schema exists to document return values. Gaps like error handling and empty-layer behavior are minor for a research tool with an output schema.
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 well-described parameters (layered result counts for limit_per_layer, accuracy hints for tax_type), so the baseline is 3. The description's layer hierarchy does help interpret limit_per_layer and include_guidance (which map to specific layers like 기본통칙·집행기준), but it adds no parameter-specific detail beyond what the schema already 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 uses a specific verb+resource: 'collects one tax issue as evidence' organized by an explicit hierarchical cascade (법률→시행령→...→판례·헌재). The layered research concept, authorityLevel tagging, and the explicit no-legal-conclusions scope clearly distinguish it from sibling search/lookup/get tools focused on individual document types.
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 names korean-law-mcp as an explicit companion tool for statutory text ('법령 본문이 필요하면'), gives an explicit scope exclusion for enforcement rules (시행규칙 '범위 밖, 확인 경로 안내'), and notes the tool's pure-research limitation ('법적 판단이나 결론을 만들지 않는다'). However, it never explicitly contrasts with sibling tools like search_tax_interpretations or search_tax_decisions, which an agent might confuse it with.
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 transparency burden on its own. It helpfully discloses the exact-lookup priority ('질의에 문서번호가 섞여 있으면 exact lookup 을 최우선으로 시도한다') and the auto-domain-detection behavior. However, it does not reveal the return-retention format, pagination, sorting, or what happens when the auto-detection is ambiguous, leaving some important behavior unaddressed.
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 economical and front-loaded: the first sentence states the tool's core purpose, the next two sentences provide essential behavioral constraints, and the final sentence gives the usage context. Every sentence serves a distinct, valuable purpose without repetition or wasted tokens.
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 available context with low complexity and a schema with 100% description coverage, the description is sufficiently complete. It explains the main behavioral nuances (exact lookup, auto-domain detection), and its entry-point advice makes it clear when to invoke this tool in a larger flow. A slightly more explicit distinction from lookup_tax_document and the named domain-specific siblings would make it fully complete, so it stops one step short of 5.
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 schema already covers all four parameters with full coverage, which gives a baseline of 3. The description adds value by clarifying that the query parameter can include document numbers and that domains can be auto-inferred from expressions like '예규', '심판', '통칙', and '적부'. This goes beyond the schema's short description and improves an agent's understanding of how to fill meaningful values.
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 opens with a clear and specific statement: '국세청 자료 전 영역을 한 번에 검색한다' – it searches all NTS data areas at once (inquiries, decisions, notices, forms). This distinguishes the tool from sibling domain-specific search tools, and adds the exact-lookup behavior for document numbers, making the purpose explicit and unique.
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 says to use this tool as the entry point when unsure which area to search ('어느 영역을 봐야 할지 모를 때의 진입점으로 쓸 것'). It also implies that when the domain is unknown, the tool will auto-detect it based on the query. However, it does not explicitly name alternatives or state when not to use this tool, so it falls just short of a 5.
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 of behavioral disclosure. It explains the scope of search sources, that result filtering is supported, and prominently states that case_number triggers an exact lookup. It does not discuss pagination or result structure, but the presence of an output schema mitigates that need.
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 compact and front-loaded, with no filler or repetition of unrelated material. The dense list of target types/codes is necessary for scoping a search tool of this breadth and is immediately usable for an agent.
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 high parameter count and no annotations, the description explains the essential aspects: what data sources are searched, what document categories are covered, what filters exist, and how to use exact lookup. It does not discuss sibling-tool selection, but the tool name and description together with sibling names still provide sufficient 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 description coverage is high (87%), so the baseline is 3. The description adds useful context beyond the schema by mapping the target types to their official category codes (05, 06, 07, etc.) and by emphasizing that case_number yields an exact lookup. It also ties decision result and attribution year to filter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses an active verb ('검색한다') and clearly specifies the resource: tax case precedents and rulings from the National Tax Service, Tax Tribunal, and courts. It also lists the exact target categories and filter dimensions, making its purpose unambiguous and sufficiently distinct from sibling tools like search_tax_interpretations or search_tax_guidance.
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 when to use the tool: searching tax decisions/rulings, optionally filtering by decision result or attribution year. It explicitly tells the agent to use case_number for exact lookup when the case number is known, which is a strong usage guideline, though it does not name sibling tools or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
annotations이 전혀 없는 상황에서도 기본통칙은 조항 본문까지, 실행기준은 조항명(목차)까지만 제공된다는 중요한 결과 제약을 밝히고, 결과에 법규 아님 표기를 함께한다는 동작 표현을 서술한다. 다만 읽기 전용 명시나 페이지네이션 동작 같은 추가 동작 표현은 드러나 있어 완전한 투명성은 아닌 정도는 남는다.
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?
첫 문장으로 목적을 밝히고, 이후 kind 구분 → 제공 범위 제한 → 필수 조건 → 법규 여부 표기 순서로 핵심 정보를 겹침 없이 압축했다. 문장마다 도구 사용에 필요한 정보가 하나씩 담겨 있어 효율적이다.
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?
6개 파라미터와 kind별 반환 수준 차이라는 복잡도를 고려할 때, 법률명 조건부 파라미터와 검색 결과가 법규 아님을 표시해야 한다는 부분까지 다루진 완성도가 높다. 다만 형제 도구와의 경계를 한 문장으로 정리해 주면 더 충분할 수 있다.
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 설명은 67%만 제공되고 page/limit은 스키마에도 상세 설명이 없다. 설명은 kind enum의 사실상 의미를 국세기본통칙·세법집행기준 같은 실제 라벨로 채워주고, law_name이 어떤 kind에서 필수인지 조건부 판단정보를 추가해 값을 더해준다.
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?
'국세청 행정 해석기준을 검색한다'로 시작해 검색 대상을 구체적으로 특정하고, kind에 따라 basic_ruling, execution_standard, notice, directive의 네 가지 범위를 제시한다. 또한 '법규가 아닌 내부 집행기준'이라는 점을 명시하여 search_taxlaw나 search_tax_decisions 같은 형제 도구와 구별되는 목적이 분명히 드러난다.
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?
기본통칙·집행기준 검색 시 law_name이 필요하다는 조건을 예시와 함께 명시하여 실제 호출 맥락을 알려준다. '이 자료는 법규가 아니다'라는 제약도 안내하지만, 형제 도구와 비교하는 명시적 when-to-use/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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It clearly discloses the non-obvious limitation that this server does not return binaries and instead provides a viewing screen URL. It also states the exact output fields, which is strong behavioral disclosure 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 just two sentences. The first sentence immediately states the action and resource, and the second adds a critical limitation. Every sentence earns its place with no filler or repetition.
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?
The tool is a straightforward search operation with an output schema available. The description covers the tool's purpose, return fields, and the crucial binary/URL limitation, making it complete enough 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes `query` and `law_name`, and the description reinforces these by mentioning form name and related law. However, `page` and `limit` are not explained in either the schema or the description, leaving a gap for pagination semantics. With 50% schema coverage, the description partially compensates but does not add significant 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 uses a specific verb ('검색한다', searches) and clearly identifies the resource (tax legal forms and schedules). It enumerates exact return fields (form name, related law, revision date, file identifier) and is clearly distinct from sibling tools focused on interpretations, decisions, guidance, or tax 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?
It provides clear context that this tool searches tax forms and returns metadata plus a viewing URL. It also explains the important limitation that binaries are not provided because the upstream system only serves them via POST form. However, it does not explicitly name alternative tools for other document types or 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.
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, and it delivers: states exact scope (four types), explains match semantics (AND/OR/NOT), and discloses the data-sourcing tradeoff (direct NTS with fresh data, but not a legal mirror). Loses a point because it doesn't explain what fields are returned, pagination behavior beyond a 'page' parameter, or rate limits.
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 avoids filler, front-loads the core purpose in the first line with a period, and the remaining text efficiently covers types, filters, query semantics, and data-source advantage in sentence fragments. It's structured as a single dense paragraph that is 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?
For a complex, 13-parameter tool with no annotations and no defaults on half the fields, the description explains the semantics of match models (AND/OR/NOT), the exact-lookup path, and the source-freshness tradeoff. However, it doesn't describe the kind of data returned (e.g., fields/structures) since it relies on an output schema, which the rules allow. Minor gap: it does not explain default sort behavior or how to combine 'tax_type' and 'query'—two behaviors that would have completed the picture.
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 schema already has 100% coverage, giving a baseline of 3. The description adds value by clarifying that 'document_number' triggers exact lookup, and that whitespace-separated words become AND terms in the query parameter, which matches the 'query' parameter's description of quoted phrase behavior. However, it doesn't provide the full boolean logic detail for exclude or how sort values map to behavior—the description adds some contextual glue but doesn't fully compensate for what's missing in terse 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?
Description states '국세청 세법해석례(예규)를 검색한다' with specific object (searching tax interpretations), lists the four categories covered, and differentiates itself from siblings by clarifying it directly queries the NTS original rather than the Ministry of Government Legislation mirror. It's specific and distinguishes the tool from search_tax_decisions, which handles rulings.
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 this instead of the alternative by mentioning '법제처 미러가 아니라 국세청 원본을 직접 조회하므로 최신 예규가 바로 잡힌다'—differentiating from sibling tools that might query the other source. It also cites a data-freshness advantage over alternatives. Though it doesn't name sibling tools explicitly, it provides clear context for when this tool's characteristics matter.
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?
The description discloses key behaviors: missing sections are omitted, and if the original does not provide the body, it returns DETAIL_NOT_AVAILABLE and does not generate it. This proactively sets expectations about edge cases and output handling.
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 yet information-dense. Each sentence contributes: purpose, specification method, structure for both document types, handling of missing sections, and fallback for body. No fluff or 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 complexity (different document types with varying fields, potential for missing data), the description is complete. It explains the output structure, edge cases, and fallback behavior. With no output schema provided, the description fully covers what is returned.
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 schema already provides descriptions for all four parameters. The tool description adds context for ntst_dcm_id and document_number (how they relate to search results and fallback), and mentions include_full_text indirectly via '본문' but does not elaborate on body_limit. It adds some value beyond the schema, but not complete coverage 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?
The description clearly states the tool fetches one document's body and structured fields, and distinguishes it from search tools by specifying document ID or number. It also explains the two types of documents (해석례 and 결정례) and their corresponding fields, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear guidance on how to specify the document (by ID or number) and when to expect missing sections. It implies usage after search results (mentioning '검색 결과의 문서 ID') but does not explicitly state not to use for searching or when to choose this over sibling tools. Still, the practical instructions are solid.
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?
No annotations are provided, so the description carries the full burden. It discloses exact-match only behavior, normalization of varying notation, NOT_FOUND when no exact match, separation of similarDocuments, and automatic classification of document types. This is highly transparent about expected behavior and edge cases.
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 purpose. Every sentence adds value: principal function, document type coverage, normalization examples, NOT_FOUND/similarDocuments behavior, and usage priority. No fluff or 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?
The description covers important edge cases (no exact match, partial overlaps), normalization rules, and document type scope. With an output schema present for return values, the description does not need to repeat those details. It is complete for both simple and complex scenarios.
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%, so baseline is 3. The description adds significant value for the document_number parameter by giving concrete examples of accepted notation variations and normalization, which goes beyond the schema. It does not add new meaning for body_limit or include_full_text, but the schema already describes those adequately.
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: find documents by exact document number match and return the body. It distinguishes itself from siblings by emphasizing exact-match semantics and automatic normalization, and explicitly mentions it should be used before other tools when a document number is known.
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 usage guidance: when you know the document number, always use this tool first. It also clarifies that partial matches are returned as similarDocuments and are not the answer, implicitly steering users to alternative search tools for fuzzy lookups.
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:

[![nts-taxlaw-mcp MCP server](https://glama.ai/mcp/servers/zisu17/nts-taxlaw-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zisu17/nts-taxlaw-mcp)

Score Badge

Copy to your README.md:

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

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