lawmadi-os

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

There are no annotations, so the description carries the full transparency burden. It discloses non-obvious behavior: automatic routing to one of 60 specialists, real-time law.go.kr verification, and bilingual support. It does not describe response format or limitations, but it goes well beyond a generic question-answering 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, delivering purpose in the first sentence and workflow in the second. The bilingual repetition is justified for the tool's Korean/English audience, and 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?

For a 3-parameter tool with full schema coverage and no output schema, the description provides sufficient operational context: routing, verification, and language behavior. It could add response shape or exclusion criteria, but it is not severely incomplete.

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 input schema already documents all parameters with 100% coverage, so the baseline is 3. The description adds only the fact that Korean and English are supported, which maps to the lang parameter; it does not add further 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 clearly states the tool's purpose: 'Ask a Korean legal question' with a distinctive workflow of routing to 1 of 60 specialist AI legal leaders and returning a statute-verified analysis via real-time law.go.kr checks. It is specific and action-oriented, but it does not explicitly distinguish itself from overlapping sibling tools like 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 description implies usage for Korean legal questions but provides no explicit when-to-use guidance or alternatives. With sibling tools like ask_expert, chat_leader, lookup_statute, and verify_citations, the description gives no basis for choosing among them.

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

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 clearly states it is slower than `ask`, is Pro-only, requires a Pro credit pack (balance alone insufficient), charges 2 credits, and refuses non-Pro callers without charge. It also discloses idempotent behavior in the parameter description. This is excellent transparency beyond the schema.

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

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

The description is compact, written in bilingual format (Korean and English), and front-loads the core purpose. It includes important caveats but avoids fluff. Slight redundancy from bilingual repetition, but the structure is clear and every sentence adds essential insight.

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?

Given that the tool has no output schema and complex multi-parameter behavior, the description and schema together are fairly complete. It covers the invocation semantics, error conditions (non-Pro refusal), credit cost, and idempotency. Minor gap: it doesn't describe the detailed response content or how to handle timeouts besides idempotency key, but it's adequate.

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 input schema has high coverage (100%) with detailed descriptions for each parameter. The description adds value by explaining the Pro requirement and credit cost, and the idempotency_key parameter description includes additional behavioral context (never charged twice, replays stored answer). This goes beyond a baseline 3, but since schema is already thorough, it doesn't reach 5.

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 it performs expert mode legal analysis with a deeper, verification pipeline for detailed, deeply-cited answers. It specifies the main action (run full verification pipeline) and resource (legal analysis), and explicitly contrasts with sibling `ask`, which helps distinguish 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?

The description explicitly states when to use it (when deeper, more detailed answers are needed) and when not to (for non-Pro users, use `ask` instead). It also clarifies the Pro plan requirement and that non-Pro callers are refused without charge, which is critical usage guidance.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals that citations have passed law.go.kr verification, indicating reliability, and explicitly lists the output fields. It doesn't mention side effects, but as a search tool, read-only is implied. It could be more explicit about being non-mutating, but the detail provided is strong.

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 two sentences, both in Korean and English, and every phrase adds value. The first sentence establishes scope and data quality, the second covers usage and output. No filler, no repetition, and it's front-loaded with the core purpose.

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?

Despite no output schema, the description fully explains the return structure (회차, 과목, 문항번호, 공식 정답, 지문, 인용 조문/판례와 링크). It also covers the corpus size and verification. The parameters are all in the schema, and the description effectively complements them, making the tool's behavior predictable for an agent.

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 documents the parameters. The description adds value by explaining that 'q' accepts docket numbers, statute articles, or keywords, and gives concrete examples ('2014도6992', '형법 제310조'). It also clarifies the output mapping, which enriches understanding beyond raw schema names.

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 the verb 'search' and the resource 'Korean bar exam corpus', and details the scope (15 rounds, 2,340 questions) and what results include (round, subject, question number, official answer, text, cited statutes/cases, and links). This distinguishes it from siblings like lookup_precedent or lookup_statute by explicitly targeting the bar exam corpus.

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 provides clear context on what queries to use (e.g., docket number, statute article, keyword) and what it returns. It doesn't explicitly mention alternatives or when not to use this tool, but the specificity of the bar exam corpus makes the intended use case obvious. A slight deduction for not naming alternatives.

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

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

