get_footnote_section

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description implies usage for extracting footnote sections with risk keywords to uncover hidden liabilities, but it does not explicitly state when to use or avoid this tool, nor does it mention alternative tools. The context is clear but lacks explicit guidance on exclusions or prerequisites.

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