OpenDART MCP Server

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 disclosures or reports, with clear descriptions that differentiate them. However, some tools like get_compensation_by_type, get_individual_compensation, get_total_compensation, and get_top5_compensation could cause confusion due to overlapping compensation-related themes, though descriptions help clarify nuances.
Naming Consistency5/5
All tools follow a consistent snake_case naming pattern with a 'get_' prefix, followed by descriptive nouns or phrases. This uniformity makes the tool set predictable and easy to navigate, with no deviations in style or structure.
Tool Count2/5
With 83 tools, the count is excessively high for an MCP server, making it overwhelming and difficult for agents to manage. While the domain (Korean financial disclosures) is broad, this many tools suggests poor scoping and could lead to inefficiency in tool selection.
Completeness5/5
The tool set comprehensively covers the domain of Korean corporate disclosures, including financial statements, executive data, securities, mergers, and more. It provides extensive CRUD-like access to various report types with no obvious gaps, ensuring agents can handle diverse queries effectively.
Average 3.1/5 across 83 of 83 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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

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 states the tool '제공합니다' (provides) information, implying a read-only operation, but doesn't specify authentication requirements, rate limits, pagination, error conditions, or what format the information comes in. For a tool with 3 required parameters and no 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with two sentences: one stating purpose and one listing parameters. However, the parameter documentation is embedded in the description rather than separated, and the purpose statement could be more front-loaded. Some redundancy exists in parameter formatting 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 3 required parameters, 0% schema coverage, no annotations, but presence of an output schema, the description is minimally adequate. The output schema existence means return values don't need explanation in the description, but the description should better address parameter semantics and usage context. It covers basic purpose and parameter identification but lacks behavioral details and sibling differentiation.
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%, so the schema provides no parameter documentation. The description adds minimal semantics: it identifies parameters as 'corp_code: 고유번호(8자리)' (unique 8-digit code) and date parameters with format 'YYYYMMDD' and constraint '2015년 이후' (after 2015). However, it doesn't explain where to find corp_code values, whether dates are inclusive/exclusive, or what happens if no data exists in the range. This partially compensates but leaves important gaps.
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: '회사합병 결정 - 주요사항보고서 내 회사합병 결정 정보를 제공합니다' (provides merger decision information from major issue reports). It specifies the verb '제공합니다' (provides) and resource '회사합병 결정 정보' (merger decision information), but doesn't explicitly differentiate from sibling tools like 'get_division_merger_decision' or 'get_merger_reg' which might handle related but different 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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention any prerequisites, constraints beyond date parameters, or comparison to sibling tools like 'get_division_merger_decision' or 'get_merger_reg' that appear to handle similar corporate actions. The agent 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 full burden for behavioral disclosure. The description only states what information is provided, without mentioning whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or response format. For a tool with no annotation coverage, this represents 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 appropriately concise with a clear two-part structure: purpose statement followed by parameter list. The purpose is front-loaded, and the parameter section is formatted for readability. No unnecessary verbiage is present, though the parameter explanations could be more informative.
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 that an output schema exists (which reduces the need to describe return values), the description covers the basic purpose and parameters. However, with no annotations and 0% schema description coverage, the description should do more to explain behavioral aspects and parameter semantics. It's minimally adequate but leaves significant gaps in understanding how to use the tool effectively.
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%, so the description must compensate. It does list the three parameters with brief Korean explanations, but these don't add meaningful semantic context beyond what's already evident from parameter names. The explanations ('고유번호(8자리)', '시작일(YYYYMMDD)', '종료일(YYYYMMDD)') essentially restate the parameter titles in Korean with format hints, but don't explain their significance, constraints, or relationships. With 0% schema coverage and minimal parameter explanation, this is inadequate.
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: '지분증권 - 증권신고서 내 지분증권 요약정보를 제공합니다' translates to 'Equity securities - provides summary information of equity securities within securities registration statements.' This specifies the verb (provides), resource (equity securities summary information), and scope (within securities registration statements). It doesn't explicitly distinguish from sibling tools, but the specificity is sufficient for clear understanding.
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. While the purpose is clear, there's no mention of prerequisites, appropriate contexts, or comparison to similar tools like 'get_debt_securities_reg' or 'get_depositary_receipts_reg' from the sibling list. The user 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool '제공합니다' (provides information), which implies a read-only operation, but doesn't confirm this or describe other behaviors like rate limits, authentication needs, error handling, or response format. For a tool with zero annotation coverage, 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 appropriately concise and well-structured: a single sentence states the purpose, followed by a clear 'Args:' section listing parameters with brief notes. There's no unnecessary fluff, and information is front-loaded. It could be slightly improved by integrating the parameter notes more seamlessly, but overall, it's efficient and easy to parse.
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 (3 required parameters, no annotations, but has an output schema), the description is minimally adequate. It covers the basic purpose and parameters but lacks behavioral context, usage guidelines, and detailed parameter explanations. The presence of an output schema means the description doesn't need to explain return values, but it still falls short in other areas, making it just barely sufficient for a simple lookup tool.
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 the input schema provides no descriptions for parameters. The description adds minimal semantics: it lists the three parameters (corp_code, bgn_de, end_de) and provides basic format hints (e.g., '8자리' for corp_code, 'YYYYMMDD' for dates, '2015년 이후' for date range). However, it doesn't explain what 'corp_code' represents (e.g., company identifier), the significance of the date range, or any constraints beyond the year 2015, leaving key details 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: '교환사채권 발행결정 - 주요사항보고서 내 교환사채권 발행결정 정보를 제공합니다' (Provides exchangeable bond issuance decision information from major reports). It specifies the verb ('제공합니다' - provides) and resource ('교환사채권 발행결정 정보' - exchangeable bond issuance decision information), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_convertible_bond_decision' or 'get_bond_with_warrant_decision', which prevents a perfect score.
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 comparisons to sibling tools (e.g., 'get_convertible_bond_decision'), leaving the agent with no context for tool selection. The only usage hint is implicit from the parameters (date range and corp_code), but this is insufficient for explicit guidelines.
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 states the tool '정보를 제공합니다' (provides information), implying a read-only operation, but doesn't clarify authentication requirements, rate limits, pagination, error conditions, or what format the information comes in. The mention of date constraints (2015년 이후 - after 2015) is useful but insufficient 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 appropriately concise with two sentences: one stating the purpose and another listing parameters. The parameter documentation is structured with clear labels and constraints. There's no unnecessary verbiage, though the Korean/English mix might cause minor parsing issues for some agents.
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 that an output schema exists, the description doesn't need to explain return values. However, with no annotations and 0% schema description coverage, the description compensates moderately by documenting all parameters and their basic semantics. It falls short in providing behavioral context (authentication, rate limits) and usage guidelines compared to sibling tools, making it minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds basic semantics for all three parameters: corp_code (고유번호 - unique number), bgn_de (시작일 - start date), and end_de (종료일 - end date). It also specifies date format (YYYYMMDD) and temporal constraint (2015년 이후 - after 2015). However, it doesn't explain where to obtain corp_code values or provide examples, leaving some ambiguity.
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: '신주인수권부사채권 발행결정 - 주요사항보고서 내 신주인수권부사채권 발행결정 정보를 제공합니다.' This translates to 'Provides bond with warrant issuance decision information from major matters reports.' It specifies both the verb (provides information) and the resource (bond with warrant issuance decisions from reports). However, it doesn't explicitly differentiate from sibling tools like 'get_convertible_bond_decision' or 'get_exchangeable_bond_decision' which likely handle similar 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. While it mentions the source ('주요사항보고서' - major matters reports), it doesn't specify use cases, prerequisites, or exclusions. There's no comparison to sibling tools that handle related bond decisions, leaving the agent without contextual 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 only states what information is provided, without mentioning whether this is a read-only operation, if there are rate limits, authentication requirements, pagination behavior, or what format the output takes. For a tool with 3 required parameters and an 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 efficiently structured with a purpose statement followed by parameter explanations. The Korean text is concise and front-loaded with the main functionality. The parameter section uses clear formatting with colons and parentheses for additional details, though the English parameter names mixed with Korean explanations creates minor cognitive friction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters, no annotations, but does have an output schema, the description is moderately complete. It covers the basic purpose and parameter meanings, but lacks behavioral context (permissions, rate limits, etc.) and usage guidance. The presence of an output schema means return values are documented elsewhere, reducing the burden on the 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?
Schema description coverage is 0%, so the description must compensate. It provides Korean translations and brief explanations for each parameter (corp_code: 고유번호(8자리), bgn_de: 시작일(YYYYMMDD, 2015년 이후), end_de: 종료일(YYYYMMDD, 2015년 이후)), adding meaningful context beyond the bare schema. However, it doesn't explain where to obtain corp_code values or clarify date format expectations beyond the YYYYMMDD notation.
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 provides business transfer decision information from a major matters report, with a specific verb ('제공합니다' - provides) and resource ('영업양도 결정 정보' - business transfer decision information). It distinguishes itself from siblings like 'get_business_acquisition_decision' by focusing on transfers rather than acquisitions, though it doesn't explicitly contrast with other transfer-related tools like 'get_asset_transfer_putback'.
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. While the description mentions it's for business transfer decisions, it doesn't specify scenarios where this would be preferred over other decision tools or how it relates to the broader disclosure search tool. The date constraints (2015년 이후) are parameter-specific rather than usage guidance.
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 states this is an information-providing tool, which implies read-only behavior, but doesn't explicitly confirm this. It doesn't mention authentication requirements, rate limits, error conditions, response format, or what happens when parameters are invalid. For a tool with 3 required parameters and no annotation coverage, this is insufficient 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 appropriately concise with two sentences: one stating the purpose and one documenting parameters. The parameter documentation is structured clearly with bullet points. There's no unnecessary verbiage, and the information is front-loaded with the purpose statement first.
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 that there's an output schema (which handles return values), no annotations, and 3 parameters with 0% schema coverage, the description does an adequate but incomplete job. It covers the basic purpose and documents parameters minimally, but lacks behavioral context, usage guidance, and deeper parameter semantics. For a corporate data retrieval tool with date constraints, more context about what constitutes valid inputs and expected outputs would be 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 description provides parameter documentation in the Args section, listing all 3 parameters with brief explanations. However, with 0% schema description coverage, the schema provides only titles without descriptions. The description adds value by explaining corp_code as '고유번호(8자리)' (unique number, 8 digits) and date parameters with format (YYYYMMDD) and temporal constraint (2015년 이후). This partially compensates for the schema's lack of descriptions, but doesn't fully explain parameter semantics or provide examples.
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: '감자 결정 - 주요사항보고서 내 감자 결정 정보를 제공합니다' (Capital reduction decision - provides capital reduction decision information within major issue reports). It specifies the verb '제공합니다' (provides) and resource '감자 결정 정보' (capital reduction decision information), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_division_decision' or 'get_merger_decision' that also provide corporate decision 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. It doesn't mention sibling tools, doesn't specify prerequisites or appropriate contexts, and offers no comparison to other decision-related tools in the list. The only implicit guidance is the date range requirement (2015년 이후), but this doesn't help with 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 full burden. It states this is a read operation ('제공합니다' - provides), implying it's non-destructive, but doesn't disclose any behavioral traits like rate limits, authentication needs, response format, or error handling. For a tool with no annotation coverage, 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 appropriately concise with two sentences: one stating the purpose and one documenting the parameter. It's front-loaded with the core functionality. The formatting with 'Args:' is clear, though the mix of Korean and English might slightly reduce readability for some agents.
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 one parameter with 0% schema coverage and an output schema present, the description is minimally complete. It covers the basic purpose and parameter, but lacks behavioral context (no annotations) and usage guidance. The output schema will handle return values, so the description doesn't need to explain those, but overall it's adequate with clear gaps for a simple lookup 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 0%, so the description must compensate. It adds the parameter 'corp_code' with a brief explanation '고유번호(8자리)' (unique number, 8 digits), which provides basic semantics beyond the schema's title 'Corp Code'. However, it doesn't explain where to obtain this code or its format constraints, leaving some ambiguity. With one parameter partially documented, this meets the baseline for minimal compensation.
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: '기업개황 - DART에 등록된 기업의 개황정보를 제공합니다' (Company overview - provides overview information of companies registered in DART). It specifies the verb '제공합니다' (provides) and resource '기업의 개황정보' (company overview information), making the purpose clear. However, it doesn't explicitly differentiate from sibling tools, which mostly appear to be more specific financial/regulatory data retrievers.
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, context requirements, or comparison to sibling tools like 'get_corp_code' (which might be needed first) or 'search_disclosure' (which might be broader). 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?
No annotations are provided, so the description carries full burden. It implies a read-only operation (provides information) but doesn't disclose behavioral traits like authentication needs, rate limits, response format, or error handling. For a data retrieval tool with zero annotation coverage, 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 appropriately sized with a clear purpose statement followed by parameter explanations. The Korean text could be more concise, but it's front-loaded with key information and avoids unnecessary elaboration. Every sentence adds value, though the structure with bullet points in Args is slightly informal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which covers return values), no annotations, and 3 parameters with 0% schema coverage, the description provides basic purpose and parameter semantics but lacks usage guidelines and behavioral context. It's minimally viable for a read operation but incomplete for effective agent use without additional structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds basic semantics for all three parameters (corp_code as unique identifier, bsns_year as business year, reprt_code as report code with examples), which compensates somewhat. However, it doesn't detail format constraints (e.g., exact string patterns) or provide full context for parameter 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 provides 'compensation status for directors/auditors by type' from regular reports, specifying the resource (compensation data) and scope (by type, from reports). However, it doesn't explicitly differentiate from sibling tools like get_individual_compensation or get_top5_compensation, which likely provide similar compensation data but with different aggregations or filters.
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 it provides compensation data 'by type' but doesn't explain when this breakdown is preferred over other compensation tools in the sibling 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.
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 only states what information is provided, but doesn't reveal any behavioral traits - no mention of whether this is a read-only operation, what format the output takes, whether there are rate limits, authentication requirements, or any side effects. For a tool with no annotation coverage, 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 appropriately concise with a clear purpose statement followed by parameter explanations. The two-sentence structure is efficient with no wasted words, though the parameter explanations could be better integrated rather than appearing as a separate 'Args:' section.
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 that there's an output schema (which handles return values) and the tool has 3 parameters with 0% schema description coverage, the description provides basic purpose and parameter semantics but lacks behavioral context. For a financial data retrieval tool with no annotations, it should ideally mention whether this accesses public data, requires authentication, or has any usage limitations to be more 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 description provides parameter semantics in Korean: 'corp_code: 고유번호(8자리), bgn_de: 시작일(YYYYMMDD, 2015년 이후), end_de: 종료일(YYYYMMDD, 2015년 이후)'. This adds meaningful context beyond the schema (which has 0% description coverage), explaining that corp_code is an 8-digit unique identifier and dates must be in YYYYMMDD format from 2015 onward. However, it doesn't fully compensate for the complete lack of schema descriptions for all three 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: '상각형 조건부자본증권 발행결정 - 주요사항보고서 내 상각형 조건부자본증권 발행결정 정보를 제공합니다' (Provides contingent convertible bond issuance decision information from major reports). It specifies the resource (contingent convertible bond issuance decisions) and the source (major reports), but doesn't explicitly differentiate from sibling tools like 'get_convertible_bond_decision' or 'get_bond_with_warrant_decision' which might cover similar 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. While it mentions the specific type of bond (contingent convertible bonds), it doesn't explain when this tool is appropriate compared to other bond-related tools in the sibling list, nor does it mention any prerequisites or constraints beyond the date parameters.
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 states the tool provides information (implying read-only), but doesn't disclose behavioral traits like authentication requirements, rate limits, response format, pagination, or error handling. For a tool with no annotation coverage, this is inadequate.
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 sized with two sentences: one stating the purpose and another detailing parameters. It's front-loaded with the core function, though the parameter section could be slightly more integrated. No wasted sentences.
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 no annotations, 3 parameters with 0% schema coverage, and an output schema exists (which reduces need to describe return values), the description is moderately complete. It covers parameter semantics adequately but lacks behavioral context and usage guidelines, leaving gaps for effective 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 0%, but the description adds meaningful context for all three parameters: corp_code as '고유번호(8자리)' (unique 8-digit code), bgn_de as '시작일(YYYYMMDD, 2015년 이후)' (start date in YYYYMMDD format, after 2015), and end_de similarly. This compensates well for the schema's lack of descriptions, though it doesn't explain parameter interactions or constraints beyond date format.
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: '채권은행 등의 관리절차 개시 - 주요사항보고서 내 채권은행 등의 관리절차 개시 정보를 제공합니다' (Provides creditor bank management procedure initiation information within major reports). It specifies the verb '제공합니다' (provides) and resource '정보' (information), though it doesn't explicitly differentiate from sibling tools like 'get_creditor_management_stop'.
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 mentions the context ('주요사항보고서 내' - within major reports) but doesn't specify prerequisites, exclusions, or compare with similar tools like 'get_creditor_management_stop' or other financial reporting 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 for behavioral disclosure. The description only states what information is provided, without mentioning whether this is a read-only operation, if there are rate limits, authentication requirements, or what format the output takes. While the presence of an output schema helps, the description itself lacks behavioral context for a tool with 3 required 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 efficiently structured with a brief purpose statement followed by parameter documentation. The parameter explanations are clear and directly relevant. While the purpose statement could be more specific, there's no wasted text or redundancy.
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 3 required parameters with 0% schema coverage, the description compensates well with parameter documentation. The presence of an output schema means return values don't need explanation. However, for a corporate data retrieval tool with no annotations, the description lacks important behavioral context about permissions, rate limits, and error conditions that would be helpful for an AI agent.
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?
Schema description coverage is 0%, but the description provides parameter documentation in Korean that explains each parameter's purpose: corp_code (unique 8-digit identifier), bgn_de (start date in YYYYMMDD format, after 2015), and end_de (end date in YYYYMMDD format, after 2015). This adds significant value beyond the bare schema, though it doesn't explain validation rules or provide examples.
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 '부도발생 - 주요사항보고서 내 부도발생 정보를 제공합니다' which translates to 'Provides default occurrence information within the major matters report.' This identifies the resource (default occurrence information) and the context (major matters report), but the verb 'provides' is generic and doesn't specify whether this is a lookup, retrieval, or search operation. It doesn't clearly differentiate from sibling tools that also retrieve specific report 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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or limitations beyond the date constraints implied by parameters. With many sibling tools retrieving different types of corporate disclosure data, there's no indication of when this specific default occurrence data should be requested.
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 states it 'provides summary information' which implies a read-only operation, but doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the output takes. While an output schema exists (which helps), the description itself lacks critical behavioral context for a tool with 3 required parameters.
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 reasonably concise with two parts: a purpose statement and parameter documentation. However, the purpose statement could be more front-loaded and clearer in English (the Korean may require translation). The Args section is well-structured but includes some redundancy with the schema. Overall, it's functional but not optimally efficient.
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 3 required parameters with 0% schema coverage and no annotations, the description does provide parameter documentation which is crucial. The existence of an output schema means the description doesn't need to explain return values. However, for a data retrieval tool with multiple similar siblings, the description lacks context about when to use it versus alternatives and behavioral details like authentication or rate limits.
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 includes an Args section that documents all 3 parameters with Korean labels and format hints (e.g., '고유번호(8자리)' for corp_code, '시작일(YYYYMMDD)' for bgn_de). However, the input schema has 0% description coverage, so this parameter documentation in the description is essential. The description compensates adequately by providing format requirements, though it doesn't explain parameter relationships or provide examples.
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: '증권예탁증권 - 증권신고서 내 증권예탁증권 요약정보를 제공합니다' translates to 'Depositary receipts - provides summary information of depositary receipts within securities registration statements.' This specifies the verb (provides), resource (depositary receipts summary information), and context (within securities registration statements). However, it doesn't explicitly differentiate from sibling tools like 'get_equity_securities_reg' or 'get_debt_securities_reg' which handle similar registration data for different security types.
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 that handle similar registration data (e.g., get_equity_securities_reg, get_debt_securities_reg) or specify use cases like retrieving depositary receipt information specifically versus other security types. The only implied usage is when you need depositary receipt summary information, but no explicit context or exclusions 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 full burden for behavioral disclosure. While it indicates this is an information retrieval tool ('제공합니다'), it doesn't describe response format, pagination, error conditions, rate limits, authentication requirements, or what constitutes a 'dissolution event' beyond the Korean term. The mention of '주요사항보고서' (major event reports) provides some context but insufficient behavioral detail.
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: purpose statement followed by parameter documentation. The parameter section uses clear formatting with bullet-like structure. No wasted words, though the Korean-only presentation might limit accessibility for some agents.
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 3 parameters with 0% schema coverage and no annotations, the description provides basic parameter semantics and purpose. However, for a corporate disclosure tool with 80+ siblings, it lacks context about dissolution events' significance, relationship to other corporate actions, or output structure (though output schema exists). The description is minimally adequate but leaves important contextual gaps unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides parameter names and basic semantics: corp_code as unique identifier, bgn_de/end_de as date range with format YYYYMMDD and constraint '2015년 이후' (after 2015). However, it doesn't explain what happens if dates are invalid, whether the range is inclusive, or what 'corp_code' represents beyond '고유번호' (unique number). The description adds meaningful context but leaves gaps.
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: '해산사유 발생 - 주요사항보고서 내 해산사유 발생 정보를 제공합니다' (Provides dissolution reason occurrence information within major event reports). It specifies the verb '제공합니다' (provides) and resource '해산사유 발생 정보' (dissolution reason occurrence information), but doesn't explicitly differentiate from sibling tools like 'get_division_decision' or 'get_merger_decision' which handle other corporate 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?
The description provides no guidance on when to use this tool versus alternatives. With 80+ sibling tools handling various corporate events and disclosures, there's no indication of when dissolution events should be queried versus other event types, nor any prerequisites or context for usage beyond the parameter requirements.
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 only states what information is provided without mentioning whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or what format the output takes. The description doesn't contradict annotations (none exist), but provides minimal 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 appropriately concise with two sentences: a purpose statement followed by parameter documentation. The structure is clear with purpose first, then parameters. No wasted words, though the parameter documentation could be slightly more detailed given the 0% schema coverage.
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 3 parameters with 0% schema coverage and no annotations, the description provides basic parameter semantics but lacks behavioral context. The existence of an output schema helps (description doesn't need to explain return values), but for a tool that likely queries financial/regulatory data, more context about authentication, rate limits, or data freshness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides parameter names and brief explanations in Korean: 'corp_code: 고유번호(8자리)' (unique 8-digit code), 'bgn_de: 시작일(YYYYMMDD, 2015년 이후)' (start date in YYYYMMDD format, after 2015), 'end_de: 종료일(YYYYMMDD, 2015년 이후)' (end date in YYYYMMDD format, after 2015). This adds meaningful semantics beyond the bare schema, but doesn't explain where to obtain corp_code or date constraints beyond 2015.
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: '회사분할 결정 - 주요사항보고서 내 회사분할 결정 정보를 제공합니다' (Provides company division decision information from major item reports). It specifies the verb '제공합니다' (provides) and resource '회사분할 결정 정보' (company division decision information), but doesn't explicitly differentiate from sibling tools like 'get_division_merger_decision' or 'get_merger_decision' which might be related.
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. While it mentions the source ('주요사항보고서 내' - from major item reports), it doesn't specify use cases, prerequisites, or how it differs from similar tools like 'get_division_merger_decision' or 'get_merger_decision' 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 indicates this is a read operation ('정보를 제공합니다' - provides information) but doesn't mention authentication requirements, rate limits, pagination, error conditions, or what format the output takes. The description lacks critical behavioral context needed for proper 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: one stating the purpose and one documenting parameters. The parameter documentation is structured clearly with each parameter explained. There's no wasted text, though the formatting could be cleaner without the indentation issues in the Args section.
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 there's an output schema (which should document return values), the description doesn't need to explain output format. However, for a tool with 3 required parameters, no annotations, and 0% schema description coverage, the description provides only basic parameter semantics and purpose. It lacks usage context, behavioral details, and doesn't leverage the sibling tool context to help the agent choose appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds basic semantics for all 3 parameters (corp_code as 8-digit unique identifier, bgn_de/end_de as start/end dates in YYYYMMDD format with 2015+ constraint). This compensates somewhat but doesn't provide examples, validation rules, or explain what happens with invalid dates. Baseline 3 is appropriate given it documents all parameters but minimally.
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: '회사분할합병 결정 - 주요사항보고서 내 회사분할합병 결정 정보를 제공합니다' (Provides company division/merger decision information from major item reports). It specifies the verb ('제공합니다' - provides) and resource ('회사분할합병 결정 정보' - company division/merger decision information), though it doesn't explicitly differentiate from sibling tools like get_division_decision or get_merger_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?
The description provides no guidance on when to use this tool versus alternatives. There are multiple related sibling tools (get_division_decision, get_merger_decision, get_division_reg, get_merger_reg) but no indication of how this tool differs or when it should be preferred. The parameter documentation implies date-range filtering but doesn't explain context for usage.
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 only states what information is provided, without mentioning whether this is a read-only operation, what format the output takes, whether there are rate limits, authentication requirements, or any constraints on the corp_code parameter. For a tool with no annotation coverage, this represents 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 reasonably concise with two sentences: one stating the purpose and one documenting the parameter. There's no unnecessary verbiage, and the information is front-loaded with the core purpose first. The structure could be slightly improved by integrating the parameter documentation more naturally rather than as a separate Args section, but overall it's efficient.
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 that there's an output schema (which should document return values), the description doesn't need to explain output format. However, for a tool with no annotations, 0% schema description coverage, and many similar sibling tools, the description is incomplete. It covers basic purpose and parameter semantics but lacks behavioral context, differentiation from alternatives, and deeper parameter guidance. The presence of an output schema raises the baseline, but significant gaps remain.
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 includes an Args section that documents the single parameter (corp_code) with a brief explanation in Korean ('고유번호(8자리)' meaning 'unique number (8 digits)'). However, schema description coverage is 0%, so the schema provides no parameter documentation. The description adds basic semantic context (it's an 8-digit unique identifier), but doesn't explain where to obtain this code, format requirements, or validation rules. This provides marginal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '임원·주요주주 소유보고 - 임원·주요주주 특정증권등 소유상황보고서 내 소유보고 정보를 제공합니다.' This translates to providing ownership report information from executive/major shareholder ownership status reports. It specifies the resource (ownership reports) and the scope (executives/major shareholders), though it doesn't explicitly differentiate from sibling tools like 'get_major_stockholding' or 'get_largest_shareholder' which might cover similar domains.
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 in the disclosure/financial reporting domain (like get_major_stockholding, get_largest_shareholder, get_executive_status), there's no indication of what distinguishes this specific ownership report tool from others that might cover related information. No prerequisites or contextual constraints 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it indicates this is an information retrieval tool ('제공합니다'), it doesn't disclose important behavioral aspects like whether this is a read-only operation, what format the output takes, whether there are rate limits, authentication requirements, or error conditions. For a tool with no annotation coverage, this represents 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 efficiently structured with a clear purpose statement followed by parameter documentation. Both sentences earn their place: the first explains what the tool does, and the second provides essential parameter information. The formatting with clear parameter labels enhances readability without unnecessary verbosity.
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 that there's an output schema (which means the description doesn't need to explain return values) and no annotations, the description provides adequate basic information about purpose and parameters. However, for a tool with 3 parameters and no behavioral annotations, it should ideally include more context about usage scenarios, constraints, or output characteristics to be fully complete for agent understanding.
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 includes an Args section that documents all three parameters with Korean labels and format constraints (e.g., 'YYYYMMDD, 2015년 이후'). However, with 0% schema description coverage, the schema provides no parameter documentation. The description compensates adequately by explaining each parameter's meaning and format, establishing a baseline understanding despite the schema gap.
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: '무상증자 결정 - 주요사항보고서 내 무상증자 결정 정보를 제공합니다' (Provides free capital increase decision information from major issue reports). It specifies the verb '제공합니다' (provides) and resource '무상증자 결정 정보' (free capital increase decision information), making the purpose clear. However, it doesn't explicitly differentiate from sibling tools like 'get_paid_capital_increase' or 'get_mixed_capital_increase', which prevents a perfect score.
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 sibling tools like 'get_paid_capital_increase' and 'get_mixed_capital_increase' available, there's no indication of what distinguishes free capital increases from paid or mixed ones, nor any prerequisites or constraints beyond the parameter requirements. This leaves the agent without 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 states the tool 'provides information,' implying a read-only operation, but doesn't clarify permissions, rate limits, error conditions, or response format. While an output schema exists, the description doesn't mention what kind of data is returned (e.g., structured vs. raw). For a tool with no annotations, 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 efficiently structured with a clear purpose statement followed by a parameter list. It uses two sentences total, with no redundant information. However, the parameter explanations could be more concise, and the overall structure is simple but effective.
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 moderate complexity (3 required parameters, no annotations, but with an output schema), the description is partially complete. It covers the purpose and parameters but lacks usage guidelines, behavioral details, and output context. The presence of an output schema reduces the need to describe return values, but other gaps remain, making it adequate but with clear room for improvement.
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 includes an Args section that documents all three parameters with brief explanations (e.g., 'corp_code: 고유번호(8자리)' meaning 'unique number (8 digits)'). However, schema description coverage is 0%, so the schema provides no additional parameter details. The description compensates by defining each parameter, but the explanations are minimal and lack examples or constraints (e.g., format validation for 'bsns_year'). This meets the baseline for adequate but incomplete 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: '최대주주 현황 - 정기보고서 내 최대주주 현황 정보를 제공합니다' translates to 'Largest shareholder status - provides largest shareholder status information within periodic reports.' This specifies the verb (provides), resource (largest shareholder status information), and scope (within periodic reports). However, it doesn't explicitly differentiate from sibling tools like 'get_largest_shareholder_change' or 'get_major_stockholding', which appear related.
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. While it mentions the context ('within periodic reports'), it doesn't specify prerequisites, limitations, or when to choose this over similar tools like 'get_largest_shareholder_change' or 'get_major_stockholding'. The absence of usage guidelines leaves the agent without clear 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. It mentions the source ('major matters report') but lacks critical behavioral details: whether it's read-only, requires authentication, has rate limits, returns paginated data, or handles errors. For a tool with 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 front-loaded with the purpose, followed by parameter details in a structured Args section. It's efficient with minimal waste, though the Korean text might add slight complexity for non-Korean agents. Overall, it's well-organized and concise.
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 no annotations, 3 parameters with 0% schema coverage, and an output schema present, the description is partially complete. It covers the purpose and basic parameter semantics but misses behavioral context and usage guidelines. The output schema likely handles return values, so that gap is mitigated, but overall it's adequate with clear room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds basic semantics: 'corp_code' as a unique 8-digit identifier, and date ranges with format (YYYYMMDD) and a constraint (post-2015). However, it doesn't explain validation rules, defaults, or examples, leaving some ambiguity for the three required 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: 'provides lawsuit filing information from the major matters report.' It specifies the verb 'provides' and the resource 'lawsuit filing information,' making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_rehabilitation_filing' or 'get_dissolution_event,' which might also relate to legal proceedings, leaving some 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 offers no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or other contexts, such as whether it's for active lawsuits, historical data, or specific report types. Without this, an agent might struggle to choose it appropriately among similar 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. The description states it 'provides information,' which implies a read-only operation, but doesn't specify authentication requirements, rate limits, response format, or error conditions. For a tool with no 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 appropriately concise with two sentences: one stating the purpose and another documenting the parameter. There's no unnecessary fluff, and the information is front-loaded. The structure with an Args section is clear, though the purpose statement is slightly redundant.
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 that there's an output schema (which handles return values), a single parameter with basic documentation, and no annotations, the description is minimally adequate. It covers the core purpose and parameter, but lacks behavioral context and usage guidelines. For a tool with no annotations, it should do more to compensate.
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 includes an Args section that documents the single parameter 'corp_code' with a brief explanation ('고유번호(8자리)' meaning 'unique number (8 digits)'). Since schema description coverage is 0% and there's only one parameter, this adds meaningful semantics beyond the bare schema. However, it doesn't explain where to obtain this code or provide examples.
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: '대량보유 상황보고 - 주식등의 대량보유상황보고서 내 대량보유 상황보고 정보를 제공합니다' translates to 'Major stockholding situation report - provides major stockholding situation report information within the major stockholding situation report of stocks, etc.' This specifies the verb ('provides') and resource ('major stockholding situation report information'), though it's somewhat redundant. It doesn't explicitly differentiate from sibling tools, but the specificity of 'major stockholding situation report' distinguishes it from other financial reporting tools in the 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 doesn't mention prerequisites, context for usage, or compare it to any sibling tools. The agent must infer usage from the tool name and description alone without explicit 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 indicates this is a read operation ('제공합니다' - provides), it doesn't disclose important behavioral traits like whether this tool requires authentication, has rate limits, returns paginated results, or what format the output takes. The presence of an output schema helps somewhat, but the description itself lacks behavioral context beyond the basic read operation.
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 clear sections: a purpose statement followed by parameter documentation. The purpose statement is front-loaded, and the parameter section is organized with clear labels. While efficient, the Korean-only text might limit accessibility for some agents, but within the given language, it's well-structured without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters, no annotations, but does have an output schema, the description provides the minimum viable information. The purpose is clear and parameters are documented, but there are significant gaps: no usage guidance relative to sibling tools, limited behavioral context, and no information about error conditions or response formats. The output schema existence raises the baseline, but the description itself remains somewhat incomplete for a data retrieval 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?
The description includes parameter documentation in the Args section, explaining that corp_code is an 8-digit unique identifier and bgn_de/end_de are start/end dates in YYYYMMDD format. With 0% schema description coverage, this parameter information is essential. However, it doesn't add meaning beyond basic format specifications - no guidance on valid date ranges, corp_code validation, or what happens when no data exists for the specified 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: '합병 - 증권신고서 내 합병 요약정보를 제공합니다' (Mergers - provides summary information about mergers within securities reports). It specifies the verb '제공합니다' (provides) and the resource '합병 요약정보' (merger summary information). However, it doesn't explicitly differentiate from sibling tools like 'get_merger_decision' or 'get_division_merger_decision', which likely handle different aspects of merger 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 multiple sibling tools related to mergers (get_merger_decision, get_division_merger_decision) and other corporate actions, there's no indication of what makes this tool distinct or when it should be preferred over others. The only contextual information is the parameter requirements, which doesn't constitute usage guidance.
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 states the tool 'provides information' which implies a read-only operation, but doesn't clarify permissions, rate limits, response format, or any side effects. The description mentions the source ('주요사항보고서 내' - from major reports) which adds some context, but doesn't explain what constitutes a 'mixed' capital increase or how the data is structured in the output.
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 efficiently structured with a clear purpose statement followed by parameter documentation. The two-sentence format with a bulleted Args section is well-organized and front-loaded. There's no redundant information, though the Korean-only text might limit accessibility for non-Korean speaking agents.
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 that there's an output schema (which handles return values), no annotations, and 3 parameters with 0% schema coverage, the description does an adequate job. It documents all parameters and states the purpose clearly. However, for a financial data tool with sibling alternatives, it should better explain what 'mixed' capital increases are and when to use this versus other capital increase tools 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?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description includes an Args section that documents all three parameters with brief explanations in Korean: corp_code (고유번호), bgn_de (시작일), and end_de (종료일). It adds format constraints for dates (YYYYMMDD, 2015년 이후) that aren't in the schema. However, it doesn't explain where to obtain corp_code values or provide examples, leaving some ambiguity.
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: '유무상증자 결정 - 주요사항보고서 내 유무상증자 결정 정보를 제공합니다' (Provides information on mixed capital increase decisions from major reports). It specifies the verb ('제공합니다' - provides), resource ('유무상증자 결정 정보' - mixed capital increase decision information), and source ('주요사항보고서 내' - from major reports). However, it doesn't explicitly differentiate from sibling tools like get_free_capital_increase or get_paid_capital_increase, which likely cover related but different types of capital increases.
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. There are multiple sibling tools related to capital increases (get_free_capital_increase, get_paid_capital_increase), but the description doesn't explain what distinguishes 'mixed' capital increases from 'free' or 'paid' ones, nor does it mention any prerequisites or contextual constraints beyond the date range parameters.
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 states this '제공합니다' (provides) information, implying a read-only operation, but doesn't specify whether it's a query, lookup, or data retrieval tool. No information about authentication requirements, rate limits, response format, error conditions, or data freshness is provided. The description is minimal beyond stating the 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 efficiently structured with a clear purpose statement followed by parameter documentation. The two-sentence format is appropriately concise, though the parameter documentation could be more integrated rather than in a separate Args section. No redundant information or unnecessary elaboration is present.
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 that there's an output schema (which handles return values), no annotations, and 3 parameters with basic documentation in the description, the description is minimally adequate. However, for a financial data retrieval tool with sibling alternatives, it should provide more context about when to use it, what the output represents, and how it differs from related tools. The presence of an output schema reduces but doesn't eliminate the need for more complete contextual information.
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 includes an Args section that documents all three parameters with Korean explanations: corp_code (고유번호), bsns_year (사업연도), and reprt_code (보고서코드). However, with 0% schema description coverage, the schema provides only titles without descriptions. The description adds value by explaining what each parameter represents and providing reprt_code enum values, but doesn't specify format constraints (e.g., corp_code must be 8 digits, bsns_year must be ≥2015).
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: '회계감사인과의 비감사용역 계약체결 현황 - 정기보고서 내 회계감사인과의 비감사용역 계약체결 현황 정보를 제공합니다' (provides information about non-audit service contracts with accounting auditors in periodic reports). It specifies the verb '제공합니다' (provides) and resource '정보' (information), but doesn't explicitly differentiate from sibling tools like 'get_audit_service_contract' beyond the 'non-audit' distinction in the name.
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_audit_service_contract' for audit contracts or other financial reporting tools. There's no context about appropriate use cases, prerequisites, or limitations beyond the parameter requirements.
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 indicates this is a read operation ('정보를 제공합니다' - provides information) but doesn't disclose important behavioral traits like authentication requirements, rate limits, pagination, error conditions, or what format the information comes in. The description mentions the source ('주요사항보고서' - major reports) which adds some context, but overall behavioral transparency is insufficient 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 appropriately concise with a clear two-part structure: purpose statement followed by parameter documentation. Every sentence earns its place - the first establishes what the tool does, and the parameter section provides essential usage information. The formatting with clear 'Args:' labeling helps readability, though the mixing of Korean and English could be slightly confusing.
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 that an output schema exists, the description doesn't need to explain return values. However, for a tool with 3 parameters, 0% schema description coverage, and no annotations, the description provides adequate but minimal coverage. It explains what the tool does and documents parameters, but lacks behavioral context and usage guidance. The presence of an output schema raises the baseline, but the description still has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description compensates by documenting all 3 parameters with their Korean names, formats, and constraints (corp_code: 8-digit unique number, bgn_de/end_de: YYYYMMDD format, 2015 onwards). This adds meaningful semantics beyond the bare schema, though it doesn't explain what happens if dates are invalid or what the date range represents (reporting date vs decision date).
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: '타법인 주식 및 출자증권 양수결정 - 주요사항보고서 내 타법인 주식 및 출자증권 양수결정 정보를 제공합니다' (Provides information on acquisition decisions of other corporations' stocks and equity securities from major reports). It specifies both the action ('provides information') and the resource ('acquisition decisions of other corporations' stocks and equity securities'), though it doesn't explicitly differentiate from sibling tools like 'get_other_corp_stock_transfer_decision' or 'get_stock_bond_acquisition_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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts, or comparisons to sibling tools like 'get_other_corp_stock_transfer_decision' (which appears to handle transfer decisions rather than acquisition decisions). The only contextual information is the date range constraint (2015 onwards), which is parameter guidance rather than usage guidance.
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 states the tool '제공합니다' (provides) information, which implies a read-only operation, but doesn't explicitly confirm this or describe any behavioral traits like authentication requirements, rate limits, error conditions, or what format the information is provided in. The mention of date constraints (2015년 이후) is helpful but insufficient for a mutation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise and well-structured. The first sentence clearly states the purpose, followed by a parameter section with bullet-like formatting. Each parameter explanation is brief but informative. There's no wasted text, 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?
Given that there's an output schema (which handles return values), no annotations, and 3 parameters with 0% schema coverage, the description is moderately complete. It explains what the tool does and documents all parameters with format constraints. However, for a financial data tool with many similar siblings, it lacks differentiation guidance and behavioral context about the reporting system it queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides parameter semantics for all three parameters: 'corp_code: 고유번호(8자리)' (unique 8-digit code), 'bgn_de: 시작일(YYYYMMDD, 2015년 이후)' (start date in YYYYMMDD format, after 2015), and 'end_de: 종료일(YYYYMMDD, 2015년 이후)' (end date in YYYYMMDD format, after 2015). This adds meaningful context beyond the bare schema, establishing format constraints and temporal boundaries. However, it doesn't explain where to obtain the corp_code or how date ranges are interpreted.
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: '타법인 주식 및 출자증권 양도결정 - 주요사항보고서 내 타법인 주식 및 출자증권 양도결정 정보를 제공합니다' (Provides information on other corporation stock and equity securities transfer decisions within major matters reports). It specifies the verb '제공합니다' (provides) and resource '정보' (information) with context about the source document. However, it doesn't explicitly distinguish this from sibling tools like 'get_other_corp_stock_acquisition_decision' or 'get_stock_bond_transfer_decision', which appear related.
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. There are multiple sibling tools with similar names (e.g., 'get_other_corp_stock_acquisition_decision', 'get_stock_bond_transfer_decision') that likely handle related financial disclosures, but the description doesn't explain what differentiates this specific transfer decision tool or when it should be selected 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 the full burden of behavioral disclosure. It states the tool 'provides information,' which implies a read-only operation, but doesn't clarify authentication needs, rate limits, error conditions, or response format. The description lacks details on what specific data is returned (e.g., list of directors, dates, changes) or any behavioral traits beyond the 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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a structured Args section. There's minimal waste, though the Korean text might require translation for some users. The structure with bullet points for parameters enhances readability without unnecessary verbosity.
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 moderate complexity (3 required parameters, no annotations, but has an output schema), the description is partially complete. It covers the purpose and parameter meanings, but lacks behavioral context (e.g., authentication, errors) and doesn't explain the output format. The presence of an output schema mitigates the need to describe return values, but overall completeness is adequate with clear gaps in usage and transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds parameter semantics by explaining each argument in Korean: corp_code (고유번호), bsns_year (사업연도), and reprt_code (보고서코드 with code mappings). This provides meaningful context beyond the schema's generic titles, but it doesn't fully detail formats (e.g., corp_code length validation) or optionality, leaving some gaps. With 0% schema coverage, the description does add value but not comprehensively.
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: '사외이사 및 그 변동현황 - 정기보고서 내 사외이사 및 그 변동현황 정보를 제공합니다' translates to 'Outside directors and their change status - provides information on outside directors and their change status within regular reports.' This specifies the verb (provides information), resource (outside directors and their change status), and scope (within regular reports). However, it doesn't explicitly differentiate from sibling tools like get_executive_status or get_employee_status, which might cover related personnel 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, exclusions, or compare it to sibling tools such as get_executive_status or get_employee_status that might handle similar corporate personnel information. Usage is implied through parameter descriptions but not explicitly stated.
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 states the tool '정보를 제공합니다' (provides information), implying it's a read-only operation, but doesn't address rate limits, authentication requirements, error conditions, or response format. The date constraints (2015년 이후) are mentioned but not explained.
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 efficiently structured with a clear purpose statement followed by parameter documentation. The Korean text is direct without unnecessary elaboration, though the formatting with indentation could be cleaner. Every sentence serves a purpose.
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 3-parameter tool with no annotations but with an output schema present, the description provides basic purpose and parameter context. However, it lacks behavioral details (rate limits, auth needs) and doesn't explain the relationship with the similar 'get_overseas_delisting' sibling tool, leaving gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It documents all 3 parameters with basic explanations: corp_code as 고유번호(8자리), bgn_de as 시작일(YYYYMMDD, 2015년 이후), and end_de as 종료일(YYYYMMDD, 2015년 이후). This adds meaningful context beyond the bare schema, though format details remain minimal.
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: '해외 증권시장 주권등 상장폐지 결정 정보를 제공합니다' (provides information about overseas securities market delisting decisions). It specifies the resource (overseas delisting decisions) and source (major reports), but doesn't explicitly differentiate from sibling 'get_overseas_delisting' which appears to be a similar tool.
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 the sibling 'get_overseas_delisting' tool or explain the difference between them, nor does it provide any context about prerequisites or appropriate use cases.
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 context. It mentions the source ('주요사항보고서' - major reports) and date constraints ('2015년 이후' - after 2015), but doesn't disclose whether this is a read-only operation, what format the information is returned in, potential rate limits, authentication needs, or error conditions. For a tool with 3 required parameters and 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 appropriately concise with two sentences: one stating the purpose and another detailing parameters. The Args section is well-structured with clear parameter explanations. No unnecessary information is included, though the Korean-only text might limit accessibility in multilingual contexts.
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 3 required parameters, 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. It covers basic purpose and parameter semantics but lacks behavioral context, usage guidelines, and doesn't leverage the output schema's existence to clarify return values. For a data retrieval tool in a complex domain with many siblings, more contextual guidance would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaningful parameter context in the Args section: it explains 'corp_code' as '고유번호(8자리)' (unique 8-digit code) and date parameters with format 'YYYYMMDD' and constraint '2015년 이후' (after 2015). This compensates partially for the schema's lack of descriptions, though it doesn't cover all potential semantic nuances (e.g., date validation, corp_code format examples).
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: '해외 증권시장 주권등 상장 - 주요사항보고서 내 해외 증권시장 주권등 상장 정보를 제공합니다' (Provides overseas securities market stock listing information from major reports). It specifies the verb '제공합니다' (provides) and resource '정보' (information), but doesn't explicitly differentiate from sibling tools like 'get_overseas_delisting' or 'get_overseas_listing_decision' beyond the general domain.
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, constraints beyond date parameters, or compare it to related tools like 'get_overseas_delisting' or 'get_overseas_listing_decision'. Usage is implied only through parameter requirements.
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 describes a read operation ('정보를 제공합니다'), implying it is non-destructive, but does not disclose behavioral traits such as authentication needs, rate limits, error handling, or output format. The mention of '주요사항보고서 내' (within major reports) adds some context, but overall, the description lacks sufficient behavioral details for a tool with no 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 concise and well-structured: a clear purpose statement followed by a parameter list. It uses two sentences effectively with no wasted words. However, the formatting with indentation in the Args section is slightly verbose but not detrimental.
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 no annotations, 0% schema coverage, but an output schema exists, the description is moderately complete. It covers purpose and parameters adequately, but lacks behavioral context and usage guidelines. The output schema likely handles return values, so the description does not need to explain those, but it should provide more operational details for a tool with no 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 0%, but the description includes an Args section that documents all three parameters with brief semantics: corp_code as a unique identifier, bgn_de and end_de as start and end dates with format and year constraints. This compensates partially for the schema gap, but it does not provide deep semantic context (e.g., valid corp_code formats, date validation rules). Baseline is 3 as it adds meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: '해외 증권시장 주권등 상장 결정 정보를 제공합니다' (provides information on overseas securities market stock listing decisions). It specifies the verb '제공합니다' (provide) and resource '정보' (information), distinguishing it from siblings like 'get_overseas_listing' or 'get_overseas_delisting_decision' by focusing on decisions. However, it does not explicitly differentiate from all siblings, such as 'get_overseas_delisting_decision', which might be similar in scope but for delisting.
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 includes no guidance on when to use this tool versus alternatives. It lists parameters but does not mention prerequisites, context (e.g., for regulatory reporting), or comparisons to siblings like 'get_overseas_listing' or 'get_overseas_delisting_decision'. Usage is implied by the parameter descriptions but not explicitly stated.
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 states the tool '제공합니다' (provides information), implying a read-only operation, but doesn't clarify authentication needs, rate limits, error conditions, or response format. For a financial data tool with zero annotation coverage, this leaves significant behavioral gaps, though it at least indicates the data source.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by a parameter list. It's concise at two sentences plus parameter details, with no redundant information. The front-loaded purpose statement helps, though the parameter section could be slightly more integrated into the flow.
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 moderate complexity (3 parameters, financial data), no annotations, and an output schema (which reduces need to describe returns), the description is partially complete. It covers purpose and parameters but lacks usage guidelines, behavioral details, and sibling differentiation. This makes it adequate for basic understanding but insufficient for optimal agent decision-making in a crowded toolset.
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 includes an Args section that lists and briefly describes all three parameters ('corp_code: 고유번호(8자리)', 'bgn_de: 시작일(YYYYMMDD, 2015년 이후)', 'end_de: 종료일(YYYYMMDD, 2015년 이후)'). Since schema description coverage is 0%, this adds crucial semantic context beyond the bare schema. However, it doesn't explain parameter interactions or constraints beyond date ranges, keeping it at a baseline level.
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: '주권 관련 사채권 양도 결정 - 주요사항보고서 내 주권 관련 사채권 양도 결정 정보를 제공합니다' (Provides stock-related bond transfer decision information from major reports). It specifies the verb ('제공합니다' - provides) and resource ('주권 관련 사채권 양도 결정 정보' - stock-related bond transfer decision information), making the purpose clear. However, it doesn't explicitly differentiate from sibling tools like 'get_stock_bond_acquisition_decision' or 'get_other_corp_stock_transfer_decision', which prevents a perfect score.
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 source ('주요사항보고서 내' - from major reports) but doesn't specify use cases, prerequisites, or exclusions. With many sibling tools for financial disclosures (e.g., 'get_bond_with_warrant_decision', 'get_convertible_bond_decision'), the lack of comparative context leaves usage ambiguous.
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 states the tool '정보를 제공합니다' (provides information), suggesting a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, pagination, error handling, or what format the information comes in. The description is minimal and lacks crucial operational context 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 appropriately concise with two sentences: one stating the purpose and another listing parameters. The parameter section is clearly formatted. There's no wasted text, though the purpose sentence could be slightly more specific. The structure is front-loaded with the core functionality first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces need to describe return values) but no annotations and 0% schema description coverage, the description is moderately complete. It covers the basic purpose and parameter formats, but lacks behavioral context (e.g., read/write nature, error handling) and usage differentiation from siblings. For a 3-parameter tool with no annotations, it meets minimum viability but has clear 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 0%, so the schema provides no parameter descriptions. The description adds basic semantics for all three parameters: 'corp_code: 고유번호(8자리)' (unique 8-digit code), 'bgn_de: 시작일(YYYYMMDD, 2015년 이후)' (start date in YYYYMMDD format, after 2015), and 'end_de: 종료일(YYYYMMDD, 2015년 이후)' (end date in YYYYMMDD format, after 2015). This covers format and constraints but doesn't explain where to get corp_code or date validation rules. With 0% schema coverage, this partial compensation earns a baseline score.
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: '주식교환·이전 결정 정보를 제공합니다' (provides stock exchange/transfer decision information). It specifies the resource ('주식교환·이전 결정' - stock exchange/transfer decisions) and context ('주요사항보고서 내' - within major matters reports). However, it doesn't explicitly differentiate from similar sibling tools like 'get_stock_bond_transfer_decision' or 'get_other_corp_stock_transfer_decision', which prevents a perfect score.
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 similar sibling tools (e.g., 'get_stock_bond_transfer_decision', 'get_other_corp_stock_transfer_decision'), there's no indication of what distinguishes this tool's scope or when it's appropriate. The parameter descriptions imply date constraints ('2015년 이후' - after 2015) but no 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what information is provided, without mentioning whether this is a read-only operation, what format the output takes, whether there are rate limits, authentication requirements, or any side effects. For a tool with 3 required parameters and no annotation coverage, this represents significant gaps 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 efficiently structured with a clear purpose statement followed by parameter documentation. The bilingual approach (Korean purpose, English parameter names) is slightly inconsistent but doesn't significantly impact clarity. Every sentence serves a purpose, though the parameter documentation could be more integrated with the purpose statement.
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 that there's an output schema (which should document return values), the description doesn't need to explain output format. However, for a tool with 3 required parameters, 0% schema description coverage, and no annotations, the description should do more to explain the business context of 'tangible asset transfer decisions' and how this tool differs from related sibling tools. The parameter documentation is adequate but the overall context is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description includes an Args section that documents all 3 parameters with Korean labels and format constraints (corp_code: 8-digit unique number, bgn_de/end_de: YYYYMMDD format after 2015). This adds meaningful semantics beyond the bare schema, but doesn't explain what '유형자산 양도 결정' (tangible asset transfer decision) means in business context or how the parameters relate to the output.
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: '유형자산 양도 결정 - 주요사항보고서 내 유형자산 양도 결정 정보를 제공합니다' (Tangible asset transfer decision - provides tangible asset transfer decision information within major report). It specifies the verb ('제공합니다' - provides), resource ('유형자산 양도 결정 정보' - tangible asset transfer decision information), and context ('주요사항보고서 내' - within major report). However, it doesn't explicitly differentiate from sibling tools like 'get_tangible_asset_acquisition_decision' or 'get_asset_transfer_putback', which prevents a perfect score.
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, prerequisites, or specific scenarios where this tool is appropriate. The only contextual information is that it operates within '주요사항보고서' (major report), but this doesn't help distinguish it from other tools that might also work with similar reports.
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 states the tool '정보를 제공합니다' (provides information), implying a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or response format. The description mentions the data source ('정기보고서 내' - within periodic reports) but lacks details on data freshness, access restrictions, or what happens if no matching data exists.
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: a purpose statement followed by parameter documentation. The parameter section is clearly formatted with bullet-like structure. No redundant information is present, and the description is front-loaded with the core purpose. Minor improvement could be made by integrating parameter details more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and 3 parameters with 0% schema coverage, the description is minimally complete. It covers the purpose and parameters but lacks behavioral context and usage guidance. For a read-only data retrieval tool with output schema, the description meets basic needs but leaves gaps in operational understanding that the agent must infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description compensates by listing all three parameters with brief explanations: corp_code (고유번호), bsns_year (사업연도), and reprt_code (보고서코드 with code mappings). It adds value by explaining reprt_code values, but doesn't provide format details (e.g., corp_code length validation, bsns_year range beyond '2015년 이후'), or examples. With 0% schema coverage, this partial compensation earns a baseline score.
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: '개인별 보수지급 금액(5억이상 상위5인) 정보를 제공합니다' (provides information on individual compensation payments of top 5 individuals with 500 million won or more). It specifies the verb '제공합니다' (provides) and resource '정보' (information) with scope '정기보고서 내' (within periodic reports). However, it doesn't explicitly differentiate from sibling tools like 'get_individual_compensation' or 'get_total_compensation', which appear related.
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_individual_compensation' or 'get_total_compensation', nor does it specify prerequisites, exclusions, or appropriate contexts beyond the basic parameter requirements. The agent must infer usage from the tool name and 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. While it indicates this is a read operation (정보를 제공합니다 - provides information), it doesn't mention any behavioral traits like rate limits, authentication requirements, error conditions, or what format the output takes. For a tool with no annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter documentation. The purpose is front-loaded, and the parameter explanations are concise yet informative. There's minimal wasted text, though the formatting could be slightly cleaner.
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 that an output schema exists, the description doesn't need to explain return values. However, for a tool with 3 parameters, 0% schema description coverage, and no annotations, the description provides adequate parameter semantics but lacks behavioral context. It's minimally viable but has clear gaps in usage guidance and transparency.
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 provides parameter documentation in Korean with clear explanations: corp_code (고유번호 8자리 - unique 8-digit code), bsns_year (사업연도 4자리, 2015년 이후 - 4-digit business year, 2015 onwards), and reprt_code with specific code mappings. With 0% schema description coverage, this documentation adds substantial value beyond the bare schema, though it doesn't fully compensate for the complete lack of schema descriptions.
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: '이사·감사 전체의 보수현황 - 정기보고서 내 이사·감사 전체의 보수현황 정보를 제공합니다' (Provides compensation status information for all directors/auditors within periodic reports). It specifies the resource (directors/auditors compensation status) and context (periodic reports), though it doesn't explicitly differentiate from sibling tools like get_compensation_by_type or get_individual_compensation.
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. There are multiple compensation-related sibling tools (get_compensation_by_type, get_individual_compensation, get_top5_compensation, get_unregistered_exec_compensation), but the description doesn't explain how this tool differs from them or when each should be used.
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 the resource type and date constraints, it doesn't describe whether this is a read-only operation, what permissions might be required, whether it returns paginated results, error conditions, or rate limits. For a tool with no annotation coverage, 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 efficiently structured with a clear purpose statement followed by parameter documentation. The bilingual approach (Korean purpose, English parameter names) is slightly inconsistent but functional. Every sentence serves a purpose with minimal waste, though the formatting could be cleaner.
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 that there's an output schema (which handles return values), no annotations, and 3 parameters with 0% schema coverage, the description does an adequate job. It covers the purpose and parameters but lacks behavioral context and usage guidance. For a financial data retrieval tool with sibling alternatives, it should provide more differentiation and operational 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 explicitly documents all three parameters with their Korean names and constraints (corp_code: 8-digit unique number, bgn_de/end_de: YYYYMMDD format after 2015). Since schema description coverage is 0%, this parameter documentation in the description is essential and adds meaningful semantics beyond the bare schema. However, it doesn't explain where to obtain corp_codes or provide examples of valid values.
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: '자기주식 취득 결정 - 주요사항보고서 내 자기주식 취득 결정 정보를 제공합니다' (Provides treasury stock acquisition decision information within major reports). It specifies the verb ('제공합니다' - provides) and resource ('자기주식 취득 결정 정보' - treasury stock acquisition decision information), but doesn't explicitly differentiate from sibling tools like 'get_treasury_stock_disposal_decision' or 'get_other_corp_stock_acquisition_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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools, prerequisites, or specific contexts where this tool is appropriate versus other treasury stock or acquisition-related tools in the list. The only implicit guidance is the date range constraint (2015년 이후 - after 2015).
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 only states what information is provided, without mentioning whether this is a read-only operation, what format the output takes, whether there are rate limits, authentication requirements, or error conditions. For a tool with no annotation coverage, this represents 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 appropriately concise with two sentences: a purpose statement followed by parameter documentation. The structure is clear with the purpose first and parameters in a labeled section. No unnecessary information is included, though the parameter documentation could be more efficiently integrated.
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 that there's an output schema (which handles return values), no annotations, and 3 parameters with 0% schema coverage, the description provides basic purpose and parameter semantics. However, for a financial data tool with no behavioral annotations, it should ideally include more about data freshness, source reliability, or typical use cases to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds basic semantics for all three parameters: corp_code (고유번호 - unique number, 8 digits), bgn_de (시작일 - start date, YYYYMMDD format, after 2015), and end_de (종료일 - end date, YYYYMMDD format, after 2015). This compensates somewhat for the schema gap but doesn't provide rich details like valid date ranges, corp_code format validation, or relationship between dates.
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: '자기주식 처분 결정 - 주요사항보고서 내 자기주식 처분 결정 정보를 제공합니다' (Provides treasury stock disposal decision information within major reports). It specifies the verb ('제공합니다' - provides) and resource ('자기주식 처분 결정 정보' - treasury stock disposal decision information). However, it doesn't explicitly differentiate from sibling tools like 'get_treasury_stock_acquisition_decision' or 'get_treasury_stock_status', which deal with related but different treasury stock matters.
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, specify use cases, or indicate prerequisites. The only contextual information is the date range constraint ('2015년 이후' - after 2015), but this is parameter documentation rather than usage guidance.
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 states the tool 'provides information,' which implies a read-only operation, but doesn't clarify authentication requirements, rate limits, error conditions, or response format. For a tool with no annotation coverage, this leaves significant behavioral gaps, though it correctly indicates a data retrieval function without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by a parameter list. It avoids unnecessary verbosity, with every sentence serving a functional role. The bilingual content (Korean and English) is handled compactly, though minor improvements in formatting could enhance readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values) but no annotations and low schema coverage, the description is moderately complete. It covers the purpose and parameters adequately but lacks behavioral details and usage guidelines. For a data retrieval tool with structured output, this is minimally viable but leaves room for improvement in contextual richness.
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 includes an Args section that documents all three parameters (corp_code, bsns_year, reprt_code) with semantic explanations in Korean, such as '고유번호(8자리)' for corp_code. Since schema description coverage is 0%, this adds crucial meaning beyond the bare schema. However, it doesn't fully compensate by explaining parameter interactions or constraints beyond basic descriptions, warranting a baseline score.
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: '자기주식 취득 및 처분 현황 - 정기보고서 내 자기주식 취득 및 처분 현황 정보를 제공합니다' translates to 'Treasury stock acquisition and disposal status - provides information on treasury stock acquisition and disposal status within periodic reports.' This specifies the verb (provides information) and resource (treasury stock acquisition/disposal status), though it doesn't explicitly differentiate from sibling tools like get_treasury_stock_acquisition_decision or get_treasury_stock_disposal_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?
The description provides no guidance on when to use this tool versus alternatives. While it mentions the context ('within periodic reports'), it doesn't specify prerequisites, appropriate scenarios, or contrast with sibling tools that might handle related treasury stock decisions or statuses. The parameter documentation implies usage for specific corporate reports but offers no strategic guidance.
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 indicates this is a read operation ('정보를 제공합니다' - provides information), but doesn't disclose important behavioral aspects like authentication requirements, rate limits, error conditions, response format, or whether it's idempotent. For a tool with no annotation coverage, 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 appropriately sized with a clear purpose statement followed by parameter documentation. The structure is logical and front-loaded with the main functionality. While efficient, the parameter documentation could be slightly more concise by avoiding repetition of obvious information like '8자리' for corp_code.
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 that an output schema exists (context signals indicate 'Has output schema: true'), the description doesn't need to explain return values. However, for a tool with 3 parameters, 0% schema description coverage, and no annotations, the description provides adequate basic information about what the tool does and what parameters mean, but lacks behavioral context that would be important for reliable 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 0%, but the description provides parameter documentation in Korean that explains each parameter's purpose: corp_code (고유번호), bsns_year (사업연도), and reprt_code (보고서코드 with specific code values). This adds meaningful semantics beyond the bare schema, though it doesn't fully compensate for the 0% schema coverage by explaining data formats or constraints.
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: '미등기임원 보수현황 - 정기보고서 내 미등기임원 보수현황 정보를 제공합니다' (Provides information on unregistered executive compensation in periodic reports). It specifies the verb '제공합니다' (provides) and resource '미등기임원 보수현황 정보' (unregistered executive compensation information), but doesn't explicitly differentiate from sibling tools like 'get_compensation_by_type' or 'get_individual_compensation' that also handle compensation 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. While it mentions '정기보고서' (periodic reports), it doesn't specify which types of compensation queries this tool handles versus other compensation-related tools in the sibling list, nor does it mention any prerequisites or exclusions for usage.
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 only states what information the tool provides, without mentioning whether this is a read-only operation, what authentication might be required, rate limits, error conditions, or response format. For a data retrieval 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with a clear purpose statement followed by parameter documentation. However, the parameter section uses a code-like formatting that could be more natural, and the overall structure could be improved by separating the purpose from parameter details more clearly. It's functional but not optimally structured.
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 that there's an output schema (which handles return values), no annotations, and the description provides good parameter semantics, the description is adequate but incomplete. It lacks behavioral context about the operation's nature (read-only, authentication needs, etc.) and doesn't help the agent understand when to use this versus similar tools. For a data retrieval tool with sibling alternatives, more contextual guidance would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaningful parameter documentation in Korean that adds substantial value beyond the 0% schema description coverage. It explains that corp_code is an 8-digit unique identifier, bsns_year is a 4-digit business year (2015+), and reprt_code corresponds to specific report types with code mappings. This compensates well for the schema's lack of descriptions.
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: '감사용역체결현황 - 정기보고서 내 감사용역체결현황 정보를 제공합니다' translates to 'Audit service contract status - provides information on audit service contract status within regular reports.' This specifies the verb (provides information) and resource (audit service contract status within reports), but doesn't explicitly differentiate from sibling tools like 'get_non_audit_service_contract' beyond the obvious audit vs non-audit distinction.
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. While the parameter documentation implies it's for retrieving audit service contract data for specific corporations and reporting periods, there's no explicit comparison with sibling tools or indication of prerequisites. 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 full burden. It mentions the source ('periodic reports') but doesn't disclose behavioral traits like whether this is a read-only operation, what authentication might be needed, rate limits, error conditions, or response format. For a tool with no annotation coverage, 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 reasonably concise with two sentences, but the structure could be improved. The first sentence is somewhat vague ('dividend-related matters'), and the parameter documentation is embedded in a code-like format rather than integrated naturally. It's front-loaded with purpose but could be more polished.
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 that there's an output schema (which handles return values), no annotations, and 3 parameters with good semantic coverage in the description, this is adequate but not comprehensive. The description covers the basics but lacks behavioral context and usage guidance that would be helpful for an agent.
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?
Schema description coverage is 0%, but the description provides clear parameter documentation in the Args section: it explains what each parameter represents (corp_code as 'unique number', bsns_year as 'business year', reprt_code with specific code mappings). This compensates well for the lack of schema descriptions, though it doesn't provide format examples or validation rules.
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 states the tool 'provides dividend-related information from periodic reports', which clearly indicates the verb (provide) and resource (dividend information). However, it doesn't differentiate from sibling tools like 'get_document' or 'search_disclosure' that might also provide financial information, 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 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 (like get_document, get_full_financial_statement, search_disclosure), there's no indication of when this specific dividend tool is appropriate versus other data sources.
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 only states what data is provided without mentioning whether this is a read-only operation, if there are rate limits, authentication requirements, or what format the output takes. The description doesn't contradict annotations (since none exist), but provides minimal behavioral context for a tool that presumably accesses financial data.
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 appropriately sized with a clear purpose statement followed by parameter documentation. However, the structure could be improved by front-loading more critical information about the tool's behavior and usage context. The parameter documentation is thorough but occupies most of the description space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and the description documents all parameters, the description is minimally complete. However, for a financial data tool with no annotations, it should provide more context about data freshness, source reliability, and typical use cases to be fully helpful to an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by documenting all 3 parameters in the Args section with clear explanations: corp_code (8-digit unique number), bsns_year (business year, 4 digits, 2015+), and reprt_code (report codes with specific values). This adds substantial meaning beyond the bare schema, though it doesn't explain parameter constraints or validation rules.
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: '공모자금의 사용내역 - 정기보고서 내 공모자금의 사용내역 정보를 제공합니다' (Provides public offering fund usage details from periodic reports). It specifies the resource (public offering funds) and the information provided (usage details from reports), but doesn't explicitly differentiate from sibling tools like 'get_private_placement_fund_usage' beyond the 'public' vs 'private' distinction in names.
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. While it mentions the data source (periodic reports), it doesn't indicate when this tool is appropriate compared to other financial data tools in the sibling list, nor does it mention prerequisites or exclusions for usage.
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 describes what the tool provides but lacks behavioral details such as whether it's a read-only operation, potential rate limits, authentication requirements, or what the output looks like. For a tool with no annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, followed by parameter details. However, the formatting includes extra whitespace and could be more streamlined. It's not overly verbose but could be more efficient in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values) and the description covers the single parameter well, it's somewhat complete. However, with no annotations and missing behavioral context, it falls short of being fully comprehensive for a tool that likely deals with financial data standards.
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 adds crucial meaning beyond the input schema, which has 0% coverage. It explains the 'sj_div' parameter with specific values (BS, IS, CIS, CF, SCE) and their Korean meanings, compensating fully for the schema's lack of documentation. This is effective for a single parameter tool.
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 provides XBRL taxonomy for financial statements based on IFRS standards, with a specific resource (XBRL taxonomy) and scope (IFRS-based). However, it doesn't explicitly differentiate from sibling tools like 'get_xbrl_document' or 'get_full_financial_statement,' which might be related but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 tool's function but offers no context about prerequisites, when it's appropriate, or how it differs from other tools in the server that might handle financial data or XBRL-related 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?
No annotations are provided, so the description carries full burden. It indicates this is a read operation ('정보를 제공합니다' - provides information) but doesn't disclose important behavioral aspects like authentication requirements, rate limits, error conditions, or response format. The date constraints (2015년 이후 - after 2015) are mentioned, but other operational characteristics 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 efficiently structured with a clear purpose statement followed by parameter documentation. The Korean text is concise, and the parameter explanations are direct. There's minimal redundancy, though the formatting with indentation could be cleaner.
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 that there's an output schema (which handles return values) and the description documents all parameters, the basics are covered. However, as a financial data tool with no annotations, it lacks important context about authentication, rate limits, error handling, and data freshness that would be valuable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant value by documenting all 3 parameters: corp_code (고유번호 8자리 - unique 8-digit code), bgn_de (시작일 YYYYMMDD 2015년 이후 - start date after 2015), and end_de (종료일 YYYYMMDD 2015년 이후 - end date after 2015). It provides format requirements and temporal constraints that aren't in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '자산양수도(기타), 풋백옵션 - 주요사항보고서 내 자산양수도 및 풋백옵션 정보를 제공합니다' (Provides asset transfer (other) and putback option information from major reports). It specifies the resource (asset transfer and putback option information) and verb (provides), but doesn't explicitly differentiate from sibling tools beyond the specific 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?
The description provides no guidance on when to use this tool versus alternatives. While it mentions the specific data type (asset transfer and putback options), it doesn't indicate prerequisites, constraints beyond date parameters, or when other tools might be more appropriate. The sibling list includes many other financial reporting tools, but no comparative context is 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 full burden. It states this is an information retrieval tool ('정보를 제공합니다'), implying read-only behavior, but doesn't disclose any behavioral traits like authentication requirements, rate limits, error conditions, or response format. For a tool with 3 required parameters and 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: one stating the purpose and one explaining parameters. The parameter explanations are clear and directly relevant. There's no wasted text, though the structure could be slightly improved by separating the purpose statement from the parameter documentation more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters, no annotations, but has an output schema, the description is moderately complete. It explains what the tool does and what each parameter means, which addresses the parameter coverage gap. However, it lacks behavioral context that would be important for a data retrieval tool, and while the output schema exists, the description doesn't hint at what kind of data structure to expect in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides essential semantic context for all 3 parameters: corp_code is explained as '고유번호(8자리)' (unique 8-digit code), bsns_year as '사업연도(4자리, 2015년 이후)' (business year, 4 digits, 2015 onwards), and reprt_code with specific report type codes. This compensates well for the schema's lack of descriptions, though it doesn't provide examples or format details beyond the basic explanations.
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: '회계감사인의 명칭 및 감사의견 - 정기보고서 내 회계감사인의 명칭 및 감사의견 정보를 제공합니다' (Provides auditor name and opinion information from periodic reports). It specifies the verb '제공합니다' (provides) and resource '회계감사인의 명칭 및 감사의견' (auditor name and opinion). However, it doesn't explicitly differentiate from sibling tools that also retrieve financial report data, though the specific focus on auditor opinions is implied.
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, prerequisites, or specific scenarios where this tool is appropriate. The only contextual information is that it works with '정기보고서' (periodic reports), but this doesn't help an agent choose between this and other financial data 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what information is provided without describing response format, pagination, error conditions, authentication requirements, rate limits, or whether this is a read-only operation. For a tool with 3 required parameters and 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 efficiently structured with a purpose statement followed by clearly formatted parameter documentation. Both sentences earn their place, though the formatting with indentation and line breaks could be more streamlined for pure text presentation.
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 3 required parameters with 0% schema coverage, the description adequately documents parameter semantics but lacks behavioral context. The existence of an output schema reduces the need to describe return values, but without annotations, the description should provide more operational guidance about what 'provides information' entails in practice.
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 provides explicit parameter documentation with Korean labels and format constraints (8-digit corp_code, YYYYMMDD dates after 2015). With 0% schema description coverage, this documentation fully compensates by explaining what each parameter represents and their temporal constraints, though it doesn't explain where to obtain corp_code values.
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 provides '영업양수 결정 정보' (business acquisition decision information) from '주요사항보고서' (major matters report). It specifies the resource (business acquisition decisions) and source document, but doesn't explicitly differentiate from sibling tools like 'get_business_transfer_decision' or 'get_other_corp_stock_acquisition_decision' that might handle related corporate actions.
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 doesn't mention prerequisites, limitations, or relationships to other tools in the extensive sibling list. 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what information is provided, without mentioning whether this is a read-only operation, what permissions might be required, rate limits, error conditions, or what format the output takes. For a tool with 3 required parameters and no annotation coverage, this is insufficient 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 appropriately sized with a clear purpose statement followed by a structured parameter explanation. The two-sentence structure is efficient, though the Korean-to-English transition in the purpose statement could be slightly smoother. Every element serves a purpose with minimal waste.
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 that an output schema exists (which handles return values), the description covers the basic purpose and parameters adequately. However, for a tool with 3 required parameters and no annotations, it should ideally provide more behavioral context about what the tool actually does with those parameters and what kind of information is returned, even with an output schema available.
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 provides clear parameter semantics in the Args section, explaining that corp_code is an 8-digit unique identifier and that bgn_de/end_de are start/end dates in YYYYMMDD format with a 2015+ constraint. With 0% schema description coverage, this documentation fully compensates by adding essential format and constraint information not present in the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '영업정지 - 주요사항보고서 내 영업정지 정보를 제공합니다' (Business suspension - provides business suspension information within major matter reports). It specifies both the verb ('provides') and resource ('business suspension information'), though it doesn't explicitly differentiate from sibling tools beyond the specific domain of business suspensions.
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. While sibling tools like 'get_document' or 'search_disclosure' might overlap in accessing corporate information, there's no explicit comparison or context for choosing this specific business suspension tool over other disclosure-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 full burden. It mentions the output is base64-encoded ZIP, which is useful behavioral information. However, it doesn't disclose important traits like whether this is a read-only operation, potential rate limits, authentication requirements, or what happens if no data is available. For a 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 sentence that conveys the essential information: what data is returned, in what format, and how it's encoded. There's no wasted verbiage or redundant information. It could potentially benefit from a second sentence about usage context, but as a standalone description it's appropriately concise.
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 that the tool has an output schema (which presumably documents the return structure), the description doesn't need to explain return values in detail. However, for a tool with no annotations and many sibling alternatives, the description should provide more context about when and why to use this specific tool. The current description is adequate but leaves important contextual gaps.
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 zero parameters with 100% schema description coverage. The description appropriately doesn't waste space discussing non-existent parameters. It focuses on what the tool does rather than what inputs it accepts, which is correct for a parameterless tool.
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: it returns a ZIP file containing corporate codes from DART with specific data fields (unique numbers, company names, stock codes). It specifies the format (ZIP file) and encoding (base64). However, it doesn't explicitly differentiate from sibling tools, which all appear to retrieve different types of DART 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 compare it to other tools that might retrieve corporate information. With many sibling tools available, this lack of context is a significant gap.
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 only states that the tool 'provides information' without specifying whether this is a read-only operation, what format the output takes, whether there are rate limits, authentication requirements, or error conditions. For a tool with 3 parameters and an 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 efficiently structured with a clear purpose statement followed by parameter explanations. The parameter documentation is well-organized with meaningful explanations. There's minimal wasted text, though the formatting with indentation could be slightly cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with 0% schema coverage but an output schema exists, the description does a reasonable job explaining parameter semantics. However, with no annotations and no behavioral context about what the tool actually returns or how it behaves, there are significant gaps. The presence of an output schema helps but doesn't fully compensate for the lack of operational context.
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 adds substantial semantic value beyond the input schema, which has 0% description coverage. It explains that 'corp_code' is an 8-digit unique identifier, 'bsns_year' is a 4-digit business year (2015 onward), and 'reprt_code' corresponds to specific report types with clear code mappings. This compensates well for the schema's lack of descriptions.
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 provides '채무증권 발행실적 정보' (debt securities issuance performance information) from regular reports. It specifies the verb '제공합니다' (provides) and resource '채무증권 발행실적' (debt securities issuance performance). However, it doesn't explicitly differentiate from sibling tools like 'get_debt_securities_reg' or 'get_corporate_bond_balance', which appear related.
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, doesn't specify prerequisites beyond the parameters, and offers no context about appropriate use cases or limitations. The only implicit usage context is that it retrieves data from regular reports.
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 '제공합니다' (provides) suggests a read-only operation, the description doesn't explicitly state whether this is a safe read operation, what permissions might be required, whether there are rate limits, or what the response format looks like. 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 efficiently structured with a clear purpose statement followed by a well-formatted parameter documentation section. Every sentence earns its place, though the formatting with indentation could be slightly cleaner. The information is front-loaded with the core purpose immediately stated.
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 that there's an output schema (which handles return values), no annotations, and the description fully documents all parameters, the description is reasonably complete for a read operation. However, it lacks behavioral context about permissions, rate limits, or error conditions that would be helpful for an agent, and provides no usage guidance relative to sibling tools.
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 includes an Args section that documents all three parameters (corp_code, bgn_de, end_de) with clear Korean labels and format specifications (YYYYMMDD for dates, 8-digit code). With 0% schema description coverage, this documentation in the description fully compensates for the schema gap, providing essential semantic context that the schema's bare titles lack.
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: '채무증권 - 증권신고서 내 채무증권 요약정보를 제공합니다' (Debt securities - provides summary information of debt securities within securities registration statements). It specifies both the resource (debt securities) and the action (provides summary information). However, it doesn't explicitly differentiate from sibling tools like 'get_debt_securities_issued' or 'get_corporate_bond_balance', which appear related but not identical.
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. There's no mention of prerequisites, appropriate contexts, or comparisons to sibling tools like 'get_debt_securities_issued' or 'get_corporate_bond_balance'. The agent must infer usage from the tool name and 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. It states the tool '제공합니다' (provides) information, which implies a read-only operation, but doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the output takes. The description lacks crucial behavioral context for a tool that appears to query financial regulatory data.
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: one stating the purpose and one documenting parameters. The parameter documentation is clearly formatted with each parameter on its own line. No unnecessary information is included, though the parameter documentation could be slightly more integrated with the purpose statement.
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 3 required parameters, no annotations, and an output schema (which exists according to context signals), the description is minimally adequate. It covers the purpose and parameters but lacks behavioral context about authentication, rate limits, or output format. The presence of an output schema reduces the need to describe return values, but the description should still address operational constraints for this financial data query tool.
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 explicitly lists all three parameters with their Korean names and provides semantic context: 'corp_code: 고유번호(8자리)' (unique number, 8 digits), 'bgn_de: 시작일(YYYYMMDD)' (start date), 'end_de: 종료일(YYYYMMDD)' (end date). With 0% schema description coverage, this parameter documentation in the description is essential and provides meaningful context beyond the bare schema field names.
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: '분할 - 증권신고서 내 분할 요약정보를 제공합니다' (Division - provides summary information of division within securities registration statements). It specifies the verb '제공합니다' (provides) and resource '분할 요약정보' (division summary information). However, it doesn't explicitly distinguish this tool from sibling tools like 'get_division_decision' or 'get_division_merger_decision', which appear to be related to division decisions rather than registration statements.
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. There are multiple sibling tools related to divisions (get_division_decision, get_division_merger_decision) and registrations (get_merger_reg, get_equity_securities_reg), but the description doesn't explain how this tool differs from them or when it should be selected over those alternatives.
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 states this is a data retrieval tool ('정보를 제공합니다'), implying read-only behavior, but doesn't disclose important details like rate limits, authentication requirements, error conditions, or response format. For a tool with zero annotation coverage, this represents 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 appropriately concise with two sentences: one stating the purpose and one explaining parameters. The parameter explanations are clear and specific. There's no wasted text, though the structure could be slightly improved by separating the purpose statement from parameter documentation more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 3 parameters with 0% schema coverage, and no annotations, the description does an adequate job. It covers the purpose and parameter meanings, but lacks behavioral context and usage guidance. For a data retrieval tool with sibling alternatives, this represents a minimum viable level of completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides crucial parameter semantics that aren't in the schema. It explains that corp_code is an 8-digit unique identifier, bsns_year is a 4-digit business year (2015+), and reprt_code corresponds to specific report types with code mappings. This adds substantial value beyond the bare schema, though it doesn't cover all possible parameter nuances.
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: '이사·감사의 개인별 보수현황 - 정기보고서 내 이사·감사의 개인별 보수현황 정보를 제공합니다' (Provides individual compensation information for directors/auditors from periodic reports). It specifies the verb ('제공합니다' - provides) and resource (individual compensation data), though it doesn't explicitly differentiate from sibling tools like get_compensation_by_type or get_top5_compensation.
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. There are several compensation-related sibling tools (get_compensation_by_type, get_top5_compensation, get_total_compensation, get_unregistered_exec_compensation), but the description offers no comparison or context about which tool to choose for different 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 full burden for behavioral disclosure. While it indicates this is an information retrieval tool ('정보를 제공합니다'), it doesn't address important behavioral aspects like whether this requires authentication, rate limits, error conditions, or what format the output takes. The description is minimal and 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 efficiently structured with a clear purpose statement followed by parameter explanations. The bilingual presentation (Korean purpose, English parameter names) is slightly inconsistent but doesn't significantly impact clarity. Every sentence serves a purpose with minimal waste.
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 that an output schema exists, the description doesn't need to explain return values. However, for a tool with 3 parameters and no annotations, the description provides adequate parameter semantics but lacks behavioral context about authentication, rate limits, or error handling. It's minimally complete but leaves operational questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides crucial semantic context for all three parameters: corp_code (8-digit unique number), bsns_year (business year, 2015 onward), and reprt_code (report codes with specific mappings). This compensates well for the lack of schema documentation, though it doesn't explain parameter constraints beyond the basics.
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: '최대주주 변동현황 정보를 제공합니다' (provides largest shareholder change information). It specifies the source ('정기보고서 내' - within periodic reports) and the type of data. However, it doesn't explicitly differentiate from sibling tools like 'get_largest_shareholder' or 'get_major_stockholding', which appear related but have different scopes.
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 appear to retrieve different types of shareholder or financial information (e.g., get_largest_shareholder, get_major_stockholding, get_executive_stockholding), there's no indication of how this tool differs or when it should be selected over those options.
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 states the tool 'provides information' which suggests a read-only operation, but doesn't explicitly confirm this or describe other behavioral aspects like authentication requirements, rate limits, error conditions, or response format. The description mentions the source ('regular reports') which adds some context, but lacks comprehensive behavioral transparency 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 appropriately sized and well-structured with a clear purpose statement followed by parameter documentation. The bilingual presentation (Korean purpose statement, English parameter names) is slightly inefficient but not wasteful. Every sentence serves a purpose, and the information is front-loaded with the core functionality stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and 3 parameters fully documented in the description, the description is moderately complete. It explains what the tool does and documents all parameters, but lacks behavioral context (permissions, rate limits, errors) and usage guidance relative to sibling tools. For a read-oriented data retrieval tool, this represents a minimum viable level of completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (no descriptions in the input schema properties), the description provides all parameter documentation through the Args section. It clearly explains each parameter: corp_code (8-digit unique number), bsns_year (business year, 4-digit, 2015 onward), and reprt_code (report code with specific values). This adds substantial meaning beyond the bare schema, though it doesn't explain parameter relationships or validation rules.
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: '소액주주 현황 - 정기보고서 내 소액주주 현황 정보를 제공합니다' translates to 'Minority shareholder status - provides minority shareholder status information within regular reports.' This specifies the verb (provides), resource (minority shareholder status information), and scope (within regular reports). However, it doesn't explicitly differentiate from sibling tools like 'get_largest_shareholder' or 'get_major_stockholding' that also provide shareholder 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. It doesn't mention sibling tools like 'get_largest_shareholder' or 'get_major_stockholding' that might provide related shareholder information, nor does it specify prerequisites or appropriate contexts for use. The parameter documentation implies usage for specific corporate reports, but no explicit usage guidelines 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what data is provided without describing how the tool behaves: no information about response format, error conditions, rate limits, authentication requirements, or whether this is a read-only operation. 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 efficiently structured with a clear purpose statement followed by parameter documentation. The parameter explanations are concise yet informative. No unnecessary verbiage, though the formatting with indentation could be cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and the description provides good parameter semantics, the main gap is behavioral transparency. For a financial data retrieval tool with 3 parameters and no annotations, the description should ideally mention whether this is a read-only operation, typical response structure, or any constraints beyond the parameters documented.
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 provides meaningful parameter documentation despite 0% schema description coverage. It explains: corp_code as '고유번호(8자리)' (unique 8-digit code), bsns_year as '사업연도(4자리, 2015년 이후)' (business year, 4 digits, after 2015), and reprt_code with specific code mappings for different report types. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '신종자본증권 미상환 잔액 정보를 제공합니다' (provides information on outstanding balance of new capital securities). It specifies the resource (new capital securities balance) and context (within periodic reports), but doesn't explicitly differentiate from sibling tools like 'get_contingent_capital_balance' or 'get_corporate_bond_balance' which might cover similar 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. While it mentions the data comes from '정기보고서' (periodic reports), it doesn't explain when this specific balance information is needed compared to other financial data tools in the sibling list, nor does it mention any prerequisites or exclusions.
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 states what information is provided but doesn't describe the tool's behavior: whether it's a read-only query, what format the output takes, whether there are rate limits, authentication requirements, or error conditions. 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 efficiently structured with a clear purpose statement followed by parameter documentation. The bilingual presentation (Korean purpose, English parameter names) is slightly inconsistent but functional. No sentences are wasted, though the formatting with indentation could be cleaner for an MCP tool definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and the description provides parameter semantics, the basics are covered. However, for a financial data tool with no annotations and complex sibling relationships, the description should provide more context about what constitutes 'paid capital increase' versus other types, and behavioral aspects like data freshness or source reliability.
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 provides meaningful parameter explanations beyond the schema's 0% coverage. It clarifies that 'corp_code' is an 8-digit unique identifier, 'bgn_de' is a start date in YYYYMMDD format, 'end_de' is an end date in the same format, and both dates must be 2015 or later. This compensates well for the schema's lack of descriptions, though it doesn't explain validation rules or provide examples.
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: providing paid capital increase decision information from major issue reports. It specifies the resource ('유상증자 결정 정보' - paid capital increase decision information) and source ('주요사항보고서 내' - within major issue reports). However, it doesn't explicitly differentiate from sibling tools like 'get_free_capital_increase' or 'get_mixed_capital_increase' beyond the 'paid' qualifier in the name.
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 doesn't mention sibling tools like 'get_free_capital_increase' or 'get_mixed_capital_increase' that handle related capital increase types, nor does it specify prerequisites or appropriate contexts for use. The only implicit guidance is the date range constraint (2015 onward).
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 implies this is a read-only data retrieval tool (consistent with 'get_' naming), it doesn't explicitly state this, nor does it mention any rate limits, authentication requirements, error conditions, or what the output contains. The description is minimal and doesn't provide adequate behavioral context 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 efficiently structured with a clear purpose statement followed by well-organized parameter documentation. The parameter explanations are concise yet informative. While the Korean text might require translation for some agents, the structure itself is clean and 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?
Given that the tool has an output schema (which handles return values), no annotations, and the description provides excellent parameter semantics, the description is reasonably complete for a data retrieval tool. However, it lacks behavioral context about what kind of data is returned, potential limitations, or error conditions, which would be helpful despite the output schema.
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 provides excellent parameter semantics despite 0% schema description coverage. It clearly explains each parameter: corp_code (8-digit unique number), bsns_year (business year, 4-digit, 2015 onward), and reprt_code (report code with specific values for quarterly/half-year/3-quarter/annual reports). This fully compensates for the lack of schema descriptions and provides meaningful context for all 3 required 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: '단기사채 미상환 잔액 - 정기보고서 내 단기사채 미상환 잔액 정보를 제공합니다' (provides short-term bond outstanding balance information from periodic reports). It specifies both the resource (short-term bond balance) and the source (periodic reports), though it doesn't explicitly differentiate from sibling tools like get_commercial_paper_balance or get_corporate_bond_balance.
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 financial disclosures and bond information, there's no indication of when this specific tool is appropriate versus tools like get_commercial_paper_balance or get_corporate_bond_balance. The parameter documentation implies usage context but doesn't provide explicit guidance.
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 states the tool provides key accounts from XBRL financial statements, implying a read-only operation, but doesn't clarify data format, pagination, rate limits, authentication needs, or error handling. For a tool with zero annotation coverage, this leaves significant behavioral gaps, though it's not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise and structured: a clear purpose statement followed by parameter explanations in a bullet-like format. Every sentence adds value, with no redundant information. It could be slightly improved by front-loading the purpose more prominently, but overall it's efficient and well-organized.
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 (3 required parameters, no annotations, but with an output schema), the description is moderately complete. It covers the purpose and parameter semantics adequately, but lacks behavioral details (e.g., response format, errors). The presence of an output schema means the description doesn't need to explain return values, but it should still address usage context and operational traits, which are insufficient here.
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 adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains each parameter: 'corp_code' as a unique 8-digit code, 'bsns_year' as a business year from 2015 onward, and 'reprt_code' with specific codes for quarterly/half-year/annual reports. This compensates well for the schema's lack of descriptions, though it doesn't cover all possible nuances (e.g., format examples for corp_code).
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 재무제표에서 주요계정을 제공합니다' (provides key accounts from a single company's XBRL financial statements). It specifies the verb '제공합니다' (provides) and resource '주요계정' (key accounts) with context about XBRL financial statements. However, it doesn't explicitly differentiate from sibling tools like 'get_multi_company_accounts' or 'get_full_financial_statement', which would be needed for a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_multi_company_accounts' for multiple companies or 'get_full_financial_statement' for comprehensive data, nor does it specify prerequisites or exclusions. The only implicit usage hint is the parameter descriptions, but no explicit when/when-not instructions 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 full burden. It states the tool '정보를 제공합니다' (provides information), implying a read-only operation, but doesn't disclose any behavioral traits like authentication requirements, rate limits, response format, or error conditions. For a 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 sized with a clear purpose statement followed by parameter documentation. The Args section is structured but could be more integrated. There's minimal waste, though the formatting with indentation could be cleaner. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values) but zero annotation coverage, the description is moderately complete. It covers the purpose and parameters well, but lacks behavioral context about how the tool operates. For a read-only query tool with 3 parameters, this is adequate but could benefit from more operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate - and it does by documenting all 3 parameters with their Korean names and constraints. It explains corp_code is an 8-digit unique identifier, and both date parameters require YYYYMMDD format with the constraint '2015년 이후' (after 2015). This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '주권 관련 사채권 양수 결정 정보를 제공합니다' (provides information about stock-related bond acquisition decisions). It specifies the source ('주요사항보고서 내' - within major fact reports) and distinguishes from siblings by focusing on stock-related bond acquisitions rather than other types of decisions. However, it doesn't explicitly differentiate from similar tools like get_bond_with_warrant_decision or get_convertible_bond_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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools dealing with various corporate decisions (bond decisions, acquisitions, transfers), there's no indication of when this specific stock-related bond acquisition decision tool is appropriate versus other bond or acquisition decision tools. The date range constraint (2015년 이후 - after 2015) is a parameter requirement, not usage guidance.
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 only states what information is provided, without mentioning whether this is a read-only operation, if there are rate limits, authentication requirements, what format the output takes, or any error conditions. For a tool with 3 required parameters and 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 efficiently structured with a clear purpose statement followed by a well-formatted parameter documentation section. Both sentences earn their place, though the Korean text might require translation for some agents. No redundant information is present.
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 that an output schema exists, the description doesn't need to explain return values. However, for a tool with 3 required parameters and no annotations, the description should provide more behavioral context about how the tool operates, what happens with invalid dates, or what 'summary information' entails. The parameter documentation is good, but overall completeness is only adequate.
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 includes an Args section that documents all 3 parameters with clear explanations: corp_code (8-digit unique number), bgn_de (start date in YYYYMMDD format), and end_de (end date in YYYYMMDD format). With 0% schema description coverage, this parameter documentation in the description fully compensates and provides essential semantic context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '주식의 포괄적 교환·이전 요약정보를 제공합니다' (provides summary information of comprehensive stock exchange/transfer in securities registration statements). It specifies the resource (stock exchange/transfer information) and verb (provides), but doesn't explicitly differentiate from sibling tools like 'get_stock_exchange_transfer_decision' or 'get_stock_bond_transfer_decision' which appear related.
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 doesn't mention any prerequisites, exclusions, or recommend other tools for different types of stock-related information. Given the many sibling tools with similar naming patterns, this is a significant gap.
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 states the tool 'provides information,' which implies a read-only operation, but doesn't specify authentication needs, rate limits, response format, or error handling. For a tool with no 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 appropriately sized and front-loaded: the first sentence states the purpose, followed by a structured Args section. There's no wasted text, and the information is organized for quick understanding, though minor formatting issues (e.g., indentation) slightly affect structure.
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 that there's an output schema (context signals indicate true), the description doesn't need to explain return values. However, with no annotations and a focus on financial data retrieval, it lacks details on behavioral aspects like data freshness, limitations, or error cases. The parameter documentation is strong, but overall completeness is moderate due to missing operational context.
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 includes an Args section that documents all three parameters (corp_code, bsns_year, reprt_code) with semantic details: corp_code is an 8-digit unique number, bsns_year is a 4-digit business year from 2015 onward, and reprt_code specifies report types with codes. Since schema description coverage is 0%, this fully compensates by adding meaning beyond the bare schema, making parameters clear and usable.
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: '증자(감자) 현황 - 정기보고서 내 증자/감자 현황 정보를 제공합니다' translates to 'Stock issuance/reduction status - provides information on stock issuance/reduction status within periodic reports.' This specifies the verb (provides information) and resource (stock issuance/reduction status from reports). It distinguishes from siblings by focusing on stock issuance/reduction status specifically, though it doesn't explicitly contrast with similar 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. It doesn't mention prerequisites, timing considerations, or how it differs from other stock-related tools in the sibling list (e.g., get_capital_reduction, get_paid_capital_increase). Usage is implied only by the description's focus on stock issuance/reduction status in reports.
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 the source ('major reports') and that it 'provides information,' implying a read-only operation, but doesn't disclose authentication needs, rate limits, pagination, error conditions, or what specific information is returned. For a tool with 3 parameters and no 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 appropriately sized with two sentences: one stating the purpose and another detailing parameters. It's front-loaded with the core function, and the parameter explanations are necessary given the 0% schema coverage. No wasted sentences, though the Korean language might require translation for some agents.
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 3 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is moderately complete. It covers parameter semantics well but lacks behavioral context (e.g., read/write nature, error handling). The output schema likely handles return values, so that gap is mitigated, but for a tool with no annotations, more operational guidance would improve completeness.
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?
Schema description coverage is 0%, but the description compensates by explaining all 3 parameters in Korean: 'corp_code: 고유번호(8자리)', 'bgn_de: 시작일(YYYYMMDD, 2015년 이후)', 'end_de: 종료일(YYYYMMDD, 2015년 이후)'. It adds meaning by specifying format (8-digit code, YYYYMMDD), constraints (2015 or later), and semantic roles (start date, end date), which the schema's generic titles ('Corp Code', 'Bgn De', 'End De') lack.
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: '유형자산 양수 결정 - 주요사항보고서 내 유형자산 양수 결정 정보를 제공합니다' (Tangible asset acquisition decision - provides information about tangible asset acquisition decisions within major reports). It specifies the verb ('provides information') and resource ('tangible asset acquisition decisions'), but doesn't explicitly differentiate from sibling tools like 'get_tangible_asset_transfer_decision' or 'get_asset_transfer_putback', which appear related.
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, constraints beyond date parameters, or how it differs from similar tools in the sibling list. 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an information-providing tool but doesn't specify whether it's read-only, what permissions might be needed, rate limits, or what format the output takes. While '정보를 제공합니다' implies a read operation, it lacks details about authentication requirements, response structure, or potential limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. The first sentence clearly states the purpose, followed by a well-formatted Args section that explains each parameter. There's no wasted text, though the formatting with indentation could be slightly cleaner for machine parsing.
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 that there's an output schema (which handles return values), no annotations, and 3 parameters with good semantic coverage in the description, the description is reasonably complete. However, it lacks behavioral context about authentication, rate limits, or error conditions that would be important for a production API tool. The parameter explanations are strong, but overall context about the tool's operation is minimal.
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 provides excellent parameter semantics despite 0% schema description coverage. It clearly explains each parameter: corp_code as '고유번호(8자리)' (unique 8-digit code), bsns_year as '사업연도(4자리, 2015년 이후)' (business year, 4 digits, 2015 onward), and reprt_code with specific code mappings (11013:1분기, etc.). This fully compensates for the schema's lack of descriptions.
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: '이사·감사 전체의 보수현황(주주총회 승인금액) 정보를 제공합니다' (provides information on total compensation status of directors/auditors approved by shareholders' meeting). It specifies the verb ('제공합니다' - provides) and resource ('보수현황' - compensation status), but doesn't explicitly differentiate from sibling tools like 'get_compensation_by_type' or 'get_individual_compensation'.
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_compensation_by_type' or 'get_individual_compensation' that appear related to compensation data. There's no context about when this specific 'total compensation approval' data is needed versus other compensation-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 full burden. It states this is an information-providing tool ('정보를 제공합니다'), implying read-only behavior, but doesn't disclose any behavioral traits like authentication requirements, rate limits, response format, or error conditions. For a 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 appropriately sized with a clear purpose statement followed by a structured Args section. Every sentence earns its place, though the formatting could be slightly cleaner. It's 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?
Given the tool has an output schema (which handles return values), no annotations, and 3 parameters with good semantic coverage in the description, the description is moderately complete. However, it lacks behavioral context and usage guidelines that would be important for proper tool invocation, especially without annotations.
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?
Schema description coverage is 0%, but the description provides clear parameter semantics in the Args section: corp_code (고유번호), bsns_year (사업연도), and reprt_code (보고서코드) with specific format constraints and code explanations. This fully compensates for the lack of schema descriptions, though it doesn't explain parameter relationships or validation rules.
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: '주식의 총수 현황 - 정기보고서 내 주식의 총수 현황 정보를 제공합니다' (Total shares status - provides total shares status information within periodic reports). It specifies the verb '제공합니다' (provides) and resource '주식의 총수 현황 정보' (total shares status information), though it doesn't explicitly differentiate from sibling tools like get_stock_issuance_status or get_treasury_stock_status.
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 it provides information from '정기보고서' (periodic reports), but doesn't specify prerequisites, exclusions, or when to choose other stock-related tools. This leaves the agent without 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 full burden. It mentions the source ('주요사항보고서' - major report) and date constraints ('2015년 이후' - after 2015), but doesn't disclose whether this is a read-only operation, what permissions might be needed, rate limits, error conditions, or what the output contains. For a tool with no 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 efficiently structured with a clear purpose statement followed by parameter explanations. The Korean text is concise, and the Args section is well-organized. However, the English translation in parentheses could be more consistent ('시작일' translated as 'bgn_de' rather than 'start date').
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 that an output schema exists (context signals indicate 'Has output schema: true'), the description doesn't need to explain return values. However, for a tool with 3 parameters, 0% schema coverage, and no annotations, the description provides adequate parameter semantics but lacks behavioral context and usage guidance. The presence of an output schema raises the baseline, but the description could better address when to use this versus sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds crucial parameter semantics. It explains that corp_code is an 8-digit unique identifier, bgn_de is a start date in YYYYMMDD format after 2015, and end_de is an end date in YYYYMMDD format after 2015. This compensates well for the schema's lack of descriptions, though it doesn't explain validation rules or format constraints beyond the basic pattern.
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: '자기주식취득 신탁계약 체결 결정 - 주요사항보고서 내 자기주식취득 신탁계약 체결 결정 정보를 제공합니다' (Provides treasury stock acquisition trust contract decision information from major report). It specifies the verb ('제공합니다' - provides) and resource ('정보' - information), but doesn't explicitly differentiate from sibling tools like 'get_treasury_stock_acquisition_decision' or 'get_treasury_trust_termination_decision' which appear related.
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 multiple treasury/stock-related sibling tools (get_treasury_stock_acquisition_decision, get_treasury_stock_disposal_decision, get_treasury_trust_termination_decision), there's no indication of how this specific trust contract decision tool differs or when it's appropriate versus those other 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 full burden for behavioral disclosure. It indicates this is a read operation (정보를 제공합니다 - provides information) but doesn't mention authentication requirements, rate limits, error conditions, response format, or whether the data is real-time/historical. For a tool with 3 parameters and 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 appropriately concise with two sentences: one stating the purpose and one documenting parameters. The parameter documentation is structured clearly with bullet-like formatting. No wasted words, though the Korean-only text might limit accessibility for non-Korean agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, but does have an output schema, the description is minimally adequate. It covers parameter semantics well but lacks behavioral context and usage guidance. The output schema existence means return values don't need explanation, but more operational context would be helpful for this financial data tool.
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 provides clear semantic meaning for all 3 parameters beyond the schema (which has 0% description coverage). It explains corp_code is an 8-digit unique identifier, bgn_de is start date in YYYYMMDD format after 2015, and end_de is end date with same constraints. This fully compensates for the schema's lack of descriptions.
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: providing information about treasury stock acquisition trust contract termination decisions from major reports. It specifies the resource ('자기주식취득 신탁계약 해지 결정 정보') and the source ('주요사항보고서'), though it doesn't explicitly differentiate from sibling tools beyond the specific 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools, prerequisites, or specific use cases. The only contextual information is the date range requirement (2015+), but this is parameter documentation rather than usage guidance.
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 states this is an information-providing tool, which implies read-only behavior, but doesn't specify whether it requires authentication, has rate limits, returns paginated results, or what the output format looks like. The description lacks details about error conditions, data freshness, or any side effects, leaving significant gaps 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 appropriately concise with two sentences: one stating the purpose and another listing parameters. The parameter documentation is structured clearly with bullet-like formatting. There's no unnecessary repetition or verbose explanations, though the dual-language presentation (Korean purpose statement, English parameter names) could be slightly confusing.
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 that there's an output schema (which handles return values), no annotations, and 3 parameters with 0% schema coverage, the description does the minimum required: it states the purpose and documents parameters. However, for a financial data tool with no behavioral annotations, it should ideally include more context about data sources, update frequency, or authentication requirements 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 description includes an Args section that documents all three parameters (corp_code, bgn_de, end_de) with brief explanations in Korean. Since schema description coverage is 0%, this adds meaningful value beyond the bare schema. However, the explanations are minimal ('고유번호(8자리)' for corp_code, date format constraints for bgn_de/end_de) and don't elaborate on where to obtain corp_code values or how date ranges are interpreted.
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: '전환사채권 발행결정 - 주요사항보고서 내 전환사채권 발행결정 정보를 제공합니다' (Provides convertible bond issuance decision information from major matter reports). It specifies the verb ('제공합니다' - provides) and resource ('전환사채권 발행결정 정보' - convertible bond issuance decision information), though it doesn't explicitly differentiate from sibling tools like 'get_bond_with_warrant_decision' or 'get_exchangeable_bond_decision'.
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 context by mentioning '주요사항보고서 내' (within major matter reports), suggesting this tool retrieves information from regulatory filings. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like other bond-related tools in the sibling list, nor does it mention any prerequisites or exclusions beyond the date range constraint noted in the parameters.
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 indicates this is a read operation ('정보를 제공합니다' - provides information) but doesn't mention authentication requirements, rate limits, error conditions, or what the output contains. The description is functional but lacks important operational context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter explanations. Each sentence adds value, though the parameter section could be more integrated with the main description. There's no unnecessary verbosity, and 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?
Given 3 parameters with 0% schema coverage and no annotations, the description provides adequate parameter semantics but lacks behavioral context. The existence of an output schema reduces the need to describe return values, but for a tool with no annotations and moderate complexity, more operational guidance would be beneficial. The description is minimally complete but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides only parameter names without descriptions. The description adds meaningful semantics by explaining: corp_code as '고유번호(8자리)' (unique 8-digit code), bsns_year as '사업연도(4자리, 2015년 이후)' (business year, 4 digits, 2015 onward), and reprt_code with specific code mappings. This compensates partially but doesn't fully document all parameter constraints or formats.
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: '임원 현황 - 정기보고서 내 임원 현황 정보를 제공합니다' (Executive status - provides executive status information within periodic reports). It specifies the verb '제공합니다' (provides) and resource '임원 현황 정보' (executive status information), though it doesn't explicitly differentiate from sibling tools like 'get_executive_stockholding' or 'get_outside_director_status'.
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 context by mentioning '정기보고서 내' (within periodic reports) and listing specific report codes, suggesting this tool is for retrieving executive data from formal corporate filings. However, it doesn't provide explicit guidance on when to use this versus similar executive-related tools or mention any prerequisites or alternatives.
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 states the tool '제공합니다' (provides information), which implies a read-only operation, but doesn't confirm this or describe any behavioral traits like rate limits, authentication needs, error conditions, or response format. For a tool with zero annotation coverage, 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 appropriately sized and front-loaded: the first sentence states the purpose, followed by a structured parameter list. There's no wasted text, and each part earns its place. However, the formatting with indentation in the Args section is slightly inconsistent, and it could be more polished, preventing a perfect score.
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 (3 required parameters, no annotations, but has an output schema), the description is partially complete. It covers the purpose and parameters well, but lacks behavioral context (e.g., read-only nature, error handling). The presence of an output schema means the description doesn't need to explain return values, but it should still address basic operational traits. This results in a minimum viable but incomplete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explains all three parameters in Korean: 'corp_code: 고유번호(8자리)' (unique number, 8 digits), 'bsns_year: 사업연도(4자리, 2015년 이후)' (business year, 4 digits, after 2015), and 'reprt_code: 보고서코드 (11013:1분기, 11012:반기, 11014:3분기, 11011:사업보고서)' (report code with specific codes and meanings). This fully compensates for the schema's lack of descriptions, providing clear semantics and constraints.
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: '회사채 미상환 잔액 - 정기보고서 내 회사채 미상환 잔액 정보를 제공합니다' (Corporate bond outstanding balance - provides information on corporate bond outstanding balances in periodic reports). It specifies the verb ('제공합니다' - provides) and resource ('회사채 미상환 잔액 정보' - corporate bond outstanding balance information), making the purpose clear. However, it doesn't explicitly differentiate from sibling tools like get_short_term_bond_balance or get_commercial_paper_balance, which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like get_short_term_bond_balance or get_commercial_paper_balance, nor does it specify prerequisites or exclusions. The parameter descriptions imply usage context (e.g., '정기보고서 내' - within periodic reports), but this is too vague to constitute explicit guidelines.
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 indicates this is a read operation ('정보를 제공합니다' - provides information) which is helpful, but doesn't disclose other important behavioral aspects: whether it requires authentication, rate limits, pagination behavior, error conditions, or what format the output takes. For a tool with 3 required parameters and an output schema, 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 efficiently structured with a clear purpose statement followed by parameter documentation. The Korean text is direct and each sentence serves a purpose. While slightly longer due to bilingual parameter documentation, it maintains focus without unnecessary elaboration. The formatting with clear parameter sections enhances readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters, no annotations, but does have an output schema, the description provides adequate but incomplete context. The parameter semantics are well-covered, and the purpose is clear, but behavioral aspects are underspecified. The existence of an output schema means the description doesn't need to explain return values, but other operational context (authentication, errors, etc.) is missing for a tool with required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides essential parameter context that the schema lacks. It clearly explains: 'corp_code: 고유번호(8자리)' (unique 8-digit code), 'bgn_de: 시작일(YYYYMMDD, 2015년 이후)' (start date in YYYYMMDD format, after 2015), and 'end_de: 종료일(YYYYMMDD, 2015년 이후)' (end date in YYYYMMDD format, after 2015). This adds crucial format requirements and constraints not present in the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '채권은행 등의 관리절차 중단 - 주요사항보고서 내 채권은행 등의 관리절차 중단 정보를 제공합니다' (Provides creditor bank management procedure stop information from major reports). It specifies the verb '제공합니다' (provides) and resource '정보' (information) with context about the source. However, it doesn't explicitly differentiate from sibling tools like 'get_creditor_management_start' beyond the 'stop' vs 'start' distinction in names.
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. There's no mention of when this specific creditor management stop information is needed, what distinguishes it from other financial reporting tools in the sibling list, or any prerequisites for its use. The parameter descriptions imply date constraints (2015년 이후 - after 2015) but this is parameter semantics, not usage guidance.
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 only states what the tool does ('provides employee status information') without mentioning any behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or what format the output takes. For a tool with no annotation coverage, 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 appropriately concise with a clear two-part structure: a purpose statement followed by parameter explanations. Every sentence earns its place, though the formatting with indentation could be cleaner. The information is front-loaded with the main purpose stated first.
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 that there's an output schema (which handles return values), no annotations, and the description provides excellent parameter semantics, the description is reasonably complete for a simple lookup tool. However, it lacks behavioral context about the operation (read-only vs. mutation, potential side effects, etc.) which would be important for an agent to use it correctly, especially with no annotations to provide this information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics despite 0% schema description coverage. It clearly explains all three parameters: 'corp_code: 고유번호(8자리)' (unique 8-digit code), 'bsns_year: 사업연도(4자리, 2015년 이후)' (business year, 4 digits, after 2015), and 'reprt_code: 보고서코드 (11013:1분기, 11012:반기, 11014:3분기, 11011:사업보고서)' (report codes with specific mappings). This fully compensates for the lack of schema descriptions and adds meaningful context beyond what the bare schema provides.
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: '직원 현황 - 정기보고서 내 직원 현황 정보를 제공합니다' (Employee status - provides employee status information within regular reports). It specifies the verb '제공합니다' (provides) and resource '직원 현황 정보' (employee status information), but doesn't explicitly differentiate from sibling tools like 'get_executive_status' or 'get_outside_director_status' which might provide related but different personnel 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. While it mentions the context of '정기보고서' (regular reports), it doesn't specify when this tool is appropriate compared to other employee-related tools in the sibling list or what prerequisites might be needed. There's no mention of alternatives or exclusions.
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 states what the tool does, it doesn't describe important behavioral aspects: whether this is a read-only operation, what format the output takes (though an output schema exists), potential rate limits, authentication requirements, or error conditions. For a tool with 4 required parameters and 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter documentation. The Korean purpose statement is concise, and the parameter explanations are direct. While the formatting could be cleaner (indentation issues), the content is front-loaded and every sentence earns its place by explaining either the tool's function or parameter meanings.
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 4 required parameters, 0% schema coverage, no annotations, but with an output schema present, the description is moderately complete. It adequately explains parameter semantics but lacks behavioral context. The output schema existence means the description doesn't need to explain return values, but it should address more about the tool's operation, constraints, and relationship to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides crucial semantic information for all 4 parameters. It explains: corp_code is an 8-digit unique identifier, bsns_year is a 4-digit business year (2015+), reprt_code specifies report types with exact code mappings, and fs_div distinguishes between individual and consolidated financial statements. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '단일회사 전체 재무제표를 제공합니다' (provides a single company's complete financial statements). It specifies the verb ('제공합니다' - provides) and resource ('재무제표' - financial statements). However, it doesn't explicitly differentiate from sibling tools like 'get_single_company_accounts' or 'get_single_financial_index', which might offer related 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. With many sibling tools related to financial data (e.g., 'get_single_company_accounts', 'get_single_financial_index', 'get_multi_financial_index'), there's no indication of what makes this tool distinct or when it should be preferred over others. The parameter documentation implies usage context but doesn't address 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. The description states it '정보를 제공합니다' (provides information), which implies a read-only operation, but doesn't clarify authentication requirements, rate limits, error conditions, or response format. For a tool with no annotation coverage, this leaves critical behavioral aspects 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 appropriately concise and well-structured. It starts with a clear purpose statement, then lists parameters with detailed explanations in a formatted Args section. Every sentence earns its place, though the Korean-only text might limit accessibility in multilingual contexts.
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 moderate complexity (3 required parameters) and the presence of an output schema (which handles return values), the description is partially complete. It excels at parameter documentation but lacks behavioral context and usage guidelines. With no annotations and many sibling tools, it should provide more guidance to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics beyond the input schema. The schema has 0% description coverage (only titles like 'Corp Code'), but the description explains: 'corp_code: 고유번호(8자리)' (unique number, 8 digits), 'bsns_year: 사업연도(4자리, 2015년 이후)' (business year, 4 digits, after 2015), and 'reprt_code: 보고서코드 (11013:1분기, 11012:반기, 11014:3분기, 11011:사업보고서)' (report code with specific enum values). This fully compensates for the schema's lack of descriptions.
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: '타법인 출자현황 - 정기보고서 내 타법인 출자현황 정보를 제공합니다' (Investment status in other corporations - provides information on investment status in other corporations within periodic reports). It specifies the verb '제공합니다' (provides) and the resource '타법인 출자현황 정보' (investment status in other corporations information), making the purpose clear. However, it doesn't explicitly distinguish this tool from its many siblings (e.g., other financial reporting tools), which prevents a perfect score.
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. While it mentions '정기보고서' (periodic reports) as the context, it doesn't specify prerequisites, limitations, or when other tools might be more appropriate. With 80+ sibling tools on the server, this lack of differentiation is a significant gap.
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 states the tool '정보를 제공합니다' (provides information), implying a read-only operation, but doesn't explicitly confirm safety, permissions required, rate limits, or response format. For a tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
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: one stating the purpose and another documenting parameters. The parameter documentation is well-structured with clear formatting. While efficient, the purpose sentence could be slightly more front-loaded with key details.
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 3 parameters with 0% schema coverage and no annotations, the description does well on parameter semantics but lacks behavioral context. The presence of an output schema (not shown) means return values may be documented elsewhere, but the description should still address basic behavioral traits. It's minimally adequate but has clear gaps for a tool with no annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It provides clear parameter documentation: corp_code (8-digit unique number), bgn_de (start date in YYYYMMDD format, after 2015), and end_de (end date in YYYYMMDD format, after 2015). This adds essential meaning beyond the bare schema, fully explaining all three parameters with format constraints.
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: '해외 증권시장 주권등 상장폐지 정보를 제공합니다' (provides information on overseas securities market stock delistings). It specifies the resource (delisting information from major reports) and verb (provides), making it distinct from most siblings like 'get_overseas_delisting_decision'. However, it doesn't explicitly differentiate from 'get_overseas_listing' or other overseas-related tools, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_overseas_delisting_decision' or 'get_overseas_listing', nor does it specify prerequisites or context for usage. The only implicit guidance is the parameter constraints (dates after 2015), but this doesn't help with 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what information is provided, without mentioning whether this is a read-only operation, what authentication might be required, rate limits, error conditions, or the format/scope of returned data. For a tool with 3 required parameters and an output schema, this is insufficient 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 well-structured and appropriately sized. The purpose statement is front-loaded, followed by clearly formatted parameter explanations. Each sentence earns its place, though the purpose statement could be slightly more specific about what '정보를 제공합니다' entails.
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 (3 required parameters, no annotations, but with an output schema), the description is minimally adequate. The parameter explanations are excellent, but the lack of behavioral context (permissions, rate limits, data format) and usage guidelines leaves gaps. The existence of an output schema reduces the need to describe return values, but other contextual elements are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics despite 0% schema description coverage. It clearly explains: corp_code as '고유번호(8자리)' (unique 8-digit code), bgn_de as '시작일(YYYYMMDD, 2015년 이후)' (start date in YYYYMMDD format, after 2015), and end_de as '종료일(YYYYMMDD, 2015년 이후)' (end date in YYYYMMDD format, after 2015). This fully compensates for the lack of schema descriptions.
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: '회생절차 개시신청 - 주요사항보고서 내 회생절차 개시신청 정보를 제공합니다' (Provides rehabilitation procedure commencement application information within the major matters report). It specifies the verb '제공합니다' (provides) and resource '회생절차 개시신청 정보' (rehabilitation procedure commencement application information). However, it doesn't explicitly differentiate from sibling tools that might also provide financial/legal information about companies.
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, constraints beyond date parameters, or suggest other tools for related queries. The user must infer usage from the purpose statement 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 for behavioral disclosure. It only states what the tool does (provides financial indicators) without mentioning whether it's a read-only operation, what format the output takes, potential rate limits, authentication requirements, or error conditions. For a data retrieval 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by detailed parameter explanations. While slightly verbose due to the Korean-English code explanations, every sentence serves a purpose. The parameter documentation is necessary given the lack of schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 4 parameters with 0% schema coverage, and no annotations, the description does well on parameter semantics but lacks behavioral context. It's adequate for understanding what the tool does and what inputs it needs, but doesn't provide enough operational guidance for an AI agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics that fully compensate for the 0% schema description coverage. It clearly explains each of the 4 required parameters: corp_code (8-digit unique number), bsns_year (4-digit business year), reprt_code (report codes with specific mappings to quarters/annual reports), and idx_cl_code (indicator classification codes with specific category mappings). This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '단일회사 주요 재무지표를 제공합니다' (provides key financial indicators for a single company). It specifies the resource (financial indicators) and scope (single company), though it doesn't explicitly differentiate from sibling tools like 'get_multi_financial_index' beyond the 'single' vs 'multi' distinction in their names.
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_financial_index' or 'get_full_financial_statement', nor does it specify prerequisites or contextual constraints for usage.
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 states the tool provides information, implying a read-only operation, but doesn't clarify whether it's safe, requires authentication, has rate limits, or what the output format is. The description lacks behavioral details beyond the basic purpose, leaving significant gaps for an agent to understand how to interact with 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 well-structured and concise, with a clear purpose statement followed by parameter explanations. Every sentence earns its place by providing essential information. It could be slightly more front-loaded by integrating parameter details into the main flow, but it's efficient overall with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 required parameters) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the purpose and parameter semantics thoroughly. However, it lacks behavioral context (e.g., safety, performance) and usage guidelines, which are important gaps despite the output schema's assistance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial semantic value beyond the input schema, which has 0% description coverage. It explains each parameter in Korean: 'corp_code: 고유번호(8자리)' (unique 8-digit code), 'bsns_year: 사업연도(4자리, 2015년 이후)' (business year, 4 digits, after 2015), and 'reprt_code: 보고서코드 (11013:1분기, 11012:반기, 11014:3분기, 11011:사업보고서)' (report code with specific values). This compensates fully for the schema's lack of descriptions, making the parameters clear and actionable.
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: '조건부 자본증권 미상환 잔액 - 정기보고서 내 조건부 자본증권 미상환 잔액 정보를 제공합니다' (Provides information on outstanding contingent capital securities balances in periodic reports). It specifies the verb '제공합니다' (provides) and resource '조건부 자본증권 미상환 잔액 정보' (contingent capital securities balance information), making the purpose clear. However, it doesn't explicitly differentiate from sibling tools that also provide financial data from reports, which prevents a perfect score.
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 sibling tools that might be more appropriate for related queries. The agent must infer usage solely from the purpose statement, which is insufficient for effective 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an information-providing tool ('정보를 제공합니다'), which implies a read-only operation, but doesn't explicitly confirm this. It doesn't disclose any behavioral traits like rate limits, authentication requirements, error conditions, or what happens when parameters are invalid. For a tool with no annotation coverage, this represents 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 well-structured and appropriately sized. It begins with a clear purpose statement, then provides parameter documentation in a structured format. Every sentence earns its place by either stating the tool's function or explaining parameters. The only minor improvement would be separating the purpose statement from parameter documentation more clearly, but overall it's efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and 3 parameters with excellent description coverage, the description is reasonably complete. It clearly explains what the tool does and documents all parameters thoroughly. The main gaps are the lack of behavioral context (no annotations to rely on) and no usage guidance, but the parameter documentation is comprehensive and the purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics despite 0% schema description coverage. It clearly explains all three parameters: 'corp_code: 고유번호(8자리)' (unique 8-digit code), 'bsns_year: 사업연도(4자리, 2015년 이후)' (business year, 4 digits, 2015 or later), and 'reprt_code: 보고서코드 (11013:1분기, 11012:반기, 11014:3분기, 11011:사업보고서)' (report codes with specific mappings). This fully compensates for the lack of schema descriptions and adds meaningful context beyond what the bare schema provides.
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: '사모자금의 사용내역 - 정기보고서 내 사모자금의 사용내역 정보를 제공합니다' (Private placement fund usage - provides private placement fund usage information within periodic reports). It specifies the verb ('제공합니다' - provides) and resource ('사모자금의 사용내역 정보' - private placement fund usage information), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_public_offering_fund_usage', which appears to be a related but distinct tool.
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, context for usage, or comparison with sibling tools like 'get_public_offering_fund_usage' that appears to handle public offering fund usage. The only contextual information is that it works with '정기보고서' (periodic reports), but this doesn't constitute usage guidance.
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 indicates this is a search operation (implying read-only), it doesn't explicitly state whether it's safe, whether authentication is required, what rate limits exist, or what happens with invalid parameters. The description provides functional context but lacks important behavioral details 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by detailed parameter documentation. While the parameter section is lengthy, each entry provides essential information. The structure is logical and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, search functionality) and the presence of an output schema, the description provides good coverage. The parameter documentation is comprehensive, and the output schema will handle return value details. The main gap is the lack of behavioral context that would normally come from annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides extensive parameter documentation that fully compensates for the 0% schema description coverage. It explains all 11 parameters with clear semantics, including: corp_code behavior when empty, date range constraints, enum values for pblntf_ty and corp_cls, sorting options, and pagination limits. This adds significant value beyond the basic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '공시검색 - 공시 유형별, 회사별, 날짜별 등 여러 조건으로 공시보고서를 검색합니다' (Search disclosures - searches disclosure reports by various conditions such as disclosure type, company, date, etc.). It specifies the verb ('검색합니다' - searches) and resource ('공시보고서' - disclosure reports). However, it doesn't explicitly differentiate from sibling tools, which appear to be specific data retrieval functions rather than general search 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. It doesn't mention any prerequisites, limitations, or compare it to sibling tools. The parameter documentation implies usage context but doesn't provide explicit guidelines 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 full burden. It states the tool '제공합니다' (provides) information, implying a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, response format, or error handling. For a tool with 3 parameters and 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 appropriately sized and front-loaded with the purpose in the first sentence, followed by parameter details. It's efficient with no wasted sentences, though the parameter explanations could be slightly more structured. Overall, it earns its place with clear 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?
Given the tool has 3 parameters, no annotations, and an output schema exists (which reduces the need to describe return values), the description is moderately complete. It covers parameter semantics well but lacks behavioral context and usage guidelines. For a data retrieval tool in a financial context, more guidance on when to use it would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains each parameter: corp_code as '고유번호(8자리)' (unique 8-digit code), bsns_year as '사업연도(4자리, 2015년 이후)' (business year, 4 digits, after 2015), and reprt_code with specific codes and their meanings (e.g., 11013:1분기 - 1st quarter). This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('제공합니다' - provides) and resource ('기업어음증권 미상환 잔액 정보' - commercial paper outstanding balance information), and distinguishes it from siblings by specifying it's from '정기보고서' (regular reports). It's not a tautology of the name/title.
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 mentions it provides information from regular reports, but doesn't specify prerequisites, exclusions, or compare to sibling tools like get_corporate_bond_balance or get_short_term_bond_balance. Usage context 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the batch capability and input constraints (comma-separated, up to 100 corp codes), which is useful. However, it doesn't describe output format, pagination, rate limits, authentication requirements, error handling, or whether this is a read-only operation. For a data retrieval tool with no 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 appropriately concise with two sentences followed by parameter details. The first sentence states the purpose clearly, the second explains the batch constraint. The Args section is well-structured but could be more integrated. Minor improvement possible by combining the constraint note with the parameter explanation, but overall efficient with minimal waste.
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 3 parameters with 0% schema coverage and no annotations, the description does well on parameter semantics but lacks output information. The existence of an output schema helps, but the description doesn't hint at return structure or data format. For a financial data retrieval tool with multiple siblings, more context about what '주요계정' includes and how results are organized would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It provides detailed semantic information for all three parameters: corp_code format (8-digit, comma-separated up to 100), bsns_year range (4-digit, 2015+), and reprt_code mappings (11013:Q1, 11012:半期, 11014:Q3, 11011:annual report). This adds substantial value beyond the bare schema, explaining formats, constraints, and code meanings that aren't in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '여러 회사의 주요계정을 일괄 조회합니다' (batch retrieval of major accounts for multiple companies). It specifies the verb '조회합니다' (retrieve/query) and resource '주요계정' (major accounts), and distinguishes from sibling 'get_single_company_accounts' by emphasizing multi-company batch capability. However, it doesn't fully explain what '주요계정' entails compared to other financial data tools.
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 context through parameter explanations (e.g., '2015년 이후' for bsns_year, report code mappings), suggesting when data is available. It distinguishes from 'get_single_company_accounts' by mentioning multi-company capability. However, there's no explicit guidance on when to use this versus other financial data tools like 'get_full_financial_statement' or 'get_multi_financial_index', nor any prerequisites or exclusions stated.
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 the comma-separated format for corp_code but doesn't disclose rate limits, authentication requirements, error conditions, response format, or whether this is a read-only operation. For a tool with 4 required parameters and batch functionality, 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 efficiently structured with a clear purpose statement followed by well-organized parameter documentation. Every sentence adds value, though the formatting with indented Args section could be slightly cleaner. The information density is high without unnecessary verbiage.
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 (4 required parameters, batch operation) and the presence of an output schema, the description is moderately complete. The parameter documentation is excellent, but behavioral aspects are lacking. With an output schema available, the description doesn't need to explain return values, but it should cover more operational context given no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics despite 0% schema description coverage. It explains corp_code format (8-digit, comma-separated), bsns_year format (4-digit), and provides complete enum mappings for reprt_code and idx_cl_code with clear code-to-meaning translations. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('일괄 조회합니다' - batch retrieval) and resource ('다중회사 주요 재무지표' - multi-company key financial indicators). It distinguishes from sibling tools like get_single_financial_index by explicitly mentioning '여러 회사의' (multiple companies) and '일괄' (batch), making the scope and differentiation clear.
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. While it mentions batch retrieval for multiple companies, it doesn't specify scenarios where this is preferable over single-company tools or other financial data tools in the sibling list. No prerequisites, exclusions, or comparative context are provided.
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 of behavioral disclosure. It usefully describes the return format ('base64 인코딩된 ZIP 파일을 반환합니다' - returns base64 encoded ZIP file), which is valuable behavioral information. However, it doesn't mention potential errors, rate limits, authentication requirements, or other operational constraints that would be helpful for an agent.
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 efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence serves a purpose - first stating what the tool does and what it returns, then documenting the two parameters. The formatting with Args: section is helpful, though the text could be slightly more polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (which presumably describes the base64 ZIP return), the description doesn't need to explain return values. It adequately covers the tool's purpose and parameters. For a document retrieval tool with 2 parameters and no annotations, this provides reasonable context, though it could benefit from more behavioral details about error conditions or usage constraints.
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 schema description coverage is 0%, so the description must compensate. It provides clear semantic explanations for both parameters: rcept_no as '접수번호(14자리)' (14-digit receipt number) and reprt_code with specific code mappings for different report types. This adds substantial value beyond the bare schema, though it doesn't explain parameter format constraints or validation rules.
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 specific action ('다운로드합니다' - downloads) and resource ('재무제표 원본파일(XBRL)' - XBRL financial statement original file), distinguishing it from sibling tools like get_document or get_full_financial_statement which handle different document types. The purpose is precise and unambiguous.
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 like get_document or get_full_financial_statement. The description mentions what the tool does but offers no context about appropriate use cases, prerequisites, or comparisons with other document retrieval 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.
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 the return format (base64-encoded ZIP file) which is valuable behavioral information. However, it doesn't mention potential errors (e.g., invalid rcept_no), file size considerations, authentication requirements, or rate limits. The description adds some context but leaves significant 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 efficiently structured with a clear purpose statement followed by parameter documentation. Every sentence earns its place, though the Korean-only text might limit accessibility for non-Korean agents. The information is front-loaded with the core functionality stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter file download), no annotations, but with an output schema (implied by 'Has output schema: true'), the description is reasonably complete. It explains what the tool does, the parameter meaning, and the return format. The output schema presumably covers the base64 structure, so the description doesn't need to detail return values further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage (no parameter descriptions in schema), so the description fully compensates by explaining the single parameter: '접수번호(14자리)' (receipt number, 14 digits). This provides crucial semantic context that the schema alone lacks, including format requirements and the parameter's purpose in identifying the specific document.
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 specific action ('다운로드합니다' - downloads) and resource ('공시보고서 원본파일(ZIP)' - disclosure report original file ZIP), and distinguishes from siblings by focusing on raw file download rather than structured data extraction (unlike get_xbrl_document or search_disclosure). The Korean text is precise and unambiguous about what the tool delivers.
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 like get_xbrl_document (for structured XBRL data) or search_disclosure (for finding documents). The description assumes the user already knows they need the raw ZIP file, but offers no comparative context with the 80+ sibling tools listed.
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:

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

Score Badge

Copy to your README.md:

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

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/RealYoungk/opendart-mcp'

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