With no annotations provided, the description carries the full burden, and it does so well. It discloses the daily free allowance, the cost-return behavior, and that credits are never deducted unless confirm=true (default false). This is exactly the side-effect and cost behavior an agent needs.

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 content is front-loaded with purpose, then parameter guidance, then cost behavior. However, the full description is duplicated in Korean and English, which adds unnecessary length even if it may support bilingual users.

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 the critical invocation details and charging workflow. It does not describe what a successful response contains, but for a chat tool this is low-risk and the absence of an output schema makes that less critical.

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 documents all parameters. The description adds value by tying leader_id to get_leaders and giving rich semantics for confirm: only set after payment_required, never charged by default.

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 action: chat 1:1 with a particular legal leader, and requires a leader_id obtained from get_leaders. This clearly differentiates it from generic ask/ask_expert tools even though those siblings are not named.

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 context: use a leader_id from get_leaders, and it explains the confirm flow for paid usage. It does not explicitly name alternatives or state when not to use this tool, but the leader-specific guidance is sufficient for selection.

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

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

With no annotations, the description carries the burden and discloses important behaviors: the program only covers rural eup/myeon areas, metropolitan districts are absent, empty results expose a coverage field, and the tool uses public data without calling an LLM. It does not mention rate limits or exact return formatting, but the key operational caveats are covered.

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

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

The description is front-loaded with the core purpose, followed by examples, a critical coverage caveat, and a data-source note. The bilingual repetition makes it longer, but each sentence contributes necessary selection or invocation 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?

For a simple two-parameter lookup with no output schema, the description covers what the tool returns conceptually (contact points), how to handle empty results, and the data source. It could specify result fields (e.g., lawyer name/phone) but is otherwise 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; the description adds value by giving region examples, explaining the searchable administrative levels (시·도, 시·군·구, 읍·면), and clarifying that metropolitan districts are invalid search targets. The limit parameter is not elaborated, but the schema already defines it.

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 uses a specific verb-resource pair ('마을변호사를 지역으로 찾습니다' / 'Find the village lawyer assigned to a Korean locality') and clearly distinguishes this from sibling legal-research tools by emphasizing locality-based lookup, free consultation contacts, and public-data/no-LLM behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides concrete search examples ('강원 강릉', '고성군', '완도'), explains the geographic scope, and instructs users to check the coverage field on empty results. It does not explicitly name alternative tools or state when not to use it beyond the implied metropolitan-district exclusion.

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

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

No annotations are provided, so the description must carry the burden. It discloses that citations go through fail-closed law.go.kr verification and that invalid doc_type should be avoided by checking via list_document_types味的, but does not mention output format, potential errors, or edge cases. Adequate but not rich.

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?

Description is two bilingual sentences, front-loaded with purpose and crucial verification info. No fluff, efficient, though the bilingual repetition doubles length without adding new 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?

Given 4 simple params, no output schema, and no annotations, the description covers the key usage pattern (check doc_type) and informs about verification behavior. It lacks details on return format but that's minor given the tool's simplicity.

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 param descriptions, so baseline is 3. The description adds the crucial dependency on doc_type keys (from list_document_types) but does not elaborate on context, lang, or extra_instructions beyond schema. Neutral.

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 the tool drafts Korean legal documents from user facts, enumerating types (고소장·소장·내용증명 etc.), and distinguishes it from siblings like ask and list_document_types by specifying its unique drafting function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly instructs to use list_document_types first to obtain valid doc_type keys, giving clear context for proper usage. It does not mention when not to use this tool versus alternatives, but the drafting purpose is distinct enough.

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

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

