Skip to main content
Glama

fin_law_search

Read-onlyIdempotent

Search Korean financial, tax, and accounting laws and reorder results by financial relevance. Flags repealed, historical, or upcoming statutes and provides topic-specific legal hints.

Instructions

[재무·세무·회계 전용 — 법령 검색은 이 도구를 우선 사용] 법령을 검색해 재무 관련도순으로 재정렬한다. 폐지·연혁·시행예정을 표시하고, 주제어에 맞는 법령 힌트를 동봉한다. 조문 내용까지 필요하면 결과를 fin_article에 넘길 것.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes검색어 (법령명 또는 법령명+키워드)
basis_dateNo기준일 YYYY-MM-DD (생략 시 현행) — 해당 시점 시행본으로 검색
include_ordinanceNo지방세 감면 조례 확인 시에만 true (기본 false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint), yet the description adds genuine behavioral context beyond them: results are re-ranked by financial relevance, repealed/historical/scheduled-enforcement laws are flagged, and topical law hints are attached. It does not describe result shape, counts, or pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, with the most decision-critical information (financial-domain scope and priority) front-loaded in the bracket. Every sentence carries a distinct payload; only the bracketed form is slightly dense.

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 3-parameter read-only search with fully documented schema but no output schema, the description supplies the missing pieces: output shaping (relevance re-rank, status flags, hints) and the downstream handoff to fin_article. Nothing essential to correct invocation is absent, though result size/format remains unspecified.

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 all three parameters (query, basis_date, include_ordinance) are already documented with format and defaults. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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+resource (법령을 검색) scoped to 재무·세무·회계, and explicitly differentiates its role from fin_article by noting article-level content is a separate step. An agent can tell it apart from fin_ruling_search and fin_annex without opening any schema.

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 bracketed prefix gives an explicit priority rule ('법령 검색은 이 도구를 우선 사용') and the closing sentence names the alternative and the condition that selects it ('조문 내용까지 필요하면 fin_article로'). It stops short of explaining when a rulings tool (fin_ruling_search) should be preferred instead, so the routing is clear but not exhaustive.

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