Verify Korean legal citations against law.go.kr: precedents, statutes, bar-exam answers.
Scored across 19 tools
Most tools target distinct resources (Q&A, document drafting, statute lookup, precedent lookup, citation verification), but a few pairs overlap: ask/ask_expert are tiered versions, bar_exam_search/get_exam_answer both access the exam corpus, and latest_content/get_daily_content both serve daily posts. The detailed descriptions help disambiguate, but an agent could still misselect between these pairs.
The majority follow a verb_noun pattern (get_account, lookup_statute, verify_citations, generate_document), but there are inconsistencies: bar_exam_search reverses the expected search_bar_exam order, latest_content has no verb, and search is a bare verb without an object. These are readable but break the otherwise consistent convention.
19 tools falls in the 16-25 'heavy' range, and some tools are redundant (ask_expert is a Pro variant of ask, latest_content overlaps with get_daily_content). Still, the server covers many distinct subdomains (Q&A, drafting, research, content, billing), so the count is not extreme but could be trimmed.
The tool surface covers the core lifecycles: Q&A with ask/chat_leader, document generation with generate_document/list_document_types, verification with verify_citations, and lookup with lookup_statute/lookup_precedent. However, there is no full-text keyword search for statutes or precedents (search only handles law names, and precedents require a docket number), which is a notable gap for research workflows.
[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가 아니면 2크레딧을 차감하지 않고 거절합니다 — 그 경우 ask(1크레딧)를 쓰세요. / 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 (1 credit) 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시간). 전문가 답변은 2크레딧이라 타임아웃 시 이 키가 특히 중요합니다. / 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 discloses key behaviors: requires a Pro plan, a balance alone is insufficient, non-Pro callers are not charged, it is slower, and it runs a full verification pipeline. However, the credit cost is internally inconsistent (header says '3 credits' but text says non-Pro not charged '2 credits'), creating ambiguity about actual pricing.
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 constraints (key, credits, Pro-only) and is logically structured. However, it duplicates the same content in Korean and English, making it longer than strictly necessary; each pair of sentences conveys identical info.
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?
The description covers purpose, cost, plan restrictions, refusal behavior, speed, and the alternative, which is substantial for a tool with no annotations and no output schema. The credit ambiguity and lack of any info about response format or potential errors are minor gaps given the otherwise dense context.
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% for all 4 parameters, so the schema already documents them. The tool description adds no parameter-specific meaning beyond the schema, hitting the baseline for 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?
The description states a specific verb and resource: 'runs the full verification pipeline' for 'legal analysis' to produce 'a more detailed, deeply-cited answer.' It explicitly contrasts with `ask` ('Slower than ask'), making the tool's role distinct from its closest sibling.
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 explicit when-to-use (need deeper, verified citations; Pro plan only), when-not-to-use (non-Pro callers are refused), and names the alternative (`ask`, 1 credit). No inference is required to decide between this and `ask`.
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 · charged — see get_pricing] 특정 리더와 1:1로 대화합니다. get_leaders에서 얻은 leader_id(예: 'L01', 'L32', 'CCO')를 넘기세요. 하루 무료 5회를 넘기면 추가 이용에 크레딧이 듭니다 — 그때는 비용을 알려 주는 응답이 오고, confirm: true 로 다시 부를 때만 차감합니다(기본값 false, 확인 없이는 절대 차감하지 않습니다). / Chat 1:1 with a specific legal leader. Provide the leader_id (e.g. 'L01', 'L32', 'CCO') from get_leaders. Past the free daily allowance the call returns the exact cost; credits are spent only when you retry with confirm: true (default false). 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 | 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. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so well: it discloses the key requirement, charging model, free daily allowance, cost notification, and the confirm-gate that prevents charges. It also explains the server's fresh-conversation behavior without history.
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 critical '[KEY REQUIRED · charged]' warning and then packs in essential usage details. The Korean/English duplication makes it longer than necessary, but each section 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 paid, history-sensitive tool with no output schema and no annotations, the description covers the key operational rules: ID source, charging protocol, confirmation flow, and history behavior. It does not describe the normal response shape, but what it does cover is sufficient 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 coverage is 100%, so the baseline is 3, but the description adds real value beyond the schema: it explains why history matters, when confirm should be true, and how client_tag is ignored. These enrich the agent's ability to call parameters correctly.
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 identifies the action ('Chat 1:1 with a specific legal leader') and the resource (leader_id from get_leaders, with examples). It is specific enough to distinguish from generic 'ask' siblings, though it does not explicitly name an alternative tool or draw the boundary.
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 concrete usage context: obtain leader_id from get_leaders, pass history when continuing, and set confirm only after a payment_required response. It lacks explicit 'when not to use' guidance versus siblings like ask_expert, but the intended scenarios are clear.
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] 법무부 '마을변호사'를 지역으로 찾습니다 — 무료 법률상담 연락처입니다. 시·도, 시·군·구, 읍·면 이름으로 검색하세요(예: '강원 강릉', '고성군', '완도'). 이 사업은 변호사가 없는 읍·면을 대상으로 하므로 서울·부산 등 특별시·광역시의 구(區)는 수록되어 있지 않습니다 — 결과가 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: '강릉시'. |
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 well: it discloses that a KEY is required at no credit cost, a 60/day rate limit, that the data is public and no LLM is invoked, that the programme scope excludes metropolitan districts, and that empty results surface a coverage field listing covered provinces. These are exactly the behavioural facts an agent needs before and after the call.
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 key/rate-limit tag and the core constraint bolded mid-paragraph, and it is easy to scan. It is, however, fully duplicated in Korean and English, which roughly doubles the length; the duplication is defensible for a bilingual service but is still redundancy.
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 returns, and it does: an empty result yields a coverage list of covered provinces. Combined with scope exclusions, rate limits, and key requirements, an agent has everything needed to call this correctly and interpret the response.
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 meaning: region may be a province, city/county/district, or township name, multi-token queries like '강원 강릉' work, and the coverage limitation on metropolitan districts directly shapes what values to pass. It does not clarify the limit parameter beyond the schema.
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 precise verb+resource: finding the Ministry of Justice 마을변호사 (village lawyer) assigned to a Korean locality, described as a free legal-consultation contact point. The resource is specific enough that an agent can distinguish it from siblings like lookup_precedent, lookup_statute, or search_legal_forms 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit search granularity (시·도, 시·군·구, 읍·면 names) with concrete examples ('강원 강릉', '고성군', '완도'), and a clear when-NOT: metropolitan-city districts such as Seoul/Busan are not listed. However, it never names or contrasts sibling tools (e.g., lookup_precedent) for users who actually need general legal lookup, so alternatives are not addressed.
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] 사용자의 사실관계로 한국 법률 문서 초안을 작성합니다(고소장·소장·내용증명·답변서·합의서·법률의견서 등). 초안의 모든 조문·판례 인용은 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. | |
| 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. | |
| extra_instructions | No | Optional extra drafting instructions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses fail-closed law.go.kr verification for every citation, quota/credit limits, and key requirement. It does not explain failure modes or output format, but it provides meaningful behavioral context beyond a bare 'generates a document' statement.
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-loaded with the key constraint, then states purpose, verification behavior, and prerequisite. The bilingual repetition adds length but serves the audience; every substantive point 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?
The tool is moderately complex and has no output schema, yet the description covers validation prerequisites, citation verification, document variety, and quota limits. It does not state the return shape or error behavior, but the essential call details are present.
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 five parameters. The description reinforces that doc_type must come from list_document_types and explains verification behavior, but it does not add much new parameter-level meaning beyond the schema.
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 names a specific verb and resource: 'Draft a Korean legal document from the user's facts' and enumerates concrete document types (고소장·소장·내용증명·답변서·합의서·법률의견서). It also points to list_document_types for valid keys, distinguishing it from legal research or Q&A siblings.
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 clearly states a precondition: use list_document_types first to obtain a valid doc_type. It also communicates operational constraints (key required, no credits, 20/day limit). It does not explicitly contrast with alternatives like ask, but the document-drafting context makes the intended use apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and largely does: it discloses the auth prerequisite ('[KEY REQUIRED]'), that the call is a read-only status check, and what comes back. It leaves one relevant behavior unspecified — whether this call itself consumes credits or is free — which matters for a credit-checking 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?
Front-loaded with the key requirement and the core purpose, with the call-to-action last. The Korean and English versions are parallel duplicates, which roughly doubles length, though the i18n duplication is defensible and each sentence still carries content.
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 zero-param, no-output-schema tool with no annotations, the description supplies the prerequisite, the return fields, and the decision context for calling it. The only material omission is whether the call is itself metered.
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?
The tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter discussion and instead covers return content, which is the right use of space.
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 ('account status for the API key in use') and enumerates the payload — remaining credits, plan, top-up link — which is more than the name implies. It does not name a sibling (e.g. get_pricing) as the alternative for top-up, so it stops short of full disambiguation.
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 condition: call before a long run of metered queries to avoid an exhausted balance mid-task. That is actionable when-to-use guidance. It does not state when not to call, nor does it name an alternative tool for pricing/purchase.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does notable work: 'KEY REQUIRED' (auth requirement), 'no credits', '60/day' (rate limit) are all disclosed up front. It also describes the return payload per stream. It stops short of stating what happens on an invalid date or unpublished stream.
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 key/rate-limit banner, then purpose, then streams, then the date rule. Every sentence earns its place. Slightly penalized because the full Korean and English restatement 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, and the description compensates by describing the record contents per stream, so an agent knows what it will receive. The omission is failure-mode behavior (invalid date, empty stream) and any pointer to the latest_content alternative.
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 a 3 is the baseline, but the description goes beyond the enum: it explains what each stream value actually yields (verified provisions and FAQ for daily, live-confirmed references for tech, source domains for news, attached verified records for precedent). That meaningfully enriches the enum semantics.
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 as a full record) and enumerates all six streams with what each contains (verified provisions, source domains, attached precedent records). The only gap is sibling differentiation: latest_content and search are never named, so an agent could confuse the omit-date behavior with latest_content.
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 one concrete usage rule — pass a date, or omit it for the latest post in that stream — plus auth/rate-limit context. However it never says when to prefer this over latest_content or search, leaving the main selection ambiguity unaddressed.
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 | 공법 · 민사법 · 형사법 (선택과목명도 가능). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so: API key required, rate limit (3/day free, then 1 credit each), one item per call, no bulk export, and a provenance guarantee that every citation passed law.go.kr verification. These are exactly the operational constraints an agent cannot infer from schema or annotations.
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 two things an agent must know first (key + cost), then usage, then guarantees. The bilingual Korean/English pairing doubles the length with translated repetition, which is somewhat redundant but each section 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?
No output schema exists, and the description compensates by enumerating the returned fields per question type, including citation provenance. For a four-parameter retrieval tool with cost implications, nothing material is left unexplained.
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, but the description adds genuine meaning by mapping parameter combinations to output shapes (no → MCQ payload; format → essay/record payload) beyond the schema's field-level docs. Enum values are also reinforced contextually.
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 bar-exam question with its full gold answer') and enumerates exactly what comes back for each format (prompt, 5 choices, ministry answer, commentary, notes, cited statutes/precedents). The scope statement 'one item per call — not available for bulk export' cleanly separates it from bulk/search siblings like bar_exam_search.
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 invocation recipes per format: '선택형: round+subject+no' and '사례형·기록형: round+subject+format', so the agent knows which parameters to combine for each question type. It lacks an explicit 'use bar_exam_search to discover question numbers first' pointer, so it is clear on context but silent on the sibling alternative.
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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full disclosure burden and does add real operational context: an API key is required, calls consume no credits, and throughput is capped at 60/day. It does not mention ordering, pagination, or caching behavior for what is presumably a static directory, which are the remaining gaps.
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 rate-limit and auth constraint is front-loaded in a bracketed tag, followed by a single tight purpose sentence, so the most decision-relevant fact appears first. The Korean and English lines are verbatim duplicates, which is redundant but keeps the definition short overall.
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 parameterless list tool with no annotations and no output schema, the description supplies what is needed: who is returned, which fields come back, and the key/rate-limit constraints. Only secondary details like ordering or result size handling are absent.
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?
The tool takes zero parameters, so there is nothing for the description to clarify at the argument level; the baseline for a parameterless tool applies. The description instead spends its words on output shape, which is reasonable.
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 concrete verb and resource ('List all 60+ specialist legal leaders') and names the fields returned (names and specialties), which is enough to distinguish it from sibling lookups such as find_village_lawyer or chat_leader. It stops short of explicitly contrasting itself with those siblings, so it is clear but not fully disambiguated.
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 bracketed prefix tells the agent it needs a key and that calls are limited to 60/day, but nothing says when this directory listing should be chosen over chat_leader, ask_expert, or find_village_lawyer. No prerequisites, exclusions, or alternative-selection logic is offered.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and delivers the two most important facts: it is callable without authentication and it is the recommended first call for new agents, plus it lists what the response contains including checkout links. It stops short of 5 because nothing is said about response format, size, rate limits, or whether the pricing data is cached/live.
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 key constraint ('[NO KEY NEEDED]') and each sentence earns its place, but the entire content is duplicated in Korean and English, roughly doubling the token footprint with no added information for a single-language reader.
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 describe return values — and it does, enumerating the sign-up flow, key issuance, allowances, prices, and checkout links. Combined with the no-auth disclosure, an agent has enough to decide to call it, though the shape/format of the returned data remains unspecified.
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% with a single optional enum parameter (lang: ko/en/''), so the schema already documents it. The description is written bilingually, which implicitly signals the language option, but it never explains what lang does or its default. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('how to get access and what it costs') and enumerates exactly what comes back: sign-up flow, API-key issuance location, free allowance, credit-pack prices in KRW/USD, credit purchasing power, and checkout links. No sibling (ask, get_account, search, etc.) covers pricing or onboarding, so the scope is unambiguous.
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: 'an AI agent arriving for the first time should call this to learn how to obtain access.' That is clear when-to-use guidance, but no when-not-to-use or alternative tool is named, so it stops short of full 5-level routing.
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. |
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 meaningful behavior: an API key is required, calls consume no credits, there is a 60/day rate limit, and every post has passed a publishing gate with citations verified against law.go.kr. Return format is not described, but for a read-only listing endpoint this is solid beyond-schema disclosure.
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 (key required, no credits, rate limit) are front-loaded and the stream list is compact. The full Korean/English duplication roughly doubles the text without adding new information, which is the only real structural cost.
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, no-output-schema tool the description covers auth, cost, rate limit, stream semantics and content guarantees, which is close to sufficient. It omits any indication of the response shape and, more importantly, gives no basis for choosing it over get_daily_content, leaving a real routing 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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the raw enum by naming what each stream contains in Korean (오늘의 법률상식, 전략 칼럼, 기술 칼럼, 리걸테크 뉴스, 수험 판례 강의노트, 오늘의 판례), which the enum values alone do 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?
The description gives a specific verb+resource ('Get Lawmadi's latest daily legal content') and enumerates the six streams (daily, strategy, tech, news, bar, precedent), so the agent knows exactly what is returned. However, it never distinguishes itself from the sibling get_daily_content, which by name looks like an overlapping tool, so it falls 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?
There is no statement of when to use this tool versus alternatives. The 'KEY REQUIRED · no credits, 60/day' note is operational context, not selection guidance, and the closest sibling, get_daily_content, is never mentioned or contrasted.
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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose useful operational traits: a key is required, calls cost no credits, and there is a 60/day cap. It does not, however, describe the return shape beyond 'types with Korean and English labels' or note any caching/pagination behavior, leaving meaningful gaps for a no-annotation 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 bracketed access/rate note is front-loaded, followed by a bilingual one-sentence statement of purpose with examples. It is compact and well-ordered, though the duplicated Korean/English phrasing slightly inflates length for a bilingual 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 zero-parameter enumeration tool with no output schema, the description tells an agent what it returns (draftable legal document types with bilingual labels) and the access constraints. Only a note tying it to generate_document as the follow-up would make it fully complete.
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?
The tool takes zero parameters, so the baseline of 4 applies. There are no parameter semantics to clarify, and the description correctly signals a no-input listing operation.
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') and enumerates concrete examples (고소장·소장·내용증명·답변서 etc.), making the tool's output scope unambiguous. It does not, however, explicitly contrast itself with the sibling generate_document, so an agent must infer that this lists types rather than producing 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?
The description implies usage (a discovery step to learn which document types can be drafted) but never states it directly, nor does it name generate_document as the natural follow-up. The rate-limit and credit notes give operational context but no when/when-not guidance.
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,625건, 전부 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,625 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. |
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 thoroughly: it discloses deterministic behavior, no hallucination risk, the meaning of the source field values (corpus vs authoritative_index), fallback order, preview-depth limitations, and rate-limit hint. This goes well beyond a generic tool description.
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 key constraint and core purpose, then organized into useful sections with concrete examples. There is some redundancy from Korean/English repetition, but each block contributes distinct operational detail such as source-field semantics, preview depth, and withheld fields.
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 no output schema, the description enumerates the return fields, explains the source field, gives format examples, and specifies access-level differences. An agent has sufficient information to invoke the tool and interpret the response 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 already covers both parameters at 100%, so the baseline is 3. The description adds practical value by giving multiple input examples and warning that client_tag must not be embedded in the query text, which meaningfully enhances correct usage.
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?
Description states the specific action: 'Look up a Korean court case by docket number' and clearly describes the verified corpus plus fallback to law.go.kr's index. It also distinguishes this tool from legal-statute lookup by focusing on precedents/case law.
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?
Provides clear invocation context: callable without an API key at preview depth, with an explicit daily rate hint and what a key unlocks. It does not explicitly name alternatives like search or verify_citations, but the docket-number targeting and deterministic nature imply when it should be used.
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] 한국 법령 조문을 조회합니다. 먼저 검증 자산(31,548개 조문, 본문 포함)을 보고, 없으면 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,548 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, the description carries the full disclosure burden and does so thoroughly. It states that the tool is deterministic, does not fabricate body text, can return absent=true when the statute is known to be missing, falls back law.go.kr link-only results from the canonical index, and explains preview-depth limits and API-key behavior.
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 long but well structured with Korean/English sections and front-loaded key constraints such as preview depth and no-API-key access. Each section adds useful behavioral information, though the bilingual repetition makes it slightly less concise than it could be.
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 correctly explains the return behavior: article title, body text, link, absent=true, preview truncation at 200 characters, and key-based full access. Combined with parameter examples and operational limits, the agent has enough context to call 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?
Since schema description coverage is 100%, the schema already documents both parameters, so the baseline is 3. The tool description adds example reference formats like '형법 제307조 제1항', but it does not materially add semantic meaning beyond what the input schema already provides.
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 names a specific verb and resource: looking up Korean statute articles in a verified statute corpus and returning title, body text, and a law.go.kr link. It also distinguishes itself from a generic legal search or precedent lookup by emphasizing 'statute article' and 'deterministic — no LLM'.
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 case is clear: use this tool to look up Korean statute articles, with optional no-key preview access and key-based full-body access. It does not explicitly name alternative sibling tools or state when not to use it, but the context is specific enough to route an agent correctly.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals a required API key, a 60/day rate limit, and server-side search behavior. This is meaningful operational context, though it does not describe the response shape or failure behavior.
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, front-loads the critical authentication/rate-limit warning, and states the tool's purpose in two languages without filler. Every clause 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 small search tool, the description covers purpose, auth requirements, rate limits, and query strategy. It does not describe the return format, but the absence of an output schema is partially mitigated by the tool's straightforward search nature and complete parameter documentation.
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 parameters thoroughly. The description itself adds no parameter-level detail beyond what is in the schema; the query tip about enforcement rules is already echoed in the query parameter's description. 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?
The description states a specific verb and resource: 'Search official Korean statutory forms and appendix tables (별표·서식) served by law.go.kr.' This clearly differentiates it from sibling tools like lookup_statute or search by narrowing to legal forms and appendix tables.
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 useful query guidance, noting that enforcement rules (시행규칙) are more likely to contain forms and explaining the server's two-range search behavior. However, it does not explicitly say when to prefer this tool over siblings like lookup_statute or search, so usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses auth requirements (KEY REQUIRED) and a rate limit (20/day), which a bare schema would not convey. It says nothing about output format, whether questions are cached, or how many are returned, leaving real gaps for a no-annotation 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 short and front-loads the critical operational metadata before the purpose. The bilingual Korean/English repetition is redundant but conventional for this toolset and does not obscure the message.
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 one-parameter generator with full schema coverage and no output schema, the description covers purpose and operational constraints adequately. Missing output shape is acceptable here since no output schema exists, and only the lack of sibling routing keeps it from a 5.
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 a single parameter with 100% schema description coverage (max 500 chars), so the schema already documents it fully. The description adds no syntactic or format guidance beyond restating that it takes a query, 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: generates follow-up legal questions for a given query. This is clear and distinguishable from generic responders like ask or search. However, it does not explicitly differentiate itself from siblings such as chat_leader or generate_document, which could overlap in 'generate content' territory.
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 bracketed metadata gives operational constraints (KEY REQUIRED, free, 20/day), but the description never says when to use this rather than ask, ask_expert, or chat_leader. No alternatives or exclusions are named, so usage must be inferred from the name alone.
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.
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"
+}chat_leader1 field changedInput schema / properties / confirmAdded value: +{
+ "description": "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.",
+ "type": "boolean"
+}Korean public procurement law: rule-engine rulings, statutes search, live court precedents
Korean public procurement law: rule-engine rulings, statutes search, live court precedents
Verifies legal citations vs primary sources: existence, quote match, proposition support.
Curated Korean AEC expertise for AI agents: KDS·KCS·KS, building law, practice, and the reasoning.
Add one secure layer between your agents and this server.
