Korean Assembly bills tracked hourly in English, plus Korean Acts and decrees article by article.
Scored across 7 tools
Each tool targets a clearly distinct resource and action: bills are covered by search_bills and get_bill, while laws are covered by list_laws, search_law_articles, get_law_overview, and get_law_article. The descriptions explicitly cross-reference each other, such as telling users to use get_law_article for full text after search_law_articles or get_law_overview.
Most names follow a predictable verb_noun pattern: get_bill, list_laws, search_bills, search_law_articles, get_law_overview, and get_law_article. The only notable deviation is latest_briefs, which uses a noun phrase rather than a verb, but it remains clear and readable.
Seven tools is well within the appropriate range for a focused legal-research server. Each tool has a clear role—searching, listing, retrieving overviews, retrieving article text, and surfacing briefs—without redundant operations.
The surface covers the core workflows: finding laws, searching articles, reading article text, exploring law structure, searching bills, getting bill facts, and reading briefs. Minor gaps remain, such as no direct list_bills operation and no full bill text retrieval, but the current tools are sufficient for the stated purpose.
Facts about one National Assembly bill by its bill number: English title, current stage and date, filing date, effective dates when promulgated, a one-line summary of what the bill proposed as filed, and links. committee_alternative = a replacement bill drafted by a committee, whose filing date can be later than its committee or judiciary dates.
| Name | Required | Description | Default |
|---|---|---|---|
| bill_no | Yes | Seven-digit National Assembly bill number, e.g. "2216797". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description goes beyond them by disclosing the shape of the payload (title, stage and date, filing/effective dates, one-line summary, links) and by explaining the committee_alternative field's semantics, including the non-obvious caveat that its filing date can postdate its committee/judiciary dates.
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 field inventory is front-loaded in the first clause, with the committee_alternative caveat following as a secondary note. It is information-dense but every clause maps to a real returned field or a real interpretation hazard.
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 return contents and does so concretely. For a one-parameter read-only lookup the coverage is nearly sufficient, with the only gap being no statement of failure behavior for an unknown bill number.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter's seven-digit format and example are fully documented in the schema. The description adds no parameter-level detail beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (get) and resource (National Assembly bill) and enumerates exactly what facts are returned, so the agent knows it is a single-record lookup rather than a search. It does not explicitly name search_bills as the alternative, but 'by its bill number' implicitly separates the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the agent must infer that this tool is the right one when it already has a bill number, versus search_bills when it does not. No when-not conditions or prerequisites (e.g. valid-number format) are stated, though the schema does cover the number format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full English text of one article of a South Korean statute or enforcement decree (the law may be given by slug or by name), with a one-line plain-English explanation where available, the attached tables (fine amounts, fees and criteria that the article refers to) once they are translated, the version date and the official Korean source link.
| Name | Required | Description | Default |
|---|---|---|---|
| law | Yes | Law slug, e.g. "labor-standards-act" (see list_laws). | |
| article | Yes | Article number, e.g. "56" or "2-3" (Article 2-3). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value with return-content traits: the plain-English one-liner, attached tables, the version date, and the official Korean source link, plus the honest caveat that tables appear only 'once they are translated' — a conditional-availability disclosure an agent would otherwise miss.
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 front-loaded sentence that leads with the resource before enumerating the return payload. It is dense with nested parentheticals but no clause is filler; slightly tighter phrasing would earn a 5.
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 only two fully documented parameters and no output schema, the description correctly spends its budget on describing what comes back, including version date and source link. It stops short of the edge cases a caller will hit — untranslated articles, article not found, decree vs statute resolution — but the essentials 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 coverage is 100%, so the baseline is 3, but the description adds a genuine delta: the law may be given by name as well as by slug, whereas the schema only documents the slug form. The article-number format is left to the schema's example, which is sufficient.
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 precise resource and scope: the full English text of exactly one article of a South Korean statute or enforcement decree, plus its ancillary material. That scope implicitly separates it from search_law_articles and get_law_overview, but no sibling is named outright, so the 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?
Usage is only implied: the required article parameter and 'one article' framing tell an agent this is a targeted single-record fetch rather than a search. There is no explicit when-to-use statement, no exclusion of alternatives, and no guidance on prerequisites such as resolving a slug via list_laws first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The shape of one South Korean statute or enforcement decree without its full text: official English name, version in force, how much is translated into English, its chapters and sections with the article ranges they cover, the linked enforcement decree or parent Act, and how many amendment bills are pending in the National Assembly (a count and a link, not what each bill changes). Works for laws whose English translation is still in progress. Use get_law_article for the text.
| Name | Required | Description | Default |
|---|---|---|---|
| law | Yes | Law slug, e.g. "labor-standards-act" (see list_laws or search_law_articles). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With read-only/idempotent annotations already covering safety, the description adds substantial behavioral detail: exact returned fields, that amendment bills are a count and link rather than bill contents, and that partial-translation laws are supported. Goes well 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-loads the core purpose, then compactly enumerates returned data, adds the translation caveat, and finishes with the alternative tool. No filler sentences; the length is justified by the absence of an output schema.
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?
Covers exactly what the tool returns and what it omits (full text), which is critical since there is no output schema. Together with the fully described law parameter and annotations, an agent has everything needed.
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 schema already defines the law slug with example and lookup tools. The description adds modest semantic value by clarifying the law argument can be a statute or enforcement decree, but adds no syntax or format beyond schema. Baseline 3 plus small lift = 4.
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 (get) and resource (law overview/structure) for one South Korean statute or enforcement decree, and distinguishes from get_law_article by noting it excludes full text. The field list makes the scope 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?
Explicitly directs the agent to get_law_article for the text, establishing the primary alternative. Also notes it works for laws whose English translation is in progress, giving a clear usage condition. Routing is explicit even though other sibling tools are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The most recent Koreanics Bill Briefs (analysis of one bill for foreign companies) or Weekly Briefs, with title, date, summary line and URL.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | "bill" (default) or "weekly". | |
| limit | No | Maximum results (default 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add context. It does add the return payload fields (title, date, summary line, URL), which is useful since there is no output schema, but it says nothing about pagination, rate limits, or ordering beyond 'most recent'.
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 with no filler; the resource and its scope are front-loaded, and the return fields are appended compactly rather than as a separate list.
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 two-optional-parameter read tool with no output schema, the description covers purpose, the two result kinds, and the returned fields. The only gap is that it does not say what happens if no briefs exist or how results are ordered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both the enum for 'kind' and the limit bounds/default are already documented. The description's 'or Weekly Briefs' phrasing loosely maps to the enum values but adds no syntax, formatting, or behavioral detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific resource (Koreanics Bill Briefs / Weekly Briefs) and a scope qualifier (most recent), and glosses what a bill brief actually is. It is clearly distinct from every sibling (get_bill, list_laws, search_bills, etc.), though it is phrased as a noun phrase rather than an explicit verb+resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the mention of two brief kinds tells the agent this tool spans both, and the schema supplies the default (bill). There is no statement of when to prefer this over search_bills or get_bill, nor any exclusion or prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The South Korean statutes and enforcement decrees available in English, with slug, subject area, version in force and how many articles are translated. Paged: 50 per call by default; pass next_offset to continue, or filter by area.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | Optional subject area to filter by, as shown in the results (e.g. "Employment & Labor"). | |
| limit | No | Laws per page (default 50). | |
| offset | No | Start position for paging (use next_offset from the previous result). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds value on top of that by disclosing the default page size, the continuation mechanism, and the shape of each returned row - context the annotations do not carry.
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, both earning their place: the first front-loads what the tool returns, the second carries paging and filtering. No filler, no restatement of the tool name.
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 describing the returned fields. Read-only/idempotent behavior is covered by annotations, all parameters are documented, and paging is explained - nothing an agent needs in order to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all three parameters are already documented in the schema, including that offset should come from the previous result. The description restates the 50 default and filtering but adds no syntax or format detail beyond the schema; minor terminology drift ('next_offset' vs the actual 'offset' parameter) slightly blurs rather than clarifies.
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 resource and enumerates what each row contains (slug, subject area, version in force, translated-article count), so an agent knows exactly what this returns. It does not explicitly contrast itself with search_law_articles or get_law_article, but the 'available in English' scope is concrete enough to distinguish it in practice.
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 operating context: results are paged at 50 per call by default, next_offset continues, and area filters. What it lacks is tool-selection guidance - nothing says when to browse here versus calling search_law_articles or get_law_article for a specific statute.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search over bills that Koreanics tracks (English titles and one-line summaries). Returns stage, dates, topic tags and URL.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results (default 10). | |
| query | Yes | Keywords in English, e.g. "customs" or "personal information". | |
| stage | No | Optional stage to filter by, e.g. "In committee", "Passed committee", "Passed plenary", "Promulgated", "In force". |
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 job is to add scope detail — and it does, disclosing the matching fields and the return contents (stage, dates, topic tags, URL). That is meaningful context an agent could not derive from the annotations alone; pagination/ordering behavior is the only notable omission.
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 tight sentences with zero filler; the search scope is front-loaded and the return fields are compactly enumerated at the end.
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 appropriately names the returned fields and clarifies the searchable corpus. Combined with 100% schema coverage on the three parameters, an agent has nearly everything needed; what is missing is only minor (result ordering, behavior when query matches nothing).
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 query, stage and limit are already documented in the schema, setting the baseline at 3. The description reinforces that queries are English keywords but adds no syntax, matching, or stage-filter semantics 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 specific verb (keyword search) and resource (bills), and narrows the searchable surface to 'English titles and one-line summaries', which tells the agent exactly what text is matched. It does not name or distinguish itself from the sibling search/get tools by name, but the scope statement is concrete enough to place it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the 'English titles and one-line summaries' scope implicitly warns that non-English queries or full-text body matching will not work, and the tool's nature suggests it is the discovery step before get_bill. However, there is no explicit when-to-use, when-not, or pointer to an alternative sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search over the English text of South Korean statutes and enforcement decrees in the Koreanics law database. Each Act and its Enforcement Decree are separate laws with their own slugs (e.g. labor-standards-act and enforcement-decree-of-the-labor-standards-act; also personal-information-protection-act, foreign-investment-promotion-act, foreign-exchange-transactions-act, monopoly-regulation-and-fair-trade-act, commercial-act, customs-act, value-added-tax-act, immigration-act, patent-act, copyright-act). Periods, amounts and thresholds are often in the Decree, so search it too; a law may also be given by name. Returns matching articles with a short snippet and URL. Use get_law_article for the full text.
| Name | Required | Description | Default |
|---|---|---|---|
| law | No | Optional law slug from list_laws, to search one law only. | |
| limit | No | Maximum results (default 10). | |
| query | Yes | Keywords in English, e.g. "overtime pay" or "foreign investment notification". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds non-obvious domain behavior: Acts and their Enforcement Decrees are separate laws with distinct slugs, and results come back as a snippet plus URL rather than full 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 purpose, then routing guidance, then return format. Efficient overall, though the long parenthetical list of law slugs is heavier than needed and could be trimmed without losing essential meaning.
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 specifies the return shape (matching articles with a snippet and URL), the scope of the corpus, the Act/Decree split, and the escalation path to get_law_article. An agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline would be 3, but the description goes further for the 'law' parameter by explaining that each Act and Decree has its own slug, giving a concrete slug convention ('labor-standards-act', 'enforcement-decree-of-the-labor-standards-act') and several real examples. It adds no meaning for 'limit' or query syntax beyond the schema, keeping it at 4.
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 ('keyword search over the English text of South Korean statutes and enforcement decrees') and explicitly distinguishes itself from the sibling get_law_article, which retrieves full text. An agent can tell it apart from search_bills and get_law_article without opening a 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?
Names the follow-up alternative ('Use get_law_article for the full text') and gives a substantive usage rule: search the Enforcement Decree too because periods/amounts/thresholds often live there, and a law may be referenced by name. It does not explicitly differentiate from the nearby sibling search_bills, so it falls short of a full when-not statement.
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_law_overviewlist_laws3 fields changedInput schema / properties / area / descriptionPrevious value: -"Optional subject area to filter by, as shown in the results (e.g. \"Labor & Employment\")."New value: +"Optional subject area to filter by, as shown in the results (e.g. \"Employment & Labor\")."Input schema / properties / limitAdded value: +{
+ "description": "Laws per page (default 50).",
+ "maximum": 200,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Start position for paging (use next_offset from the previous result).",
+ "minimum": 0,
+ "type": "integer"
+}get_billget_law_articlelatest_briefslist_lawssearch_billssearch_law_articlesOfficial English text of Korean laws (law.go.kr): search by name, get articles; flags outdated texts
Laws of South Korea from law.go.kr: statutes, official English translations, cases and rulings
Korean law: statutes, precedents, ordinances, treaties and citation verification (법제처 API).
Korea Law MCP — South Korean national statutes via the Ministry of Government Legislation's (법제처)…
Add one secure layer between your agents and this server.