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 only mentions the return format and does not clarify whether the operation is read-only, timezone-dependent, or side-effect-free.

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

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

The description is brief and front-loaded with the core purpose. The Args/Returns sections are structured, but the Args section includes the misleading `ctx` entry, which slightly detracts from overall clarity.

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

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

For a simple tool, the description covers the return format and purpose adequately. However, the undocumented `ctx` parameter and absence of behavioral details (since there are no annotations) leave gaps in completeness.

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

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

The input schema has zero parameters, yet the description documents a `ctx` argument that is not present in the schema. This introduces confusion and misleads the agent about what inputs are accepted.

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

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

The description clearly states that the tool returns the current date in YYYYMMDD format, using a specific verb and resource. This unambiguously distinguishes it from the sibling search tools.

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

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

The description does not explicitly specify when to use this tool or mention any alternatives. Its purpose is self-evident, but there is no guidance about exclusions or preferred contexts.

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

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 transparency. It discloses that the tool returns text for the requested information type, and the search/provide semantics imply read-only behavior. However, it omits any details about error handling, date range validation, rate limits, or whether certain companies might have no available data.

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

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

The description is well-structured with a one-line purpose, a clear Args list, and a Returns section. It is not overly verbose for the amount of information conveyed, though the enumeration of seven information types is inherently lengthy. Each sentence/line adds value, and it is front-loaded with the purpose statement.

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

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

The description covers all four parameters thoroughly and specifies the return type (text), which is sufficient for a straightforward query tool. However, it lacks details on how this tool relates to sibling search tools (e.g., overlap with search_disclosure) and does not explain any constraints on date ranges or company coverage. Given the output schema exists, return values are adequately addressed.

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

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

The input schema provides no descriptions (0% coverage), so the description fully compensates by detailing every parameter. It gives format examples for dates, explains company_name, and exhaustively enumerates all information_type options with Korean descriptions. This goes well beyond the schema's bare property types.

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

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 a company's business-related status information, with specific information types enumerated. It distinguishes from sibling financial-data tools by focusing on business overview, products, raw materials, sales, risk, contracts, and R&D, though it doesn't explicitly name alternatives. The verb 'provide' is somewhat generic but the scope is specific.

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

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

The description implies when to use the tool by listing seven information_type categories that narrow the query context, but it does not explicitly state when to use this over sibling tools like search_disclosure or search_detailed_financial_data. No exclusions or alternative recommendations are given, so the guidance is implied rather than direct.

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

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

With no annotations, the description carries the full burden. It discloses that it parses XBRL files and returns text with detailed items, and explains the behavior of the optional statement_type. However, it lacks details on error handling, data freshness, or edge cases, making it only moderately transparent.

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

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

The description is well-structured with a summary, Args, and Returns sections. It is concise and easy to scan, though the opening phrase restates the tool name, making it slightly redundant.

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

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

The description covers purpose, parameters, and return type adequately for a 4-parameter tool with an output schema. However, it lacks usage guidance and has the ctx inconsistency, leaving some gaps in completeness.

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

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

The Arg values section provides examples for company_name, start_date, end_date, and describes statement_type options, which compensates for 0% schema coverage. However, the inclusion of 'ctx' as an argument not present in the schema creates inconsistency and potential confusion for the agent, lowering the score.

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

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

The description clearly states the tool provides detailed financial information by parsing XBRL files, with a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like search_json_financial_data, so it earns a 4 rather than a 5.

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

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

The description gives no guidance on when to use this tool versus alternatives. It only implies usage for detailed financial data but does not mention any trade-offs, exclusions, or comparison to sibling tools like search_json_financial_data. This is a clear gap.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It does disclose that only disclosures with data matching requested_items are returned, and describes the return text. However, it does not explicitly state that the operation is read-only, nor does it mention error handling, date range validation, or the absence of results. The inclusion of a 'ctx' parameter not present in the schema adds minor confusion.

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

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

The description is well-structured with an intro, Args section, and Returns section, front-loading the primary purpose. It is slightly longer than necessary due to detailed examples and the redundant ctx parameter, but every other piece of information earns its place. The structure aids quick scanning.

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

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

The description covers the main behavior: purpose, filtering logic, and return summary. Since an output schema exists, the return details are partially covered elsewhere. However, it lacks information about edge cases (e.g., no disclosures found) and does not explicitly state whether the tool is read-only, which would be expected given no annotations.

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

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

The description adds substantial meaning beyond the schema, which has 0% description coverage. It provides concrete examples for company_name (e.g., Samsung Electronics, Naver), exact date format with examples (YYYYMMDD), and a comprehensive list of valid financial items for requested_items. This effectively compensates for the schema's lack of descriptions. The only minor flaw is the stray 'ctx' parameter mention.

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

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

The description clearly states the tool 'searches and provides a company's key financial information' (회사의 주요 재무 정보를 검색하여 제공하는 도구), identifying a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like search_detailed_financial_data or search_json_financial_data, relying mainly on the name for differentiation.

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

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 its alternatives. There is no mention of sibling tools, exclusions, or prerequisites. The only hint is the purpose statement, which implies usage for financial disclosure search but does not help an agent choose among similar tools.

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

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

No annotations are provided, so the description carries the burden. It discloses the data source (JSON API), its role as a fallback tool, and a key behavioral limit: '당기 데이터만 표시' (only current-period data is shown). It lacks details on failure modes or error behavior but is adequate for a read-only retrieval tool.

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

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

The description is structured with a brief usage note, a labeled Args section, and a Returns section. The opening sentence is grammatically awkward ('제공하는 실패시 보완하는'), but overall it is efficiently organized and not overly verbose for a 5-parameter tool.

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

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

Given the lack of annotations and barren schema, the description covers parameter semantics, use-case context, and return type. It explains most of what an agent needs, though it could mention how to handle failures or the exact structure of the returned text. It is largely complete for a fallback financial-data retrieval tool.

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

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

The schema has 0% description coverage, yet the description explains all 5 parameters with examples, valid values, and defaults. It adds significant meaning beyond the bare schema fields, including corporate name examples, report codes, and statement type enum values.

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

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

The description states it provides company financial information via JSON API and explicitly names it as a fallback when sibling tools fail for pre-September 2023 data. This distinguishes it from search_disclosure and search_detailed_financial_data, though the phrasing is slightly awkward and lacks a crisp verb like 'retrieve'.

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

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

The description explicitly states when to use this tool: when search_disclosure and search_detailed_financial_data fail to analyze data before September 2023. It clearly names the alternative tools, giving strong usage guidance.

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