Verified Korean facts: law changes by date, Bank of Korea figures, fact-check requests.
Scored across 12 tools
Most tools cleanly separate search vs. get and target distinct resources such as articles, entities, facts, changes, and requests. The aggregate lookup overlaps with search_entities and search_facts, and what_changes can slightly blur against search_facts for law-related queries, but descriptions give usable guidance.
Names are consistently snake_case and mostly follow a verb_noun pattern: get_*, search_*, list_categories, request_check. The outliers lookup and what_changes break the pattern, but the set remains readable and predictable.
Twelve tools is well within a sensible range for a fact-verification desk, and each tool maps to a distinct search, retrieval, or request operation. The convenience lookup is the only mild redundancy.
The surface covers the core read/verify lifecycle: search and retrieve entities, facts, articles, and law changes; submit and retrieve verification requests; list categories. Minor gaps include no request listing or broader request-management operations beyond retrieval by id, but agents can work around this using returned ids.
기사 전문과 문장별 판정을 줍니다. 각 판정의 fact_status.is_current가 false면 그 문장은 이후 바뀐 사실이므로 현재 사실로 인용하지 마세요.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | 기사 slug. search_articles 결과의 slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the semantic caveat that a sentence whose fact_status.is_current is false represents a superseded fact and must not be cited as current. That is real behavioral context beyond the structured fields, though it does not cover pagination or output 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?
Two sentences, no filler: the first states what is returned and the second states the critical interpretation rule. Purpose is front-loaded and the caveat follows immediately.
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 carries the burden of describing the return value, and it does so at a useful level (full text plus per-sentence verdicts, with the is_current flag explained). The internal structure of a verdict is not detailed, but the agent gets enough to call and interpret 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% for the single slug parameter, so the schema already documents it fully. The description adds no syntax, format, or sourcing detail about slug beyond what the schema provides, making the baseline 3 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 concrete verb and resource: it returns the article's full text plus per-sentence verdicts (판정). This clearly separates it from search_articles, which only finds articles, but the description never names a sibling explicitly, so differentiation is inferred rather than stated.
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 warns how to interpret the returned verdicts, but gives no guidance on when to call this tool versus search_articles, get_fact, or get_entity. The workflow (find a slug via search, then fetch the full text) is only implied by the schema's mention of 'search_articles 결과의 slug', not by the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
what_changes 결과의 id(chg-…)로 변경 카드 하나를 받습니다: 개정이유 전문, 바뀌는 문구 전체, 시행일 조항, 이날 시행되는 조문, 인용 한 줄(cite). EN: Full verbatim change card by id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by enumerating what the card actually contains (verbatim revision reason, full changed text, effective-date clauses, cited line), which is meaningful for a tool with no output 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?
Front-loaded with the core action and id source, then a compact enumeration of returned fields. The trailing EN line is a short translation that aids a bilingual catalog, though it is partly redundant with the Korean sentence.
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 usefully describes the card's contents, and the annotations cover the read-only/idempotent behavior. Nothing critical to correct invocation is missing, though a note on behavior for an unknown or expired id is 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?
Schema coverage is 0% and the single 'id' parameter carries a strict pattern (^chg-\d{6}-\d{8}$), but the description compensates by stating the id format prefix (chg-…) and its provenance from what_changes output. That is the key semantic an agent needs to supply a valid value.
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 ('변경 카드 하나를 받습니다' / 'Full verbatim change card by id') and enumerates the returned content: 개정이유 전문, 바뀌는 문구 전체, 시행일 조항, 이날 시행되는 조문, cite. This clearly separates it from siblings like get_article, get_fact, and get_entity, which retrieve different resource types.
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 routes the agent: the id comes from what_changes results ('what_changes 결과의 id(chg-…)로'), so the discovery-then-fetch workflow is unambiguous. There is no explicit when-not or alternative for single-card retrieval, but the sourcing instruction is clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
대상 하나의 속성(근거 출처 포함), 현재 사실, 연결된 대상을 줍니다. 법령이면 상위법·하위법(시행령·시행규칙)·소관부처, 기관이면 소관 법령 목록입니다. 연결은 원자료(법제처 법령 체계도·법령 목록)에서 확인된 것만 있습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 대상 id. 예: law-011357, org-1790365, org-bok | |
| relation_limit | No | 돌려줄 연결 수 상한 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: connections are limited to those verified in the source material (법제처 법령 체계도/목록), and returned attributes carry source citations. It omits any note on how relation_limit paginates or what happens when the cap is hit.
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?
Three sentences, front-loaded with the return payload, then the entity-type breakdown, then a provenance caveat. Each earns its place, though the caveat sentence is somewhat tangential to selecting the tool.
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 present, the description correctly carries the return-value burden, naming attributes, facts, and connections and explaining relation semantics per entity type. It stops short of describing relation_limit behavior or total-result shaping, a modest gap for a read 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%: id format examples (law-011357, org-1790365, org-bok) and relation_limit's default/max/min are all documented in the schema. The description adds no parameter-level detail beyond that, 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?
States a specific verb+resource: retrieve a single entity with its attributes (including source citations), current facts, and connections. The type-specific detail (laws → parent/subordinate statutes and ministry; organizations → managed statutes) pins down the domain. It does not, however, contrast itself against sibling search_entities or lookup, so an agent must infer the id-first nature from 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?
The description is entirely about what is returned; it never states when to reach for this tool versus search_entities, lookup, or get_fact. There is no mention of prerequisites (needing a known id) or exclusions, leaving routing to 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.
사실 하나의 현재 버전과 이력을 줍니다. as_of(YYYY-MM-DD)를 주면 그날 참이던 버전을 줍니다. 버전마다 valid_from, valid_until, superseded_by, 근거(원자료 값)가 있습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 사실 id. 예: kr-bok-base-rate. search_facts 결과의 id | |
| as_of | No | 이 날짜에 참이던 버전을 원할 때(YYYY-MM-DD) | |
| history_limit | No | 함께 돌려줄 과거 버전 수 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine domain context beyond annotations: the versioning model (valid_from, valid_until, superseded_by) and that each version carries provenance (source values), which an agent cannot get from the 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?
Three short, front-loaded sentences: purpose first, then the as_of behavior, then the shape of each version. Every sentence carries information and none is wasted.
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 takes on the job of describing the return shape, and it does so (versions with validity windows, superseded_by, and source values). Combined with annotations covering safety and 100% parameter coverage, it is nearly complete; only the pagination behavior of history_limit is left entirely to the schema.
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 all three parameters are already documented in the schema, including as_of's date pattern and history_limit's default/range. The description's explanation of as_of duplicates the schema's temporal semantics without adding syntax or edge-case guidance, 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 and resource: it returns the current version plus history of a single fact, and explains the temporal scoping via as_of. It is clear what the tool does, but it never names or contrasts a sibling such as search_facts, so 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?
Usage is only implied: a single-fact lookup with an optional time-travel parameter, distinct from the sibling search_facts. There is no explicit statement of when to choose this tool over search_facts or the other get_* siblings, and no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_check 가 돌려준 id(rq_…)로 요청 상태와 결과를 다시 봅니다. EN: Get a verification request's status/result by id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description contributes the workflow linkage (the id originates from request_check) but adds no behavioral detail such as result lifetime, polling semantics, or what states a request can be in.
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 short sentences, front-loaded with the purpose and then the English gloss; nothing is wasted. The bilingual restatement is slightly redundant but keeps both audiences served without bloating the text.
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-parameter, read-only lookup with no output schema, the description covers what is fetched (status and result) and where the id comes from. It does not describe the shape of the returned status/result, but annotations and simplicity keep the remaining gap small.
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 0%, so the description must carry the param meaning, and it does add the key fact that id is the value returned by request_check. That is genuinely useful provenance beyond the schema's bare pattern '^rq_[A-Za-z0-9_-]{8}$', though it gives no further format or casing guidance.
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 ('요청 상태와 결과를 다시 봅니다' / get a verification request's status/result) and ties it to the id produced by request_check, which partially separates it from the sibling request_check. It stops short of stating what request_check itself does, so the boundary between the two is only implied.
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 implies the calling context ('request_check 가 돌려준 id로' – use the id returned by request_check), which is real usage guidance. However, there is no explicit when-to-use vs when-not, and no statement of when to re-check versus calling request_check again.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
다루는 분야, 분야별 건수, 다루지 않는 분야, 판정 어휘의 뜻을 줍니다.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, closedWorldHint-equivalent (openWorldHint=false), and destructiveHint=false, so the safety profile is fully covered structurally. The description usefully adds that the result includes negative coverage (categories NOT handled) and the semantics of judgment vocabulary, but says nothing about response shape or ordering.
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?
A single sentence that front-loads the most important content (the handled categories) before the supplementary items. No filler and no 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?
With no output schema, the description carries the burden of describing returns, and it does list the four payload elements reasonably well. It could still be tighter on how the categories/counts are structured, but for a zero-parameter reference tool it is largely sufficient.
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 per the rubric the baseline is 4. Nothing is left to clarify on the input side.
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 Korean description names the resource and enumerates the payload concretely: covered categories, per-category counts, uncovered categories, and the meaning of judgment vocabulary. An agent can tell this is a metadata/vocabulary reference tool distinct from the get_*/search_* siblings, though no sibling is named 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?
There is no statement of when to call this versus the closest sibling, lookup, nor any prerequisite or exclusion. The agent must infer that this is an orientation step to be used before interpreting category or judgment terms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
질문에 나온 대상(법령·기관)과 지금 참인 사실을 한 번에 찾습니다. 처음엔 이 도구를 쓰세요. 띄어쓰기·가운뎃점은 무시합니다. 사실마다 freshness(낡음 여부)와 cite(답변에 붙일 인용 한 줄)가 있습니다. EN: One-call lookup of Korean entities (laws, agencies) and current verified facts (economic indicators, law effective dates). Each fact has freshness and a ready-to-paste citation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | 예: 기준금리, 원달러 환율, 개인정보보호법, 국토교통부 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, yet the description still adds behavior the annotations cannot: matching ignores whitespace and middle dots, and each returned fact carries freshness and a ready-to-paste citation. That normalization rule and return-shape context are genuinely useful beyond structured fields.
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 purpose, then the 'use first' routing cue, normalization note, and return-value note in a tight sequence. The Korean and English blocks are somewhat redundant but serve cross-lingual agents rather than being pure 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?
There is no output schema, so the description correctly compensates by describing the freshness and cite fields that come back per fact, and annotations carry the safety profile. It is nearly complete, missing only how the `limit` behaves and what an empty/no-match result looks like.
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?
With only 50% schema coverage, the description should compensate, and it partly does: it explains that the query targets entities named in a question and that spacing/middle-dot punctuation is normalized, which clarifies the query param. However, the `limit` parameter is undocumented in both the schema and the description, leaving a real gap.
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: a one-call lookup of Korean entities (laws, agencies) and current verified facts (economic indicators, effective dates), narrowing the domain explicitly. It implicitly contrasts with the granular siblings (get_entity, get_fact, search_entities, search_facts) by declaring itself the one-call combined entry point, but it does not name any sibling outright.
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 this tool first) gives explicit, actionable when-to-use guidance for an entry-point tool. It stops short of naming when NOT to use it or pointing to the specialized getters/search tools as alternatives for narrow lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
한국에 관한 사실 문장 하나의 확인을 Æfact에 요청합니다. 법령 시행일·한국은행 기준금리·월별 소비자물가 상승률·문장 안 증감률·비율·합계는 바로 원자료로 판정해 공개 결과 주소(url)와 인용 한 줄(cite)을 돌려줍니다. 그 밖의 문장은 접수(status=queued)되어 수요로 집계됩니다. 결과는 공개됩니다(개인정보·정치·수사·재판·의료·연예 사생활 문장은 받지 않음). 같은 문장은 같은 결과를 돌려줍니다. EN: Submit a Korean factual claim for verification. Decidable claims (law effective dates, BOK base rate, monthly CPI, in-sentence arithmetic) are judged immediately against primary data and published at a public URL.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | 확인할 문장 하나(원문 그대로). 예: 근로기준법 개정안은 12월 8일부터 시행된다 / 9월 소비자물가 상승률은 2.9%다 | |
| context | No | 선택: 맥락(누가·언제 한 말인지 등) | |
| source_url | No | 선택: 문장이 나온 주소 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: it discloses the write side effect (claims are accepted with status=queued and aggregated as demand), the idempotency behavior ('같은 문장은 같은 결과'), the return payload (public url + one-line cite), and privacy restrictions. This is well beyond what readOnlyHint=false/idempotentHint=true already convey.
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 purpose and the decision rule, and every sentence carries information. The bilingual Korean/English duplication adds length but serves a legitimate audience purpose rather than pure 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?
With no output schema, the description fully carries the return-value burden (public url, cite, status=queued) and also covers exclusions, idempotency, and the immediate-vs-queued branching. An agent has everything needed to call and interpret it.
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 all three parameters are documented with examples in the schema itself. The description reinforces the claim types but adds no syntax or format detail beyond what the schema already provides, 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?
States a specific verb+resource: submitting a single Korean factual claim for verification to Æfact, and enumerates the decidable claim types (law effective dates, BOK base rate, monthly CPI, in-sentence arithmetic). It does not explicitly distinguish itself from retrieval siblings like get_fact or get_request, 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?
Gives clear when-to-use context (decidable claims are judged immediately; others are queued) plus an explicit when-not exclusion list (personal info, politics, investigation, trial, medical, celebrity private life). It does not name an alternative sibling for non-submittable cases, so no explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
기사를 찾습니다. 기사는 사실의 값이 바뀐 시점의 기록입니다. 지금 값이 필요하면 search_facts를 쓰세요.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | 찾을 말. 비우면 최신순 전체. | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds genuinely non-obvious context beyond the annotations: articles are point-in-time snapshots tied to fact changes, which shapes how results should be interpreted. It omits pagination/limit and return-shape behavior, keeping it below a 5.
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?
Three short sentences, front-loaded with the action, then the resource definition, then the disambiguation hint. Zero waste and no repetition of structured 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?
For a read-only, no-output-schema search tool the core semantics and the sibling routing are covered, but the description leaves the 'limit' cap and the 'category' enum values unexplained, and says nothing about result ordering or shape. Adequate but with clear gaps given only 33% schema coverage.
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 only 33% (only 'query' carries a description noting that empty means all-in-latest-order). The description says nothing about any of the three parameters, leaving 'limit' and the 'category' enum undocumented in both places. With coverage below 50%, the description was expected to compensate and does not.
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 ('기사를 찾습니다' – finds articles) and then defines the resource conceptually as 'a record of when a fact's value changed.' It explicitly distinguishes itself from the sibling search_facts, so an agent can route between the two 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 an explicit alternative with a selecting condition: 'if you need the current value, use search_facts.' This tells the agent when NOT to use search_articles, but it never states positively when this tool is the right choice (e.g., 'use when you need historical snapshots').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
법령·기관 같은 대상을 이름으로 찾습니다. 현행 법령 전체와 소관부처, 한국은행이 있습니다. 결과의 id로 get_entity를 부르면 그 대상의 현재 사실과 연결(상위법·하위법·소관부처)을 받습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | law(법령) 또는 org(기관) | |
| limit | No | ||
| query | No | 대상 이름이나 약칭. 공백으로 나눈 낱말이 모두 들어간 것만 돌려줍니다. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, not destructive, closed-world), so the bar is lower. The description adds genuinely useful scope information — only 현행 (current) laws are indexed, plus the specific org coverage — and explains the id-to-get_entity chaining path. It does not describe result shape or pagination, but adds real context beyond 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?
Three short sentences: purpose, scope, and next step. Front-loaded with the action, no filler, every sentence 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, yet the description covers the essentials an agent needs — what is searchable and that results carry an id used by get_entity. It stops short of describing the return payload or the default/maximum result count, which for a search tool 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 coverage is 67%: query semantics (space-separated terms are AND-ed) and the type enum are documented in the schema. The description adds only a general 'search by name' framing and says nothing about the type or limit parameters, so it does not compensate for the coverage gap. 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?
States a specific verb+resource (이름으로 대상 검색) and enumerates the searchable scope (현행 법령, 소관부처, 한국은행). It also distinguishes itself from the sibling get_entity by casting that tool as the follow-up detail lookup rather than a competing 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?
Clearly tells the agent when to reach for this tool (finding an entity by name) and what to do with the result (pass id to get_entity). There is no explicit when-not condition or contrast with the sibling search_articles/search_facts, but the workflow routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
지금 참인 사실(상태)을 찾습니다. 기준금리·환율·소비자물가지수 같은 경제지표, 시행 예정 법령, 현행 법령 버전(법령마다 1건)이 있습니다. 결과마다 현재 값, 언제부터 참인지(valid_from), 문장, id가 있습니다. 자세한 이력은 get_fact로 보세요.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | 찾을 말. 공백으로 나눈 낱말이 모두 들어간 사실만 돌려줍니다. 비우면 전체. | |
| category | No | economy(경제지표), law(제도·법령), companies(기업·공시) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-open-world, so the safety profile is covered. The description adds value beyond that with a 'one entry per law' deduplication guarantee and the exact per-result fields (current value, valid_from, sentence, id) — important since there is no output schema. It omits pagination/limit behavior and result ordering.
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?
Four short sentences, front-loaded: what it finds, then the covered domains, then the return shape, then the alternative. Each sentence carries information, though the enumerated domain list is slightly verbose for a single-sentence idea.
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 correctly compensates by naming the returned fields and the valid_from semantics, and it covers scope plus the get_fact escape hatch. It stops short of describing result limits/pagination, which matters for a search tool defaulting to 20 (max 50).
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 67% (query and category documented, limit not). The description adds no parameter-level detail beyond the schema — it never explains limit, result ordering, or how query tokens combine. With mid-range coverage, the schema does most of the work and the description neither compensates nor regresses.
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 ('지금 참인 사실(상태)을 찾습니다') and then enumerates the actual domains it covers (economic indicators, laws to be enforced, current law versions, one entry per law). This lets an agent distinguish it from siblings like search_entities or search_articles 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?
Explicitly routes the agent: '자세한 이력은 get_fact로 보세요' names the alternative and the condition that selects it. However, it gives no guidance on when to prefer this over other search_* siblings (search_entities, search_articles) or how category/query should be chosen to narrow results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
언제부터 무엇이 바뀌나. 기간(from~to)·분야·검색어로 시행되는(또는 막 시행된) 한국 법령 변경을 찾습니다. 결과마다 시행일, 법령명, 바뀌는 문구, 개정이유 첫 문장(법제처 원문 그대로)이 있습니다. 자세한 원문은 get_change. EN: What Korean laws/regulations change between dates (effective dates from the Ministry of Government Legislation), with verbatim reasons and changed wording.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | 끝일 YYYY-MM-DD (기본: 30일 뒤) | |
| from | No | 시작일 YYYY-MM-DD (기본: 오늘) | |
| limit | No | ||
| query | No | 예: 전세, 근로자, 건강보험, 육아휴직 | |
| topic | No | 분야(일·노동, 복지·건강, 세금·금융·경제, 주거·교통, 교육·가족, 안전·행정·사법, 환경·에너지, 농어업, 문화·관광, 과학·디지털, 국방·외교·보훈) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely useful behavioral context the annotations do not: each result carries the effective date, statute name, changed wording, and the verbatim first sentence of the amendment reason from the Ministry of Government Legislation's original text.
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 core question ('언제부터 무엇이 바뀌나') followed by scope, result contents, and the sibling pointer. The Korean/English duplication adds length but serves non-Korean agents; nearly every sentence 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?
With no output schema, the description compensates by enumerating the returned fields (effective date, statute name, changed wording, verbatim amendment reason). An agent knows what it will get and where to go for full text; only pagination/limit behavior is left unstated.
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 80%, so most parameters are already documented in the schema. The description restates the filter triad (period from~to, topic, query) but adds no syntax or default detail beyond what the schema provides, and does not mention limit at all — 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+resource: finding Korean legal/regulatory changes effective within a date range, scoped by topic and keyword. It also names the sibling that returns the full text (get_change), so an agent can distinguish it from the other retrieval tools 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?
The description frames usage well ('기간(from~to)·분야·검색어로 시행되는(또는 막 시행된) 한국 법령 변경을 찾습니다') and routes to get_change for full text. It lacks explicit when-not conditions (e.g. for historical amendments outside effective-date windows), so it stops 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_articleget_changeget_entityget_factget_requestlist_categorieslookuprequest_checksearch_articlessearch_entitiessearch_factswhat_changesKorean law: statutes, precedents, ordinances, treaties and citation verification (법제처 API).
Korean fact-verification tools for AI agents: business registration, address, DART, apt prices, laws
Korean accounting standards, audit, tax and legal sources and rulings, with citation checks
Korean Assembly bills tracked hourly in English, plus Korean Acts and decrees article by article.
Add one secure layer between your agents and this server.