Skip to main content
Glama

Lifelaw Korean Law (라이프로 법령)

Tax enforcement standards (세법 집행기준)

list_tax_execution_standard
Read-onlyIdempotent

Get Korean tax enforcement standards (집행기준: the National Tax Service's compilation of the Act, Decree, basic rulings and interpretations). With only law: item numbers and titles; with item: that item's text (read from the NTS-published PDF); with keyword: items with that word in the title. Enforcement standards are not law. Available: 국세기본법, 국세징수법, 법인세, 국제조세, 종합소득세, 양도소득세, 종합부동산세, 상속증여세, 개별소비세, 인지세, 주세, 주류면허법, 증권거래세, 부가가치세, 조세특례제한법.

Input Schema

NameRequiredDescriptionDefault
lawYesTax or law name in Korean or English. E.g. 양도소득세, 부가가치세, 법인세법, Value-Added Tax Act
itemNoItem number. E.g. 89-155-1, 88-152의3-4
pageNoResult page number (from 1). Default 1
yearNoEdition (year). Default: latest
keywordNoOnly items with this Korean word in the title (cannot be combined with item)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / item / description
      Previous value: -"항목 번호. 예: 89-155-1, 88-152의3-4"New value: +"Item number. E.g. 89-155-1, 88-152의3-4"
    • changedInput schema / properties / keyword / description
      Previous value: -"제목에 이 낱말이 든 항목만(item 과 함께 쓸 수 없음)"New value: +"Only items with this Korean word in the title (cannot be combined with item)"
    • changedInput schema / properties / law / description
      Previous value: -"세목 또는 법 이름. 예: 양도소득세, 부가가치세, 법인세법"New value: +"Tax or law name in Korean or English. E.g. 양도소득세, 부가가치세, 법인세법, Value-Added Tax Act"
    • changedInput schema / properties / page / description
      Previous value: -"검색 결과 쪽 번호(1부터). 생략하면 1"New value: +"Result page number (from 1). Default 1"
    • changedInput schema / properties / year / description
      Previous value: -"판(연도). 생략하면 최신판"New value: +"Edition (year). Default: latest"
  2. Changed2 schema fields changed
    • addedInput schema / properties / item
      Added value: +{
      +  "description": "항목 번호. 예: 89-155-1, 88-152의3-4",
      +  "type": "string"
      +}
    • changedInput schema / properties / keyword / description
      Previous value: -"제목에 이 낱말이 든 항목만"New value: +"제목에 이 낱말이 든 항목만(item 과 함께 쓸 수 없음)"
  3. First observed

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds useful context beyond that: the text is read from the NTS-published PDF, the result shape differs per mode, and the keyword/item mutual exclusion is stated. It stops short of pagination or edition-default behavior for the year parameter.

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?

Front-loaded with the definition, then mode behavior, then the availability list. The trailing enumeration of fifteen statutes is long, but it is genuinely useful domain scope rather than filler; a couple of clauses (the parenthetical glossary) could be tightened.

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 no output schema and five parameters, the description carries the return-value burden and does so for all three modes, plus it discloses the source of the text and the supported tax domains. Only paging behavior across large result sets is left unexplained.

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 the baseline would be 3, but the description goes further by explaining what each parameter combination actually changes in the response (titles vs. full item text vs. title keyword match) and by enumerating the accepted law values, information not present in 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 names a specific verb and resource ('Get Korean tax enforcement standards'), defines the resource precisely (the NTS compilation of Act, Decree, rulings and interpretations), and explicitly separates it from statutory law ('Enforcement standards are not law'), which is exactly the distinction an agent needs against siblings like get_article 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?

It gives clear mode-selection guidance keyed to the parameters: law alone returns titles, law+item returns that item's text, keyword searches titles. That is real routing advice, but it never names a sibling alternative for the 'I want the actual statute text' case, so exclusion guidance is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources