local-tax-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
The search/get pairs are clearly distinct (search then fetch full text), and each tool targets a distinct document type or task (reduction-ordinance vs moi-interpretation vs tax-decision). However, get_local_tax_decision, get_ordinance_text, and get_moi_interpretation are all retrieval-after-search tools targeting different document types, which could cause minor boundary confusion, and trace_local_tax_application references get_local_tax_article which isn't even in this set, creating some ambiguity about the workflow.
Naming Consistency4/5
The naming is mostly consistent with a clear verb_noun pattern: search_*, get_*, verify_*, trace_*. However, trace_local_tax_application is not a straight get/search verb and deviates from the dominant pattern, and search_local_tax_decisions/get_local_tax_decision vs search_reduction_ordinance/get_ordinance_text use inconsistent noun naming for the pair structure (decision/ordinance vs never matching).
Tool Count5/5
8 tools is well within the ideal 3-15 range for a focused local-tax research server. Each tool covers a distinct search-or-fetch capability across the key data sources (조세심판원, 법제처 자치법규, 행정안전부 유권해석) plus a verification and application-timing utility. Nothing feels extraneous.
Completeness3/5
The server covers search+fetch for three major tax authorities, plus application-timing (trace) and citation verification. However, trace_local_tax_application explicitly references get_local_tax_article as a required companion to determine applicable tax years, yet that tool is absent from the set — creating a dead end in the core work flow of handling 과세연도 applications. This is a notable gap.
Average 3.8/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses what's returned (full text with listed fields) but doesn't describe safety profile (read-only presumably), error behavior, whether partial data can be retrieved, or any rate limits. For a retrieval tool this is a moderate gap—it's clearly a read operation but lacks behavioral detail.
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 compact single sentence that conveys the resource, its contents, and usage in Korean. No wasted words. However, the enclosed field list in parentheses is somewhat dense and could be structured better for parsing.
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 retrieval tool with a single required param, this is reasonably complete. There's no output schema, so the description's list of returned fields (세목·재결요지·참조결정·주문·이유) serves as the output documentation, which is valuable. The undocumented 'oc' param and lack of behavioral notes leave some gaps.
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 50%: the 'id' parameter has a Korean description (특별행정심판재결례일련번호) but 'oc' has none. The description explains that 'id' should come from search results, which adds context beyond the schema's bare field name. However, the 'oc' parameter remains entirely undocumented in both the schema and the description, and the description doesn't clarify its purpose/optionality.
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 it returns the full text of a 조세심판원 재결례 (tax tribunal decision) including specific fields (세목, 재결요지, 참조결정, 주문, 이유). This clearly identifies the verb (get/retrieve) and resource (full decision text). It doesn't explicitly distinguish from siblings like search_local_tax_decisions, though the distinction is implied by the contrast with 'search'.
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 usage guidance: input the [ID] obtained from search results. This tells the agent how to use the tool (after a search) and implies it's the follow-up step to search_local_tax_decisions. Explicit exclusion of alternatives isn't stated, but the search→get workflow is clearly conveyed.
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 for behavioral disclosure. It confirms it's a read/retrieval operation but doesn't describe what happens with invalid/missing IDs, whether the returned document contains the complete official text, authentication requirements, or any rate limits. For a detail-fetch tool, the lack of these details is a moderate gap.
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 that states the resource, the content components, and the required id origin. Efficient with no wasted words, though slightly under-specified in behavioral transparency.
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 single-parameter detail-fetch tool with no output schema and no annotations, the description is minimally adequate. It tells the agent what it returns and where to source the id, which is enough for basic use. However, it doesn't describe the return format (structured JSON vs raw text) or error behavior, and lacks the behavioral depth expected without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single id parameter (OLTA 문서 ID). The description adds the valuable context that the id comes from search_moi_interpretation results, which gives it provenance beyond the schema. However, no additional format/syntax details are provided beyond what the schema already states.
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 retrieves the full text of an MOI (행정안전부) interpretation including 답변요지, 질의요지, 회신내용. It clearly identifies the resource and that it's the detail view paired with search_moi_interpretation. It could more explicitly distinguish from get_local_tax_decision, though the Korean MCP shows this is specifically for MOI interpretations.
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 instructs to use the [ID] from search_moi_interpretation results, which creates a clear usage pattern where search comes first then detail retrieval. This differentiates from sibling get_local_tax_decision by its linkage to the specific search tool, though it doesn't 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.
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 of behavioral disclosure. It mentions retrieving text and filtering by article, but doesn't disclose return format, whether the full document is paginated, authorization needs, or error behavior when seq is invalid. For a read tool with zero annotations, this is thin.
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 filler. Each sentence earns its place: the first states the primary function, the second explains the article filter option. Zero waste.
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 1-3 parameter retrieval tool with no output schema and no annotations, the description gives the essential workflow (chain from search_reduction_ordinance, article filtering). However, the undocumented 'oc' parameter and absence of return-format details leave some gaps for an agent operating in a Korean regulatory context.
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% (seq and jo have descriptions, oc does not). The description adds meaning for seq (source field from search_reduction_ordinance) and jo (article filtering, example given in schema). oc remains undocumented in both schema and description. Partial improvement over schema but not complete.
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 '자치법규 본문 조회' (retrieve autonomous law text body), a specific verb+resource. It distinguishes from siblings like search_reduction_ordinance by referencing its result field [자치법규일련번호]. However, it doesn't fully differentiate from other get/search tools in the sibling set.
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 says to feed in the [자치법규일련번호] from search_reduction_ordinance results, establishing a clear workflow chain. It also notes that 'jo' can extract specific articles. However, it doesn't mention when NOT to use it or name alternative tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It reveals a key behavioral trait: reverse index lookup by jo allows pulling all relevant rulings for an article at once. It also frames the tool as more current than NTS. But it doesn't mention response format, pagination behavior, authentication needs, or any side effects. This is adequate but leaves gaps.
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 four sentences, each serving a distinct purpose: resource identification, functional equivalence, key feature, and usage guidance. It is dense but not wordy. No fluff, though it could arguably be tightened by merging the NTS comparison into a single clause.
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 query tool with 5 parameters and no output schema, the description covers the core purpose, a distinctive capability, and usage preference. It is competent but not exhaustive: it doesn't describe return values, error conditions, or the undocumented 'oc' parameter. The schema helps, but the absence of output schema means the description should have filled more gaps.
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 80%, so baseline is 3. The description adds semantic value for 'jo' by explicitly explaining its reverse index capability and giving the '지방세법 제106조' example. However, the 'oc' parameter remains entirely undocumented, and the description doesn't elaborate on 'limit' or 'query' beyond their schema descriptions.
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 the Ministry of the Interior's 'Local Tax-Related Law Operation Rules' and mentions the reverse index lookup by article number, which differentiates it from general search tools. It also adds context by relating it to the National Tax Service's basic ruling. However, it doesn't explicitly contrast with sibling tools like search_moi_interpretation, so it's not a full 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 explicitly advises using this tool over the NTS basic ruling because the NTS version is from 2018 and stale, providing clear contextual guidance. It doesn't mention exclusions or alternative sibling tools, but the 'use this as the authoritative version' instruction is a strong usage signal.
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 discloses the tool's role in the tax workflow and cites the legal basis, implying this is a read-only search operation. However, it doesn't describe pagination behavior, result format, whether results come from a live API vs cache, or rate/auth considerations. The legal-citation context adds value but behavioral traits beyond search semantics are not disclosed.
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 tight two-sentence paragraph that front-loads the core purpose (searching ordinances for tax reduction/rates) and packs legal citations and workflow context efficiently. The Korean text is dense but every clause earns its place, introducing the legal basis, the positioning relative to national tax tools, and the region-accuracy tip. Slightly dense for non-Korean readers but well-structured.
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?
This tool has meaningful complexity: no output schema, 6 parameters with 2 undocumented (oc, page), and no annotations. The description compensates reasonably by explaining the legal framework, workflow timing, and positioning against national tax tools. However, it doesn't clarify the return format (result count, fields), the meaning of oc and page parameters, or filtering semantics of localTaxOnly beyond schema text. Good for a search tool, but leaves the oc and page gaps unaddressed.
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 67% with 3 of 6 parameters described (query, region, display, localTaxOnly have descriptions; oc and page do not). The description adds strategic meaning beyond the schema: it emphasizes that specifying region (지자체명) significantly improves accuracy, which is the description's most actionable parameter guidance. It also frames query as keyword enrichment. However, oc and page remain undocumented in description, leaving some gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: searching municipal reduction ordinances and tax rate ordinances in the legal affairs bureau (법제처) local ordinance database. It clearly distinguishes from national tax MCP tools by noting this is a missing axis (축) not covered by national tax tools. However, it doesn't explicitly name sibling alternatives for differentiation, and the purpose is embedded in a dense two-sentence paragraph.
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 on when to use: before concluding tax amounts (세액 결론 전 반드시 확인), because local taxes rely on ordinances for flexible rates and exemptions per specific legal provisions (지방세법 §111③, 지방세특례제한법 §4). It notes specifying the municipality (지자체명) greatly improves accuracy. It doesn't explicitly state when NOT to use it or name alternatives, but the timing guidance is unusually specific and actionable.
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 full burden, and it delivers substantial behavioral disclosure: default sorting behavior, why the default matters (DRF score ordering pitfalls), and the implicit local-tax filter default. This exceeds the baseline for a search tool without 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 compact, three sentences, and front-loaded with purpose before behavioral warnings. Every sentence earns its place, though the second sentence is dense with reasoning that could be slightly clearer. 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?
For a search tool with 100% schema coverage and no output schema, the description adequately explains purpose, default behavior rationale, and filtering. It doesn't describe return format but output schema is absent, so a slightly richer note on results would be welcome. Overall complete enough for practical 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 6 parameters. The description adds context about the sort default justification (why ddes over score) and local-tax filter behavior, which adds value beyond schema. But it doesn't detail parameter syntax or constraints beyond what 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 the tool searches 조세심판원 지방세 재결례 (local tax tribunal rulings) via 법제처 DRF. The specific verb+resource is clear and disambiguates from siblings like search_reduction_ordinance and search_moi_interpretation which target different 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 provides strong usage context: it warns that the DRF default (score ordering) surfaces 10-year-old cases first and misleads practical judgment, explaining why default sort is ddes. It also notes the local-tax filter is ON by default. This gives clear behavioral guidance. However, it doesn't explicitly contrast with siblings beyond the domain distinction.
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 the description carries the burden. It discloses the sort behavior (최근날짜순 default), the taxItem filter set, and the corpora size (3,369건) which adds context about scope. However, it doesn't disclose pagination behavior beyond '10건 단위' (already in schema), response format, or whether this is a read-only operation - though for a search tool the read-only nature is reasonably implied.
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 compact two-sentence block that front-loads the core purpose, followed by sort and filter options. Every sentence earns its place - the 국세대비 positioning adds valuable context, and the taxItem enumeration is useful. Slightly dense but efficient for a tool with this many filter options.
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 100% schema coverage and no output schema, the description covers the essential context: what it searches, how it differs from 국세 queries, default ordering, and filter options. It could add more about result format or how results relate to get_moi_interpretation sibling, but the coverage is adequate for the tool's moderate complexity.
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 the schema documents all 4 parameters. The description adds marginal value: query examples (별도합산, 부담부증여) and the complete taxItem enum list mirror code. It adds the sort default context (DATE) and page semantics but largely restates what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
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 행정안전부 지방세 유권해석 via OLTA, distinguishes it from 국세 질의회신 (法濟處/NTS do not have it), gives the scale (3,369건), and lists it as a distinct axis vs siblings like search_local_tax_decisions. Verb+resource+scope is specific and distinguishes from 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains the default sort (DATE/최근날짜순), provides query examples (별도합산, 부담부증여), and details the taxItem filter options with all 13 세목 values. It differentiates from 국세 tools and gives clear when-to-use context, though it doesn't explicitly name sibling alternatives for exclusion.
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 discloses that it performs batch verification against real records (실존 여부), which is useful behavioral context. However, it doesn't describe output format, whether it's a read-only operation, rate limits, or what happens when citations don't exist—though the nature as a verification tool makes read-only fairly inferable.
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, zero waste. Front-loaded with the core verification function and format pattern, then the usage timing. 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?
For a verification tool that takes text and checks citations, the description adequately covers the core purpose and invocation timing. No output schema exists, so the description could ideally mention return format or what 'validated' output looks like. But given the relatively simple input (text) and clear purpose, this is nearly complete for the tool's complexity level.
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 50% (text documented, oc undocumented). The description adds context that 'text' is the content to verify (사유서 초안 등) and describes what it extracts. However, the 'oc' parameter is completely undocumented—the description doesn't clarify what 'oc' means, leaving the agent to guess. With only 50% coverage and a silent parameter, baseline 3 is appropriate but not higher.
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 local tax case numbers (조심 ****지****/****방**** format) from text and batch-verifies their real existence. The verb '일괄 검증한다' (batch verify) plus the specific resource (조세심판원 지방세 사건번호) makes it distinct from siblings like search_local_tax_decisions (searching) or get_local_tax_decision (retrieving one).
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?
States when to call it: '사유서·검토조서 확정 직전에 호출할 것' (call before finalizing reason documents/review memos). This gives clear timing context. However, it doesn't explicitly state when NOT to use it or name alternative tools, though the verification-vs-search distinction is fairly implied by the description.
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 of behavioral disclosure. It does disclose a key behavioral trait: the tool returns limited information (본문 only up to '그 시점 시행 문구', not the full application-year determination) and defers the actual application-year decision to the 부칙 logic. However, it doesn't describe return format, failure modes, or data-source boundaries. Moderate transparency given the zero-annotation 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 concise—three sentences covering purpose, scope boundary, and pairing requirement. Every sentence carries distinct value with no fluff. Slightly loses a point for mixing Korean technical legal terms in a way that's dense but still appropriate for the domain.
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 6 parameters with 83% schema coverage and no output schema, the description does well: it explains the tool's judgment logic, boundary (본문만 제공), and the critical pairing requirement. The undocumented 'oc' parameter and lack of return-format clarity are minor gaps for a tool of moderate complexity. Overall adequate for correct invocation.
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 83% (5 of 6 params documented: jo, year, limit, query, lawName; oc has no description). The description explains the jo param's priority logic (specified jo prioritizes relevant 부칙) and the year param's semantics (the 과세연도 to determine). This adds reasonable meaning but doesn't fully compensate for the undocumented 'oc' parameter, which remains opaque.
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 verb ('판정한다' - determines), the resource (부칙/supplementary provisions of 시행일·적용례·경과조치), and the scope (which 과세연도 a provision applies to). It distinctly differentiates from siblings by explaining what it does NOT do (본문 only shows '그 시점 시행 문구', application year comes from 부칙) and names the sibling it pairs with (get_local_tax_article).
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 gives explicit when-to-use guidance: use it when determining application timing via supplementary provisions (부칙). It explicitly states the pairing requirement ('get_local_tax_article과 반드시 짝으로 호출할 것') when handling past attribution-year adjustments, which is a clear directive distinguishing it from alternatives. This is a strong explicit guideline.
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 reveals that year/efYd selects the version in effect at a given time, that the tool automatically compares with the current version and warns about changes/deletions, and that it refuses non-local-tax laws to prevent partial-matching errors. This adds substantial context beyond the schema, though it does not describe the exact return format or edge cases like missing versions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and the supported-law list is presented as a compact enumeration. Every sentence provides either scope, usage, or behavioral context with no redundant content, making it both concise and well-structured.
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 having 6 parameters and no output schema, the description covers the primary purpose, version selection logic, comparison behavior, supported law scope, and rejection policy. It does not explain the 'oc' parameter (which also lacks a schema description) or the precise return structure, but the phrase '조문 본문' and the warning behavior make the output fairly predictable, so the description is highly complete.
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 at 83%, giving a baseline of 3. The description adds meaning by explaining that year/efYd select the version in effect at that point ('year/efYd로 그 시점 시행본을 선택') and by listing acceptable lawName values (supported laws). This enriches the understanding of these key parameters 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?
Description opens with '지방세 관계법의 시점별 조문 본문' (time-specific article text of local tax laws), which specifies the exact resource and the time-scoped retrieval. It enumerates the supported local tax laws, clearly differentiating this tool from sibling tools like get_ordinance_text (ordinance text) or get_local_tax_decision (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?
The description states that only the listed local tax laws are supported and explicitly says non-local-tax laws are rejected without fallback ('지방세 관계법이 아니면 폴백 없이 거부한다'), providing clear exclusion criteria. It does not, however, name alternative tools for non-local-tax queries, so explicit alternatives are missing.
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:

[![local-tax-mcp MCP server](https://glama.ai/mcp/servers/seunguk3/local-tax-mcp/badges/card.svg)](https://glama.ai/mcp/servers/seunguk3/local-tax-mcp)

Score Badge

Copy to your README.md:

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

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