Skip to main content
Glama

Relief candidates to check

screen_relief_candidates
Read-onlyIdempotent

Surface tax relief and special-case articles to review for a given situation before closing a consultation, so missed reductions don't silently cost the client.

Instructions

List the tax reliefs and special cases worth checking for a given situation, to avoid omissions.

조특법·지특법 감면/특례 중 이 상담에서 검토해야 할 조문을 뽑는다 (누락 방지용).

**판정이 아니다.** judge_*/calc_*는 A등급 법문 노드로 결론을 내지만 이 툴은
C등급 기계추출 색인이라 "여기를 봐라"까지만 한다. 감면 누락은 고객이 세금을 더
내는 방향이라 틀린 답보다 조용히 손해가 나므로, 상담 마무리 전에 한 번 돌려
빠진 감면이 없는지 확인하는 용도다. 걸린 조문은 반드시 원문·판정툴로 재확인한다.

Args:
    tax_types: 세목 쉼표 구분 — "양도소득세,취득세,재산세,종합부동산세,증여세" 등
    situation: 상담 문장 그대로 넣어도 된다. 생활어(첫집·다둥이·수용보상)를
        법령 용어 계열로 확장해 매칭한다
    assets: 자산 쉼표 구분 — "주택,농지,토지,임대주택,미분양주택,분양권·입주권" 등
    include_expired: 본문 기한이 전부 과거인 조문까지 포함(경정청구·과거 취득분 검토 시)
    include_decree: 시행령 조문까지 포함(요건 상세를 볼 때. 기본은 법 조문만)
    include_corporate: 법인·기관 전용 조문까지 포함
    limit: 최대 표시 건수

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
assetsNo
situationNo
tax_typesNo
include_decreeNo
include_expiredNo
include_corporateNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses the critical behavioral caveat: this is a C-grade machine-extracted index, not authoritative, and omissions cause silent client harm (over-payment), so every hit must be re-verified. This reliability/quality disclosure is exactly what annotations cannot convey.

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 English one-liner followed by detailed Korean guidance; each part earns its place. However, the bilingual rendering conveys the same purpose twice, adding length and some parsing friction for an agent, so it is slightly redundant rather than maximally tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, no required params, and a complex domain, the description still supplies purpose, usage timing, reliability caveats, and full parameter semantics. An agent has everything needed to invoke it correctly and interpret its output cautiously.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden and does so for all 7 parameters: tax_types (comma-separated 사목), situation (free text; living language expanded to legal terms), assets, and the three boolean includes with their concrete conditions, plus limit. It adds meaning well beyond the bare schema titles.

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?

States a specific verb (list), resource (tax reliefs and special cases), and scope (worth checking for a given situation, to avoid omissions). It explicitly differentiates itself from the judge_*/calc_* siblings by noting those produce conclusions with A-grade law nodes while this is a C-grade index that only points to where to look.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says '판정이 아니다' (this is not a determination), directs the agent to judge_*/calc_* for conclusions, and prescribes exactly when to run it (before finishing a consultation to catch missed reliefs) and how to treat results (re-verify hits with original text and judgment tools). Clear when-to-use plus the alternative tools, no inference needed.

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