The description adds useful behavioral context by explaining the top-up link purpose, which is not evident from the name alone. However, it does not detail response format, rate limits, or whether the tool makes network calls. Since there are no annotations, the description carries full burden but remains somewhat limited.

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 concise, with two sentences in the bilingual format (Korean/English), each serving a clear purpose: defining the tool and providing usage guidance. It is front-loaded and contains no extraneous 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?

Given that the tool takes no parameters and has no output schema, the description provides sufficient information for most use cases. However, it could have specified the format of the top-up link (e.g., whether it is a URL) or included a note about what constitutes 'metered queries' to prevent overcalling. Still, it is adequate.

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 no parameters, the schema is inherently complete proportionally. The description effectively communicates the scope—it retrieves account-level information—and does so without needing to explain parameter details.

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 the tool's function as retrieving account status (credits, plan, top-up link) for the API key. It distinguishes itself from siblings like get_pricing and get_leaders by focusing on the user's own account and balance.

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 explicitly states when to use it—before long metered queries—and why (to avoid exhausting balance mid-task). This provides clear actionable guidance that is particularly relevant for billing-related tools.

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

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

There are no annotations, so the description carries the full burden. It discloses the return format ('full-record form') and the specific fields included per stream, which adds value. However, it does not address potential issues such as permissions, missing dates, or error behaviors, leaving some 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 description is concise, with two clear sentences explaining purpose and usage. The bilingual presentation adds slight redundancy, but the structure is front-loaded and efficient. 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?

Given the tool's simplicity (2 params, no nested objects, no output schema), the description is complete enough. It covers the retrieval logic, the streams, and the default date behavior. It does not need to discuss return format beyond what is stated, and the absence of edge-case detail is acceptable for this scope.

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 documents both parameters. The description adds contextual detail—like what each stream contains—but does not clarify parameter formats beyond the schema. This meets the baseline for high schema 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 clearly states the action: 'Fetch one published daily post in full-record form.' It specifies the resource (daily post) and provides a detailed breakdown of the content types per stream. It effectively distinguishes itself from list-oriented siblings like 'latest_content' by emphasizing a single post retrieval.

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 explains the usage pattern: 'Pass a date, or omit it for the latest post in that stream.' It clearly communicates the optional date parameter and the default behavior. However, it does not explicitly mention when not to use this tool or suggest alternatives, so it loses one point.

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

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

With no annotations, the description fully discloses behavior: it states that every citation passed law.go.kr verification, that the corpus is proprietary and not for bulk export, and details exactly what content is returned for each question type. This goes beyond the schema and provides essential constraints.

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 well-structured, front-loaded with the core purpose, then provides format-specific instructions and a usage constraint. Despite being bilingual, every sentence conveys necessary information without redundancy, and the bullet-style organization aids readability.

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 has conditional parameters and no output schema, yet the description explains exactly what is returned for each question type, covers all parameter combinations, and includes a usage limitation. It is comprehensive enough for an agent to invoke correctly without ambiguity.

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?

Although the schema covers 100% of parameters, the description adds crucial semantic context by explaining the conditional combinations (round+subject+no for MCQ, round+subject+format for essay/record). This clarifies how to correctly invoke the tool for each format, which is not obvious from the schema alone.

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 clearly that the tool fetches one bar-exam question with its full gold answer, specifying distinct formats (MCQ, essay, record) and what is returned for each. It differentiates itself from siblings like bar_exam_search by focusing on a single item with full answer 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?

The description gives explicit conditional usage: for MCQ pass round+subject+no, for essay/record pass round+subject+format. It also warns against bulk usage with 'One item per call'. However, it does not explicitly name alternatives or state when not to use this tool in favor of a sibling search tool.

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

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

