Server Quality Checklist

Tool Scores

• list_dart_filingsA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses that the parser auto-detects format, that non-parseable types are flagged, and that omitting dates returns most recent filings. This provides useful behavioral context beyond parameter syntax.

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

  Conciseness5/5

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

  Description is well-structured with separate strategy and critical rules sections, concise sentences, and no redundant information. Every sentence adds distinct value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having an output schema (not shown), the description mentions that it returns rcept_no and flags non-parseable types. For a 5-parameter tool, this is sufficient to understand the tool's role and output, though additional return value details could be included.

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

  Parameters5/5

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

  Schema description coverage is 0%, so description compensates fully. It provides concrete examples for stock_code ('005930'), format for dates (YYYYMMDD), default values for report_types and limit, and max value for limit. All five parameters are clearly explained.

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

  Purpose5/5

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

  Description uses specific verb 'List' and explicitly states resource 'DART filings for a Korean listed company by stock code'. It clearly distinguishes from sibling tool 'download_dart_report' by mentioning it returns 'rcept_no' needed for download.

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

  Usage Guidelines4/5

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

  The strategy section instructs to invoke this tool before downloading, and the critical rules provide concrete guidance on using return value for download_dart_report and handling date parameters. However, it does not explicitly contrast with other siblings like get_report_pages.

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

• get_report_tocA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses that the tool does NOT use heuristic page-scan; section_tree is built directly from toc.yaml and parsed XML, making page ranges authoritative. It also notes that an optional stock_code improves cache hit rate, adding behavioral insight.

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

  Conciseness5/5

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

  The description is well-structured with sections (main description, <strategy>, <critical_rules>, args). It is front-loaded with the key purpose. Every sentence adds value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the presence of an output schema (not shown but indicated), the description need not explain return values. It adequately covers purpose, usage guidelines, behavioral transparency, and parameter semantics for a simple tool with 2 parameters (1 required) and a well-defined output.

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

  Parameters5/5

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

  Schema coverage is 0%, so the description compensates fully. It explains that rcept_no is a 14-digit DART receipt number from list_dart_filings, and stock_code is an optional 6-digit code that improves cache hit rate. This adds valuable context beyond the schema's title and default.

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

  Purpose5/5

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

  The description clearly states it retrieves the complete DART section_tree (Table of Contents) for a parsed report, specifying entry fields (start_page, end_page, local_pages, children). This distinguishes it from siblings like get_report_pages (which reads sections) and list_dart_filings (which lists filings).

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

  Usage Guidelines4/5

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

  The <strategy> block explicitly says 'Directly invoke this tool to understand the structural layout of the report' and explains that returned section_code values can be passed to get_report_pages. This provides clear guidance on when to use and how it integrates with sibling tools, though it does not explicitly 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.

• download_dart_reportA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description fully carries the transparency burden. It discloses caching behavior, auto-detection of document format, and parsing routes for different report types. It lacks explicit mention of side effects like network usage, but covers core 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.

  Conciseness4/5

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

  The description is longer but well-structured with strategy and critical rules in XML tags. Every sentence adds value, and the purpose is front-loaded. Minor room for cutting verbosity without losing meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (5 parameters, multiple report types, caching), the description covers workflow, error handling, auto-detection, parameter usage, and sibling relationships. The presence of an output schema complements the description.

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

  Parameters5/5

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

  Schema coverage is 0%, but the description provides rich parameter details: rcept_no's format and source, stock_code's role in file naming, rcept_dt's informational nature, report_type's default and flexibility, and force_parse's meaning. This adds significant value over the bare schema.

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

  Purpose5/5

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

  The description clearly states the tool's action ('Download and parse a single DART filing') and distinguishes it from siblings by noting it combines two SEC flow steps. This provides specificity and uniqueness.

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

  Usage Guidelines5/5

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

  The description includes an explicit strategy that tells the agent when to invoke this tool (only on 'file not found' errors from other tools) and critical rules that prevent misuse (never assume download before search). This provides thorough usage guidance.

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

• get_report_pagesA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description clearly explains parameter interactions (end_page wins over page_count, section_code overrides others), default values, and cache hint via stock_code. No contradictions.

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

  Conciseness4/5

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

  The description is well-structured with sections and bullet points, but slightly verbose with some repeated explanations (e.g., end_page winning). Still, each sentence adds value, so it remains efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no annotations, the description covers all aspects: modes, parameter usage, strategy, rules, and acknowledges the output schema (not shown). It is complete for an agent to use the tool correctly.

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

  Parameters5/5

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

  Schema coverage is 0%, but the description provides detailed parameter meanings, default values, interactions, and examples (e.g., stock_code for cache hit rate), going far beyond the bare schema.

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

  Purpose5/5

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

  The description clearly states the tool retrieves page content from a parsed DART report, specifies two modes (page range vs section_code), and distinguishes from sibling tools like keyword_search and get_report_toc.

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

  Usage Guidelines5/5

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

  The description includes a <strategy> block advising to use this tool for reading large continuous blocks and to prefer keyword_search for targeted fact-finding. <critical_rules> advise keeping page_count reasonable and using get_report_toc for section_code.

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

• search_dart_companyA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses behavior: case-insensitive matching, exact vs. substring modes, returning all candidates on multiple matches (not guessing), and the include_delisting option. No contradictions.

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

  Conciseness4/5

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

  The description is well-structured with sections for strategy, critical rules, and examples. It is comprehensive but slightly lengthy; however, every sentence adds value. Front-loading the core purpose helps efficient reading.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (4 parameters, ambiguity resolution, sibling coordination) and presence of an output schema, the description is complete: it explains purpose, usage, parameter details, return behavior, and provides examples. No gaps remain.

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

  Parameters5/5

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

  The description details all 4 parameters beyond the schema: query (Korean/English name), exact (exact match vs substring), limit (default 20, max 50), include_delisting (returns delisted companies). Schema coverage is 0%, so the description fully compensates.

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

  Purpose5/5

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

  The description clearly states the tool searches Korean listed companies by name (Korean or English) and returns stock_code/corp_code. It distinguishes from sibling tools like list_dart_filings by explicitly stating to resolve stock_code first. Examples solidify the purpose.

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

  Usage Guidelines5/5

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

  The <strategy> section explicitly says to invoke this tool FIRST when a company name is given without a stock_code. The <critical_rules> specify to SKIP if a stock_code is already provided and call list_dart_filings directly. This provides clear when-to-use and when-not-to-use guidance with alternatives.

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

• keyword_searchA
  5/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavior: substring matching, character-count TF normalization, no word boundaries, result context, error fallback strategy. No contradictions or gaps.

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

  Conciseness5/5

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

  Well-structured with distinct sections (description, strategy, critical rules, examples, args). Every sentence adds value; no redundancy or verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity (5 params, no annotations, but output schema exists), the description is comprehensive. It covers usage, rules, examples, parameter details, and even a fallback strategy, ensuring an AI agent can use the tool correctly.

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

  Parameters5/5

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

  Despite 0% schema coverage, the description thoroughly explains each parameter: rcept_no (14-digit), keywords (1-5, include variants, omit particles), match_mode (ANY/ALL), max_results (default 5, max 50), stock_code (optional 6-digit). Adds significant value beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool performs 'Korean full-text keyword search across a parsed DART report', specifying the action, resource, and scope. It effectively distinguishes from siblings like download_dart_report or get_report_toc, which serve different purposes.

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

  Usage Guidelines5/5

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

  The <strategy> section explicitly instructs to use this for targeted fact-finding and provides fallback guidance. <critical_rules> and <examples> offer detailed, actionable usage criteria, including keyword selection and morphological variants.

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