taxlaw-nts-mcp

Server Quality Checklist

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

Latest release: v0.3.4
Disambiguation3/5
Many tools are clearly distinct, but there are redundant tools (get_taxlaw_interpretation_text and search_taxlaw_interpretations) that are just aliases for existing ones, causing potential confusion. Also, multiple search tools with different scopes may overlap in function.
Naming Consistency5/5
All tool names follow a consistent verb_taxlaw_object pattern (e.g., call_taxlaw_action, list_taxlaw_basic_ruling_laws, search_taxlaw_documents), making naming predictable and easy to understand.
Tool Count5/5
With 14 tools covering various aspects of tax law information access (search, retrieval, listing, raw calls), the count is well-scoped for the server's purpose, neither too few nor excessive.
Completeness4/5
The tool set covers search, retrieval, and navigation of the NTS tax law system, including documents, interpretations, rulings, forms, and publications. Minor gaps exist (e.g., reliance on korean-law-mcp for some law text), but the coverage is comprehensive for its intended use.
Average 3.5/5 across 14 of 14 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 40 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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 'search' without revealing pagination limits, authentication needs, scope, or whether it returns metadata or full text. The brief description leaves agents blind to important constraints.
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?
Two short sentences, no redundancy. However, the lack of structure (e.g., bullet points) and missing title are minor drawbacks. Still, it's efficient for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 50% schema coverage, no annotations, and no output schema, the description is too minimal. It doesn't explain what results look like, how to use categories, or any typical usage pattern. A search tool needs more context to be safely invoked.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only query and categoryCode have descriptions). The description adds no parameter meaning; it doesn't explain how query or categoryCode interact, nor does it hint at display or page behavior. With low coverage and no compensation from the description, this is insufficient.
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 searches for publications (발간책자) in the national tax law system, distinguishing it from siblings like search_taxlaw_documents or search_taxlaw_interpretations. However, 'publications' could be more specific (e.g., booklets/guides), and the null title misses an easy clarity win.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other search tools. The description only states its function; it doesn't explain context, alternatives, or prerequisites. Siblings like search_taxlaw_all exist, but no comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It reveals that the tool internally uses another search tool, but does not mention side effects, limitations, or differences in behavior. This is minimal 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 extremely concise with two phrases, front-loaded with the core purpose and the internal mechanism. Every part is necessary and no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is severely lacking. It does not explain how to use the parameters, what the search returns, or how it differs from the internal tool. This is insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its 8 parameters, and the description does not explain any parameter meaning or usage beyond the schema. The description fails to compensate for the lack of parameter documentation.
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 searches tax law interpretations and inquiry replies for backward compatibility, and notes it internally uses search_taxlaw_documents. This provides a specific verb and resource, and hints at differentiation from the sibling tool by mentioning internal delegation.
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 phrase 'backward compatibility' implies that this tool is for legacy use, but it does not explicitly state when to use it vs. the internal search_taxlaw_documents. The description provides context but lacks explicit usage guidance or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits (e.g., read-only, output format, pagination). Given the burden on the description, it adds minimal insight beyond the tool's 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Korean. It is front-loaded and gets the point across efficiently without unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description lacks context about the output structure, the meaning of 'categories', or how the result integrates with other tools. Minimal 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?
The input schema has 0 parameters with 100% coverage, so the description does not need to add parameter details. Baseline 3 applies as schema coverage is high and no compensation is needed.
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 lists field codes for publications in the tax law system. It uses a specific verb ('list') and resource ('publication categories'), distinguishing it from sibling tools that search or retrieve other items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With many sibling tools, the lack of context on when to choose this for listing categories vs searching publications or listing laws leaves the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only labels the call as 'raw' without explaining side effects, required permissions, rate limits, or error handling. This is insufficient for an agent to anticipate tool behavior.
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 (two sentences), with the main purpose stated upfront. It avoids fluff and each sentence contributes useful contextual information about parameter sourcing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the tool's low-level nature, the description is incomplete. It fails to explain what the response contains, how to interpret results, or any constraints on usage. More context is needed for effective 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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds marginal value by hinting at the source of actionId, but does not deepen understanding of parameter semantics beyond what the schema provides.
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 is a raw call to action.do of the tax law system, using a specific verb and resource. It implicitly distinguishes itself from sibling tools, which are more specific (get, search, list), by being a lower-level operation.
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 provides guidance on where to obtain valid actionId values (from list_taxlaw_site_menus or browser), implying when to use this tool (for arbitrary action.do calls). However, it does not explicitly state when to avoid it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the search action and content type, but does not mention pagination, result format, permissions, or any side effects (though it is read-only by nature). The minimal description does not sufficiently inform the agent of the tool's behavior beyond its 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loads the purpose. It is concise but could include more useful information without being lengthy. The structure is acceptable for its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description is far from complete. It lacks details on how parameters work, what the return value contains, pagination, and how 'kind' filters results. Users (or agents) would need to guess or consult external sources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 5 parameters with only 40% description coverage (query and lawId have descriptions, kind/display/page do not). The description adds no additional meaning to the parameters or their usage. It does not compensate for the missing 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 explicitly states it searches for '별표/서식' (appendix/forms) in the tax law information system, and lists the types of forms covered: all forms, appendix, legal forms, instruction forms, frequently searched forms. This clearly distinguishes it from sibling tools like search_taxlaw_documents or search_taxlaw_interpretations.
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?
Description implies the tool is for searching tax law forms but gives no explicit guidance on when to use it versus alternatives like search_taxlaw_all or search_taxlaw_documents. No when-to-use or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions internal use of get_taxlaw_document_text, which implies a read operation, but does not disclose any other behavioral traits like safety, needed permissions, or idempotency. The description is too terse to be transparent.
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 very short (one sentence), which is concise but lacks essential details. It front-loads purpose and usage, but the brevity comes at the cost of missing parameter and behavior descriptions. It is not optimally structured for completeness given the tool's 0% schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, 0% schema coverage, and two parameters, the description is insufficient. It provides purpose and usage guidelines but omits parameter semantics, return value description, and detailed behavior. The tool is not fully described for an agent to use correctly without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not mention the parameters (id, full) at all. It fails to explain what values are expected for id or the effect of the full flag, leaving the agent with no guidance 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 detailed tax law interpretation cases/inquiry responses ('세법해석례/질의회신 상세 조회'), and explicitly marks itself as backward-compatible ('하위호환용'), distinguishing it from siblings like get_taxlaw_document_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 states this tool is for backward compatibility and internally uses get_taxlaw_document_text, indicating to agents that newer code should prefer the latter. This provides clear when-to-use guidance and exclusion of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states conversion to text but does not disclose behavior on invalid paths, authentication needs, rate limits, or what the 'full' parameter does. Significant gaps for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. No wasted words, efficient structure.
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 or annotations. Description is minimal but covers basic purpose. However, missing explanation of 'full' parameter and behavioral details makes it slightly incomplete for full comprehension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (50%) with 'full' parameter having no description. Tool description does not explain 'full' or add detail to 'path' beyond existing schema. Fails to compensate for missing schema information.
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 an HTML/text page from the National Tax Law Information System and converts it to text, specifying it is for static materials like tax item summary pages. It effectively distinguishes from sibling tools that target specific 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for checking static materials but does not explicitly compare to sibling tools or provide when-not-to-use guidance. No mention of alternatives or context when to prefer this over specific document retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic operation. It does not disclose any behavioral traits like error handling, rate limits, or authentication needs that might be relevant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, with a single sentence and a clarifying note. It is efficient but could be slightly more structured with explicit headings or bullet points.
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 three parameters and no output schema or annotations, the description provides sufficient context about input (using search result IDs) and basic behavior. It does not explain return values but that is acceptable without 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 description coverage is 100%, so the parameters are fully described in the schema. The description adds no additional meaning beyond what the schema already provides, meeting the baseline for high coverage.
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 detailed document text from the tax law information system using an ID from search results, distinguishing it from sibling tools that are specific to 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?
It explicitly instructs to use DOC_ID/id from search_taxlaw_documents or search_taxlaw_all, providing clear context for when to invoke this tool. However, it does not explicitly mention when not to use it or contrast with specialized get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only describes what the tool searches and gives a usage hint, but does not disclose any behavioral traits such as read-only nature, rate limits, authentication needs, or side effects. The lack of annotation coverage combined with minimal behavioral description results in low 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 (three sentences in Korean), front-loads the main purpose, and includes a helpful recommendation without unnecessary details. Every sentence adds value, making it easy to digest.
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 8 parameters and no output schema, the description covers the main searchable categories and provides a usage guideline. However, it does not describe the return format, pagination behavior, or what to do when no results are found. Given the lack of output schema and annotations, some contextual 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?
Schema coverage is 50% (4 of 8 parameters have descriptions). The description adds meaning beyond the schema by explaining the docType enum values (01-04 and 05-10 categories) and their correspondence to document types. This helps an agent understand the parameter semantics, though some parameters (display, page, sort) lack additional explanation.
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 it searches the National Tax Law Information System and enumerates specific document categories (interpretations, inquiries, disputes, etc.). It also distinguishes from sibling tools by recommending this tool for Tax Tribunal decisions and suggesting an alternative if not found. The verb 'search' combined with the resource and scope makes 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends prioritizing this tool for recent Tax Tribunal decisions and advises using 'korean-law-mcp's search_decisions' as a fallback. This provides clear context on when to use this tool versus an external alternative. However, it does not explicitly compare with sibling search tools on the same server, so some guidance is missing for complete differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'detailed inquiry,' implying a read operation, but does not disclose any behavioral traits such as idempotency, error conditions, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates purpose and parameter origin. No unnecessary words, front-loaded with the action and object.
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 adequately covers what and how. It mentions the ID source but does not specify the output format (presumably text), which could be inferred.
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 one parameter with a description including an example. The tool description adds context by specifying the ID originates from search_taxlaw_all results, enhancing 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 retrieves detailed text of a Home Tax counseling case from the National Tax Law Information System. It distinguishes from sibling tools by specifying the document type (hometax counsel) and mentions the ID source from search_taxlaw_all results.
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 a clear usage scenario: use the ID from search_taxlaw_all's hometaxCnslThan results. It does not explicitly state when not to use, but the context of sibling tools for different document types implies exclusivity.
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; description indicates a read-like query but lacks details on idempotency, rate limits, or response behavior. Adequate for a simple list operation, but could be more informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. Front-loads purpose then usage. Every word earns its place.
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 low complexity (single optional parameter, no output schema), the description is mostly complete. Lacks explicit mention of return format, but sufficient for an agent to infer usage.
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%, and the parameter description in the schema already captures the filter purpose. The description adds no new semantic information 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?
Description clearly states the tool queries a list of basic ruling laws and specifies its role in obtaining lawId for get_taxlaw_basic_ruling_text. This differentiates it from sibling list tools.
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?
Explicitly identifies the primary use case (securing lawId for another tool), providing clear context. Does not include negative usage guidance, but specificity is high.
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 bears full responsibility. It discloses that the tool lists paths and call info, but does not mention any behavioral traits like side effects, rate limits, or return format. Adequate 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 two sentences long, starting with the main purpose and then providing guidance. No redundant information; every sentence earns its place. Very 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?
The tool has one optional parameter and no output schema. The description informs what the tool outputs (paths and call info). For a simple list tool with filter, this is sufficient, though more detail on output structure could help.
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 has one optional parameter 'query' with a description in Korean explaining it filters by menu name/section/key/action ID. With 100% schema coverage, the description adds marginal value beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool lists main menu access paths and action.do call info for the tax law information system. It uses specific terms but the purpose is clear. It mentions alternatives for cases without high-level tools, which helps distinguish from siblings.
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 (to list menu paths) and when not to, providing specific alternative tools: 'call_taxlaw_action' or 'get_taxlaw_page_text'. This is excellent guidance for an agent.
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 burden. It implies a read operation but does not disclose idempotency, error behavior, or rate limits, though it mentions the dependency on a sibling 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 a single concise sentence with two clauses: the resource and the usage direction. No unnecessary words, effectively front-loaded.
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 5-parameter tool with no output schema and no annotations, the description is moderately complete. It explains the key parameter but lacks details on return values, error cases, and the effect of the 'full' boolean.
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 descriptions cover 60% of parameters, but the description adds value by explaining that lawId originates from list results, which is not in the schema. Other parameter descriptions are present in the schema, so baseline is met and improved.
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 basic ruling text from the National Tax Laws Information System and specifies the required lawId from a sibling tool, distinguishing it from other get_ and search_ tools.
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 the lawId from list_taxlaw_basic_ruling_laws results, providing clear when-to-use guidance. However, it does not state when not to use or list alternatives, missing explicit exclusions.
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 disclosure. It honestly states that the statute collection is metadata/citation-focused rather than full text, which is critical behavioral context. It could further mention rate limits or result structure, but the core behavioral trait is transparently communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with purpose and immediately provides distinguishing guidance. Every sentence earns its place.
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 complexity (9 parameters, many collections, no output schema), the description adequately explains the scope and limitation of statute collection. It does not describe return format or pagination behavior, which would improve completeness, but it is sufficient for an agent to understand the tool's role among siblings.
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 67% with most parameters having descriptions. The description does add value by listing the collections in text, reinforcing the enum options, but does not provide additional semantics beyond schema for other parameters like sort or page. Baseline 3 is appropriate as schema does most of the work.
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 comprehensive search of the Korean tax law information system, listing all covered collections. It explicitly distinguishes from sibling tools by noting that for statute text, korean-law-mcp's get_law_text is more accurate, highlighting this tool's complementary role.
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 recommends using this tool in conjunction with korean-law-mcp for precise statute text, providing clear guidance on when to use alternatives. However, it does not explicitly differentiate from the many sibling specialized search tools (e.g., search_taxlaw_interpretations), leaving the agent to infer the generalist vs. specialist distinction.
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:

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

Score Badge

Copy to your README.md:

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

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