With no annotations provided, the description carries the burden. It states the tool 'returns' a list, implying a read operation, but does not disclose any additional behavioral traits (safety, side effects, rate limits). Adequate for a simple retrieval but not rich.

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 concise (two short lines) and front-loaded with the core action and output. Every word adds value; no fluff or repetition.

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, read-only list retrieval with no output schema, the description fully covers what the agent needs to know to invoke and interpret the result. No missing details.

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 has zero parameters, so the schema is trivially complete. Per rubric baseline, a description for a no-parameter tool gets a 4. The description adds no parameter info but none is needed.

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 the tool's action ('List all 60+ specialist legal leaders') and the returned fields (names and specialties). It distinguishes from sibling tools like 'chat_leader' by implying a simple retrieval, not interaction.

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 a straightforward use case (getting a list of leaders) but does not explicitly state when to use or avoid this tool versus alternatives. No exclusions or context are provided.

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

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

With no annotations provided, the description carries the transparency burden and does reveal a key behavioral fact: no authentication is required. It also makes clear the tool is informational (returns details) and intended as an entry point, which gives useful context beyond the schema.

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

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

The description is front-loaded with the core purpose and then enumerates specific content areas. Bilingual repetition doubles the length, but each language block is compact and information-dense, so the structure is still efficient.

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 optional-parameter tool with no output schema, the description is complete: it explains what will be returned, that no authentication is needed, and when an agent should call it. No critical behavioral or usage gaps remain.

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 only parameter, lang, is already fully described in the schema with an enum and default value ('Default en.'), so schema coverage is high. The description adds no additional meaning about this parameter, matching the baseline for well-covered schema parameters.

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 the tool's function: it returns onboarding and pricing information including sign-up flow, API key issuance, free allowance, credit-pack prices, and checkout links. It also distinguishes itself from siblings like get_account by positioning itself as the first-stop tool for newly arriving agents.

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 explicitly says it is callable without authentication and that first-time AI agents should call it to learn how to obtain access. It provides clear context for when to use the tool, though it does not explicitly mention alternatives or when-not-to-use scenarios.

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

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

With no annotations provided, the description carries the full transparency burden. It adds valuable behavioral context by asserting that every post passed a publishing gate with citations verified against law.go.kr and sources live-checked, indicating data quality and trustworthiness. While it does not explicitly state that the operation is read-only, that is evident from the verb 'get' and the absence of side effects, so no contradiction or gap is significant.

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 exceptionally compact: two sentences, bilingual yet front-loaded with the key function and stream list. Every element (stream enumeration, verification claim) earns its place. There is zero redundancy or fluff, making it easy to parse quickly.

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 content-fetch tool with no output schema, the description adequately conveys the full set of content categories and the high-level verification status. It does not describe pagination or return structure, but given the simplicity and the schema's detail on limit, this is sufficient. No further context is likely needed for the agent to understand the tool's output.

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 input schema fully documents both parameters (limit: integer, stream: enum) with descriptions covering all meanings. The tool description adds no extra parameter semantics beyond repeating the stream types in the text, which are already in the schema. Since schema coverage is 100%, the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states its function: fetching Lawmadi's latest daily legal content across six enumerated streams (daily, strategy, tech, news, bar, precedent). This distinguishes it from sibling tools like get_daily_content, which presumably focuses on a single stream. The scope is explicit and the verb 'get' is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the stream parameter and the note that blank returns the latest of each stream. However, the description does not explicitly contrast with sibling tools like get_daily_content or how this relates to search tools. No prerequisites or restrictions are stated, leaving the agent to infer when to prefer this tool over others.

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

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 does not mention any side effects or confirm read-only behavior, but the nature of listing document types is inherently non-modifying. The description adds no extra transparency beyond the obvious.

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 concise, provides examples, and is structured in both Korean and English. Every sentence contributes to explaining the tool's purpose without unnecessary fluff.

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 return values are not required to be explained. The description fully covers what the tool does—listing document types with labels—and is complete for a simple listing operation.

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 has zero parameters, so the description correctly provides no parameter details. According to the rubric, a tool with 0 parameters starts at a baseline of 4, and there is no need for further explanation.

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 that the tool lists legal document types that Lawmadi can draft, with Korean and English labels and provides examples. This is a specific and unambiguous purpose, distinct from sibling tools like search or lookup.

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 for when to use the tool (to see available document types) but does not explicitly mention alternatives or exclusions. It is adequate but lacks explicit guidance on when not to use it compared to other tools.

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

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

