Server Quality Checklist

Tool Scores

• test_connection_to_dartB
  3.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses the return value ('detailed message about connection test process and results'), which is helpful given the lack of output schema. However, it fails to mention safety characteristics (read-only vs. write), side effects, or whether the test consumes API quota/rate limits.

  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 appropriately concise and structured with clear Purpose, Args, and Returns sections. It is front-loaded with the main function. The Args section mentioning 'ctx' is slightly redundant since it's not part of the user-facing schema, but it does not significantly detract from clarity.

  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?

  Given the tool's low complexity (zero parameters, no output schema), the description is sufficiently complete. It compensates for the missing output schema by describing the return value. For a simple connectivity test tool, the level of detail provided is adequate, though usage context would be beneficial.

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

  Parameters4/5

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

  With zero parameters in the input schema, the baseline score is 4. The description mentions 'ctx: MCP Context 객체' which corresponds to the framework-injected context, not a user-facing parameter. Since there are no parameters requiring semantic explanation, this is acceptable.

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

  Purpose4/5

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

  The description clearly states the tool tests connection status with the DART server (specific verb + resource). However, it does not explicitly differentiate from sibling search tools (e.g., when to use this diagnostic vs. the search functions), which prevents a score of 5.

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

  Usage Guidelines2/5

  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 the available search alternatives (search_business_information, search_disclosure, etc.). It does not mention prerequisites, such as using this to verify connectivity before attempting searches.

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

• search_detailed_financial_dataA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full disclosure burden. It successfully documents the data source method (XBRL parsing) and return format (text), but fails to mention critical behavioral traits like read-only status, rate limits, error handling scenarios (e.g., invalid company names), or data availability constraints.

  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 uses a clear Args/Returns structure that efficiently organizes information. Given the lack of schema descriptions and output schema, the length is appropriate and necessary. No sentences are wasted, though the Korean text is slightly more verbose than the minimal English equivalent.

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

  Completeness3/5

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

  The description adequately covers input parameters and return values (compensating for missing output schema), but remains incomplete regarding operational context. For a financial data tool of this complexity, it should mention data freshness, potential for missing filings, or authentication requirements, especially absent any annotations.

  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?

  Given 0% schema description coverage, the Args section fully compensates by providing comprehensive semantics: date format specifications (YYYYMMDD), statement_type enum values ("재무상태표", "손익계산서", "현금흐름표"), default behavior for None, and concrete examples for company names. This adds substantial value beyond the schema.

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

  Purpose4/5

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

  The description clearly states the tool parses XBRL files to extract detailed financial data (specific verb + resource). However, it does not explicitly differentiate when to use this versus the sibling 'search_json_financial_data' tool, though it implies distinction via the XBRL and text-output mentions.

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

  Usage Guidelines2/5

  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 'search_json_financial_data' or 'search_business_information'. It lacks explicit when-to-use or when-not-to-use conditions, prerequisites (e.g., specific company naming conventions), or exclusion criteria.

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

• search_business_informationA
  3.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure but only minimally indicates it returns '텍스트' (text) versus structured data. It fails to disclose data source, rate limits, authentication requirements, caching behavior, or error scenarios that an agent would need to handle this safely.

  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 uses a clear Args/Returns structure that efficiently organizes information. While the information_type enumeration is lengthy, every line is necessary given the lack of schema enums. The front-loaded purpose statement followed by detailed parameter documentation represents effective information architecture.

  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?

  For a 4-parameter tool with no output schema and 0% parameter coverage, the description adequately covers all parameters including format constraints and categorical options. It indicates the return type (text). Minor gaps include lack of error handling documentation and date range constraints (e.g., maximum range limits).

  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?

  Given 0% schema description coverage, the description excellently compensates by providing detailed Args documentation: date format specifications (YYYYMMDD with examples), company name examples (삼성전자, 네이버), and comprehensive enum-like explanations for information_type with 7 distinct categories and their meanings. This adds critical semantic value missing from the schema.

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

  Purpose4/5

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

  The description clearly states it provides '회사의 사업 관련 현황 정보' (company business-related status information) with specific verb and resource. It implicitly distinguishes from siblings like search_detailed_financial_data (financial vs. business operational data) and search_json_financial_data (text return vs. JSON), though explicit differentiation from search_disclosure would strengthen this further.

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

  Usage Guidelines3/5

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

  The description provides implied usage guidance through the detailed enumeration of information_type categories (e.g., when to request '매출 및 수주상황' vs '주요계약 및 연구개발활동'), but lacks explicit when-to-use guidance relative to sibling tools like search_disclosure or search_detailed_financial_data.

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

