Verify Korean legal citations against law.go.kr: precedents, statutes, bar-exam answers.
Scored across 19 tools
Each of the 19 tools has a clearly distinct purpose — lookup_statute vs lookup_precedent vs search vs verify_citations are explicitly differentiated in their descriptions, and the description of `search` even directs users to the correct alternatives. The distinction between ask, ask_expert, and chat_leader is spelled out via plan/credit/cost differences.
Nearly all tools follow a consistent snake_case verb_noun pattern (lookup_statute, lookup_precedent, search_legal_forms, get_leaders, generate_document), with minor but readable forms like ask, search, verify_citations. No camelCase or mixed conventions.
19 tools is borderline high for a single server; it spans legal analysis, document generation, exam corpus, content, account/billing, and lookup, which could arguably be split into sub-servers. The count is not unreasonable but is heavier than typical well-scoped servers.
The surface covers CRUD-like reads across statutes/precedents/forms/content/leaders, drafting, verification, and account/pricing, with no glaring dead ends. Minor gap: no tool to update or delete user accounts or manage credit packs beyond reading status/pricing, but the core legal workflows are fully supported.
[KEY REQUIRED · 2 credits] 한국 법률 질문에 답합니다. 60명의 전문 리더 중 한 명에게 자동 배정하고, 인용한 조문을 law.go.kr에서 실시간 검증한 분석을 돌려줍니다. 한국어·영어 모두 지원합니다. / Ask a Korean legal question. Routes to 1 of 60 specialist AI legal leaders and returns a statute-verified analysis (real-time law.go.kr check). Korean and English.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language. Auto-detected if omitted. | |
| query | Yes | Legal question in Korean or English (max 2000 chars). | |
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. | |
| idempotency_key | No | 선택. 재시도 안전 키(8~64자, 영숫자·_-.). 같은 키로 다시 부르면 **두 번 과금되지 않고** 보관된 답변을 그대로 돌려줍니다(24시간). 타임아웃·연결 끊김으로 응답을 못 받았을 때 같은 키로 재시도하세요. / Optional retry-safe key (8-64 chars). Retrying with the same key is never charged twice and replays the stored answer for 24h. |
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 explains key and credit requirements, automatic routing among 60 specialists, real-time statute verification via law.go.kr, and bilingual support. It does not disclose response format or rate limits, but it covers the most important behavioral traits for an agent deciding whether to call it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the most operationally important facts: key required and 2 credits. The bilingual Korean/English form is justified by the tool's advertised language support, though it does duplicate the same content. No unrelated or filler information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-required-parameter ask tool, the description and schema together provide the necessary context: cost, required key, language support, routing behavior, verification process, retry semantics, and caller tagging. No output schema exists, but the description's phrase 'returns a statute-verified analysis' gives a reasonable high-level return expectation. Minor gaps like exact response shape are not critical for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema entries are already rich, especially for client_tag and idempotency_key. The main description adds no parameter-specific meaning beyond the schema, such as retry behavior or formatting rules aids. It repeats that questions can be in Korean or English, which the schema already states, so the description only meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: asking a Korean legal question and receiving a statute-verified analysis routed to one of 60 specialist AI leaders. It is not vague or tautological, and the real-time law.go.kr verification detail adds distinctiveness. However, it does not explicitly distinguish itself from similar siblings such as ask_expert or chat_leader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this for Korean legal questions in Korean or English. The description also communicates prerequisites like requiring a key and costing 2 credits. But it gives no explicit when-not-to-use guidance or comparisons to alternatives like ask_expert or chat_leader, leaving sibling selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[KEY REQUIRED · 3 credits · PRO plan only] 전문가 모드 법률 분석 — 전체 검증 파이프라인을 돌려 더 깊이 인용된 답변을 만듭니다. ask보다 느립니다. Pro 요금제 전용입니다(Pro 크레딧 팩 구매 시 활성화). 잔액만으로는 열리지 않으며, Pro가 아니면 3크레딧을 차감하지 않고 거절합니다 — 그 경우 ask(2크레딧)를 쓰세요. / Expert mode legal analysis — runs the full verification pipeline for a more detailed, deeply-cited answer. Slower than ask. Pro plan only (unlocked by buying the Pro credit pack); a positive balance alone is not enough. Non-Pro callers are refused without being charged — use ask (2 credits) instead.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language. Auto-detected if omitted. | |
| query | Yes | Legal question in Korean or English (max 2000 chars). | |
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. | |
| idempotency_key | No | 선택. 재시도 안전 키(8~64자, 영숫자·_-.). 같은 키로 다시 부르면 **두 번 과금되지 않고** 보관된 답변을 그대로 돌려줍니다(24시간). 전문가 답변은 단가가 가장 높아 타임아웃 시 이 키가 특히 중요합니다. / Optional retry-safe key (8-64 chars). Retrying with the same key is never charged twice and replays the stored answer for 24h. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it discloses significant behavior: cost (3 credits), Pro-plan gating, refusal-without-charge for non-Pro, and higher latency vs `ask`. It stops short of describing the answer's return structure or any rate limits, but the billing and access semantics are unusually well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the critical gating facts in bracketed tags ('KEY REQUIRED · 3 credits · PRO plan only') before any prose, which is ideal for scanning. The Korean/English duplication is deliberate for a bilingual product but does inflate length noticeably.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-param tool with no output schema and no annotations, the description covers pricing, access gating, latency, and the sibling alternative. What is missing is only minor: a brief note on the answer's shape (beyond 'deeply cited') and any timeout/latency guidance beyond 'slower'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 query, lang, client_tag, and idempotency_key in detail (including the idempotency replay and charging behavior). The description adds no parameter-level detail beyond that, so the baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('전문가 모드 법률 분석' / expert-mode legal analysis) plus the mechanism ('runs the full verification pipeline'). It explicitly distinguishes itself from the sibling `ask` ('slower than ask', 'use ask (2 credits) instead'), so an agent can pick between them without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use (deep citations, expert mode) and when-not-to-use (non-Pro callers, use `ask`). It names the alternative and the condition that selects it, and clarifies that a positive balance alone is insufficient and that non-Pro calls are refused without charge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[KEY REQUIRED · no credits, 60/day] 변호사시험(변시) 코퍼스를 검색합니다 — 15회 전 회차 2,340문항(선택형 2,250 + 사례형 45 + 기록형 45), 인용이 law.go.kr 검증을 통과한 금답안. 사건번호('2014도6992')·조문('형법 제310조')·키워드로 조회하면 회차·과목·문항번호·공식 정답·지문·인용 조문/판례와 링크를 돌려줍니다. / Search the Korean bar exam (변호사시험) corpus — all 15 rounds, 2,340 questions (2,250 MCQ + 45 case-type + 45 record-type) with gold-standard answers whose citations passed law.go.kr verification.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Docket, statute article or keyword. | |
| limit | No | Max results (1-20, default 5). | |
| round | No | Filter by exam round 1-15 (optional). | |
| subject | No | Filter by subject: 공법 / 민사법 / 형사법 (optional). | |
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. |
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 key behavioral traits: a key is required, a daily quota of 60 applies, citations have passed law.go.kr verification, and client_tag is logged-only and ignored if invalid (not rejected). It also warns that putting client_tag in the query text changes results. This goes beyond minimal disclosure, though it doesn't describe error handling or pagination behavior, which are minor gaps for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the most critical constraint ([KEY REQUIRED · no credits, 60/day]), then the corpus scope, then the return details. It includes both Korean and English translations, which is slightly redundant but not wasteful. It is structured and informative without excessive fluff, earning a solid score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description must cover both usage and returns. It enumerates the output fields (round, subject, question number, official answer, text, cited statutes/cases, links) and explains the client_tag edge case thoroughly. It does not explicitly describe result ordering, pagination, or how multiple matches are presented, but for a search tool with a limit parameter, the essentials are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds extra value by giving concrete examples for the 'q' parameter ('2014도6992', '형법 제310조') and by extensively clarifying the client_tag parameter's semantics: it never affects the response, is only logged for caller identification, is ignored if invalid rather than rejected, and must not be placed in the query text. This supplements the schema meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('search') and resource (Korean bar exam corpus), with detailed content (15 rounds, 2,340 questions, breakdown by type) and a precise list of returned fields (round, subject, question number, official answer, text, cited statutes/cases, links). It distinguishes itself from siblings like lookup_statute or search by being specific to the bar exam corpus, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is for searching the bar exam corpus using docket numbers, statute articles, or keywords, and mentions the daily limit of 60 and key requirement. However, it does not explicitly state when to prefer this tool over siblings like lookup_precedent, lookup_statute, or search, nor does it mention any exclusions (e.g., when not to use). Thus it provides context but lacks explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[KEY REQUIRED · 1 credit] 특정 리더와 1:1로 대화합니다. get_leaders에서 얻은 leader_id(예: 'L01', 'L32', 'CCO')를 넘기세요. 1회당 1크레딧이 차감됩니다(ask 와 같은 선예약 — 답변이 실패하면 환불). / Chat 1:1 with a specific legal leader. Provide the leader_id (e.g. 'L01', 'L32', 'CCO') from get_leaders. Each call costs 1 credit, reserved up front like ask and refunded if no answer is delivered. Pass history when continuing a conversation — otherwise the leader asks the same follow-up questions again.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Question to ask the leader (max 2000 chars). | |
| confirm | No | Deprecated (2026-09-27): leader chat now costs 1 credit per call with no separate free allowance, so no confirmation step is needed. Accepted and ignored for backward compatibility. | |
| history | No | 이전 대화. 이것을 안 보내면 서버는 매 호출을 **첫 대화**로 보고 같은 것을 또 되묻습니다 — 리더가 물어본 뒤 답을 줄 때는 그 두 턴을 반드시 함께 넘기세요. 최근 20턴까지 반영됩니다. / Prior turns. Without this the server treats every call as a fresh conversation and asks the same questions again — when you answer a leader's follow-up, send those turns here. Up to 20 recent turns are used. | |
| leader_id | Yes | Leader identifier (e.g. 'L01'). See get_leaders. | |
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. | |
| idempotency_key | No | 선택. 재시도 안전 키(8~64자, 영숫자·_-.). 30초 안에 안 끝나면 'pending'과 키를 돌려줍니다 — 같은 키로 다시 부르면 진행 중이거나 방금 끝난 답을 **새로 과금하지 않고** 받습니다. / Optional retry-safe key. If the chat takes longer than ~30s you get `pending` with a key; call again with the same key to collect the reply without a second charge. |
[KEY REQUIRED · no credits, 60/day] 법무부 '마을변호사'를 지역으로 찾습니다 — 무료 법률상담 연락처입니다. 시·도, 시·군·구, 읍·면 이름으로 검색하세요(예: '강원 강릉', '고성군', '완도'). 이 사업은 변호사가 없는 읍·면을 대상으로 하므로 서울·부산 등 특별시·광역시의 구(區)는 수록되어 있지 않습니다 — 결과가 0건이면 응답의 coverage 항목에서 수록된 시·도를 확인하세요. 공공데이터 기반, LLM 미호출. / Find the Ministry of Justice 마을변호사 (village lawyer) assigned to a Korean locality — a free legal-consultation contact point. The programme covers rural 읍·면 without a resident lawyer, so districts of Seoul and other metropolitan cities are not listed; an empty result returns the covered provinces. Public data, no LLM.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-50, default 10). | |
| region | Yes | Region name. Example: '강릉시'. | |
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: KEY REQUIRED, no credits, 60/day rate limit, public data source, no LLM call, and the empty-result/coverage behavior. These are non-obvious operational traits an agent needs before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Key operational facts (KEY REQUIRED, rate limit) are front-loaded and the critical coverage caveat is bolded. It is dense rather than bloated, though the full Korean/English duplication roughly doubles the length for the same information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description still tells the agent that an empty result returns covered provinces via a coverage field. Combined with the rate limit, key requirement, and coverage scope, an agent has everything needed to call correctly and interpret a null result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by showing multiple region-name formats ('강원 강릉' as a combined string, '고성군', '완도') and by explaining the coverage limitation that governs whether region matches anything, which the schema's single '강릉시' example does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (find) plus resource (마을변호사/village lawyer) and the scope (assigned to a Korean locality, a free legal-consultation contact point). This is clearly distinguishable from siblings like lookup_precedent, lookup_statute, or search, which cover different legal resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to search by 시·도, 시·군·구, 읍·면 name and gives concrete query examples ('강원 강릉', '고성군', '완도'). It also states the negative condition — metropolitan districts like Seoul/Busan are not covered — and tells the agent what to do on an empty result (check the coverage field). This is when-to-use, when-not, and fallback all in one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[KEY REQUIRED · 2 credits] 사용자의 사실관계로 한국 법률 문서 초안을 작성합니다(고소장·소장·내용증명·답변서·합의서·법률의견서 등). 초안의 모든 조문·판례 인용은 ask와 동일한 fail-closed law.go.kr 검증을 거칩니다. 유효한 doc_type 키는 list_document_types로 먼저 확인하세요. / Draft a Korean legal document from the user's facts. Every statute/precedent citation in the draft goes through the same fail-closed law.go.kr verification as ask. Use list_document_types first for valid doc_type keys.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Default ko. 'en' returns the Korean original (the version to file with Korean courts/police) followed by an English translation for reference. | |
| context | Yes | The user's facts/situation the document must be built from. | |
| doc_type | Yes | Document type key from list_document_types (e.g. 'complaint'). | |
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. | |
| idempotency_key | No | 선택. 재시도 안전 키(8~64자, 영숫자·_-.). 같은 키로 다시 부르면 **두 번 과금되지 않고** 보관된 문서를 돌려줍니다(24시간). 30초 안에 안 끝나면 'pending'과 키를 돌려줍니다. / Optional retry-safe key. Retrying with the same key is never charged twice and replays the stored document for 24h. Long drafts return `pending` with a key after ~30s. | |
| extra_instructions | No | Optional extra drafting instructions. |
[KEY REQUIRED] 사용 중인 API 키의 계정 상태 — 남은 크레딧, 플랜, 충전 링크. 과금 도구를 길게 쓰기 전에 호출해, 작업 도중 잔액이 떨어지는 대신 미리 충전하세요. / Your account status for the API key in use — remaining credits, plan, and a top-up link. Call this before a long run of metered queries so you can purchase in advance instead of hitting an exhausted balance mid-task.
| Name | Required | Description | Default |
|---|---|---|---|
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose the key pieces: the tool requires an API key ([KEY REQUIRED]), it reads rather than mutates, and it explains the operational rationale (avoiding balance exhaustion mid-task). It stops short of rate-limit, error, or freshness behavior, but covers the traits an agent needs most.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the critical constraint ([KEY REQUIRED]) then the purpose and the usage trigger. It is duplicated in Korean and English, which doubles the length, but the content is dense and every sentence earns its place, so this is a structural choice rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A simple single-parameter read tool with no output schema and no annotations; the description compensates by naming the returned fields (credits, plan, top-up link) and the auth requirement. Nothing essential for correct invocation is missing, though error/edge behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single optional client_tag parameter is fully documented in the schema itself, including its no-effect-on-response semantics. The description adds no parameter detail beyond that, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (account status for the API key in use) and enumerates exactly what is returned — remaining credits, plan, top-up link. It is unmistakably distinct from every sibling, all of which are legal-research or content tools, so an agent can select it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger: 'Call this before a long run of metered queries so you can purchase in advance instead of hitting an exhausted balance mid-task.' That is clear when-to-use guidance. It does not name a when-not-to-use case or an alternative tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[KEY REQUIRED · no credits, 60/day] 발행된 데일리 콘텐츠 한 편을 전체 레코드 형태로 가져옵니다: 오늘의 법률상식(daily — 검증 조문 목록과 FAQ 포함), 전략 칼럼(strategy)·기술 칼럼(tech, 라이브 확인된 참고자료 포함), 리걸테크 뉴스(news, 출처 도메인 포함), 수험 판례 강의노트(bar), 오늘의 판례(precedent — 검증 판례 레코드 첨부). 날짜를 주거나, 생략하면 해당 스트림의 최신 편. / Fetch one published daily post in full-record form. Pass a date, or omit it for the latest post in that stream.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD. Omit for the latest post. | |
| stream | Yes | Content stream. | |
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: auth requirement (KEY REQUIRED), cost/quota (no credits, 60/day), and the date-vs-latest defaulting behavior. It stops short of describing failure modes or what 'full record' concretely returns, but the quota and auth disclosures are the high-value facts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Key constraints are front-loaded in the bracketed prefix before the content explanation. The Korean/English duplication roughly doubles the length, but the English mirrors rather than adds, so no information is wasted, just repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter read tool with no output schema and no annotations, the description covers auth, quota, stream enumeration, and date defaulting — everything needed to call it correctly. Only the concrete shape of the returned 'full record' is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns more by explaining what each stream value actually yields (daily includes verified provisions and FAQ, tech includes live-verified references, precedent attaches verified case records), which the bare enum does not convey. Date omission semantics are also restated usefully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('fetch one published daily post in full-record form') and enumerates the six streams with what each contains, so the agent knows exactly what comes back. It does not, however, differentiate itself from the sibling latest_content, which appears to overlap on the 'omit date for latest' behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete operating conditions up front (KEY REQUIRED, no credits, 60/day limit) and explains the core usage decision — pass a date or omit it for the latest post in that stream. It never names an alternative tool or states when NOT to use this one, so no explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[KEY REQUIRED · 3/day free, then 1 credit each] 변호사시험 문항 하나를 금답안 전문과 함께 가져옵니다. 선택형: round+subject+no → 공식 지문·선택지 5개·법무부 정답·해설·선택지별 노트·인용 조문/판례. 사례형·기록형: round+subject+format → 서면 종류·목차·답안 본문. 모든 인용은 게시 전 law.go.kr 검증을 통과했습니다. 호출당 1문항 — 이 코퍼스는 대량 추출 대상이 아닙니다. / Fetch ONE bar-exam question with its full gold answer. MCQ (선택형): pass round + subject + no. Essay (사례형) and record-type (기록형): pass round + subject + format. Every citation passed law.go.kr verification before publishing. One item per call — this corpus is proprietary and not available for bulk export.
| Name | Required | Description | Default |
|---|---|---|---|
| no | No | Question number (선택형 only). | |
| round | Yes | Exam round 1-15 (제N회). | |
| format | No | Default 선택형 when `no` is given. | |
| subject | Yes | 공법 · 민사법 · 형사법 (선택과목명도 가능). | |
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the key requirement, the rate model (3/day free, then 1 credit each), the single-item-per-call limit, and the law.go.kr citation-verification provenance. It does not describe error behavior or what happens when a round/subject combination has no matching item.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The pricing/quota warning is front-loaded in brackets, followed by the format routing, which is good structure. It is somewhat long because the same content is repeated in Korean and English, but the duplication is deliberate for bilingual callers and each version is tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return contents — and it does, listing 지문/선택지 5개/정답/해설/인용 조문·판례 for MCQ and 서면 종류/목차/답안 본문 for essays. Combined with the quota and routing details, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the baseline is 3, but the description adds real value beyond the schema by explaining the conditional routing between `no` (MCQ) and `format` (essay/record) and the valid format values. It stops short of documenting round ranges or subject edge cases that the schema already handles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Fetch ONE bar-exam question with its full gold answer,' and it enumerates what each exam format returns. It is clearly distinguishable from the sibling bar_exam_search, which searches rather than retrieves a single item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly routes the agent by format (선택형 → round+subject+no; 사례형/기록형 → round+subject+format) and warns 'one item per call — not available for bulk export,' which implies the corpus-wide alternative. It never names the sibling to use for bulk/search, so no explicit exclusion is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[KEY REQUIRED · no credits, 60/day] 60명 이상의 전문 리더 목록을 이름·전문 분야와 함께 돌려줍니다. / List all 60+ specialist legal leaders with their names and specialties.
| Name | Required | Description | Default |
|---|---|---|---|
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does deliver real behavioral context: API key required, no credit consumption, and a 60/day rate limit. It also clarifies that the full set (60+) is returned rather than a filtered subset. It stops short of stating what happens on a missing/invalid key or whether pagination exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The operational constraints are front-loaded in a bracketed tag, and the core purpose follows immediately. The bilingual restatement doubles the length, but it is deliberate audience coverage and no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-argument listing tool with no output schema and no annotations, the definition covers the essentials: auth requirement, cost, quota, and what fields come back (names and specialties). Only edge-case behavior (invalid key, empty results) is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single optional client_tag parameter is thoroughly documented in the schema (format, logging-only behavior, non-rejection). The description adds nothing about parameters, which is acceptable given the schema does the work, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: returning a list of 60+ specialist legal leaders with their names and specialties. It is clearly distinguishable from chat_leader or ask_expert by being a read-only directory listing, though it never names those siblings. Purpose is unambiguous on its own.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It discloses prerequisites and constraints ('KEY REQUIRED', 'no credits, 60/day'), which implies this is a metered listing call. However, it gives no guidance on when to prefer this over sibling tools like chat_leader or find_village_lawyer, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[NO KEY NEEDED] 이용 방법과 비용을 돌려줍니다 — 가입 절차, API 키 발급처, 무료 제공량, 크레딧 팩 가격(KRW/USD), 크레딧 1개로 무엇을 할 수 있는지, 결제 링크. 인증 없이 호출할 수 있습니다 — 처음 방문한 AI 에이전트는 이 도구로 접근 방법을 확인하세요. / How to get access and what it costs. Returns the sign-up flow, where to issue an API key, the free allowance, credit-pack prices (KRW/USD), what one credit buys, and direct checkout links. Callable without authentication — an AI agent arriving for the first time should call this to learn how to obtain access.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Default en. | |
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It crucially states '[NO KEY NEEDED]' and 'Callable without authentication', which are key auth traits, and it enumerates the returned information. It does not mention rate limits or side effects, though these are likely absent for a read-only info endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with '[NO KEY NEEDED]' and clear structure using bold and separators. The bilingual Korean and English duplication doubles length, but each version is concise and well-organized for its respective audience.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must explain return values; it does so comprehensively, listing sign-up flow, API key location, free allowance, credit prices, what a credit buys, and checkout links. Given no annotations and a simple two-parameter schema, the description is complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both parameters thoroughly, including enum values and client_tag logging behavior. The description adds no parameter semantics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb 'returns' and enumerates the exact resource: sign-up flow, API key issuance, free allowance, credit-pack prices in KRW/USD, what one credit buys, and checkout links. This clearly distinguishes it from legal-query siblings like lookup_statute or ask_expert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'an AI agent arriving for the first time should call this to learn how to obtain access', giving clear context for use. It does not name alternatives or when-not to use, but the context is sufficient for this informational tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[KEY REQUIRED · no credits, 60/day] 법마디의 최신 데일리 법률 콘텐츠 — 오늘의 법률상식(daily), 전략 칼럼(strategy), 기술 칼럼(tech), 리걸테크 뉴스(news), 수험 판례 강의노트(bar), 오늘의 판례(precedent). 모든 편은 발행 게이트를 통과했습니다(조문·판례 인용 law.go.kr 검증, 출처 라이브 확인). / Get Lawmadi's latest daily legal content. Every post passed its publishing gate (statute/precedent citations verified against law.go.kr, sources live-checked).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Posts per stream (1-20, default 5). | |
| stream | No | Single stream, or blank for the latest of each. | |
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the auth requirement (key), the rate limit (60/day), zero credit cost, and a meaningful quality guarantee (every post passed a publishing gate with citations verified against law.go.kr and live-checked sources). It stops short of 5 by not describing response shape 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The critical constraints ('KEY REQUIRED · no credits, 60/day') are front-loaded and every sentence conveys operational information. However, the full bilingual duplication of the body roughly doubles the length, which is redundant for an agent reading either language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param, no-output-schema tool with no annotations, the definition covers the essentials: what content is returned, per-stream semantics, quota, and a quality guarantee. The main gap is that the response structure (per-stream grouping, limits) is only hinted at rather than described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description adds value by mapping each enum value to its Korean-language stream concept (e.g. daily = 오늘의 법률상식, strategy = 전략 칼럼) and clarifying that a blank stream means 'the latest of each.' This gives the agent meaning beyond the raw enum tokens.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Get Lawmadi's latest daily legal content' and enumerates the concrete content streams (daily, strategy, tech, news, bar, precedent). However, it never distinguishes itself from the sibling get_daily_content, which sounds like it could serve an overlapping purpose, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives real usage context — 'KEY REQUIRED · no credits, 60/day' tells the agent the cost and quota — but never says when to call this versus alternatives like get_daily_content or the individual lookup tools. Usage is implied rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[KEY REQUIRED · no credits, 60/day] 법마디가 초안을 쓸 수 있는 법률 문서 종류를 한국어·영어 라벨과 함께 나열합니다(고소장·소장·내용증명·답변서·탄원서·합의서·법률의견서 등). / List the legal document types Lawmadi can draft, with Korean and English labels.
| Name | Required | Description | Default |
|---|---|---|---|
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it front-loads '[KEY REQUIRED · no credits, 60/day]', disclosing auth requirement, cost model, and a rate limit. It does not explicitly state the return shape or that it is a pure read, though 'list' implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the critical operational constraint (key/quota), followed by the purpose statement. The bilingual duplication is mildly redundant but serves a genuinely bilingual product, so it still earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-required-parameter listing tool with no output schema and no annotations, the description covers purpose, examples, cost, and quota. It stops short of describing the return structure (e.g., how Korean/English labels are paired), the only minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one optional parameter and schema description coverage is 100%, so the schema already fully documents client_tag, including its logging-only, non-response-affecting behavior. The description adds nothing about parameters, which is the correct baseline at full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the legal document types Lawmadi can draft') and even enumerates representative examples (고소장·소장·내용증명·답변서·탄원서·합의서·법률의견서). This clearly separates it from siblings like generate_document or search_legal_forms without needing either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The catalog-listing nature implies when to use it (discovering what can be drafted before calling generate_document), but this is never stated explicitly. No when-not-to-use or sibling routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[NO KEY · preview depth, 1/day] 사건번호로 한국 판례를 조회합니다. 먼저 검증 자산(17,954건, 전부 law.go.kr 본문 대조 완료)을 보고, 없으면 law.go.kr 정본 색인(대법원 판례·헌재결정례 전수)에서 실재를 확인한 뒤 본문을 직접 받아옵니다. 응답의 source 필드가 근거의 강도를 가릅니다 — corpus 는 본문까지 대조된 것이고, authoritative_index 는 정본에서 실재를 확인하고 본문을 그 자리에서 받아온 것입니다. 법원·선고일·사건명·판시사항·판결요지·참조조문과 law.go.kr 원문 직결 링크를 돌려줍니다. LLM을 부르지 않는 결정론적 조회라 할루시네이션이 없습니다. 입력 예: '2020도3050', '대법원 2024. 4. 16. 선고 2020도3050 판결', '2016헌마90'. / Look up a Korean court case by docket number in Lawmadi's verified-asset corpus (17,954 precedents, each confirmed against law.go.kr). Returns court, decision date, case name, holding, summary, referenced articles and a direct law.go.kr full-text link. Deterministic — no LLM, no hallucination. Callable without an API key at preview depth (metadata + law.go.kr link + first 200 chars of the holding); a key unlocks the full holding, summary and referenced articles. / 키 없이도 미리보기 깊이로 조회됩니다 — 판시사항 전문·판결요지·참조조문은 키 발급 후 제공됩니다.
| Name | Required | Description | Default |
|---|---|---|---|
| case_no | Yes | Docket number or full citation. Example: '2020도3050'. | |
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. |
[NO KEY · preview depth, 1/day] 한국 법령 조문을 조회합니다. 먼저 검증 자산(31,830개 조문, 본문 포함)을 보고, 없으면 law.go.kr 정본 색인(현행 법령 전수)으로 그 조문이 실재하는지 판정합니다. 정본 색인 경로는 본문을 갖고 있지 않으므로 실재 여부와 law.go.kr 링크만 돌려줍니다 — 본문을 지어내지 않습니다. 그 법령을 결번 없이 아는 경우에는 없다는 것도 말합니다(absent=true). LLM 미호출·결정론. 입력 예: '민법 제750조', '형법 제307조 제1항'. / Look up a Korean statute article in Lawmadi's verified-asset corpus (31,830 articles). Returns the article title, body text and law.go.kr link. Deterministic — no LLM. Callable without an API key at preview depth (title + law.go.kr link + first 200 chars of the body); a key unlocks the full article body. / 키 없이도 미리보기 깊이로 조회됩니다 — 조문 본문 전문은 키 발급 후 제공됩니다.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | Statute reference. Example: '민법 제750조'. | |
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does so well: it discloses the preview depth without a key (title + law.go.kr link + first 200 chars), the 1/day limit, that a key unlocks the full body, that it is deterministic with no LLM call, that it will not fabricate body text, and that it can affirmatively return absent=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The critical 'no key / preview depth' constraint is front-loaded, which is good, but that same information is repeated three times across the header tag, the English paragraph, and the closing Korean sentence. The bilingual duplication makes it noticeably longer than necessary for a two-parameter lookup.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain the return shape, and it does: article title, body text, law.go.kr link, and an absent flag for confirmed non-existence. It stops short of describing error behavior for malformed references or how the one-per-day limit is surfaced, minor gaps for an otherwise complete lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented, including client_tag's full contract. The description adds concrete input examples ('민법 제750조', '형법 제307조 제1항'), but those largely restate the example already in the schema, so no credit above the high-coverage baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (look up a Korean statute article) and describes both the primary corpus path and the law.go.kr canonical-index fallback, so the agent knows exactly what is being retrieved. It never names its obvious sibling lookup_precedent to disambiguate statutes vs precedents, so sibling differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Use is implied by the description ('look up a Korean statute article') and the input examples clarify the shape of a valid query, but there is no explicit statement of when to choose this over verify_citations or lookup_precedent. The '먼저...없으면' text describes internal fallback logic rather than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[KEY REQUIRED · no credits, 60/day] law.go.kr에서 법령명으로 한국 법령을 검색합니다(조문 본문·판례는 검색하지 않습니다). 판례는 lookup_precedent, 조문은 lookup_statute, 아무 텍스트의 인용 검증은 verify_citations 를 쓰십시오. 입력 예: '주택임대차보호법', '근로기준법'. / Search Korean statutes by law name on law.go.kr (it does not search article text or case law). Use lookup_precedent for cases, lookup_statute for articles, verify_citations to check citations in arbitrary text.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query (min 2 chars). Example: '근로기준법'. | |
| limit | No | Max results (1-100, default 10). | |
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. |
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 key constraint (law-name only, not article text or case law) and the rate limit (60/day, no credits, key required). However, it doesn't describe the return format, pagination, or what happens on no results. The disclosed constraints are useful but not fully rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences in Korean and English, front-loaded with the key constraint and rate limit, then routing to siblings. Every sentence earns its place; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 usage context: what it searches, what it excludes, alternatives, examples, and rate limit. The only gap is the return shape, but that's minor for a search tool whose schema is fully documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 three parameters. The description adds example queries and clarifies that client_tag never affects the response and invalid values are ignored, which is useful. But it doesn't add much beyond the schema for q and limit. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('search'), resource ('Korean statutes by law name on law.go.kr'), and explicit exclusions ('does not search article text or case law'). It also names sibling tools for those exclusions, so an agent can distinguish it from lookup_precedent, lookup_statute, and verify_citations without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool vs alternatives: use lookup_precedent for cases, lookup_statute for articles, verify_citations for citation checks. It also gives concrete example queries ('주택임대차보호법', '근로기준법'), which is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[KEY REQUIRED · no credits, 60/day] law.go.kr이 제공하는 법정 서식·별표를 검색합니다 — 예: 특정 법률에 따른 신청서 서식. / Search official Korean statutory forms and appendix tables (별표·서식) served by law.go.kr.
| Name | Required | Description | Default |
|---|---|---|---|
| knd | No | Kind of appendix, **not** a search scope: 1 별표 · 2 서식 · 3 별지 · 4 별도 · 5 부록 (blank = all). 검색범위는 서버가 정합니다. | |
| limit | No | Max results (1-100, default 20). | |
| query | Yes | Form name or statute name. 법령명으로 찾을 때는 **시행규칙·규칙**이 적중률이 높습니다(서식은 대개 거기 있습니다). 서버가 별표서식명 → 해당법령 순으로 두 범위를 모두 시도합니다. / Form or statute name; enforcement rules (시행규칙) usually hold the forms. | |
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers real operational context: an API key is required, calls consume no credits, and the rate limit is 60/day. It also discloses that the server searches both name-scopes (별표서식명 → 법령). What it omits is behavior on empty/failed results and result shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The bracket-prefixed key/credit/rate-limit notice is front-loaded, followed by two tight sentences. The full Korean/English duplication roughly doubles the length, which is defensible for a bilingual service but not maximally economical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-param, no-output-schema, no-annotation tool, the description plus schema covers the essentials: prerequisites, quota, scope behavior, and search semantics. Only the return format and pagination behavior are left unstated, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter docs (knd semantics, query hints, client_tag isolation warning) are unusually rich, so the baseline of 3 applies. The description text itself adds little parameter detail beyond the general search framing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource: 'Search official Korean statutory forms and appendix tables (별표·서식) served by law.go.kr', with a concrete example of a covered use case. It is clearly distinct from statute/precedent lookup siblings, though it never names an alternative tool explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through an example ('특정 법률에 따른 신청서 서식') and the query param hints that enforcement rules (시행규칙) are the best place to find forms. However, there is no explicit when-to-use/when-not statement or routing to sibling tools like lookup_statute for the underlying law text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[KEY REQUIRED · no credits, 20/day] 주어진 질의에 이어질 만한 법률 후속 질문을 생성합니다. / Generate relevant follow-up legal questions for a given query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Current user question (max 500 chars). | |
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose valuable operational traits: an API key is required, it consumes no credits, and it is rate-limited to 20 calls per day. It does not say how many questions are returned or in what language, but the quota and auth disclosures are meaningful beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The response is short and front-loads the most actionable constraint (KEY REQUIRED · no credits, 20/day) before the purpose sentence. The bilingual duplication doubles the text, but it mirrors the schema's own bilingual style and is justified for the audience.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema and no annotations, the description covers auth, cost, quota, and purpose, but never indicates the return shape (e.g., a list of questions, how many, in what language). That is a notable gap given there is no output schema to fall back on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are documented in detail in the schema, including the caveat that client_tag never affects the response. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: generating follow-up legal questions for a given query. This is distinguishable from answering siblings like ask/ask_expert, though it does not name those siblings directly. Clear purpose with no explicit sibling routing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied — the phrase 'for a given query' suggests it is meant to follow a prior query or answer, but there is no explicit when-to-use, when-not-to-use, or statement of which sibling to prefer. Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[KEY REQUIRED · 1 credit] 아무 텍스트에 담긴 한국 법률 인용을 검증합니다 — 다른 LLM이 쓴 답변도 됩니다. 조문과 사건번호를 전부 추출해 검증 자산과 대조하고, 인용별 상태(verified_in_corpus 본문까지 대조 / verified_in_index 정본 색인에서 실재 확인 / absent_in_index 그 법령을 결번 없이 아는데 이 조문이 없음 / not_in_corpus 덮지 못함)를 출처 링크와 함께 돌려줍니다. 1회에 크레딧 1개를 사용합니다. LLM 미호출·결정론. 주의: not_in_corpus는 '이 코퍼스에 없다'는 뜻이지 '지어낸 인용'이라는 증명이 아닙니다 — law.go.kr에서 직접 확인하라는 표시입니다. 인용 실재(L1) 외에 네 축을 더 돌립니다: doctrine(법리 모순 — 조문이 실재해도 적용이 어긋나는 경우), currency(폐지·개명된 법령 인용), precedent_currency(이후 전원합의체가 견해를 변경하며 참조한 판례), support(인용 조문 본문에 그 수치가 실제로 있는가). 각 축은 검사 범위(scope)와 분모(examined·known_count·index_size)를 함께 냅니다 — findings 0 은 '정확하다'가 아니라 '그 축에서 안 잡혔다'는 뜻입니다. 전부 결정론이며 LLM을 부르지 않습니다. / Fact-check the Korean legal citations inside any text — including text another LLM produced. Returns per-citation status (verified_in_corpus = body matched, verified_in_index = existence confirmed in the authoritative index, absent_in_index = the law is indexed gaplessly and this article is not in it, not_in_corpus = not covered) with source links. Costs 1 credit per call. Deterministic, no LLM. IMPORTANT: Beyond citation existence (L1) it runs four more axes: doctrine (misapplied rule even when the provision exists), currency (repealed or renamed statutes), precedent_currency (cases referenced by a later en banc decision that states a change of position), and support (whether the figure claimed actually appears in the cited provision's text). Each axis reports its scope and denominator — findings==0 means 'nothing caught on that axis', not 'correct'. All deterministic, no LLM call. 'not_in_corpus' means the citation is NOT in this corpus — it is a flag to check manually at law.go.kr, not proof that the citation is fabricated.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text containing Korean legal citations (max 20000 chars). | |
| client_tag | No | 선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and handles it well: it discloses deterministic/no-LLM behavior, the 1-credit cost, per-citation statuses, the four additional axes, scope/denominator reporting, and the important caveat that not_in_corpus is not proof of fabrication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and front-loads key operational facts, but the Korean and English sections duplicate nearly all of the same content, making it longer than necessary. A tighter single-language version would earn higher marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description explains what is returned (per-citation statuses, source links, axes, scope/denominators) and how to interpret ambiguous results. For a complex verification tool, this is complete enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents text and client_tag. The tool description adds no parameter-specific detail beyond what the schema provides, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (verify/fact-check), a clear resource (Korean legal citations inside any text), and enumerates the detailed status taxonomy and four extra verification axes. This makes the tool instantly distinguishable from sibling lookup/search tools even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: accepts any text, including text produced by another LLM; specifies what not_in_corpus means and directs manual follow-up at law.go.kr; and clarifies that findings==0 means 'nothing caught,' not 'correct.' It stops short of explicitly naming alternatives or stating when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
chat_leader1 field changedInput schema / properties / idempotency_keyAdded value: +{
+ "description": "선택. 재시도 안전 키(8~64자, 영숫자·_-.). 30초 안에 안 끝나면 'pending'과 키를 돌려줍니다 — 같은 키로 다시 부르면 진행 중이거나 방금 끝난 답을 **새로 과금하지 않고** 받습니다. / Optional retry-safe key. If the chat takes longer than ~30s you get `pending` with a key; call again with the same key to collect the reply without a second charge.",
+ "type": "string"
+}generate_document1 field changedInput schema / properties / idempotency_keyAdded value: +{
+ "description": "선택. 재시도 안전 키(8~64자, 영숫자·_-.). 같은 키로 다시 부르면 **두 번 과금되지 않고** 보관된 문서를 돌려줍니다(24시간). 30초 안에 안 끝나면 'pending'과 키를 돌려줍니다. / Optional retry-safe key. Retrying with the same key is never charged twice and replays the stored document for 24h. Long drafts return `pending` with a key after ~30s.",
+ "type": "string"
+}ask_expert1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"선택. 재시도 안전 키(8~64자, 영숫자·_-.). 같은 키로 다시 부르면 **두 번 과금되지 않고** 보관된 답변을 그대로 돌려줍니다(24시간). 전문가 답변은 2크레딧이라 타임아웃 시 이 키가 특히 중요합니다. / Optional retry-safe key (8-64 chars). Retrying with the same key is never charged twice and replays the stored answer for 24h."New value: +"선택. 재시도 안전 키(8~64자, 영숫자·_-.). 같은 키로 다시 부르면 **두 번 과금되지 않고** 보관된 답변을 그대로 돌려줍니다(24시간). 전문가 답변은 단가가 가장 높아 타임아웃 시 이 키가 특히 중요합니다. / Optional retry-safe key (8-64 chars). Retrying with the same key is never charged twice and replays the stored answer for 24h."find_village_lawyer1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}get_account1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}get_daily_content1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}get_exam_answer1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}get_leaders1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}get_pricing1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}latest_content1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}list_document_types1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}search_legal_forms1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}suggest_questions1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}generate_document1 field changedInput schema / properties / lang / descriptionPrevious value: -"Default ko."New value: +"Default ko. 'en' returns the Korean original (the version to file with Korean courts/police) followed by an English translation for reference."chat_leader1 field changedInput schema / properties / confirm / descriptionPrevious value: -"Spend credits when the free daily allowance is used up. Default false — nothing is ever charged without this. Only set it after a call returned status 'payment_required' telling you the cost."New value: +"Deprecated (2026-09-27): leader chat now costs 1 credit per call with no separate free allowance, so no confirmation step is needed. Accepted and ignored for backward compatibility."ask1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}ask_expert1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}bar_exam_search1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}chat_leader1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}generate_document1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}lookup_precedent1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}lookup_statute1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}search1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}verify_citations1 field changedInput schema / properties / client_tagAdded value: +{
+ "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+ "type": "string"
+}search_legal_forms2 fields changedInput schema / properties / knd / descriptionPrevious value: -"Kind: 1 별표 · 2 서식 · 3 별지 · 4 별도 · 5 부록 (blank = all)."New value: +"Kind of appendix, **not** a search scope: 1 별표 · 2 서식 · 3 별지 · 4 별도 · 5 부록 (blank = all). 검색범위는 서버가 정합니다."Input schema / properties / query / descriptionPrevious value: -"Form or statute name to search."New value: +"Form name or statute name. 법령명으로 찾을 때는 **시행규칙·규칙**이 적중률이 높습니다(서식은 대개 거기 있습니다). 서버가 별표서식명 → 해당법령 순으로 두 범위를 모두 시도합니다. / Form or statute name; enforcement rules (시행규칙) usually hold the forms."chat_leader1 field changedInput schema / properties / historyAdded value: +{
+ "description": "이전 대화. 이것을 안 보내면 서버는 매 호출을 **첫 대화**로 보고 같은 것을 또 되묻습니다 — 리더가 물어본 뒤 답을 줄 때는 그 두 턴을 반드시 함께 넘기세요. 최근 20턴까지 반영됩니다. / Prior turns. Without this the server treats every call as a fresh conversation and asks the same questions again — when you answer a leader's follow-up, send those turns here. Up to 20 recent turns are used.",
+ "items": {
+ "properties": {
+ "content": {
+ "type": "string"
+ },
+ "role": {
+ "enum": [
+ "user",
+ "assistant"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "role",
+ "content"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Korean law: statutes, precedents, ordinances, treaties and citation verification (법제처 API).
Korean accounting standards, audit, tax and legal sources and rulings, with citation checks
Korean statutes, precedents, local business-district stats and public procurement for AI agents.
Korean public procurement law: rule-engine rulings, statutes search, live court precedents
Add one secure layer between your agents and this server.