There are no annotations, so the description carries the full burden—and it delivers. It discloses the two-stage lookup strategy (corpus then authoritative_index), explains what the source field means, states that it is deterministic with no LLM, and details preview-vs-full results based on API key. This is unusually transparent.

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 purpose and organizes behavior logically, but the same information is repeated in Korean and English, and the API-key preview note is stated twice. The redundancy inflates length without adding semantic 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?

With only one required parameter and no output schema, the description still enumerates all returned fields, explains source-field semantics, covers authentication behavior, and states deterministic safety properties. It is complete enough for an agent to invoke and interpret correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with one parameter, so baseline is 3. The description adds real value by listing multiple accepted input formats—'2020도3050', a full citation string, and '2016헌마90'—which goes beyond the schema's single example.

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 opens with a specific verb and resource: '사건번호로 한국 판례를 조회합니다' and 'Look up a Korean court case by docket number.' It clearly distinguishes itself from sibling lookup_statute by focusing on precedents rather than statutes, and the scope of law.go.kr sources is explicit.

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 implies when to use this tool: when a Korean court case must be looked up by docket number, especially when deterministic, non-hallucinated results are needed. It also explains the API-key depth difference. However, it does not explicitly name sibling alternatives or state when not to use it.

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

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

With no annotations, the description fully carries the transparency burden and does so exceptionally well: it discloses determinism/no LLM, refusal to fabricate missing body text, absent=true reporting, and API-key-gated preview depth. This is far beyond a typical 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 primary action and scope, then moves to behavior details. The bilingual repetition adds some length, but the information is dense and logically organized, so it remains efficient 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?

Even without an output schema, the description explains what is returned (article title, body text, law.go.kr link), the preview-depth variant, the absent flag, and the deterministic fallback behavior. An agent has enough information to select and invoke 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?

The input schema already documents the single 'reference' parameter at 100% coverage with an example. The description adds a second example and implies the expected statute-article format, but these are marginal additions, so the high-coverage baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses a specific verb and resource ('한국 법령 조문을 조회합니다' / 'Look up a Korean statute article') and additionally narrows scope to Lawmadi's verified-asset corpus with a law.go.kr fallback. It is clearly distinct from lookup_precedent, but it does not explicitly name or contrast any sibling, so it stops just short of full differentiation.

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?

Concrete input examples ('민법 제750조', '형법 제307조 제1항'), the verified-asset/index fallback path, and preview-depth/API-key behavior make the intended use obvious. It does not explicitly state when not to use this tool, such as directing precedent lookups to lookup_precedent.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly discloses the external source (law.go.kr), the search scope (law names only), and the limitation that article text and case law are not searched. It does not describe the result format or pagination, but for a read-only search tool the disclosed scope and exclusions are the most important behavioral traits.

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 well-structured and front-loaded: the core function and scope come first, then alternative routing, then examples. It is bilingual, repeating the same content in Korean and English, which adds length but is not wasted in a Korean legal context. It contains no filler or irrelevant detail.

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-parameter search tool, the description is nearly complete: it explains what to search, what not to search, gives alternatives, and provides examples. The main gap is that it does not describe the shape or fields of the returned results, and there is no output schema to compensate. Still, an agent can confidently select and invoke this tool with the given guidance.

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 schema already documents both q and limit with 100% coverage, so the baseline is 3. The description adds meaning beyond the schema by specifying that q must be a 'law name' and providing valid examples, which clarifies what kind of query is expected. The limit parameter is fully covered by the schema, so no additional description is necessary.

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 Korean statutes by law name on law.go.kr.' It also explicitly excludes article text and case law, which distinguishes it from lookup_statute and lookup_precedent. The examples ('주택임대차보호법', '근로기준법') clarify the intended input without ambiguity.

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 explicitly routes to alternatives: use lookup_precedent for cases, lookup_statute for articles, and verify_citations for checking citations in arbitrary text. It also states a clear when-not: this tool does not search article text or case law. This is strong routing guidance for an agent choosing among siblings.

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

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

