Server Quality Checklist

Tool Scores

• get_financial_anomaliesB
  3.2/5.0
  Behavior2/5

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

  No annotations provided; description only mentions the analysis and scanning function. Lacks disclosure of behavioral traits like read-only nature, authentication needs, rate limits, or what constitutes an 'anomaly'.

  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?

  Description is a single sentence, concise and to the point, but lacks structural elements like paragraphs or bullet points that could improve readability.

  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?

  Given the presence of an output schema, the description does not need to detail return values, but it omits information about the output format or what constitutes an anomaly, leaving some gaps for a tool of moderate complexity.

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

  Parameters3/5

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

  With 0% schema description coverage, description adds minimal meaning: clarifies year expects a format like '2025' and corp_name_or_code is a corporate identifier. Does not elaborate on valid values or syntax.

  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 the tool analyzes key financial metrics (Debt ratio, current ratio, operating profit trend) and scans for anomalies/distressed patterns for a given year, distinguishing it from sibling tools like get_corporate_details or get_stock_chart.

  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?

  No explicit guidance on when to use or not use this tool versus alternatives. Only implies usage for financial anomaly detection without contextual conditions.

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

• get_corporate_detailsB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must fully disclose behavioral traits. It mentions the lookup action and output, but does not disclose potential issues like no-match behavior, rate limits, authentication requirements, or whether the query is exact or fuzzy. The minimal disclosure is insufficient for a tool without annotations.

  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 concise at two sentences, front-loading the purpose and input/output. Every clause is necessary and adds value, with no redundant information.

  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 simplicity (1 parameter, simple lookup) and the presence of an output schema, the description provides a sufficient overview. It covers the essential purpose and parameters. However, completeness is slightly reduced by the lack of usage guidelines and behavioral transparency, but for a basic tool it is adequate.

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

  Parameters3/5

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

  With 0% schema description coverage, the description partially compensates by specifying that the query can be a Korean corporate name or 6-digit stock ticker code. This adds context beyond the schema's mere 'string' type. However, it does not specify format constraints or examples, so it only moderately adds meaning.

  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 ('Look up'), the resource ('Korean corporate'), the input ('name or 6-digit stock ticker code'), and the output ('DART corp_code and basic profile'). It distinguishes well from sibling tools like get_financial_anomalies, get_footnote_section, and get_stock_chart, which have 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 Guidelines2/5

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

  The description does not provide explicit guidance on when to use this tool versus alternatives (siblings). It implies usage when needing to look up corporate details, but lacks when-not conditions or comparisons, leaving the agent without clear selection criteria.

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

• get_footnote_sectionB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full weight. It states it 'extracts relevant sections' matching keywords, but does not disclose important behavioral traits such as whether it returns full footnotes or only excerpts, how matches are ordered, error handling for missing data, or any limitations (e.g., single year only). This lack of transparency hinders the agent's ability to predict tool behavior accurately.

  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 a single, focused sentence that front-loads the action and includes relevant keyword examples. It is efficient and contains no unnecessary words. However, it could be slightly improved by separating the purpose from the examples for even faster scanning.

  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?

  Given the tool has 3 required parameters and no annotations, the description provides a clear purpose and partial parameter guidance but lacks details on behavioral expectations (e.g., output format, error handling). The presence of an output schema reduces the need to describe return values, but other contexts like pagination or edge cases are unaddressed. The description is adequate but not complete.

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

  Parameters3/5

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

  Schema coverage is 0% meaning no descriptions for individual parameters. The description compensates partially by explaining the 'keyword' parameter through examples, but 'year' and 'corp_name_or_code' are not described beyond their names. The context implies that 'corp_name_or_code' identifies the company and 'year' selects the fiscal year, but this is not explicit. Overall, the description adds some value but does not fully compensate for the lack of schema descriptions.

  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 queries corporate audit footnotes to extract sections matching specific risk keywords. It provides concrete examples of keywords ('소송', '보증', etc.) and explicitly ties the action to identifying hidden liabilities. The verb 'Query' and resource 'corporate audit footnotes' are specific, and the tool is well-differentiated from siblings like get_financial_anomalies or get_stock_chart.

  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 for extracting footnote sections with risk keywords to uncover hidden liabilities, but it does not explicitly state when to use or avoid this tool, nor does it mention alternative tools. The context is clear but lacks explicit guidance on exclusions or prerequisites.

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

• get_stock_chartA
  4.2/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It discloses data source (Yahoo Finance), automatic suffix handling, and includes SMA. Could mention more about output, but output schema exists.

  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?

  Two sentences, front-loaded, no redundancy. Every word adds 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?

  Given output schema exists, description is fairly complete for a financial data tool. Could mention available ranges, but overall adequate.

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

  Parameters3/5

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

  Schema description coverage is 0%; description explains ticker format well but does not describe range_str parameter beyond default value. Adds value for ticker but not for range.

  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 specifies the tool fetches historical stock chart info and SMA from Yahoo Finance, and the purpose of correlating with financial anomalies. It distinguishes from siblings which focus on corporate details, anomalies, and footnotes.

  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?

  Provides explicit ticker format and automatic suffix handling. Mentions use case but does not explicitly contrast with siblings or state when not to use.

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