• search_disclosureA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description explains that the tool filters disclosures based on data availability for requested items and describes the return format as summary text ('주요 재무 정보 요약 텍스트'). However, it omits operational details such as rate limits, authentication requirements, or error handling behaviors that would be necessary for full transparency.

  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 follows a clear docstring structure with purpose stated first, followed by detailed Args and Returns sections, making efficient use of space. While detailed, the parameter documentation is necessary given the complete lack of schema descriptions, though the inclusion of 'ctx' (not present in the schema) slightly detracts from precision.

  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?

  Given the lack of annotations and schema descriptions, the description adequately covers the tool's purpose, parameter usage with examples, and return value format ('검색된 각 공시의 주요 재무 정보 요약 텍스트'). It could be improved by adding error scenarios or operational constraints, but provides sufficient information for correct invocation despite the complexity of date range searching and item filtering.

  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 comprehensively compensates for the 0% schema description coverage by providing detailed semantics for all parameters, including format examples for dates (YYYYMMDD), example company names ('삼성전자, 네이버'), and an enumerated list of valid financial items for requested_items. It clearly documents the default behavior when requested_items is None.

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

  Purpose4/5

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

  The description clearly states the tool searches and provides major financial information of companies ('회사의 주요 재무 정보를 검색하여 제공하는 도구'). It specifies that it targets disclosures ('공시') and mentions the filtering capability by specific financial items, which helps distinguish it from sibling tools like search_detailed_financial_data, though it lacks explicit comparative guidance.

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

  Usage Guidelines3/5

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

  The description explains the filtering behavior when requested_items is provided versus when it is None, indicating when disclosures will be returned based on data availability. However, it lacks explicit guidance on when to choose this tool over siblings such as search_detailed_financial_data or search_json_financial_data.

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

• get_current_dateA
  3.9/5.0
  Behavior3/5

  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 successfully specifies the critical output format (YYYYMMDD) and that it returns a string, but omits other behavioral traits such as timezone handling, caching behavior, or side effects. For a simple read-only date retrieval, this is minimally acceptable but not comprehensive.

  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 appropriately brief with a clear structure: one-sentence purpose statement followed by Args and Returns sections. The Returns section is particularly valuable given the absence of an output schema. The Args section mentioning 'ctx' is slightly redundant since it's not part of the invocation schema, but does not significantly detract from clarity.

  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?

  For a tool with zero input parameters and no output schema, the description provides the essential contextual information: the specific date format (YYYYMMDD) and the fact that it returns a string. While it could benefit from timezone clarification, the description is sufficiently complete for an agent to understand what will be returned upon invocation.

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

  Parameters4/5

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

  The input schema contains zero parameters (empty properties object), which establishes a baseline score of 4. The description mentions an optional 'ctx' argument in the Args section, but this appears to be framework-internal context not exposed in the JSON schema, so it does not add confusion for the AI agent invoking the tool. No additional parameter semantics were needed beyond the empty 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 'returns current date in YYYYMMDD format' (현재 날짜를 YYYYMMDD 형식으로 반환하는 도구), providing a specific verb (반환하는/returns) and resource (현재 날짜/current date). It effectively distinguishes itself from sibling search tools (search_business_information, search_disclosure, etc.) by being the only date retrieval utility versus data search operations.

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

  Usage Guidelines3/5

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

  The description implies usage through its name and purpose statement (use when you need the current date), but provides no explicit guidance on when to use this versus alternatives or how it relates to the search workflows. It lacks prerequisites or contextual triggers that would help an agent decide to invoke this before filtering search results by date.

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

• search_json_financial_dataA
  4.7/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 the fallback/auxiliary nature ('실패시 보완하는 보조 도구') and return value constraints ('당기 데이터만 표시' - current period only). However, it lacks mention of error handling, rate limits, or authentication requirements.

  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 clear sections (summary → usage context → Args → Returns). Information is front-loaded with purpose and sibling differentiation first. Every sentence serves a function; no redundancy despite Korean/English mixed context.

  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?

  Given zero annotations, zero schema coverage, and no output schema, the description successfully explains the tool's role, parameter semantics, and return format ('텍스트' containing detailed items). Minor gap: lacks error handling or rate limit disclosure expected for financial APIs.

  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?

  Given 0% schema description coverage, the Args section fully compensates by providing semantic meaning for all 5 parameters, including Korean business term mappings for enums (e.g., '11011': 사업보고서) and examples (e.g., '삼성전자, 네이버'). The None behavior for statement_type is also 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 clearly states it provides company financial information via JSON API and explicitly identifies itself as a '보조 도구' (auxiliary tool) that compensates for failures. It distinguishes from siblings by naming search_disclosure and search_detailed_financial_data as the primary tools.

  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?

  Explicitly states when to use: 'search_disclosure, search_detailed_financial_data이 2023년 9월 이전 자료 분석에 실패했을 때 대안으로 활용' (use as alternative when primary tools fail for pre-September 2023 data). This provides clear when-to-use guidance and names specific alternatives.

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