MCP OpenDART

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes targeting specific financial events or corporate actions, such as get_bankruptcy for liquidity crises or get_merger for mergers. However, some tools like get_debt and get_debt_securities_issued have overlapping themes around debt issuance, which could cause minor confusion. The detailed descriptions help clarify, but the sheer number of tools increases the risk of misselection in closely related areas.
Naming Consistency5/5
All tools follow a consistent snake_case naming pattern with a 'get_' prefix, except for search_financial_notes which uses 'search_' but maintains the same style. This uniformity makes the tool set predictable and easy to navigate, with no deviations in verb usage or formatting that would hinder agent interpretation.
Tool Count2/5
With 85 tools, the count is excessive for a single server, likely overwhelming for agents and leading to inefficiency. While the domain of corporate financial disclosures is broad, many tools could be consolidated (e.g., multiple tools for executive compensation or treasury stock). This heavy toolset feels bloated and difficult to manage effectively.
Completeness5/5
The tool set provides comprehensive coverage for corporate financial disclosures and risk analysis, including tools for data retrieval (e.g., get_corporation_code), financial events (e.g., get_bankruptcy), governance (e.g., get_executive_info), and analysis (e.g., get_single_index). There are no obvious gaps; agents can access everything from basic company info to detailed financial notes and risk assessments.
Average 2.4/5 across 85 of 85 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but fails to disclose behavioral traits. It doesn't indicate whether this is a read-only query, what data format it returns, potential rate limits, authentication needs, or error conditions. The description is purely conceptual without operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single Korean sentence that's reasonably concise, but it's not front-loaded with operational clarity. While brief, it prioritizes conceptual framing over actionable information that would help an agent invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 required parameters (0% schema coverage), no annotations, no output schema, and complex financial analysis purpose, the description is completely inadequate. It provides conceptual context but no operational information needed to select or invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so all 4 parameters (corp_code, bsns_year, reprt_code, idx_cl_code) are undocumented in the schema. The description provides no information about what these parameters mean, their expected formats, or how they affect the analysis. It completely fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '그룹 단위의 주요 재무지표 분석을 통한 계열사 리스크 및 성장성 평가' (Group-level key financial indicator analysis for affiliate risk and growth evaluation) states a general purpose but lacks a specific verb and doesn't distinguish from siblings like 'get_single_index'. It's vague about what the tool actually does operationally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 'get_single_index' or other financial data tools. There's no mention of prerequisites, exclusions, or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. However, it only describes an abstract analysis purpose without stating whether this is a read operation, what data it returns, any rate limits, authentication needs, or side effects. For a tool with three required parameters and no output schema, this lack of behavioral information is a significant gap, making it unclear how the tool behaves or what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Korean, which is efficient in length. However, it's front-loaded with abstract terminology rather than clear action, reducing its effectiveness. While not verbose, it lacks structural clarity that would aid understanding, such as separating purpose from context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the description (involving analysis of capital reduction and risk strategies), three required parameters, no annotations, and no output schema, the description is highly incomplete. It fails to explain what the tool returns, how the analysis is performed, or any behavioral aspects, leaving critical gaps for the agent to understand and use the tool effectively.
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?
The input schema has 100% description coverage, clearly documenting each parameter (corp_code, bgn_de, end_de) with examples and types. The description adds no additional meaning about parameters, such as how they influence the analysis or any constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '감자 결정을 통한 자본 축소 목적 및 경영 리스크 대응 전략 분석' (Analysis of capital reduction purposes through capital reduction decisions and management risk response strategies) is vague and abstract. It describes a type of analysis rather than specifying what the tool actually does (e.g., retrieve, list, or generate reports). While it mentions 'capital reduction,' it doesn't clearly state the action the tool performs, making it difficult to distinguish from sibling tools like get_dividend_info or get_stock_total that might involve financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention any prerequisites, context, or exclusions, and with many sibling tools related to corporate financial data (e.g., get_dividend_info, get_equity), there's no indication of how this tool differs or when it's appropriate. This leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. However, it only describes an analytical outcome without stating what the tool does operationally (e.g., fetches data, generates reports). It lacks information on permissions, rate limits, data sources, or response format, leaving the agent with no understanding of how the tool behaves or its safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase that is overly broad and lacks structure. It fails to front-load key information about the tool's action, instead focusing on abstract outcomes. While concise, it under-specifies the tool's purpose, making it inefficient for quick understanding by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the description (involving business restructuring and risk analysis), no annotations, no output schema, and incomplete behavioral disclosure, the description is highly inadequate. It does not provide enough context for an agent to understand what the tool returns, how to interpret results, or its operational constraints, failing to meet minimal completeness standards.
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 100%, with clear descriptions for 'corp_code', 'bgn_de', and 'end_de'. The description does not add any meaning beyond the schema, such as explaining parameter relationships or usage context. Since the schema is comprehensive, the baseline score of 3 is appropriate, as the description neither compensates nor detracts from parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '회사분할 결정을 통한 사업 구조 재편 및 상장 우회 리스크 분석' (Business restructuring through corporate division decisions and analysis of listing bypass risks) states a high-level outcome but lacks a specific verb indicating what the tool actually does (e.g., retrieve, list, analyze). It does not clearly distinguish from siblings like 'get_division_merger' or 'get_division_report', making it vague about the tool's function beyond the topic of corporate divisions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions, and with many sibling tools related to corporate events (e.g., 'get_merger', 'get_business_transfer'), there is no indication of how this tool differs or when it is appropriate, leading to potential misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 fails completely. It describes an analytical concept rather than tool behavior - it doesn't indicate whether this is a read operation, what data format it returns, whether it requires authentication, has rate limits, or any other behavioral traits. The abstract description provides zero practical guidance about how the tool actually behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (one sentence), the description is under-specified rather than efficiently informative. It uses abstract strategic language that doesn't serve the practical purpose of helping an AI agent understand and invoke the tool. The single sentence fails to convey actionable information about the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the tool name (foreign listing data retrieval), no annotations, no output schema, and 3 required parameters, the description is completely inadequate. It should explain what data is returned, the tool's purpose in practical terms, and behavioral characteristics. Instead, it provides only an abstract analytical concept that offers no operational guidance for tool invocation.
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 100%, so the schema already fully documents all three parameters (corp_code, bgn_de, end_de) with clear descriptions and examples. The tool description adds no parameter information beyond what's in the schema, which meets the baseline expectation when schema coverage is complete. No additional parameter context is provided or needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '해외증권시장 상장을 통한 글로벌 시장 진출 전략 및 자금조달 구조 분석' (Global market entry strategy and funding structure analysis through foreign securities market listing) is vague and abstract. It describes a strategic analysis concept rather than specifying what the tool actually does (e.g., retrieves data about foreign listings). It doesn't clearly state the verb+resource action, making it difficult to distinguish from sibling tools like get_foreign_delisting or get_foreign_listing_decision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There are multiple related tools in the sibling list (get_foreign_delisting, get_foreign_listing_decision, get_disclosure_list, etc.), but the description offers no comparison, prerequisites, or context about appropriate use cases. This leaves the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but fails completely. It doesn't indicate whether this is a read operation, what data format it returns, whether it has side effects, rate limits, authentication requirements, or error conditions. The description is purely about the analysis topic rather than the tool's operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single Korean phrase that's technically concise but fails to communicate essential information. While it's not verbose, this conciseness comes at the cost of clarity - the description is too brief to be helpful. It doesn't follow the principle of front-loading critical information about the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 required parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool returns, how to interpret results, error conditions, or operational constraints. The description focuses on the analysis topic rather than providing the contextual information needed to use the tool effectively.
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?
The schema description coverage is 100%, with all three parameters clearly documented in the input schema (corp_code, bgn_de, end_de). The description adds no parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '합병 결정을 통한 지배구조 재편 및 소액주주 보호 리스크 분석' (Analysis of governance restructuring and minority shareholder protection risks through merger decisions) describes the analysis domain but doesn't specify what the tool actually does. It's vague about whether this retrieves data, performs calculations, or generates reports. The description focuses on the subject matter rather than the tool's function, making it difficult to distinguish from sibling tools like get_merger_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts, or comparison with similar tools like get_merger_report or get_division_merger. The agent receives no usage instructions beyond what can be inferred from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. However, it only states an analytical purpose without describing the tool's behavior—such as whether it returns data, performs calculations, requires authentication, has rate limits, or what format the output takes. This lack of information makes it inadequate for understanding how the tool operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Korean, which is efficient in length. However, it is not front-loaded with actionable information—it focuses on analysis rather than function, and the structure does not prioritize clarity. While not verbose, it lacks the effective organization needed for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the analytical purpose, lack of annotations, and no output schema, the description is incomplete. It fails to explain what the tool returns, how the analysis is performed, or any behavioral context, leaving significant gaps. For a tool with three parameters and no structured output, this description does not provide enough information for effective use.
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?
The input schema has 100% description coverage, clearly documenting the three required parameters (corp_code, bgn_de, end_de) with examples. The description adds no parameter-specific information beyond the schema, so it neither compensates nor detracts. According to the rules, with high schema coverage (>80%), the baseline score is 3, as the schema handles the parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '타법인 주식 양도를 통한 자산 유동화 및 사업 철수 신호 분석' (Analysis of asset liquidity and business withdrawal signals through other corporation stock transfers) states a high-level analytical purpose but lacks a clear action verb and specific resource. It describes what the tool analyzes rather than what it does (e.g., retrieve, list, or fetch data), making it vague compared to sibling tools like 'get_other_corp_stock_acquisition' which imply data retrieval. This is closer to a tautology of the name than a functional description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It does not mention any context, prerequisites, or exclusions, and with many sibling tools (e.g., 'get_other_corp_stock_acquisition', 'get_asset_transfer'), there is no indication of how this tool differs or when it should be selected, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. However, it fails to describe what the tool does operationally—whether it fetches data, performs calculations, returns reports, or has side effects. It doesn't mention permissions, rate limits, data sources, or output format. The description is purely conceptual without practical behavioral details, making it inadequate for agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase in Korean, which is concise but under-specified. It lacks structure—no separation of purpose, usage, or behavior. While brief, it fails to convey essential information efficiently, as every word doesn't earn its place in guiding the agent. It reads more like a topic title than a functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent complexity (analysis of financial structures), lack of annotations, and no output schema, the description is severely incomplete. It doesn't explain what the tool returns, how the analysis is performed, or any behavioral context. For a tool with three required parameters and no structured output guidance, this description leaves critical gaps for agent understanding and invocation.
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 100%, with clear descriptions for 'corp_code', 'bgn_de', and 'end_de'. The description adds no parameter-specific information beyond the schema, such as how these inputs relate to the analysis or any constraints. Since the schema handles parameter documentation well, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '유상증자를 통한 자금조달 구조와 지분 희석 및 재무구조 개선 의도 분석' (Analysis of funding structure through paid-in capital increase, share dilution, and financial structure improvement intent) states a general analytical purpose but lacks a specific action verb. It doesn't clearly indicate whether this tool retrieves, calculates, or generates such analysis, making it vague. The tool name 'get_paid_in_capital_increase' suggests retrieval, but the description doesn't confirm this or distinguish it from sibling tools like 'get_free_capital_increase' or 'get_paid_free_capital_increase'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention prerequisites, context for analysis, or differentiate from similar tools in the sibling list (e.g., 'get_free_capital_increase', 'get_paid_free_capital_increase'). There's no indication of when this analysis is appropriate or what scenarios it applies to, leaving usage entirely ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but fails completely. It doesn't indicate whether this is a read or write operation, what permissions might be required, what format the output takes, whether there are rate limits, or any other behavioral characteristics. The description is purely about the subject matter, not the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (one sentence), the description is under-specified and fails to communicate essential tool functionality. It's not appropriately front-loaded with the tool's purpose, and the single sentence doesn't earn its place by providing actionable information for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool returns, what format the output takes, or even clearly state that it retrieves or generates reports. The description is more like a topic header than a functional tool description.
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?
The schema has 100% description coverage, providing clear documentation for all three required parameters (corp_code, bgn_de, end_de). The description adds no parameter information beyond what's already in the schema, so it meets the baseline of 3. However, it doesn't compensate for any gaps since there are none in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a vague statement about analyzing governance restructuring and minority shareholder protection risks through stock exchange/transfer conditions, rather than clearly stating what the tool does. It doesn't specify the action (retrieve, generate, analyze) or what resource it operates on. While it hints at stock exchange reports, it's more of a topic description than a functional tool description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 many sibling tools available. There's no mention of alternatives, prerequisites, or specific scenarios where this tool would be appropriate. Given the extensive list of sibling tools (including get_stock_exchange, get_stock_total, etc.), this lack of differentiation is particularly problematic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. However, it only mentions analysis of strategies and possibilities, which doesn't clarify whether this is a read-only data retrieval tool, a computational analysis, or something else. It fails to describe what the tool returns (e.g., raw data, analysis results), any side effects, or operational constraints like rate limits or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but is overly verbose and abstract, using complex terms like '주가 방어 전략' (stock price defense strategy) without getting to the point. It fails to front-load the core function, making it inefficient for quick understanding. While not lengthy, it lacks structural clarity and wastes space on vague analytical goals instead of stating the tool's action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the description (analysis of strategies and possibilities), no annotations, and no output schema, the description is highly incomplete. It doesn't explain what the tool returns, how the analysis is performed, or any behavioral aspects. For a tool with three parameters and analytical claims, this leaves critical gaps in understanding its functionality and output.
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?
The input schema has 100% description coverage, with clear parameter descriptions (e.g., '고유번호 (8자리)' for corp_code). The tool description adds no additional information about parameters, such as their role in the analysis or format specifics beyond the schema. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '자기주식 취득 결정을 통한 주가 방어 전략 및 경영권 방어 가능성 분석' (Analysis of stock price defense strategy and management control defense possibility through treasury stock acquisition decisions) is vague about what the tool actually does. It describes an analytical purpose rather than specifying the action (e.g., 'retrieve data about treasury stock acquisitions'). It doesn't clearly state whether this tool fetches, lists, or analyzes data, making it difficult to distinguish from sibling tools like 'get_treasury_stock' or 'get_treasury_stock_disposal'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools (e.g., how it differs from 'get_treasury_stock' or 'get_treasury_stock_disposal'). This leaves the agent with no information to make an informed selection among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. However, it doesn't mention whether this is a read-only operation, if it requires authentication, what data sources it uses, potential rate limits, or the format of results. It fails to describe any operational behavior beyond the vague domain context, leaving critical usage information unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single Korean phrase that is overly concise to the point of being underspecified. While it's brief, it lacks necessary structural elements like stating the tool's action or purpose clearly. It doesn't front-load key information, making it inefficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the tool name and description (involving financial analysis), lack of annotations, and no output schema, the description is highly incomplete. It doesn't explain what the tool returns, how it processes inputs, or any behavioral context, making it inadequate for effective use by an AI agent.
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?
The input schema has 100% description coverage, with clear parameter descriptions (e.g., 'corp_code' as an 8-digit unique identifier, date formats for 'bgn_de' and 'end_de'). The tool description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline score of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '상각형 조건부자본증권 발행을 통한 재무구조 보완 및 잠재적 상각 리스크 분석' which translates to 'Strengthening financial structure through issuance of write-down contingent capital securities and analyzing potential write-down risks.' This describes a domain/context rather than specifying what the tool actually does (e.g., retrieve, calculate, or analyze data). It doesn't clearly state the action the tool performs, making it vague about its actual function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention any prerequisites, context, or comparison to sibling tools like 'get_conditional_capital_securities_outstanding' or 'get_debt_securities_issued', which might be related. There's no indication of appropriate scenarios or exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. The description mentions '리스크 분석' (risk analysis) which suggests analytical processing, but doesn't clarify whether this is a read-only data retrieval tool, what format the output takes, whether it requires authentication, or any rate limits. For a tool with no annotation coverage, this minimal description fails to provide essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is technically concise (one sentence), it's under-specified rather than efficiently informative. The single sentence is abstract and doesn't front-load practical information about the tool's function. It fails to earn its place by providing actionable guidance to an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the tool name (executive compensation approval data), no annotations, and no output schema, the description is inadequate. It should explain what data is returned, in what format, and how it differs from related compensation tools. The abstract analytical framing doesn't provide the completeness needed for an AI agent to understand and use this tool effectively.
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 100%, with all three parameters clearly documented in the input schema. The description adds no parameter-specific information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description. The description doesn't compensate for any gaps because there are none in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '주총 승인 보수 한도를 통한 보상 지배구조 및 집행 투명성 리스크 분석' (Analysis of compensation governance and execution transparency risks through shareholder-approved compensation limits) is vague and abstract rather than stating a clear action. It describes an analytical purpose rather than specifying what the tool actually does (likely retrieves executive compensation approval data). This is essentially a tautology that restates the tool name 'get_executive_compensation_approved' in analytical terms without providing operational clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With multiple sibling tools related to executive compensation (get_executive_compensation_by_type, get_individual_compensation, get_total_compensation, get_unregistered_exec_compensation), there is no indication of how this tool differs or when it should be preferred. The description fails to establish any context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The description fails to disclose any behavioral traits - it doesn't indicate whether this is a read-only query, what format the results might be in, whether there are rate limits, authentication requirements, or any other operational characteristics. For a tool with no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that's relatively concise, but it's front-loaded with complex terminology without establishing the basic purpose first. While not verbose, it could be more effectively structured to communicate the core function before diving into analysis details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It describes the subject matter but doesn't explain what the tool returns, how results are formatted, or any operational constraints. For a tool with 3 required parameters and no structured output documentation, the description should provide more context about what users can expect.
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 100%, so the schema already documents all three parameters (corp_code, bgn_de, end_de) with their descriptions and formats. The description adds no additional parameter information beyond what's in the schema, which meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '자산양수도 및 풋백옵션 계약을 통한 경영전략 변화 및 추가 부채 리스크 분석' which translates to 'Analysis of management strategy changes and additional debt risks through asset transfer and putback option contracts.' This is vague about what the tool actually does - it describes the subject matter but doesn't specify the action (retrieve? analyze? calculate?). It doesn't clearly distinguish from siblings like get_business_transfer or get_tangible_asset_transfer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With many sibling tools related to corporate actions and disclosures, there's no indication of what makes this tool distinct or when it should be selected over similar tools like get_business_transfer or get_tangible_asset_transfer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. However, the description is purely abstract and doesn't reveal any behavioral traits—it doesn't indicate whether this is a read or write operation, what data it returns, error conditions, rate limits, authentication needs, or side effects. It fails to provide actionable information about how the tool behaves when invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence in Korean that packs abstract concepts but lacks clarity. While concise in length, it's not effectively structured—it doesn't front-load key information or break down ideas for readability. The sentence attempts to convey purpose but does so inefficiently, making it harder to parse than a more direct statement would be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the tool name and abstract description, along with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what data is returned, how results are formatted, or the tool's operational behavior. For a tool with three required parameters and likely returning structured data, more context is needed to guide effective use, especially without annotations to fill gaps.
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?
The input schema has 100% description coverage, with clear documentation for each parameter (corp_code, bgn_de, end_de). The description adds no parameter-specific information beyond what the schema provides, such as explaining how these parameters relate to the tool's purpose. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract from the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '채권자 관리절차 개시를 통한 기업의 구조조정 진행 및 유동성 위기 분석' translates to 'Analysis of corporate restructuring progress and liquidity crisis through initiation of creditor management procedures.' This is vague and abstract rather than specifying a concrete action like 'retrieve creditor management initiation data.' It doesn't clearly state what the tool actually does operationally, and while it hints at analysis, it doesn't distinguish this tool from its sibling 'get_creditor_management_termination' in terms of function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention the sibling tool 'get_creditor_management_termination' or any other related tools, nor does it specify prerequisites, appropriate contexts, or exclusions. Users are left to infer usage from the abstract description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. The description fails to indicate whether this is a read-only data retrieval tool, an analytical tool that performs calculations, or something else. It doesn't mention authentication requirements, rate limits, potential side effects, or what kind of output to expect. For a tool with no annotation coverage, this represents a complete failure to disclose behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase that's appropriately concise, but it's not front-loaded with the most critical information. While it doesn't waste words, it also doesn't efficiently communicate the tool's purpose. The structure could be improved by starting with a clear verb-action statement rather than a conceptual description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's no output schema and no annotations, the description should provide more complete context about what this tool does and returns. The description is conceptually oriented rather than functional, leaving significant gaps in understanding how to use the tool effectively. For a tool with 3 parameters and no structured output documentation, the description is insufficiently 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?
The input schema has 100% description coverage, with clear documentation for all three required parameters (corp_code, bgn_de, end_de). The description doesn't add any meaningful parameter information beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no parameter information in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '분할합병 결정을 통한 사업 재편 및 합병 공정성 리스크 분석' (Business restructuring through division-merger decisions and merger fairness risk analysis) is vague about what the tool actually does. It describes a domain concept rather than specifying a concrete action like 'retrieve division-merger reports' or 'analyze merger fairness risks'. The description doesn't clearly state whether this tool retrieves data, performs analysis, or generates reports, making it difficult for an agent to understand its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There are multiple sibling tools related to corporate actions (get_division, get_merger, get_merger_report, get_division_report, get_business_acquisition, etc.), but the description doesn't help differentiate this tool's specific use case from those related tools. An agent would have no basis for choosing this tool over similar alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description fails to indicate whether this is a read-only operation, what data format it returns, if there are rate limits, authentication requirements, or potential side effects. It only states an analytical purpose without describing the tool's behavior or output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise but under-specified. While it's not verbose, it fails to convey essential tool functionality, making it inefficient in terms of information density. Every sentence should earn its place, and this one provides minimal actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the tool name (retrieving foreign listing decisions), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how results are structured, or any behavioral aspects. For a tool with three required parameters and no structured output documentation, the description should provide more context about the operation and results.
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 100%, with all three parameters (corp_code, bgn_de, end_de) clearly documented in the input schema. The description adds no additional parameter information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even without param details in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '해외상장 결정을 통해 자금조달 전략 및 글로벌 리스크 요인 분석' (Analysis of funding strategies and global risk factors through foreign listing decisions) describes an outcome or purpose rather than what the tool actually does. It doesn't specify the action (e.g., 'retrieve', 'fetch', 'get') or the resource (e.g., 'foreign listing decisions', 'documents'). The tool name 'get_foreign_listing_decision' suggests it retrieves data, but the description is vague about the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention any prerequisites, context for usage, or differentiate from sibling tools like 'get_foreign_listing' or 'get_foreign_delisting_decision'. Without such guidance, an agent cannot make informed decisions about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It fails to describe any behavioral traits: it doesn't indicate if this is a read-only query, what data format it returns, whether it requires authentication, or if there are rate limits. The abstract analytical language offers no practical insight into how the tool behaves when invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence in Korean that packs abstract concepts but lacks clarity. While concise in length, it's inefficiently front-loaded with analytical jargon rather than stating the tool's function upfront. It could be restructured to prioritize actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and no output schema, the description is incomplete. It fails to address key contextual needs: what the tool returns (e.g., compensation amounts, risk scores), how it differs from similar tools, or any behavioral constraints. For a tool with no structured support beyond input schema, the description leaves significant gaps.
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 100%, with clear descriptions for corp_code, bsns_year, and reprt_code. The description adds no parameter semantics beyond what the schema provides—it doesn't explain how these inputs relate to 'compensation imbalance analysis' or provide usage examples. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '고액 수령자 중심 임원 보수 정보를 통한 보상 불균형 및 지배구조 리스크 분석' (Analysis of compensation imbalance and governance risks through high-earner executive compensation information) is vague and abstract. It describes an analytical outcome rather than stating what the tool actually does (e.g., retrieves, calculates, or lists specific compensation data). It restates concepts from the tool name 'get_individual_compensation_amount' without clarifying the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention any sibling tools (e.g., get_individual_compensation, get_executive_compensation_approved, get_total_compensation) or specify contexts where this tool is appropriate. There are no prerequisites, exclusions, or comparisons to help an agent select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. The description fails to mention that this is a read operation (implied by 'get'), what data format it returns, whether it has pagination/limits, or any authentication requirements. For a tool with 3 required parameters and no annotation coverage, this lack of behavioral information is critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single Korean phrase that's appropriately brief. However, it's not front-loaded with functional information - it leads with analytical outcomes rather than the tool's core purpose. While concise, the structure doesn't prioritize what the agent needs most: understanding what the tool actually does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 required parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what kind of lawsuit data is returned, the format, or any limitations. The analytical framing in the description doesn't compensate for missing operational details that an agent needs to invoke the tool effectively.
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 100%, with clear parameter descriptions in Korean. The tool description adds no parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description. The description doesn't compensate or add context about how these parameters relate to lawsuit retrieval.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '소송 제기 사실을 통한 경영권 분쟁 및 재무 리스크 조기 분석' (Early analysis of management disputes and financial risks through lawsuit filing facts) is vague and abstract. It describes an analytical outcome rather than the tool's actual function. The tool name 'get_lawsuit' suggests retrieving lawsuit data, but the description doesn't clearly state this as a data retrieval operation. It's more of a value proposition than a functional description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides zero guidance on when to use this tool versus the many sibling tools (e.g., get_bankruptcy, get_merger, get_disclosure_document). It doesn't mention prerequisites, alternative tools for similar data, or specific use cases. The agent would have no basis for choosing this tool over others without trial and error.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description mentions 'risk analysis' which suggests some processing or interpretation, but doesn't clarify whether this is a read-only data retrieval or an analytical computation. It provides no information about permissions needed, rate limits, response format, or any behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single Korean phrase that's relatively concise, but it's not structured or front-loaded with the most critical information. While brief, it fails to efficiently communicate the tool's purpose and instead presents an abstract concept that requires interpretation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, what format the output takes, or how the 'risk analysis' manifests in practice. Given the complexity implied by the description and the lack of structured metadata, the description should provide much more context about the tool's behavior and outputs.
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 100%, with all three parameters clearly documented in the schema itself. The description adds no parameter information beyond what's already in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '사외이사 현황을 통한 이사회 독립성과 지배구조 감시 기능 리스크 분석' translates to 'Risk analysis of board independence and governance monitoring function through outside director status.' This is vague and abstract - it doesn't specify what the tool actually does (retrieve data? analyze? generate report?) or what resource it operates on. It restates the tool name concept rather than providing a clear action statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides zero guidance on when to use this tool versus the 70+ sibling tools. There's no mention of alternatives, prerequisites, or specific scenarios where this tool is appropriate. Given the extensive sibling tool list covering various corporate governance and financial topics, this lack of differentiation is particularly problematic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. However, it fails to describe what the tool does operationally—whether it's a read-only query, a computational analysis, or something else. It doesn't mention permissions, rate limits, output format, or any side effects. The abstract language offers no practical behavioral insights for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence in Korean that packs abstract concepts but lacks structural clarity. While concise in length, it's not front-loaded with actionable information—it leads with analytical jargon rather than a clear tool purpose. The sentence earns its place by attempting to convey scope, but the abstraction reduces practical utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (implied by the abstract description) and lack of annotations or output schema, the description is incomplete. It doesn't explain what the tool returns, how results are structured, or any behavioral traits. For a tool with three parameters and no structured output documentation, the description should provide more operational context to compensate, which it fails to do.
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?
The input schema has 100% description coverage, clearly documenting all three required parameters (corp_code, bgn_de, end_de) with examples. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even without param details in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '유무상증자 병행 결정을 통한 복합 자본 전략 및 지배구조 재편 가능성 분석' (Analysis of complex capital strategy and governance restructuring possibilities through concurrent paid/free capital increase decisions) is vague and abstract rather than stating a clear action. It describes an analytical purpose but doesn't specify what the tool actually does (e.g., retrieves data, generates reports, or performs calculations). The name 'get_paid_free_capital_increase' suggests data retrieval, but the description doesn't confirm this with a specific verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention any sibling tools (like 'get_free_capital_increase' or 'get_paid_in_capital_increase') that might handle similar data, nor does it specify prerequisites, appropriate contexts, or exclusion criteria. Users must infer usage from the abstract description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. The description mentions 'analysis' but doesn't specify whether this tool performs calculations, returns raw data, or generates reports. It doesn't disclose any behavioral traits like whether it's read-only, has side effects, requires authentication, or has rate limits. For a tool with no annotations, this is completely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that's reasonably concise, but it's not front-loaded with the most critical information. It focuses on the analysis purpose rather than the core function. While not verbose, it doesn't efficiently communicate what the tool does in a way that helps an AI agent understand its practical use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description should provide more complete context about what this tool returns and how it behaves. The description mentions 'analysis' but doesn't specify the format or nature of the results. For a tool with 3 required parameters and no structured output documentation, the description is insufficient to help an agent understand what to expect from invoking this tool.
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 100%, so the schema already fully documents all three parameters (corp_code, bsns_year, reprt_code) with clear descriptions and examples. The description adds no additional parameter information beyond what's in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '단기사채 미상환 내역을 통한 단기 자금조달 구조 및 유동성 리스크 분석' which translates to 'Analysis of short-term funding structure and liquidity risk through short-term bond outstanding details.' This is tautological - it essentially restates the tool name 'get_short_term_bond_outstanding' with added analysis context. While it mentions analysis, it doesn't clearly specify what the tool actually does (e.g., retrieves, calculates, or returns data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. Among the many sibling tools (e.g., get_commercial_paper_outstanding, get_corporate_bond_outstanding, get_debt), there's no indication of how this tool differs or when it should be selected. The description is purely about what the tool analyzes, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 fails completely. It doesn't indicate whether this is a read operation, what data format it returns, whether it requires authentication, has rate limits, or any other behavioral characteristics. The description only states an analytical purpose without operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single Korean sentence that's reasonably concise, but it's not front-loaded with the most critical information. While it doesn't waste words, it fails to prioritize operational details over analytical purpose, making it less effective for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It should explain what the tool actually does operationally, what data it returns, and how it differs from similar compensation tools. The current description focuses on analytical outcomes rather than tool functionality.
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 100%, providing good documentation for all three parameters (corp_code, bsns_year, reprt_code). The description adds no parameter information beyond what the schema already provides, so it meets but doesn't exceed the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '전체 임원 보수 총액을 통한 보상 구조의 투명성과 집중도 리스크 분석' (Analysis of compensation structure transparency and concentration risk through total executive compensation amount) states a high-level analytical purpose but lacks a specific action verb. It doesn't clearly indicate whether this tool retrieves, calculates, or analyzes data, making it vague compared to sibling tools like get_executive_compensation_approved which have clearer retrieval purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention prerequisites, appropriate contexts, or differentiate from sibling tools like get_individual_compensation or get_executive_compensation_by_type, leaving the agent with no usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It implies this is a read-only tool for risk assessment but doesn't specify whether it queries a database, requires authentication, has rate limits, returns structured data, or handles errors. The description focuses on the evaluation purpose rather than the tool's operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence in Korean that packs multiple concepts (business unit suspension, profitability deterioration, corporate survival risk, evaluation). While concise, it's not front-loaded with the tool's primary action and could be more structured to separate purpose from context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 required parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., suspension records, risk scores, or raw data), how results are formatted, or any limitations. The focus on evaluation rather than data retrieval leaves significant gaps for an AI agent to understand the tool's function.
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 100%, with clear parameter descriptions in Korean. The description doesn't add any parameter-specific information beyond what's in the schema (corp_code, bgn_de, end_de). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description could have explained how these parameters relate to the risk evaluation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '사업부문 단위 영업정지를 통한 수익성 악화 및 기업 존속 리스크 평가' (Evaluation of profitability deterioration and corporate survival risk through business unit suspension) describes the tool's purpose in vague, outcome-oriented terms rather than specifying the action it performs. It doesn't clearly state that this tool retrieves or fetches suspension data, making it difficult to distinguish from siblings that also retrieve corporate information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention prerequisites, appropriate contexts, or how it differs from other data retrieval tools in the sibling list like get_bankruptcy or get_dissolution, which might relate to corporate risk assessment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description mentions 'analysis' but doesn't clarify whether this is a read-only data retrieval tool (as the 'get_' prefix suggests) or a computational analysis tool. It doesn't disclose what format the results come in, whether there are rate limits, authentication requirements, or any other behavioral characteristics. The analytical focus in the description creates ambiguity about the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence in Korean that packs multiple concepts (convertible bond issuance decisions, financing strategy, shareholder value dilution risk analysis). While concise in length, it's conceptually overloaded and lacks clear structure. The front-loading is adequate but the content is too abstract for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 required parameters, no annotations, and no output schema, the description is inadequate. It doesn't clarify what the tool actually does (retrieve vs analyze), what format results come in, or how it differs from similar tools. The analytical focus creates more questions than answers about the tool's functionality and expected outputs.
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 100%, with all three parameters (corp_code, bgn_de, end_de) well-described in the schema. The description adds no parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '전환사채 발행 결정을 통한 자금조달 전략 및 주주가치 희석 리스크 분석' (Analysis of financing strategy through convertible bond issuance decisions and shareholder value dilution risk) describes the tool's analytical purpose but doesn't specify the action the tool performs. It's unclear whether this tool retrieves, calculates, or analyzes data about convertible bonds. The name 'get_convertible_bond' suggests a retrieval function, but the description focuses on analysis rather than the tool's actual operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With 75+ sibling tools on the server including related tools like get_bond_with_warrant, get_exchangeable_bond, and get_corporate_bond_outstanding, there's no indication of how this tool differs or when it should be selected over similar bond-related tools. No context about appropriate use cases is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. While it mentions 'analysis' which suggests some processing, it doesn't clarify whether this is a read-only query, a computational analysis, or something else. It provides no information about permissions needed, rate limits, response format, or potential side effects. The description is too vague to adequately inform the agent about how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, moderately long sentence in Korean. While not excessively verbose, it's not particularly well-structured or front-loaded with the most critical information. The description could be more efficiently organized to first state the tool's function before elaborating on the analysis context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a 3-parameter tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns, what format the analysis takes, or provide sufficient behavioral context. For a tool that appears to perform some kind of analysis (implied by the description), more information about the output and processing behavior would be expected.
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?
The input schema has 100% description coverage, with clear documentation for all three required parameters (corp_code, bgn_de, end_de). The description adds no additional parameter information beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology that essentially restates the tool name 'get_foreign_delisting' in Korean as '해외증권시장 상장폐지를 통한 해외사업 축소 및 자본구조 변동성 리스크 분석' (analysis of overseas business reduction and capital structure volatility risk through foreign securities market delisting). It doesn't specify what the tool actually does (e.g., retrieve data, generate reports, or perform analysis). The description focuses on the subject matter rather than the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention any sibling tools (like 'get_foreign_delisting_decision' or 'get_foreign_listing') that might be related, nor does it specify prerequisites, appropriate contexts, or limitations for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 hints at analytical output but fails to specify whether this is a read-only query, what data format or granularity is returned, any rate limits, or authentication needs. For a tool with three required parameters and no output schema, this lack of operational detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence in Korean that packs abstract concepts but lacks structural clarity. While concise in length, it's not front-loaded with actionable information and could benefit from breaking down the tool's function more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (three required parameters, no output schema, no annotations), the description is inadequate. It doesn't explain what the tool returns, how the analysis is presented, or any limitations. For a data retrieval tool in a financial context, this leaves too many unknowns for effective agent use.
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?
The input schema has 100% description coverage, clearly documenting each parameter (corp_code, bsns_year, reprt_code) with examples and enum values. The description adds no additional parameter context beyond the schema, so the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '공모자금 사용 계획과 집행 내역을 통한 자금 운용 투명성과 전용 리스크 분석' (translated: 'Analysis of fund operation transparency and diversion risk through public fund usage plans and execution details') is vague and abstract rather than stating a clear action. It describes an analytical purpose but doesn't specify what the tool actually does (e.g., retrieve, calculate, or report data). This is closer to a tautology of the tool name 'get_public_capital_usage' than a functional description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 many sibling tools (e.g., get_private_capital_usage, get_corporation_info, get_disclosure_document). It doesn't mention prerequisites, alternatives, or specific contexts for application, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While it mentions '리스크 분석' (risk analysis), it doesn't clarify whether this tool performs analysis or simply retrieves data for analysis elsewhere. There's no information about permissions, rate limits, response format, or whether this is a read-only operation versus something that triggers analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single Korean phrase that's reasonably concise, but it's conceptually dense rather than operationally clear. While not verbose, it fails to efficiently communicate the tool's function. The structure doesn't front-load the most critical information about what the tool actually does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what kind of data is returned, what format it's in, or how the 'risk analysis' mentioned relates to the retrieved data. The description leaves too many operational questions unanswered for effective tool selection and invocation.
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 100%, with all three parameters clearly documented in the schema itself (corp_code, bgn_de, end_de). The description adds no parameter-specific information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '주식 관련 사채권 양수를 통한 지분 확보 전략 및 내부거래 리스크 분석' (Stock-related bond acquisition strategy for equity securing and internal transaction risk analysis) is vague about what the tool actually does. It describes a strategic analysis concept rather than stating a clear action like 'retrieve' or 'analyze' specific data. The name 'get_stock_related_bond_acquisition' suggests a data retrieval function, but the description doesn't clearly confirm this operational purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With 80+ sibling tools including related ones like 'get_stock_related_bond_transfer' and 'get_other_corp_stock_acquisition,' there's no indication of what distinguishes this tool's functionality or appropriate use cases. The description fails to help an agent choose between similar-looking tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'analysis' which suggests a read operation, but doesn't clarify if this is a query, report generation, or data retrieval. It fails to disclose critical behavioral aspects like whether it's a safe read operation, what format the output takes, if there are rate limits, or if special permissions are required for the analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that's reasonably concise, but it's front-loaded with abstract concepts rather than concrete functionality. While not verbose, it could be more structured to first state what the tool returns before describing its analytical purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool actually returns (data, report, analysis results), the format of output, or how the 'analysis' is performed. Users cannot understand what to expect from invoking this tool beyond the abstract purpose statement.
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 100%, so the schema already documents all three parameters (corp_code, bgn_de, end_de) with clear descriptions. The tool description adds no additional parameter information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes 'asset structure changes and related-party transaction risks through tangible asset acquisition decisions', which provides some purpose but is vague and abstract. It doesn't specify what the tool actually returns (e.g., a report, data points, analysis results) or what 'analysis' entails. Compared to sibling tools like 'get_tangible_asset_transfer' which clearly retrieves specific data, this description lacks concrete action verbs and resource specification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention any prerequisites, timing considerations, or how it differs from related tools like 'get_tangible_asset_transfer' or 'get_business_acquisition'. Users must infer usage from the abstract description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. The description vaguely hints at analysis ('리스크 분석' - risk analysis) but doesn't clarify whether this tool performs read-only data retrieval, computational analysis, or something else. It lacks details on permissions, rate limits, output format, or any behavioral traits, leaving significant gaps for an AI agent to understand how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence in Korean that packs abstract concepts but lacks clarity. While concise in length, it's not front-loaded with actionable information and could benefit from restructuring to state the tool's purpose more directly. It's neither overly verbose nor efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the description (involving analysis) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns, how results are structured, or any behavioral aspects. For a tool with three required parameters and no structured output information, more context is needed to guide effective use.
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 100%, with clear descriptions for each parameter (corp_code, bgn_de, end_de). The description adds no additional parameter semantics beyond what the schema provides, such as explaining relationships between parameters or usage examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '유형자산 양도 결정을 통한 유동성 확보 및 구조조정 리스크 분석' (Liquidity securing and restructuring risk analysis through tangible asset transfer decisions) is vague and abstract rather than specifying a concrete action. It describes potential outcomes or analyses rather than stating what the tool actually does (e.g., retrieve, list, or analyze specific data). While it mentions 'tangible asset transfer,' it doesn't clearly distinguish this from sibling tools like 'get_asset_transfer' or 'get_tangible_asset_acquisition,' leading to ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention any prerequisites, context for application, or comparisons to sibling tools such as 'get_asset_transfer' or 'get_tangible_asset_acquisition.' Without this, an AI agent cannot determine appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. However, it only mentions strategic analysis and risk assessment, which are high-level outcomes, without describing the tool's actual behavior—such as whether it returns raw data, performs calculations, requires authentication, has rate limits, or is read-only. This leaves critical operational traits unspecified.
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, concise sentence in Korean. It's front-loaded and wastes no words, though its abstract nature limits utility. The structure is efficient, but the content lacks actionable detail, which affects helpfulness more than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 required parameters, no output schema, no annotations), the description is incomplete. It fails to explain what the tool returns, how results are formatted, or any behavioral constraints. For a data retrieval tool with multiple inputs, this omission leaves the agent without enough context to use the tool effectively.
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?
The input schema has 100% description coverage, clearly documenting each parameter (corp_code, bgn_de, end_de) with examples. The description adds no parameter-specific information beyond the schema, so it doesn't enhance semantic understanding. However, since schema coverage is high, the baseline score of 3 is appropriate—the schema adequately handles parameter documentation without needing description support.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '영업양수 결정을 통한 사업 확장 전략 및 내부거래 리스크 분석' translates to 'Business expansion strategy through acquisition decisions and internal transaction risk analysis.' This is vague and abstract—it describes a strategic analysis rather than a concrete tool action. It doesn't specify what the tool actually does (e.g., retrieves data, generates reports, or analyzes risks). The tool name 'get_business_acquisition' suggests data retrieval, but the description fails to clearly state the verb (get/fetch/retrieve) and resource (acquisition data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention any prerequisites, context, or comparison to sibling tools (e.g., get_business_transfer, get_merger). Without usage instructions, an AI agent cannot determine appropriate scenarios for invoking this tool over others in the list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions '리스크 분석' (risk analysis), which implies analytical processing, but doesn't disclose behavioral traits like whether it's a read-only query, requires authentication, has rate limits, returns structured data, or involves computation. For a tool with 3 parameters and no annotations, this is insufficient.
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, efficient sentence in Korean. It's front-loaded with the core purpose, though the purpose itself is abstract. There's no wasted text, but it could be more specific.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a vague description, the tool's functionality is unclear. The description doesn't explain what the tool returns (e.g., data, analysis report) or how it behaves, making it incomplete for a tool with parameters and siblings.
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 100%, with clear descriptions for 'corp_code', 'bgn_de', and 'end_de'. The description adds no parameter-specific information beyond the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '영업양도 결정을 통한 사업 철수 전략 및 자산이전 리스크 분석' (Business withdrawal strategy through business transfer decisions and asset transfer risk analysis) is vague and abstract. It describes a high-level analytical purpose rather than specifying what the tool actually does (e.g., retrieve business transfer data). It doesn't clearly state the verb (get/retrieve/fetch) or resource (business transfer records/data), making it hard to distinguish from siblings like 'get_asset_transfer' or 'get_business_acquisition'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention prerequisites, context, or differentiate from sibling tools (e.g., 'get_asset_transfer' or 'get_business_acquisition'), leaving the agent with no usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It describes analytical outcomes rather than the tool's behavior - it doesn't indicate whether this is a read operation, what data format is returned, whether there are rate limits, or authentication requirements. The description focuses on analysis results rather than tool mechanics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single Korean sentence that's reasonably concise, but it's not front-loaded with the tool's core function. It immediately jumps to analytical outcomes rather than stating what the tool does. While brief, the structure prioritizes use case over operation definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It describes analytical outcomes but doesn't explain what data the tool actually retrieves, what the return format is, or how the parameters enable the described analysis. The gap between the analytical description and actual tool function creates ambiguity.
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 100%, so the schema already documents all three parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete, but doesn't provide additional context about how these parameters relate to the described analysis.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '인건비 구조 및 조직 안정성 리스크 분석' (labor cost structure and organizational stability risk analysis), which describes an analytical purpose rather than the tool's specific function. It doesn't clearly state what the tool actually does (e.g., retrieves employee information data) and doesn't distinguish from sibling tools that also retrieve corporate data. This is closer to stating a use case than defining the tool's operation.
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 guidance is provided about when to use this tool versus alternatives. The description mentions analysis of labor costs and organizational stability, but doesn't specify prerequisites, appropriate contexts, or how this differs from other data retrieval tools in the sibling list. Users must infer usage from the analytical description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 but provides minimal information. It mentions 'analysis' which suggests a read operation, but doesn't clarify whether this is a retrieval, calculation, or reporting tool. No information about permissions, rate limits, data freshness, or response format is included. The description is too abstract to guide behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single Korean sentence that's reasonably concise, but it's front-loaded with abstract concepts rather than concrete functionality. While not verbose, it fails to efficiently communicate the tool's purpose in actionable terms. The structure could be improved by starting with the verb/action rather than the subject matter analysis.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, how the analysis is performed, or what format results come in. The abstract 'analysis' description leaves too many open questions about the tool's actual behavior and output for effective agent use.
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?
The input schema has 100% description coverage with clear parameter documentation (corp_code, bgn_de, end_de), so the baseline is 3. The description adds no additional parameter information beyond what's already in the schema - it doesn't explain how these parameters relate to treasury stock trust contract analysis or provide context about their usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '자기주식 신탁계약 체결을 통한 주가안정화 및 경영권 방어 수단 분석' (Analysis of stock price stabilization and management defense means through treasury stock trust contract conclusion) is vague about what the tool actually does. It describes the subject matter (analysis of treasury stock trust contracts) but doesn't specify the action - whether it retrieves, lists, analyzes, or creates these contracts. The description is more about the topic than the tool's function.
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 guidance is provided about when to use this tool versus alternatives. While there are related tools like 'get_treasury_stock' and 'get_treasury_stock_trust_termination' among the siblings, the description doesn't differentiate this tool from them or explain its specific use case context. Users must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. The description implies analysis but doesn't clarify if this is a read-only retrieval, a computational analysis, or something else. It doesn't mention permissions, rate limits, output format, or any behavioral traits beyond the vague analytical purpose.
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, concise phrase in Korean. It's front-loaded with the core concept but could be more structured for clarity. While efficient, it sacrifices specificity for brevity, making it somewhat under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 required parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what the tool returns, how the analysis is performed, or any behavioral context. For a tool that seems to involve financial risk analysis, more detail is needed to guide effective use.
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 100%, with clear descriptions for each parameter (corp_code, bsns_year, reprt_code). The description adds no parameter-specific information beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline is 3 even without param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '감사의견 및 강조사항을 통한 회계 신뢰성 및 지속가능성 리스크 분석' (Analysis of accounting reliability and sustainability risk through audit opinions and emphasis points) states a general purpose but lacks specificity. It doesn't clearly state what the tool actually does (e.g., retrieve, analyze, or generate reports) and doesn't distinguish from sibling tools that also handle financial/audit data. The description is more about the analysis outcome than the tool's function.
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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or exclusions. Given the many sibling tools related to financial disclosures and audits, the absence of differentiation leaves the agent without clear usage criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 '리스크 분석' (risk analysis), implying some processing or interpretation, but does not clarify if this is a read-only operation, what data format is returned, or any limitations (e.g., data availability, processing time). The description is insufficient for understanding the tool's behavior beyond its analytical purpose.
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, concise sentence in Korean that directly states the tool's analytical purpose. It is front-loaded with no unnecessary elaboration, making it efficient. However, it could be more structured by separating the action from the outcome for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by '리스크 분석' (risk analysis), no annotations, and no output schema, the description is incomplete. It does not explain what the tool returns (e.g., risk scores, detailed reports, or raw data), how the analysis is performed, or any prerequisites. For a tool that likely involves data processing, this lack of detail hinders effective use.
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?
The input schema has 100% description coverage, clearly documenting all three required parameters (corp_code, bsns_year, reprt_code) with examples and formats. The description adds no additional parameter information, so it relies entirely on the schema. This meets the baseline score of 3, as the schema adequately covers parameter semantics without need for compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '비감사용역 계약 내역을 통한 감사인의 독립성 훼손 및 이해상충 리스크 분석' (Analysis of risks to auditor independence and conflicts of interest through non-audit service contract details) states the tool's purpose but does so vaguely. It describes an analytical outcome rather than the specific action performed (e.g., retrieving, listing, or analyzing data). The tool name 'get_non_audit_service_contract' suggests a retrieval function, but the description focuses on risk analysis without clarifying the exact operation.
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. It does not mention sibling tools like 'get_audit_service_contract' or specify contexts where this tool is appropriate. Without explicit or implied usage instructions, the agent lacks direction on application scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. The description implies this is a read-only metadata lookup tool (checking tool info), but doesn't specify whether it requires authentication, has rate limits, returns structured data, or what happens on invalid input. It mentions '확인 후 진행' (check and proceed) suggesting it's a preparatory step, but lacks details on output format or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single run-on sentence in Korean that mixes instructions, purpose, and an example. It's moderately concise but lacks clear structure—front-loading is weak as it starts with a broader goal ('기업의 심층 분석을 위해') rather than the tool's immediate function. The example is helpful but embedded awkwardly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with no schema descriptions, no annotations, no output schema, and a complex context (meta-tool in a large sibling set), the description is incomplete. It hints at usage but doesn't fully explain what the tool returns, how to interpret results, or its role in the tool ecosystem. The example helps but doesn't compensate for missing behavioral and output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 1 parameter with 0% description coverage. The description adds that 'tool_name' should be '정확히 입력' (entered accurately) and provides an example value ('get_corporation_info'), but doesn't explain what constitutes a valid tool name (e.g., from the sibling list), whether it's case-sensitive, or what happens if an invalid name is provided. This partially compensates for the schema gap but remains insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose is to '확인 후 진행' (check and proceed) for '기업의 심층 분석' (in-depth corporate analysis) by verifying tool names, which is a vague purpose. It mentions '도구의 목적, 활용 흐름, 필수 파라미터, 연관 도구' (tool's purpose, usage flow, required parameters, related tools), but doesn't specify what this tool itself does (e.g., returns metadata about another tool). It distinguishes from siblings by being a meta-tool, but the purpose remains unclear.
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 explicit guidance on when to use this tool versus alternatives. It gives an example usage pattern ('예: get_opendart_tool_info(tool_name='get_corporation_info')') but doesn't explain the context or prerequisites for invoking it. There's no mention of when-not-to-use or what problem this tool solves compared to directly using the sibling tools listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions analysis and comparison but fails to disclose critical behavioral traits such as whether this is a read-only operation, potential data sources, rate limits, or output format. For a tool with 4 parameters and no output schema, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence in Korean that packs multiple concepts (XBRL, account system, IFRS, comparison, standardization). While concise, it's not front-loaded with clear action and may require parsing, reducing immediate clarity for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, 0% schema coverage, no output schema, no annotations), the description is incomplete. It doesn't explain the tool's output, parameter usage, or behavioral constraints, making it inadequate for effective agent invocation in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters (sj_div, corp_code, bsns_year, reprt_code) are undocumented in the schema. The description adds no information about what these parameters mean, their expected values, or how they affect the analysis, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool performs 'analysis through standard account system of XBRL financial statement items for IFRS-based comparison and standardization,' which indicates it analyzes XBRL taxonomies for IFRS comparisons. However, it's vague about the specific action (e.g., retrieving, listing, or analyzing taxonomy data) and doesn't clearly differentiate from siblings like 'search_financial_notes,' which might also involve financial data analysis.
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 is provided on when to use this tool versus alternatives. The description mentions IFRS-based comparison, but it doesn't specify scenarios, prerequisites, or exclusions, leaving the agent without clear usage context relative to sibling tools that handle financial data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions '분석' (analysis), suggesting it performs some processing or evaluation, but it doesn't disclose key behavioral traits such as whether it's a read-only query, what format the output takes, potential rate limits, authentication needs, or error conditions. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence in Korean that packs multiple concepts (delisting decision, global withdrawal strategy, governance risk analysis). While concise, it may be overly compact, potentially obscuring clarity. It's front-loaded with the main purpose but could benefit from more structured breakdown for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by '분석' (analysis), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a risk score, report, or raw data), how the analysis is performed, or any limitations. For a tool with three required parameters and no structured output information, more context is needed to understand its full functionality.
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?
The schema description coverage is 100%, with clear descriptions for 'corp_code', 'bgn_de', and 'end_de' in the input schema. The description adds no additional parameter semantics beyond what the schema provides (e.g., it doesn't explain how these parameters relate to the analysis or any constraints). With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes '글로벌 시장 철수 전략 및 지배구조 변동 리스크' (global market withdrawal strategy and governance change risk) through '해외증권시장 상장폐지 결정' (foreign securities market delisting decision). This indicates it analyzes risks related to delisting decisions, but it's somewhat vague about the specific action (e.g., whether it retrieves, analyzes, or generates reports). It doesn't clearly distinguish from siblings like 'get_foreign_delisting' or 'get_foreign_listing_decision'.
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 this tool versus alternatives is provided. The description implies it's for risk analysis related to delisting decisions, but it doesn't specify prerequisites, contexts where it's appropriate, or when other tools (e.g., 'get_foreign_delisting' for raw data) might be better. Usage is implied through the analysis focus, but no clear guidelines are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions 'analysis' but doesn't disclose behavioral traits such as whether this is a read-only operation, what data format is returned, potential rate limits, or authentication needs. For a tool with three parameters and no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that packs multiple concepts ('funding liquidity,' 'equity change risks'), making it somewhat front-loaded but not optimally clear. It could be more structured to separate purpose from context, but it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'analysis' and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns, how the analysis is performed, or any behavioral constraints, leaving the agent with insufficient information to use the tool effectively beyond basic parameter input.
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?
The schema description coverage is 100%, with clear descriptions for each parameter (e.g., 'corp_code' as an 8-digit unique number, date formats). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 without compensating for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes 'funding liquidity and equity change risks through stock-related bond transfers,' which provides a general purpose but lacks specificity. It doesn't clearly distinguish this tool from sibling tools like 'get_bond_with_warrant' or 'get_convertible_bond,' and the verb 'analyze' is vague compared to more precise actions like 'retrieve' or 'calculate.'
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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, and with many sibling tools related to bonds and stocks, there's no indication of how this differs from tools like 'get_stock_related_bond_acquisition' or 'get_bond_with_warrant.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions analysis of policy changes and risks, hinting at read-only data retrieval, but fails to disclose critical details like authentication needs, rate limits, error handling, or whether it returns historical or real-time data. The description is too abstract to guide safe and effective tool invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence in Korean that packs multiple concepts (termination, policy changes, risk analysis) without front-loading the core function. While not verbose, it lacks structural clarity and could benefit from breaking down the purpose versus the analytical outcome. It's concise but not optimally organized for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It omits essential context such as the return format (e.g., report, data points), data recency, error conditions, and how the analysis is presented. Given the complexity implied by 'analysis,' more detail is needed to complement the bare schema and lack of annotations.
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 100%, clearly documenting all three parameters (corp_code, bgn_de, end_de) with examples and requirements. The description adds no parameter-specific information beyond what the schema provides, such as how these dates relate to termination events or data availability. Baseline score of 3 is appropriate since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes 'stock price policy changes and governance structure risks through treasury stock trust contract termination,' which provides a general purpose but lacks a clear verb like 'retrieve' or 'fetch.' It distinguishes from siblings like 'get_treasury_stock_trust_contract' by focusing on termination rather than contract details, but the scope remains vague without specifying output format or data type.
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 is provided on when to use this tool versus alternatives. While it implies analysis related to termination events, there's no mention of prerequisites, timing, or how it differs from other treasury stock tools (e.g., 'get_treasury_stock_acquisition'). The description assumes context without offering practical usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions analysis but doesn't clarify if this is a read-only query, a computational analysis, or if it has side effects like data modification. No information on permissions, rate limits, or output format is included.
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, efficient sentence in Korean that directly states the tool's purpose. It's appropriately concise without unnecessary words, though it could be more structured for clarity in English contexts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of risk analysis, no annotations, and no output schema, the description is incomplete. It lacks details on what the analysis entails, how results are returned, and behavioral aspects, making it insufficient for effective tool use.
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 100%, so the input schema already documents all parameters (corp_code, bsns_year, reprt_code) with descriptions. The tool description adds no additional parameter details beyond what's in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes audit quality and independence risks through audit service contract history, which provides a general purpose. However, it's somewhat vague about the specific action (e.g., retrieve, analyze, or generate report) and doesn't clearly distinguish from sibling tools like 'get_non_audit_service_contract' beyond the contract type.
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 this tool versus alternatives is provided. The description implies usage for risk analysis related to audit contracts, but it doesn't specify prerequisites, exclusions, or compare with similar tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It mentions analysis but doesn't clarify whether this is a calculation, retrieval of pre-computed data, or generation of new insights. No information about data sources, update frequency, computational requirements, or output format is provided. The description is too high-level to guide the agent on what to expect behaviorally.
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, efficient sentence in Korean that states the core function. There's no wasted verbiage or unnecessary elaboration. However, it could be more front-loaded with the primary action verb to immediately clarify what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 required parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what kind of analysis is performed, what format the results take, or how bankruptcy data is sourced and processed. The high-level statement leaves too many operational questions unanswered for effective agent use.
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 100%, providing good documentation for all three parameters (corp_code, bgn_de, end_de). The description adds no additional parameter context beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes corporate liquidity crisis and structural weakness risks based on bankruptcy occurrence, which provides a general purpose. However, it doesn't specify the exact action (retrieve? calculate? generate?) or clearly distinguish from sibling tools like get_debt or get_rehabilitation that might cover related financial distress topics. The purpose is somewhat vague rather than specific.
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. With many sibling tools covering financial and corporate events (get_debt, get_rehabilitation, get_dissolution, etc.), there's no indication of when bankruptcy risk analysis is appropriate versus other financial distress indicators. No prerequisites, exclusions, or comparative context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions analysis types but doesn't disclose whether this is a read-only query, requires specific permissions, has rate limits, returns structured data or reports, or handles errors. For a financial analysis tool with zero annotation coverage, this leaves critical behavior undocumented.
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, efficient sentence in Korean that directly states the analytical focus without fluff. It's appropriately sized for the tool's apparent complexity, though it could be more front-loaded with the tool's action verb to improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's focus on financial risk analysis with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the analysis outputs (e.g., risk scores, textual reports, numerical data), how results are structured, or any behavioral traits like data sources or limitations. This leaves significant gaps for effective agent use.
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 100%, with clear parameter descriptions in Korean for corp_code, bgn_de, and end_de. The description adds no parameter-specific information beyond what the schema provides, such as format examples for dates beyond the schema's examples or how parameters influence the analysis. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes '신주인수권부사채 발행을 통한 지분희석 가능성과 재무레버리지 리스크' (equity dilution potential and financial leverage risk through warrant bond issuance), which provides a specific analytical purpose. However, it's vague about what action the tool performs (e.g., retrieves, calculates, or analyzes data) and doesn't clearly distinguish from sibling tools like get_convertible_bond or get_corporate_bond_outstanding that might handle related financial instruments.
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 offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for analysis, or compare to sibling tools like get_convertible_bond for similar financial analysis. The user must infer usage from the analytical focus alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'analysis' but doesn't specify if this is a read-only query, what data sources it uses, potential limitations, or output format. For a tool with 3 required parameters and no output schema, this is insufficient disclosure.
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, efficient sentence in Korean that directly states the tool's purpose. While concise, it could be more front-loaded with key information, but there's no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 required parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'analysis' entails, what results to expect, or how the output relates to the input parameters. The agent would struggle to understand what this tool actually returns.
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 100%, providing clear documentation for all 3 parameters (corp_code, bsns_year, reprt_code). The description adds no additional parameter information beyond what's in the schema, so it meets the baseline but doesn't enhance understanding of how parameters affect the analysis.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes capital loss and amortization risk through outstanding amortizing conditional capital securities, which is a specific purpose. However, it doesn't clearly distinguish this from sibling tools like 'get_hybrid_securities_outstanding' or 'get_corporate_bond_outstanding', leaving ambiguity about what makes this tool unique.
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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context for analysis, or how it differs from other securities-related tools in the sibling list, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. While it mentions analysis of funding structure and debt risk, it doesn't clarify whether this tool retrieves raw data, performs calculations, or generates reports. There's no information about permissions needed, rate limits, or what format the output takes.
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, efficient sentence in Korean that communicates the core purpose. There's no wasted language, though it could be more specific about the tool's action. The structure is straightforward with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 required parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool actually returns (raw data? analysis results?), how the analysis is performed, or what format the output takes. The description leaves too many open questions about the tool's behavior and output.
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 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose is to analyze funding structure and debt risk through debt securities issuance performance, which provides some context about what it does. However, it's somewhat vague about the specific action (retrieve? calculate? analyze?) and doesn't clearly distinguish this from sibling tools like get_corporate_bond_outstanding or get_debt, which also relate to debt instruments.
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. With many sibling tools related to debt, bonds, and corporate information, there's no indication of what makes this tool unique or when it should be selected over similar tools like get_corporate_bond_outstanding or get_debt.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions '분석' (analysis) which suggests a read-only operation, but doesn't explicitly state whether this is a query or calculation tool. It doesn't disclose behavioral aspects like whether it returns raw data or processed analysis, what format the output takes, or any limitations (e.g., date range constraints beyond the parameters). For a financial analysis tool with no annotation coverage, this is insufficient.
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, efficient Korean phrase that communicates the core purpose without unnecessary words. It's appropriately sized for what it does convey, though it could be more informative. There's no structural issue with front-loading since it's just one clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial analysis tool with 3 required parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what kind of analysis is performed, what the output contains, or how the parameters interact (e.g., whether the date range applies to issuance date or analysis period). The agent would need to guess about the tool's behavior and output format.
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 100%, with all three parameters clearly documented in the schema itself (corp_code, bgn_de, end_de). The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as '예탁증권 발행을 통한 해외자금조달 및 외화 리스크 분석' (Depositary receipt issuance for overseas financing and foreign exchange risk analysis), which is specific about the financial domain and activity. However, it doesn't clearly distinguish this tool from its many siblings (e.g., get_foreign_listing, get_bond_with_warrant) that also relate to international financing instruments. The purpose is clear but lacks sibling differentiation.
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. With 80+ sibling tools covering various financial disclosures and corporate actions, there's no indication of whether this tool is for historical analysis, current status, or specific types of depositary receipts. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions 'analysis' but doesn't disclose behavioral traits such as whether this is a read-only query, what data format it returns, potential rate limits, authentication needs, or error conditions. For a tool with 3 required parameters and no annotations, this is a significant gap in 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 is a single, efficient sentence in Korean that conveys the core purpose without unnecessary words. It is appropriately sized and front-loaded, though it could be slightly more structured by explicitly stating it retrieves data. There is minimal waste, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 required parameters, no output schema, and no annotations), the description is incomplete. It doesn't explain what the analysis entails, the format of results, or how it differs from similar tools. For a tool that likely returns detailed corporate dissolution data, more context is needed to guide effective use.
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?
The input schema has 100% description coverage, clearly documenting each parameter (corp_code, bgn_de, end_de) with examples. The description adds no additional parameter semantics beyond what the schema provides, such as explaining how the date range affects the analysis or the source of corp_code. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes 'dissolution reason occurrence' and 'liquidation risk' for corporations, which provides a general purpose. However, it lacks a specific verb like 'retrieve' or 'fetch' and doesn't clearly differentiate from sibling tools like get_bankruptcy or get_rehabilitation that might cover related corporate events. The purpose is understandable but vague in execution.
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 guidance is provided on when to use this tool versus alternatives. The description mentions analyzing dissolution and liquidation risk, but it doesn't specify prerequisites, exclusions, or compare it to siblings like get_bankruptcy or get_rehabilitation that might handle similar corporate status changes. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 implies a read-only analysis operation ('분석'), but doesn't specify if it's a query, calculation, or report generation, nor does it detail potential side effects, authentication needs, rate limits, or error conditions. This leaves significant gaps in understanding how the tool behaves in practice.
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, efficient sentence in Korean that directly states the tool's analytical focus. It's front-loaded with key terms ('배당금 총액 및 배당성향') and avoids unnecessary fluff, making it appropriately concise for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by financial analysis, lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., raw data, calculated metrics, or a risk assessment), how results are structured, or any limitations (e.g., data availability by year or report type). This makes it inadequate for an agent to fully understand the tool's context and usage.
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?
The input schema has 100% description coverage, clearly documenting each parameter (corp_code, bsns_year, reprt_code) with types and examples. The description adds no additional semantic context about these parameters, such as how they influence the analysis or typical values. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes dividend-related financial metrics ('배당금 총액 및 배당성향을 통한 이익 분배 정책과 재무 건전성 리스크 분석'), which translates to analyzing dividend policy and financial health risk through total dividends and payout ratios. However, it's somewhat vague about the exact operation—it doesn't specify if it retrieves, calculates, or generates a report on this data, and it doesn't clearly distinguish from sibling tools like get_stock_total or get_equity that might relate to corporate finance.
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. It doesn't mention prerequisites (e.g., needing specific financial reports), exclusions, or comparisons to other tools in the sibling list, such as get_corporation_info or search_financial_notes, which might overlap in financial analysis contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions analysis but doesn't disclose whether this is a read-only query, a computational process, or if it has side effects like data modification. There's no information on permissions, rate limits, or output format, which is a significant gap for a tool with no annotation coverage.
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, efficient sentence in Korean that conveys the core purpose without unnecessary words. It's appropriately sized for a tool with three parameters, though it could be more front-loaded with the verb action for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a description that lacks behavioral details, this is incomplete. The tool has three required parameters and performs analysis, but the description doesn't explain what the analysis returns, how it's computed, or any constraints, making it inadequate for informed use.
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 100%, with clear descriptions for corp_code, bgn_de, and end_de parameters. The description doesn't add any parameter-specific details beyond what the schema provides, such as how these dates relate to the analysis or format constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes governance structure changes and fund operation risks through new share issuance and equity securities sales history, which provides a general purpose. However, it's somewhat vague about the specific action (e.g., retrieve, generate, calculate) and doesn't clearly distinguish from sibling tools like get_stock_total or get_major_shareholder_changes that might cover related equity data.
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 this tool versus alternatives is provided. The description implies it's for analyzing governance and risk, but doesn't specify prerequisites, timing, or how it differs from other equity-related tools in the sibling list, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It mentions 'analysis', which implies a read-only operation, but doesn't clarify if it's a calculation, retrieval, or report generation. It lacks details on permissions, rate limits, output format, or any side effects, leaving significant gaps in understanding how the tool behaves.
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, concise sentence in Korean that efficiently states the tool's focus. It's front-loaded with key terms like '교환사채' (exchangeable bond) and '분석' (analysis), with no wasted words. However, it could be slightly more structured by explicitly stating the action (e.g., 'Retrieve analysis of...').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'analysis' and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the analysis entails, the format of results, or any limitations. For a tool with three required parameters and no structured output information, more context is needed to understand its full scope and usage.
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 100%, with clear parameter descriptions in Korean (e.g., '고유번호 (8자리)' for corp_code). The description doesn't add any parameter semantics beyond what the schema provides, such as explaining how the date range affects the analysis. Since the schema is well-documented, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '교환사채 발행을 통한 특정 기업 지분 연결성과 주가 변동성 리스크 분석' (Analysis of equity linkage and stock price volatility risk through exchangeable bond issuance) states the tool's purpose in Korean, but it's somewhat vague. It mentions 'exchangeable bond issuance' and 'analysis' but doesn't specify the exact action (e.g., retrieve, calculate, list). It distinguishes from siblings by focusing on exchangeable bonds, but the verb is implicit rather than explicit.
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. It doesn't mention prerequisites, context, or compare with sibling tools like 'get_convertible_bond' or 'get_bond_with_warrant', which might handle similar financial instruments. Users must infer usage from the title and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions analysis of compensation data but fails to clarify key traits: whether this is a read-only query, if it requires specific permissions, what the output format looks like, or any rate limits. This leaves significant gaps for an agent to understand how to interact with the tool effectively.
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, efficient sentence in Korean that conveys the core purpose without unnecessary details. It's appropriately sized and front-loaded, though it could be slightly more structured for clarity in English contexts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial analysis tools, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, output format, and usage guidelines, making it insufficient for an agent to fully understand the tool's operation and results.
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?
The schema description coverage is 100%, with clear descriptions for each parameter (corp_code, bsns_year, reprt_code). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, so it meets the baseline for adequate but not enhanced documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes 'executive compensation by type' for 'concentration and governance risk analysis', which clarifies the purpose beyond the name. However, it's somewhat vague about the specific action (e.g., retrieval vs. calculation) and doesn't explicitly distinguish from sibling tools like 'get_executive_compensation_approved' or 'get_total_compensation', leaving room for confusion.
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 is provided on when to use this tool versus alternatives. The description mentions analysis of compensation concentration and governance risk, but it doesn't specify prerequisites, constraints, or recommend other tools for related tasks, offering minimal usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions 'risk analysis' but doesn't disclose behavioral traits such as whether this is a read-only operation, what data sources it uses, potential rate limits, or the format of analysis results. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
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, efficient sentence in Korean that conveys the core purpose without unnecessary words. It is front-loaded with key terms like '무상증자' (free capital increase) and '리스크 분석' (risk analysis), making it easy to scan, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'risk analysis' and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the analysis outputs (e.g., risk scores, reports), how results are formatted, or any limitations. For a tool with no structured behavioral data, this leaves too much ambiguity for effective use.
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 100%, so the schema already documents all three parameters (corp_code, bgn_de, end_de) with descriptions. The description adds no additional meaning about parameters, such as explaining how the date range affects the analysis or providing examples beyond the schema. This meets the baseline score when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes risks related to capital structure adjustment and shareholder equity changes through free capital increases, which provides a general purpose. However, it lacks specificity about what exactly is analyzed (e.g., risk metrics, outputs) and doesn't clearly distinguish from sibling tools like 'get_paid_free_capital_increase' or 'get_paid_in_capital_increase' that might handle similar financial events.
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 is provided on when to use this tool versus alternatives. The description implies it's for risk analysis of free capital increases, but it doesn't specify prerequisites, exclusions, or recommend other tools for related tasks like paid capital increases or general financial data retrieval from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions 'analysis' but doesn't clarify if this is a read-only operation, what data sources are used, potential side effects, or output format. For a tool with three required parameters and no output schema, this lack of behavioral detail is a significant gap, though it doesn't contradict any annotations.
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, efficient sentence in Korean that directly states the tool's purpose without unnecessary words. It is front-loaded with the core function, though it could be slightly more structured by explicitly mentioning the action (e.g., 'retrieve and analyze'). Overall, it earns its place concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'analysis' and risk assessment, three required parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the analysis entails, how results are returned, or any behavioral traits, making it inadequate for an agent to fully understand the tool's operation and output without additional context.
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?
The description adds no parameter-specific information beyond what the input schema provides, which has 100% coverage with clear descriptions for corp_code, bsns_year, and reprt_code. Since the schema fully documents the parameters, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract from the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes 'capital-like debt risk and accounting classification risk through outstanding hybrid securities details,' which provides a general purpose but lacks specificity about the exact operation (e.g., retrieving, calculating, or reporting). It distinguishes from siblings by focusing on hybrid securities, but the verb '분석' (analysis) is vague compared to clearer verbs like 'retrieve' or 'calculate' seen in other tools.
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 this tool versus alternatives is provided. The description implies usage for risk analysis related to hybrid securities, but it doesn't specify prerequisites, exclusions, or recommend other tools for different types of securities or data needs, leaving the agent to infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions analysis of 'compensation concentration and insider risk,' which suggests read-only, analytical behavior, but doesn't clarify if it performs calculations, returns raw data, requires specific permissions, has rate limits, or what the output format might be. This leaves significant gaps in understanding how the tool behaves in practice.
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, concise sentence in Korean that efficiently states the tool's analytical purpose. It's front-loaded with the core function and avoids unnecessary details. However, it could be slightly more structured by explicitly separating the action from the outcome, but overall, it's well-sized with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'analysis' and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a report, calculated metrics, or raw data), how the analysis is performed, or any behavioral traits like error handling or data sources. For a tool with analytical claims and no structured output, more context is needed to understand its full functionality.
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?
The input schema has 100% description coverage, clearly documenting each parameter (corp_code, bsns_year, reprt_code) with examples and codes. The description adds no additional parameter semantics beyond what the schema provides, such as explaining how these inputs relate to the analysis described. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes 'compensation concentration and insider risk through individual executive compensation details,' which provides a general purpose but lacks specificity about what the tool actually does (e.g., retrieves, calculates, or reports data). It distinguishes from siblings like 'get_executive_compensation_approved' or 'get_total_compensation' by focusing on individual details, but the verb 'analyzes' is vague compared to more concrete actions like 'retrieve' or 'calculate.'
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 is provided on when to use this tool versus alternatives. While the description implies it's for analyzing individual compensation details, it doesn't specify prerequisites, context (e.g., for risk assessment vs. compliance reporting), or direct comparisons to siblings like 'get_individual_compensation_amount' or 'get_executive_compensation_by_type.' Usage is implied but not clearly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions 'analysis,' which suggests processing or computation, but doesn't disclose behavioral traits such as whether it performs calculations, returns raw data, requires specific permissions, has rate limits, or what the output format might be. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
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, efficient sentence in Korean that directly states the tool's purpose without unnecessary words. It is front-loaded with the core function, though it could be slightly more specific (e.g., by including a verb). There is no wasted text, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a vague description, the tool's context is incomplete. The description hints at analysis but doesn't clarify what the tool actually does (e.g., returns data, performs calculations) or what outputs to expect. For a tool with three parameters and potential complexity in financial analysis, more detail is needed to understand its full scope and usage.
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?
The input schema has 100% description coverage, with clear parameter details (e.g., corp_code as 8-digit unique number, bsns_year as business year, reprt_code with specific report types). The description adds no additional parameter semantics beyond what the schema provides, such as explaining how these inputs relate to the analysis. Baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '타법인 출자 내역을 통한 계열 리스크 및 재무 건전성 분석' translates to 'Analysis of affiliate risk and financial soundness through investment details in other corporations.' This states a purpose (analyzing risk/soundness via investment data) but is vague about the specific action (e.g., retrieving, calculating, or generating a report). It distinguishes from siblings by focusing on 'investment in other corporations,' but lacks a clear verb like 'retrieve' or 'analyze.'
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 guidance is provided on when to use this tool versus alternatives. The description implies it's for risk/financial analysis related to investments, but it doesn't specify contexts (e.g., due diligence, monitoring), prerequisites, or comparisons to other tools like 'get_other_corp_stock_acquisition' or 'get_debt.' Usage is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It describes the analytical purpose but doesn't reveal key behavioral traits: whether this is a read-only query (likely, but not stated), what data format or granularity is returned, if there are rate limits or authentication requirements, or how it handles errors. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
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, concise sentence in Korean that efficiently states the analytical focus. It's front-loaded with the key purpose and avoids unnecessary words. However, it could be slightly more structured by explicitly mentioning the action (e.g., 'retrieve and analyze'), but overall, it's well-sized and earns its place without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (analysis of governance and risk), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a report, numerical metrics, or raw data), how the analysis is performed, or any limitations. For a tool with no structured behavioral or output information, the description should provide more context to compensate, but it falls short, leaving critical gaps for an agent to use it effectively.
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?
The schema description coverage is 100%, with clear descriptions for each parameter (e.g., 'corp_code' as an 8-digit unique identifier, 'reprt_code' with enum-like examples). The description adds no additional parameter semantics beyond what the schema provides, such as explaining how these inputs affect the analysis. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately documents the parameters without extra help from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes '지배구조 안정성과 승계 리스크' (governance stability and succession risk) through '최대주주 및 특수관계인의 지분 현황' (major shareholder and related party shareholding status), which gives a general purpose. However, it's somewhat vague about the specific action (e.g., retrieve, calculate, or analyze data) and doesn't clearly differentiate from sibling tools like 'get_major_shareholder_changes' or 'get_major_holder_changes', which might provide related but different information.
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 explicit guidance on when to use this tool versus alternatives. It mentions analysis of governance stability and succession risk, but doesn't specify scenarios, prerequisites, or compare it to other tools in the list (e.g., 'get_major_shareholder_changes' for changes over time). Without such context, an agent might struggle to choose appropriately among similar-sounding tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions 'risk analysis', suggesting some processing or interpretation beyond raw data retrieval, but doesn't specify whether this is a read-only operation, potential rate limits, authentication needs, or what the output entails (e.g., structured report vs. raw changes). This leaves significant gaps in understanding the tool's behavior.
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, efficient sentence in Korean that front-loads the core purpose ('major shareholder changes') and intended use ('risk analysis'). It avoids unnecessary words, though it could be slightly more structured for clarity in English contexts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'risk analysis', no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a processed risk score, raw data with analysis, or a narrative report), leaving the agent uncertain about the output format and behavioral expectations.
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?
The input schema has 100% description coverage, clearly documenting all three required parameters (corp_code, bsns_year, reprt_code) with examples. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes 'major shareholder changes' for 'management control and succession flow risk analysis', which clarifies the purpose beyond just retrieving data. However, it's somewhat vague about the exact output format and doesn't explicitly differentiate from sibling tools like 'get_major_holder_changes' or 'get_major_shareholder', leaving room for ambiguity.
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, such as 'get_major_holder_changes' or 'get_major_shareholder', nor does it mention prerequisites or exclusions. It implies usage for risk analysis but lacks explicit context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It mentions analysis topics but doesn't specify if this is a read-only operation, requires authentication, has rate limits, or what the output format might be (e.g., structured data vs. narrative). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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, efficient sentence in Korean that lists key analysis areas without redundancy. It's front-loaded with the core purpose, though it could be slightly more structured (e.g., bullet points) for clarity. Overall, it's concise with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (merger analysis with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how the analysis is presented, or any behavioral traits like error handling. For a tool with no structured output or annotations, more detail is needed to be fully helpful.
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?
The schema description coverage is 100%, with clear descriptions for each parameter (corp_code, bgn_de, end_de). The description adds no additional parameter semantics beyond what the schema provides, such as format details or usage context. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes 'merger structure and conditions, management control changes, minority shareholder protection, and merger invalidity risks,' which provides a general purpose but lacks a specific verb and doesn't distinguish from sibling tools like 'get_merger' or 'get_division_merger.' It's vague about what exactly is returned (e.g., a report, data, or analysis).
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 this tool versus alternatives like 'get_merger' or 'get_division_merger' is provided. The description implies usage for merger analysis but offers no context on prerequisites, exclusions, or specific scenarios where this tool is preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions analysis but doesn't disclose behavioral traits such as whether this is a read-only query, what data sources are used, potential rate limits, authentication needs, or the format of results. For a tool with no annotations and no output schema, this leaves critical behavioral aspects unspecified.
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, efficient sentence in Korean that conveys the core purpose without unnecessary words. It's appropriately sized for the tool's complexity, though it could be more front-loaded with key details. No wasted text, but could benefit from slight expansion for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and involves analysis (implying some complexity), the description is incomplete. It doesn't explain what the analysis entails, what output to expect, or any behavioral context. For a tool with three required parameters and no structured output, more detail is needed to be fully helpful.
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 100%, so the schema already documents all three parameters (corp_code, bgn_de, end_de) with descriptions. The tool description adds no additional meaning about parameters beyond what's in the schema, such as how they relate to the analysis or any constraints. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes '타법인 주식 양수를 통한 지배구조 강화 및 우회상장 가능성' (strengthening governance structure and backdoor listing possibility through acquisition of other corporations' stocks), which provides a general purpose but lacks a specific verb and doesn't distinguish from similar tools like 'get_other_corp_stock_transfer' or 'get_investment_in_other_corp'. It's vague about what exactly is returned (e.g., analysis results, data points, or reports).
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 this tool versus alternatives. The description implies it's for analyzing acquisitions for governance and listing purposes, but doesn't specify prerequisites, context, or compare it to sibling tools like 'get_business_acquisition' or 'get_other_corp_stock_transfer'. Usage is implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It mentions analysis but doesn't specify whether this is a read-only operation, what format the analysis takes, whether it requires special permissions, or what happens if data is unavailable. For a tool with no annotation coverage, this leaves significant behavioral questions unanswered.
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, efficient sentence in Korean that communicates the core purpose. It's appropriately sized for what it covers, though it could be more front-loaded with clearer action verbs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the analysis output looks like, what metrics are calculated, or how results should be interpreted. Given the complexity implied by 'plan implementation rate and liquidity-dedicated risk analysis', more context about the return format and analytical methodology would be needed.
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 100%, so the schema already documents all three parameters thoroughly with descriptions and examples. The description adds no additional parameter information beyond what's in the schema, which meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes 'plan implementation rate and liquidity-dedicated risk through private capital usage details', which provides a general purpose. However, it's somewhat vague about the specific verb (analyzes what exactly?) and doesn't clearly distinguish from sibling tools like 'get_public_capital_usage' that likely serve related but different functions.
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 this tool versus alternatives is provided. The description doesn't mention when this analysis is appropriate, what prerequisites might exist, or how it differs from similar tools like 'get_public_capital_usage' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions '리스크 분석' (risk analysis), implying a read-only or analytical operation, but doesn't disclose behavioral traits like data sources, output format, rate limits, or error handling. This is inadequate for a tool with no annotation coverage.
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, efficient sentence in Korean that conveys the core purpose without unnecessary words. It's appropriately sized and front-loaded, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a vague purpose, the description is incomplete. It doesn't explain what the tool returns (e.g., risk metrics, reports), how the analysis is performed, or any limitations, making it insufficient for effective agent use.
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 100%, so the schema already documents all three parameters (corp_code, bgn_de, end_de) with descriptions. The description adds no additional parameter semantics beyond what's in the schema, resulting in the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes risks related to stock exchange/transfer decisions for complete subsidiary formation and governance restructuring, which provides a general purpose. However, it's vague about the specific action (e.g., retrieving data, generating reports) and doesn't clearly distinguish from sibling tools like 'get_stock_exchange_report' or 'get_stock_total' that might handle similar data.
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 is provided on when to use this tool versus alternatives. The description mentions analysis but doesn't specify prerequisites, context, or comparisons to siblings, leaving the agent with no usage direction beyond the implied purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It mentions 'analysis' but doesn't clarify if this is a read-only data fetch, a computational tool, or something else. It lacks details on permissions, rate limits, output format, or any side effects. For a tool with no annotations, this leaves critical behavioral traits unspecified.
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, concise sentence in Korean that directly states the tool's focus. It's front-loaded with the core purpose and avoids unnecessary words. However, it could be more structured by separating the action from the outcome, but it's efficient and doesn't waste space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a vague purpose, the description is incomplete. It doesn't specify what the tool returns (e.g., raw data, analysis report) or how it behaves. For a tool with 3 required parameters and complex sibling context, more detail is needed to guide effective use, such as explaining the analysis output or usage scenarios.
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 100%, with clear descriptions for corp_code, bsns_year, and reprt_code. The description adds no parameter-specific information beyond what the schema provides. It doesn't explain how these inputs relate to the analysis or provide examples. Baseline 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate with additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '주식 총수 내역을 통한 자본금 구성 및 유통물량 리스크 분석' translates to 'Capital composition and circulating volume risk analysis through total stock details.' It indicates the tool analyzes stock-related data but is vague about the specific action (e.g., retrieve, calculate, generate). It mentions 'analysis' but doesn't specify if it fetches data or performs computations, and it doesn't clearly distinguish from siblings like get_stock_increase_decrease or get_stock_exchange.
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. It doesn't mention prerequisites, context (e.g., for financial reporting, risk assessment), or exclusions. With many sibling tools related to stocks and corporate data, there's no indication of how this differs or when it's appropriate, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions analysis of acquisition, disposal, and cancellation for risk assessment, which implies a read-only operation, but doesn't specify output format, data sources, or any limitations like rate limits or authentication needs. This is insufficient for a tool with three parameters and no output schema.
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, efficient sentence in Korean that conveys the core purpose without unnecessary details. It's front-loaded with the main function, though it could be slightly more structured for clarity in English contexts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of treasury stock analysis, three parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how the analysis is performed, or any behavioral traits, making it inadequate for effective agent use without additional context.
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?
The input schema has 100% description coverage, clearly documenting all three required parameters with examples. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes treasury stock activities for risk assessment, which gives a general purpose. However, it's somewhat vague about what specific data or analysis it returns, and it doesn't clearly differentiate from sibling tools like 'get_treasury_stock_acquisition' or 'get_treasury_stock_disposal' that might handle specific aspects of treasury stock.
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 this tool versus alternatives is provided. The description mentions analysis but doesn't specify contexts or prerequisites, such as needing specific report types or years. This leaves the agent without clear direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions analysis but doesn't clarify if this is a read-only query, whether it requires specific permissions, what the output format might be, or any rate limits. This leaves significant gaps in understanding the tool's behavior beyond its purpose.
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 efficiently conveys the analysis purpose without unnecessary details. It is appropriately sized and front-loaded, though it could be slightly more specific to enhance clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'analysis' and the lack of annotations and output schema, the description is insufficient. It doesn't explain what the analysis entails, what data is returned, or how results are structured, making it incomplete for effective tool use in a broader context.
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?
The input schema has 100% description coverage, clearly documenting all three required parameters (corp_code, bgn_de, end_de). The description adds no additional parameter semantics, but since the schema is comprehensive, a baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes capital structure changes and management control variability resulting from treasury stock disposal decisions, which provides a general purpose. However, it doesn't specify the exact action (e.g., 'retrieve' or 'fetch') or clearly distinguish from sibling tools like 'get_treasury_stock' or 'get_treasury_stock_acquisition' that might handle related data.
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 this tool versus alternatives is provided. The description implies analysis of treasury stock disposal effects, but it doesn't specify prerequisites, timing, or contrast with similar tools in the sibling list, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read-only analysis function but doesn't disclose output format, data sources, rate limits, or error conditions. The phrase '투명성 및 통제 리스크 분석' suggests analytical processing, but specifics are missing.
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, efficient sentence in Korean that conveys the core purpose without unnecessary words. It's front-loaded with key terms ('미등기임원 보수 내역') but could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It lacks details on what the analysis entails, expected outputs, or how results are formatted. Given the complexity implied by 'analysis' and the absence of structured behavioral data, more context is needed.
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 100%, so parameters are well-documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain how parameters relate to the analysis). Baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes 'internal compensation transparency and control risk' through 'unregistered executive compensation details', which provides a general purpose. However, it lacks a specific action verb (e.g., 'retrieve', 'fetch', 'analyze') and doesn't clearly distinguish from sibling tools like 'get_executive_compensation_approved' or 'get_executive_compensation_by_type', making it somewhat vague.
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 is provided on when to use this tool versus alternatives. The description mentions analysis but doesn't specify contexts, prerequisites, or exclusions. Users must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions analysis of executive status, composition, career suitability, and governance risk, which suggests a read-only, analytical function. However, it lacks details on behavioral traits such as data source, update frequency, rate limits, or output format, leaving gaps in understanding how the tool behaves.
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, efficient sentence in Korean that conveys the core purpose without unnecessary words. It is front-loaded with key terms like '임원 현황' (executive status) and '지배구조 리스크 분석' (governance risk analysis), making it easy to scan. However, it could be slightly more structured by separating distinct aspects of the analysis.
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's complexity (analysis of executive and governance data), lack of annotations, and no output schema, the description is minimally adequate. It outlines what the tool does but misses details on behavioral aspects and output. For a tool with no structured support, it should provide more context to be fully 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?
The input schema has 100% description coverage, clearly documenting the three required parameters (corp_code, bsns_year, reprt_code). The description does not add any additional meaning or context beyond what the schema provides, such as explaining how these parameters affect the analysis. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes executive status, composition, career suitability, and governance risk, which provides a general purpose. However, it's somewhat vague about the specific action (e.g., retrieving vs. analyzing data) and doesn't clearly differentiate from sibling tools like 'get_executive_compensation_approved' or 'get_executive_trading', which also involve executive information.
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 is provided on when to use this tool versus alternatives. The description implies it's for analyzing executive status and governance, but it doesn't mention prerequisites, exclusions, or specific scenarios where this tool is preferred over other executive-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. The description mentions '정밀 분석' (precise analysis), which implies a read-only operation, but doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what the output format looks like. For a tool that appears to process financial data with 4 parameters, this is a significant gap in behavioral context.
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, efficient sentence in Korean that clearly states the tool's core function. It's appropriately sized for what it communicates, though it could benefit from additional context. There's no wasted language or redundancy, making it structurally sound despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial data analysis with 4 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It explains what the tool does at a high level but provides no information about parameters, behavioral characteristics, output format, or how it differs from related tools. For a tool that appears to be part of a financial reporting system, this leaves too many gaps for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 4 parameters (corp_code, bsns_year, reprt_code, fs_div) have descriptions in the schema. The tool description doesn't mention any parameters at all, providing no semantic information about what these parameters mean, their expected formats, or how they affect the analysis. This leaves all parameters completely undocumented.
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's purpose: '단일 기업의 전체 XBRL 재무제표 데이터를 기반으로 세부 계정까지 정밀 분석' (Precise analysis down to detailed accounts based on a single company's entire XBRL financial statement data). It specifies the verb ('정밀 분석' - precise analysis), resource ('XBRL 재무제표 데이터' - XBRL financial statement data), and scope ('단일 기업' - single company, '세부 계정까지' - down to detailed accounts). However, it doesn't explicitly differentiate from sibling tools like 'get_single_acnt' or 'get_multi_acnt', which appear to be related tools for financial data analysis.
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. It doesn't mention any prerequisites, exclusions, or specific contexts for usage. With many sibling tools available (e.g., 'get_single_acnt', 'get_multi_acnt', 'get_single_index'), there's no indication of how this tool differs or when it should be preferred over others for financial analysis tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It mentions analysis but doesn't specify whether this is a read-only operation, what format the analysis returns, whether there are rate limits, authentication requirements, or data freshness considerations. For a financial analysis tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient Korean sentence that communicates the core purpose without unnecessary words. It's appropriately sized for what it does convey, though it could benefit from being more comprehensive given the complexity of financial analysis.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial analysis tool with 4 required parameters (0% schema coverage), no annotations, no output schema, and complex sibling relationships, the description is inadequate. It doesn't explain parameter meanings, return format, error conditions, or differentiation from similar tools. The description fails to compensate for the lack of structured documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for all 4 required parameters (corp_code, bsns_year, reprt_code, idx_cl_code). The description doesn't explain what these parameters mean, what formats they expect, or provide examples. While it mentions the analysis is based on four indicator categories, it doesn't map these to the idx_cl_code parameter or clarify the other parameters' purposes.
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 performs '재무 리스크 분석' (financial risk analysis) based on four specific financial indicator categories (profitability, stability, growth, activity) for a single corporation. It specifies the verb (analyze) and resource (single corporation's financial risk), but doesn't explicitly distinguish this from sibling tools like 'get_multi_index' or 'search_financial_notes' which might handle multiple corporations or different financial data.
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. It doesn't mention sibling tools like 'get_multi_index' (for multiple corporations) or 'get_single_acnt' (for single account data), nor does it specify prerequisites or appropriate contexts for financial risk analysis versus other financial data tools in the extensive sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While it mentions the analytical purpose, it doesn't describe what the tool actually returns (e.g., structured data, risk scores, narrative analysis), whether it performs calculations or just retrieves raw data, or any limitations like data freshness or processing time. This leaves significant behavioral gaps for a tool with analytical claims.
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 a single, efficient sentence that front-loads the core purpose. Every word contributes meaning without redundancy. It's appropriately sized for conveying the analytical scope while maintaining brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool claiming to perform 'early analysis' of takeover possibilities with 3 parameters and no output schema, the description is incomplete. It doesn't explain what format the analysis takes, what data sources are used, or how the analytical conclusions are derived. Without annotations or output schema, the description should provide more operational context about what the tool actually delivers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (1 of 3 parameters documented). The description doesn't mention any parameters or provide additional context about what 'corp_code', 'start_date', or 'end_date' mean in relation to the analysis. It fails to compensate for the low schema coverage, leaving most parameters semantically unclear.
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's purpose: analyzing major shareholder changes for early detection of management control threats and hostile takeover possibilities. It specifies the threshold (5%+ shareholders) and the analytical goal, though it doesn't explicitly differentiate from sibling tools like 'get_major_shareholder_changes' which might have overlapping functionality.
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 guidance is provided on when to use this tool versus alternatives. The description mentions the analytical purpose but doesn't specify prerequisites, limitations, or when other tools (like 'get_major_shareholder' or 'get_major_shareholder_changes') might be more appropriate. This leaves the agent without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While it mentions analysis (implying read-only), it doesn't specify whether this tool retrieves data, performs calculations, requires authentication, has rate limits, or describes the output format. For a financial analysis tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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, efficient Korean sentence that communicates the core purpose. While appropriately concise, it could be slightly more structured by separating the data retrieval aspect from the analytical purpose, but it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial analysis tool with no annotations and no output schema, the description is insufficient. It mentions analysis but doesn't describe what kind of output to expect (raw data, calculated metrics, risk scores), nor does it address prerequisites, data sources, or limitations. Given the complexity implied by 'analysis' and the lack of structured output documentation, this leaves too many contextual gaps.
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?
The input schema has 100% description coverage, providing clear documentation for all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting. However, it doesn't explain how these parameters relate to the analysis described.
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's purpose: analyzing short-term liquidity and rollover risk through commercial paper outstanding data. It specifies the resource (commercial paper outstanding) and the analytical goal, though it doesn't explicitly differentiate from sibling tools like 'get_short_term_bond_outstanding' or 'get_debt' that might cover related financial instruments.
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. With many sibling tools related to debt, bonds, and financial disclosures, there's no indication of when this specific commercial paper analysis is appropriate compared to tools like 'get_short_term_bond_outstanding' or 'get_debt_securities_issued'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. While it mentions 'analysis,' it doesn't specify whether this is a read-only query, what data format it returns, whether it requires authentication, or any rate limits. For a financial data tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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, efficient sentence that communicates the core purpose. It's appropriately sized for what it does convey, though it could be more front-loaded with critical usage information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial analysis tools, no annotations, and no output schema, the description is incomplete. It doesn't explain what the analysis output looks like, what specific metrics are provided, or how the risk analysis is performed. For a tool that presumably returns structured financial data for analysis, this leaves too much unspecified.
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 100%, so the schema already documents all three parameters with descriptions. The tool description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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's purpose: analyzing long-term debt structure and repayment risk through corporate bond outstanding details. It specifies the resource (corporate bond outstanding) and the analytical outcome (debt structure and risk analysis), though it doesn't explicitly differentiate from sibling tools like get_debt or get_debt_securities_issued.
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. With many sibling tools related to debt, bonds, and financial data, there's no indication of when this specific bond outstanding analysis is appropriate versus other debt-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. While it mentions what information is analyzed, it doesn't describe the tool's behavior: whether it's a read-only operation, what format the analysis is returned in, whether there are rate limits, authentication requirements, or any side effects. The description is purely functional without behavioral context.
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, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a tool with one parameter and clear purpose, though it could potentially be more front-loaded with key distinguishing information given the many sibling tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what format the 'analysis' returns, what specific governance and disclosure information is included, or how comprehensive the analysis is. Given the complexity implied by 'governance and disclosure schedule analysis' and the lack of structured output documentation, more descriptive context is needed.
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?
The input schema has 100% description coverage, with the single parameter 'corp_code' clearly documented as an 8-digit unique identifier for disclosure target companies. The description doesn't add any parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
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's purpose: analyzing corporate governance and disclosure schedules based on basic company information like representative, settlement month, and listing status. It specifies the verb 'analyze' and the resource 'basic company information', making it clear what the tool does. However, it doesn't explicitly differentiate from sibling tools that also retrieve corporate information.
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. With many sibling tools that retrieve various types of corporate information (like get_corporation_code, get_executive_info, get_dividend_info, etc.), there's no indication of when this specific governance and disclosure analysis tool is appropriate versus other information retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While it mentions analysis of completion status and risk, it doesn't disclose whether this is a read-only operation, what data sources are used, whether it requires authentication, or what format the analysis results take. For a financial analysis tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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, efficient sentence in Korean that communicates the core purpose. While concise, it could potentially be more front-loaded with key information, but there's no wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial analysis tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the analysis output looks like, what specific metrics or indicators are evaluated, or how the 'completion' and 'risk analysis' are structured. Given the complexity implied by the tool name and the lack of structured output documentation, more descriptive content is needed.
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 100%, providing clear documentation for all three parameters (corp_code, bgn_de, end_de). The description doesn't add any parameter-specific information beyond what's in the schema, but with complete schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting for parameter documentation.
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 analyzes completion of restructuring and management normalization risks through creditor management procedure termination. It specifies the analysis purpose but doesn't explicitly differentiate from sibling tools like 'get_creditor_management' or 'get_rehabilitation' which might cover related financial distress procedures.
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 guidance is provided about when to use this tool versus alternatives. With many sibling tools covering financial distress events (bankruptcy, rehabilitation, debt, etc.), the description doesn't indicate whether this is for completed procedures only, ongoing monitoring, or how it differs from other restructuring-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions the analytical purpose but doesn't describe what the tool actually returns (e.g., risk metrics, structured data, analysis report), whether it performs calculations or just retrieves data, or any limitations like data freshness or coverage. For a tool with three required parameters and no output schema, this leaves significant gaps in understanding its behavior.
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, efficient sentence in Korean that directly states the tool's purpose. It's appropriately sized for what it communicates, though it could be more front-loaded with the core function. There's no wasted verbiage, but it could benefit from slightly more structure given the analytical nature of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters, no annotations, and no output schema that performs what appears to be financial risk analysis, the description is incomplete. It doesn't explain what kind of analysis is performed, what format the results take, or any limitations or assumptions in the risk calculation. The combination of analytical purpose and missing output information creates significant uncertainty about what the tool actually delivers.
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?
The input schema has 100% description coverage, providing clear documentation for all three parameters (corp_code, bgn_de, end_de). The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline expectation without adding extra value. The description implies these parameters are used for risk analysis but doesn't elaborate on how they affect the analysis.
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's purpose: analyzing debt risk and refinancing risk through debt securities issuance terms and structure. It specifies the resource (debt securities) and the analytical outcome (risk analysis), though it doesn't explicitly mention the verb 'retrieve' or 'get' which is implied by the tool name. It distinguishes itself from siblings like 'get_debt_securities_issued' by focusing on risk analysis rather than just issuance data.
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. It doesn't mention any prerequisites, exclusions, or compare it to similar tools like 'get_debt_securities_issued' or 'get_corporate_bond_outstanding'. The user must infer usage from the description alone without explicit contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. While it mentions '분석' (analysis), which suggests a read-only operation, it doesn't explicitly state whether this is a query or computation, what permissions might be required, whether it performs complex calculations, or what format the analysis results take. For a tool with 'report' in its name and no annotations, this is a significant gap in behavioral 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 is a single, efficient sentence in Korean that directly states the tool's function. There's no unnecessary verbiage or repetition. However, it could be slightly more structured by explicitly mentioning it's a report or analysis tool upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's name suggests a 'report' and the description mentions '분석' (analysis), this appears to be a potentially complex analytical tool. With no annotations, no output schema, and the description providing only basic purpose information, there are significant gaps. Users won't know what the analysis output looks like, what methodology is used, or what specific risks are evaluated.
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 100%, with all three parameters (corp_code, bgn_de, end_de) clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even without parameter details in the description.
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's purpose: analyzing risks to newly established corporations and potential shareholder value impairment through company division conditions. It uses specific terms like '리스크 및 주주가치 훼손 가능성 분석' (risk and shareholder value impairment possibility analysis), which goes beyond a simple tautology. However, it doesn't explicitly differentiate from sibling tools like 'get_division' or 'get_division_merger' that might handle related corporate division data.
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. With many sibling tools related to corporate events (e.g., get_division, get_merger_report, get_business_acquisition), there's no indication of what makes this tool distinct or when it should be preferred. The description focuses solely on what the tool does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'analysis' which implies processing/interpretation beyond raw data retrieval, but doesn't disclose behavioral traits like whether this is a read-only operation, what format the analysis takes, whether it involves external data sources, or any rate limits/authentication requirements. The description is insufficient for a tool with analytical claims.
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, efficient sentence that front-loads the core purpose. There's no wasted verbiage, though it could benefit from structural separation of purpose from additional context. Every word contributes to understanding the tool's analytical focus.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool claiming 'analysis' with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the analysis entails, what format results take, or how parameters affect the analysis. The agent lacks crucial information about behavioral expectations and output structure.
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 only 33% (only 'corp_code' has a description). The description adds no parameter-specific information beyond what's implied by the tool's purpose. It doesn't explain what 'start_date' and 'end_date' filter, the expected date format, or what happens when they're null. With low schema coverage, the description fails to compensate adequately.
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's purpose: analyzing insider trading suspicions and management signals through executive and major shareholder stock trading. It specifies the resource (executive/major shareholder trading) and the analytical goal, though it doesn't explicitly differentiate from sibling tools like 'get_major_holder_changes' or 'get_major_shareholder_changes' which might cover similar data.
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. It doesn't mention prerequisites, timing considerations, or how it differs from sibling tools that might retrieve related information about major shareholders or executive compensation. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what analysis is performed, not how. It lacks behavioral details like whether this is a read-only query, what data sources are used, response format, or any limitations. The description is functional but insufficient for behavioral understanding.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core analysis function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It explains what analysis is performed but doesn't cover behavioral aspects, output format, or usage context needed for proper tool invocation.
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 100%, so parameters are well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score for high schema coverage.
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 analyzes minority shareholder data for governance dispersion and M&A defense risk, providing specific purpose beyond the name. However, it doesn't explicitly distinguish from sibling tools like 'get_major_shareholder' or 'get_major_shareholder_changes', which reduces differentiation.
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 guidance is provided on when to use this tool versus alternatives. The description mentions analysis but doesn't specify use cases, prerequisites, or comparisons with related tools in the extensive sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 offers minimal information. It doesn't indicate whether this is a read-only operation, what format the analysis returns, whether it requires authentication, or any rate limits. The description only states what analysis is performed, not how it behaves.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a tool with 4 parameters and no output schema, though it could benefit from being more front-loaded with key usage information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial analysis tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the analysis output looks like, how to interpret results, or what happens with the optional 'fs_div' parameter. The description leaves too many behavioral and contextual questions unanswered.
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?
The description adds no parameter-specific information beyond what's already in the schema (which has 75% coverage). It doesn't explain how parameters like 'corp_code' or 'fs_div' relate to the analysis described. With decent schema coverage, the baseline is 3, but the description fails to compensate for the 25% gap in schema documentation.
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's purpose: analyzing group-wide financial health and profitability structure based on consolidated financial statements. It specifies the resource (group financial statements) and the analysis type (health and profitability), though it doesn't explicitly differentiate from sibling tools like 'get_single_acnt' or 'get_multi_index'.
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. It doesn't mention sibling tools like 'get_single_acnt' (for single accounts) or 'get_multi_index' (for multi-index analysis), nor does it specify prerequisites or appropriate contexts for this consolidated financial analysis tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'analysis' suggests a read-only operation, the description doesn't clarify whether this tool performs calculations, returns structured data, has rate limits, requires specific permissions, or what format the analysis takes. For a tool with 3 required parameters and no output schema, this leaves significant behavioral gaps.
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, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for the tool's apparent complexity, though it could potentially benefit from being broken into multiple sentences for better readability of the dual-purpose analysis (restructuring possibilities AND rehabilitation strategies).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 required parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the analysis output looks like, whether it returns structured data or narrative analysis, what time periods are appropriate, or how the rehabilitation procedure initiation applications relate to the parameters. The description leaves too many open questions about tool behavior and results.
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 100%, so the schema already documents all three parameters (corp_code, bgn_de, end_de) with clear descriptions and examples. The description doesn't add any parameter-specific information beyond what's in the schema, such as explaining how these parameters relate to the rehabilitation analysis or providing additional context about date range usage.
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's purpose: analyzing corporate restructuring possibilities and rehabilitation strategies through rehabilitation procedure initiation applications. It specifies the action ('analysis') and target ('corporate restructuring possibilities and rehabilitation strategies'), though it doesn't explicitly differentiate from sibling tools like 'get_bankruptcy' or 'get_dissolution' which might cover related corporate distress scenarios.
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. With many sibling tools covering corporate events (bankruptcy, dissolution, mergers, etc.), there's no indication of what distinguishes rehabilitation analysis from other corporate distress or restructuring tools. No prerequisites, exclusions, or comparison context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. While it mentions '분석' (analysis) which suggests a read-only operation, it doesn't explicitly state whether this is a query or computation, what permissions might be required, whether there are rate limits, what format the analysis results take, or any other behavioral characteristics. For a tool with no annotation coverage, this is insufficient disclosure.
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, efficient sentence that gets straight to the point. It's appropriately sized for what it communicates, though it could potentially be more informative. There's no wasted language or unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what kind of analysis is performed, what metrics or ratios are calculated, what format the results take, or how to interpret the output. Given the complexity implied by '수익성과 재무건전성 분석' (profitability and financial health analysis) and the lack of structured metadata, the description should provide more context about what users can expect from this tool.
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 75% schema description coverage (3 of 4 parameters have descriptions in the schema), the baseline is 3. The description doesn't add any meaningful parameter information beyond what's already in the schema. It doesn't explain the relationships between parameters, provide examples of valid inputs, or clarify the optional fs_div parameter's purpose. The description mentions '핵심 재무계정' (core financial accounts) but doesn't connect this to any specific parameters.
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's purpose: analyzing profitability and financial health based on core financial accounts of a single company. It specifies the verb ('분석' - analyze) and resource ('단일 기업의 핵심 재무계정' - single company's core financial accounts). However, it doesn't explicitly differentiate from sibling tools like get_single_acc or get_multi_acnt, which appear to be related financial analysis tools.
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. With many sibling tools available (including get_single_acc, get_multi_acnt, get_multi_index, and get_single_index), there's no indication of what distinguishes this tool from those other financial analysis tools. The description only states what the tool does, not when it's appropriate to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions 'analysis' which suggests read-only processing, but doesn't specify output format, data freshness, rate limits, or authentication requirements. The description is functional but lacks operational context.
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, efficient Korean sentence that packs substantial meaning. It's appropriately sized for the tool's complexity, though it could benefit from clearer separation of the tool's function from its analytical purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It explains what the tool analyzes but not what it returns, how results are structured, or what specific risks are identified. The analytical purpose is clear, but operational details are missing.
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 100%, providing complete parameter documentation. The description doesn't add any parameter-specific information beyond what's in the schema, but the schema adequately covers all three required parameters with clear descriptions and examples for report codes.
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 analyzes stock capital increases/decreases based on periodic reports, focusing on capital changes and governance restructuring risks. It specifies the data source (periodic reports) and the analytical purpose, though it doesn't explicitly distinguish from sibling tools like get_capital_reduction or get_paid_in_capital_increase.
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 guidance is provided on when to use this tool versus alternatives. The description mentions analysis of capital changes and governance risks, but doesn't specify prerequisites, appropriate contexts, or when other tools might be more suitable for related financial data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions searching capabilities but doesn't disclose important behavioral traits: whether this is a read-only operation, what permissions might be required, whether there are rate limits, what format the results return, or how pagination works. For a search tool with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 with two sentences that directly state the tool's functionality. It's front-loaded with the core purpose and follows with additional capability details. There's no wasted verbiage, though it could potentially be structured more clearly for non-Korean readers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the search results look like, how they're structured, what happens when no matches are found, or any limitations of the search functionality. For a search tool with moderate complexity and no structured output documentation, the description should provide more context about the return values and search behavior.
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 100%, so the schema already fully documents all 6 parameters. The description mentions searching in tables and paragraphs, and searching specific sections, which aligns with the 'search_in' and 'section_type' parameters but doesn't add meaningful semantic context beyond what the schema provides. The baseline of 3 is appropriate when the schema does the heavy lifting.
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's purpose: searching tables and paragraphs in financial statement notes, business content, and company overview data. It specifies the verb 'search' and the resources (extracted financial statement notes, business content, company overview). However, it doesn't explicitly differentiate from sibling tools, which appear to be various data retrieval tools but none specifically for searching within financial documents.
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. It mentions the tool can search specific sections (consolidated notes, separate notes, business content, company overview) but doesn't indicate when you would choose this over other data retrieval tools in the sibling list. No prerequisites, exclusions, or comparison to similar tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions the tool is for retrieval and is a first step, but lacks details on behavioral traits like error handling, rate limits, authentication needs, or what happens if the corporation name isn't found. This leaves significant gaps for an agent to understand how to use it effectively.
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, efficient sentence that front-loads the core purpose and includes usage context. There's no wasted text, but it could be slightly more structured (e.g., separating purpose from guidelines) for optimal clarity.
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's low complexity (1 parameter, no output schema, no annotations), the description is adequate but minimal. It covers the purpose and basic usage, but lacks details on output format or error cases, which could help an agent handle responses better. It's complete enough for a simple lookup tool but not robust.
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?
The input schema has 100% description coverage, with 'corp_name' clearly documented as '기업명 (예: 삼성전자, 현대자동차)' (corporation name, e.g., Samsung Electronics, Hyundai Motor). The description doesn't add any parameter details beyond this, so it meets the baseline of 3 where the schema does the heavy lifting.
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's purpose: '기업명을 이용하여 기업 고유번호 조회' (retrieve corporation code using corporation name). It specifies the verb (retrieve) and resource (corporation code), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_corporation_code' (which might work differently), so it doesn't reach the highest score.
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 by stating '공시조회를 위해 가장 먼저 실행하여 고유번호를 얻어야 함' (must be executed first to obtain the code for disclosure inquiry), suggesting this is a prerequisite step. However, it doesn't explicitly mention when not to use it or name alternatives among siblings, so it's not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses that the tool retrieves historical data (implied read-only) and mentions pagination behavior, which is useful. However, it lacks details on rate limits, authentication needs, error conditions, or what the return format looks like (no output schema). This leaves gaps for a tool with 5 parameters.
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 concise and front-loaded, with two sentences that efficiently cover the main purpose and pagination behavior. There's no wasted text, but it could be slightly more structured (e.g., separating purpose from usage notes).
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's complexity (5 parameters, no annotations, no output schema), the description is minimally adequate. It explains what the tool does and mentions pagination, but lacks details on return values, error handling, or performance characteristics. Without an output schema, the agent won't know what data structure to expect, which is a significant gap.
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 100%, so the schema fully documents all 5 parameters (corp_code, bgn_de, end_de, page_no, pblntf_ty). The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain parameter interactions, formatting nuances, or provide examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose: '조회하여 파악' (retrieve to understand) corporate disclosure history by date, covering management activities, financial status, and governance changes. It specifies the resource ('기업의 전체 공시 이력') and verb ('조회하여 파악'), but doesn't explicitly differentiate from sibling tools like 'get_disclosure_document', which might retrieve specific documents rather than a list.
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. It mentions pagination ('여러 페이지가 있을 경우 페이지 번호를 바꿔 조회') as a usage note, but doesn't specify prerequisites, exclusions, or compare it to other disclosure-related tools in the sibling list (e.g., 'get_disclosure_document').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral information. It mentions the data source (OpenDART) and format (XML), but doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, data freshness, or what happens when the XML file is unavailable. For a tool with zero annotation coverage, this is insufficient.
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 perfectly concise with two sentences that each serve distinct purposes: the first states what the tool does (retrieves complete corporation code list), and the second provides usage context. There's zero wasted language, and the information is front-loaded with the core functionality.
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?
For a zero-parameter tool with no output schema, the description provides adequate basic information about what it retrieves and its use cases. However, it lacks important contextual details about the return format beyond 'XML 파일' (XML file), such as the structure of the XML, whether it's paginated, or what specific fields are included. The absence of annotations means the description should compensate more for behavioral transparency.
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 tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on what the tool does and its use cases.
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 action ('조회합니다' - retrieves) and resource ('모든 공시대상 회사의 고유번호 전체 목록' - complete list of corporation codes for all disclosure-target companies). It specifies the data source (OpenDART) and format (XML file). However, it doesn't explicitly differentiate from its sibling 'get_corporation_code_by_name' which appears to be a more targeted version.
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 description provides clear context about when to use this tool: '기업명 검색 또는 고유번호 매핑에 사용됩니다' (used for company name search or corporation code mapping). This gives practical application guidance. However, it doesn't explicitly state when NOT to use it or mention the alternative 'get_corporation_code_by_name' tool that appears in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It mentions downloading, extraction, and caching behaviors, but doesn't disclose whether this is a read-only operation, what permissions are required, potential rate limits, error conditions, or what format the output takes. The description provides some context but misses key operational traits needed for safe invocation.
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 efficiently structured in two sentences: the first states the core functionality (download, extract, cache), and the second covers the fallback behavior. Every word serves a purpose with zero redundancy, making it easy to parse while conveying essential information.
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?
For a tool with no annotations and no output schema, the description provides adequate context about what the tool does and its fallback behavior. However, it doesn't explain the output format, caching details, or potential side effects, leaving gaps in understanding the full operational context. It's minimally viable but could be more complete given the lack of structured metadata.
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 description doesn't explicitly mention the 'rcp_no' parameter, but with 100% schema description coverage (the schema fully documents the parameter as '공시서류의 접수번호 (14자리)'), the baseline is 3. The description adds value by contextualizing what the tool does with that document (downloads, extracts notes, caches), which helps understand the parameter's purpose beyond its technical definition.
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 purpose with specific verbs ('다운로드하고', '추출하여', '캐싱합니다') and resources ('공시서류 원본파일', '재무제표 주석'). It distinguishes from siblings by focusing on document retrieval and financial statement note extraction, unlike other tools that target specific corporate events or data types.
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 when financial statement notes are needed from a disclosure document, and provides guidance on what happens if notes are absent ('다른 보고서를 찾아보라는 안내를 제공합니다'). However, it doesn't explicitly state when to use this tool versus alternatives like 'search_financial_notes' or 'get_disclosure_list', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-opendart MCP server](https://glama.ai/mcp/servers/ChangooLee/mcp-opendart/badges/card.svg)](https://glama.ai/mcp/servers/ChangooLee/mcp-opendart)

Score Badge

Copy to your README.md:

[![mcp-opendart MCP server](https://glama.ai/mcp/servers/ChangooLee/mcp-opendart/badges/score.svg)](https://glama.ai/mcp/servers/ChangooLee/mcp-opendart)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ChangooLee/mcp-opendart'

If you have feedback or need assistance with the MCP directory API, please join our Discord server