No annotations exist, and the description does not mention behavioral traits such as read-only nature, potential rate limits, authentication requirements, or output behavior. The agent is left without explicit disclosure of side effects or access constraints.

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 succinct, presented in two lines (Korean and English), with no redundant or extraneous content. It directly conveys the core purpose and an example without 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?

Given the absence of an output schema, the description should explain what the tool returns (e.g., list of forms, metadata, citations). It only mentions 'searches' without any indication of result format, pagination, or error handling, leaving the agent uninformed about expected outputs.

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 schema descriptions for query, knd, and limit are present and clear. The description adds a contextual example of a query ('application form according to a specific law') which slightly enhances understanding, but it does not elaborate on the meaning of the knd enum values beyond the schema, so it adds limited incremental 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?

The description clearly states the tool searches official Korean statutory forms and appendix tables on law.go.kr, with a concrete example. This distinctly identifies the tool's purpose and differentiates it from sibling search tools that focus on statutes or other 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?

The description provides no guidance on when to use this tool versus alternatives like lookup_statute or search. It lacks any indication of appropriate scenarios, limitations, or prerequisites, leaving the agent to infer usage from the tool's name alone.

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

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

There are no annotations, and the description does not mention whether the tool is read-only, what side effects (if any) it has, or any constraints like rate limits. It simply states that it generates questions, which implies a safe operation, but this is not explicitly stated. Given the lack of annotations, the description should carry this burden but falls short.

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 extremely concise—just one sentence in both Korean and English. It conveys the essential purpose without unnecessary words. While it lacks additional details, the brevity is appropriate for such a simple tool, and nothing is redundant.

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 is adequate for a simple tool: it names the operation and the parameter. However, it does not describe the output format (e.g., a list of strings), any examples, or error behaviors. Given that there is no output schema and no annotations, more details would be needed to fully understand the tool's behavior, but the core functionality is sufficiently conveyed.

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 parameter 'query' is described as 'Current user question (max 500 chars)', which adds practical meaning beyond the raw type (string). It clarifies that the input should be a user's question and imposes a length limit. This is helpful for the agent, though it could benefit from more details like expected format (e.g., plain text vs. structured).

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 the tool's function: generating relevant follow-up legal questions for a given query. It uses a specific verb ('generate') and identifies the resource (follow-up questions), making its purpose clear. However, it does not explicitly distinguish itself from similar sibling tools like 'ask_expert' or 'search_legal_forms', though the unique purpose is still evident.

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 provides no guidance on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or situations where it would be preferred over other tools. This is a significant gap, as the agent might not know whether to use 'suggest_questions' or another tool like 'ask_expert' for a given user query.

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

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, and it delivers substantially: deterministic operation, no LLM call, credit cost per call, and the exact semantics of not_in_corpus. It also explains that findings==0 means 'nothing caught on that axis' rather than 'correct', which is critical for interpreting results.

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 well-structured, front-loading status definitions and the credit cost. However, the full Korean and English duplication roughly doubles the length, and the same semantics are repeated across languages, so it is not as concise as 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?

Without an output schema, the description must explain return semantics, and it does so thoroughly: per-citation status values, source links, four verification axes, scope and denominator reporting, and the meaning of zero findings. It also covers cost, determinism, and the practical implication of not_in_corpus, leaving no critical gap for an agent invoking this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the single text parameter and its 20000-character limit. The description adds context about accepting arbitrary text and mentioning LLM-produced content, but no additional parameter-level syntax or format details beyond what the schema 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: 'Fact-check the Korean legal citations inside any text' and enumerates per-citation statuses. It clearly distinguishes this verification tool from sibling search/lookup tools by focusing on validating citations in arbitrary text rather than retrieving statutes or precedents.

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 makes the input context explicit: any text, including text produced by another LLM, and explains what results are returned. It does not explicitly name sibling alternatives or state when not to use this tool, but the use case is clear enough for an agent to select it appropriately.

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