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

With no annotations, the description details the output structure (time series, checks, snapshots, rankings) and mentions parallel execution. However, it lacks information on potential side effects, prerequisites, or limitations (e.g., data costs, error conditions).

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 very concise (2-3 lines) and front-loaded with the primary purpose. Every sentence adds value without redundancy.

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?

Despite having no output schema, the description only vaguely describes outputs (time series, checks, snapshots, rankings). It omits details on error handling, data precision, and additional context needed for effective use.

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 100%, so baseline is 3. The description adds context about how corps count affects behavior and implies years as 'N years', but does not provide additional meaning beyond the existing parameter 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 specifies the tool's function: generating a Buffett quality checklist with two distinct modes based on the number of companies (1 vs 2-10). It mentions integration with quality_compare, distinguishing it from sibling 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 provides clear guidance on when to use the tool (based on corps count) and explains the different behaviors. However, it does not explicitly state when not to use it or list alternatives beyond mentioning quality_compare.

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 bears full burden for behavioral disclosure. It explains that the tool returns a structured score, flags, and evidence without making direct recommendations. However, it does not mention side effects, read-only nature, rate limits, or error handling, leaving some transparency gaps.

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 concise, with three sentences covering purpose, output, and a note on LLM use. It front-loads the key information without wasted words, though a more structured format could enhance readability.

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?

With no output schema, the description partially covers the return format (score, flags, evidence, data frame) but lacks detail on the structure of flags and evidence. Given the tool's complexity (multiple factors), more completeness would be beneficial.

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 description coverage is 100%, with each parameter having a description in the schema. The tool description does not add significant meaning beyond the schema, as it focuses on the output rather than parameter details. Baseline 3 is appropriate.

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 computes an accounting/governance anomaly score based on several factors (correction disclosure ratio, auditor change, etc.) and returns a score 0-100 with flags and evidence. It distinguishes itself from sibling tools like 'get_financials' by focusing on anomaly detection rather than raw data retrieval, though sibling differentiation is not explicit.

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 analyzing disclosure anomalies and notes the tool does not make direct recommendations, leaving judgment to the LLM. However, it does not explicitly state when to use it versus alternatives or provide conditions for use, leaving guidance implicit.

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 discloses key behaviors: format conversion, DART-specific parsing, truncation at 100,000 characters, and applicability to all disclosures. No contradictions or omissions of major traits.

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?

Two efficient sentences, front-loaded with purpose and key details, no waste. Every sentence adds useful information.

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 3 parameters, no output schema, the description fully covers purpose, parameters, truncation behavior, and scope. No missing elements for an agent to invoke correctly.

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 covers all 3 parameters 100%. Description adds value by explaining truncation limit, linking rcept_no to search_disclosures, and describing format options beyond the 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 clearly states the tool returns disclosure documents in markdown/raw/text, specifies DART-specific XML parsing with heading/table preservation, and distinguishes from sibling tools like search_disclosures by focusing on downloading content.

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 any disclosure documents and mentions default format and truncation, but lacks explicit guidance on when to use vs siblings. Context is clear enough for an agent to infer purpose.

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?

The description discloses that the tool is based on DART viewer HTML scraping (not official API), and mentions the kordoc conversion engine. With no annotations provided, this covers key behavioral traits. It does not discuss rate limits or authentication, but the scraping approach is clearly stated.

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 two sentences with front-loaded purpose. It is concise and includes technical details (scraping, conversion engine). Could be slightly more structured, but overall efficient.

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 7 parameters with 100% schema coverage and no output schema, the description covers the tool's behavior well: dual modes, scraping basis, conversion engine, and parameter roles. It is missing error handling or pagination details, but the core use case is well 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?

Schema description coverage is 100%, so the schema already documents all 7 parameters. The description adds context about the mode behavior and conversion engine, but does not significantly enhance per-parameter understanding beyond the schema. Baseline 3 is appropriate.

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: to list or extract attachments from Korean disclosures (HWP/PDF/DOCX/XLSX) using two modes (list and extract). It specifies the resource (attachments) and the action (list or extract to markdown), and distinguishes the two modes effectively.

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 explains when to use each mode (list vs extract) and provides parameter guidance (e.g., filename vs index, truncate_at, outline_max_items). It does not explicitly discuss when not to use the tool or compare with siblings, but the sibling tools are unrelated to attachments, so the context is sufficient.

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 should disclose more behavioral traits. It indicates a read operation but lacks details on side effects, authentication requirements, rate limits, or data freshness. The list of returned fields is helpful but incomplete for full transparency.

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, well-structured sentence that immediately conveys the tool's purpose and included data fields. No unnecessary words or repetition.

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 with one parameter and no output schema, the description adequately covers what the tool does and the type of data returned. It could be improved by mentioning return format or behavior when the company is not found, but it is largely 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 100% because the single parameter 'corp' has a description (company name/stock code/corp_code). The tool description does not add additional semantic value beyond what is already in the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves company overview and lists specific data fields (industry, establishment date, representative, etc.). It uses a specific verb (조회합니다) and resource (기업의 개황), distinguishing it from sibling tools that focus on financials or holdings.

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 the tool is for basic company information but does not explicitly state when to use it versus alternatives, nor does it provide exclusion criteria or if additional tools might be needed for specific fields.

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 bears full burden. It indicates a read operation ('조회'), and details that timeline mode collects events in parallel and integrates them by date, revealing batch behavior. This is valuable context beyond a simple query.

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 two sentences, front-loading the core purpose and then detailing modes. Every sentence provides essential information with zero waste. Highly efficient.

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 6 parameters and no output schema, the description covers the main functionality and mode differentiation well. It could optionally mention the return format, but the core behavior is sufficiently described for an agent to use correctly.

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 100%, so baseline is 3. The description adds meaning by explaining the purpose of each mode and the automatic capital-related event selection in timeline mode when event_types is omitted. This goes beyond the schema's enum lists.

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 queries 36 types of corporate events from DS005 major reports. It distinguishes two modes (single and timeline) and, given sibling tools are about other financial data, this tool's purpose is unique and well-defined.

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 explains when to use each mode: single for detailed event_type inquiry, timeline for capital-related events in parallel and date-sorted. It positions timeline as a 'killer mode' for extracting capital stress narratives. No explicit when-not, but context is clear.

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, and the description does not disclose any behavioral traits such as data freshness, performance limits, or side effects. It only states what it does, not how it behaves or what constraints exist. Since annotations are absent, the description carries the burden but doesn't fully address it.

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 extremely concise with only two sentences, no redundancy, and places the core purpose first followed by a helpful alternative reference. Every word earns its place.

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?

With 4 parameters (2 required) and no output schema, the description covers the main composite query functionality and points to an alternative, but does not explain return format, parameter constraints (e.g., year minimum), or how the report parameter affects results. The schema fills some gaps, but the description could be more 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 50% (descriptions for corp and sections only). The description adds value by explaining the six possible sections in prose, reinforcing the sections parameter, but does not clarify the year or report parameters beyond what the schema provides (e.g., year range, quarterly options). Thus, it provides marginal improvement over the schema.

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 performs a composite query of 6 specific executive compensation sections, using strong verbs like '합성 조회' (composite query) and explicitly lists all sections, distinguishing it from sibling tool get_periodic_report which handles individual sections.

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?

It explicitly tells when to use this tool (for all six sections at once) and when to use the alternative (individual sections via get_periodic_report), providing clear usage context and exclusions.

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 provided, so description carries full burden. Mentions speed and data volume differences between scopes, but does not disclose mutability, authentication needs, or side effects. Adequate but not comprehensive.

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?

Efficient single sentence front-loading purpose. Information-dense but well-structured for quick understanding.

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?

No output schema, so description must explain return values. It does so for scope levels (rows, core items) but lacks details on error handling, nulls, or specific field names. Adequate for simple use cases.

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 description coverage is high (83%), so the description adds marginal value beyond parameter-level details. The description summarizes scopes but does not enrich parameter meaning significantly.

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 retrieves financial information with two distinct scopes (summary and full), listing specific accounts and statements. It distinguishes from siblings by focusing on financial statements vs other corporate data.

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?

Implied usage via scope options (single vs multi, summary vs full) but no explicit guidance on when to prefer this over siblings like get_xbrl or other tools. No exclusion criteria.

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 must cover behavioral traits. It only states 'snapshot' without detailing data freshness, rate limits, permissions, or what happens when no data exists. The composite nature is mentioned but lacks depth on behavior.

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 well-structured sentence that front-loads the key concept. Every word is meaningful and earns its place, with no redundancy.

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 5 parameters and no output schema, the description is too minimal. It lacks explanation of return format, pagination, result combination, or default behavior. For a composite tool, more completeness is needed.

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 description coverage is 100%, so baseline is 3. The description does not add additional meaning beyond what the schema already provides for each parameter; it only gives high-level context about the composite query.

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 is a composite query of two types of equity disclosures (major holdings and insider holdings) as a snapshot. The verb '조회' and resource '지분공시 2종 합성' are specific and distinguish from siblings like get_shareholders which likely handles only one type.

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 a composite snapshot but does not explicitly state when to use this tool versus alternatives like get_shareholders or how to choose between included types. No exclusions or alternative recommendations are provided.

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 provided, so description must carry the burden. While it explains the scope (29 sections), it does not discuss side effects, authentication needs, rate limits, or behavior when data is missing. Adequate but not comprehensive.

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?

Single, well-structured sentence with essential information front-loaded. Examples and alternative tool mention are concise. No wasted words.

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 4 parameters, no output schema, and no annotations, the description is fairly complete. It explains the tool's scope, key parameter options, and provides an alternative for full text. Lacks output format or error handling details, but sufficient for a 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?

Schema description coverage is 50%. The description adds value by grouping report_type enum values into categories (shareholders, executives, etc.) and providing an example. It compensates for the coverage gap by explaining the meaning of the key parameter beyond the schema.

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?

Description clearly states it retrieves 29 detailed sections of a periodic report via a single tool call using the report_type enum, with specific examples (e.g., largest shareholder, executive compensation). It also distinguishes the sibling tool download_document for full text.

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?

Description explicitly states when to use this tool (for specific sections) and when not to (use download_document for full text). No ambiguity.

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 full burden. It discloses that the tool returns four sections but does not mention read-only nature, permissions, or potential side effects. The transparency is adequate for a retrieval tool but not detailed.

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 extremely concise, consisting of a main sentence and a parenthetical. Every part is informative and front-loaded. No wasted words.

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 no output schema and moderate complexity, the description covers the main purpose, usage guidance, and key parameter behavior. It could mention the combined response structure, but for a tool with four sections it is fairly 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 50%. The description adds value by explaining the 'sections' parameter defaults and listing the four sections in Korean, mapping to enum values. However, it does not clarify the 'corp', 'year', or 'report' parameters beyond the schema. Baseline score of 3 with partial compensation.

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 as a governance structure snapshot aggregating four specific sections. It uses a specific verb-resource pairing ('composite query') and distinguishes itself from the sibling tool get_periodic_report by indicating it does a combined query.

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 (for composite query of all four sections) and when to use an alternative (get_periodic_report for a single section). This provides clear usage guidance.

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 minimally discloses behavior: it describes output formats and sizes but omits any effects on the system, authorization needs, or side effects. It does not state that the operation is read-only.

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 concise: one sentence with a clear break into format options. It is front-loaded with the main purpose and includes key details efficiently.

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 no output schema and moderate complexity, the description covers format choices, sizes, and applicability of parameters. It lacks error handling or prerequisite info but is otherwise adequate.

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 100%, and the description echoes parameter details with slight additions (e.g., automatic industry response for markdown_full). It adds marginal value beyond the schema.

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 retrieves XBRL financial statements and explains three format options with specific characteristics. However, it does not explicitly distinguish from sibling tools like get_financials or get_periodic_report.

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 explains when to use each format (raw, markdown, markdown_full) based on output type and size, but does not provide guidance on when to choose this tool over alternatives or mention prerequisites.

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 full burden. It describes aggregation and calculation behavior but does not disclose side effects, permissions, or limitations. Adequate but could be more 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?

Description is concise and front-loaded with purpose. Only one paragraph, no wasted words, though it could benefit from clearer structuring of information.

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 5 parameters, no output schema, and no annotations, description covers core functionality but lacks explanation of output format or interpretation of results. Adequate but not fully 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 100%, so the schema already describes each parameter. The description adds context (e.g., Buffett philosophy, cluster threshold logic) beyond schema, but does not significantly enhance understanding of individual parameters.

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?

Description clearly states it aggregates insider transactions into buy/sell clusters, calculates net change, number of buyers, and quarterly clusters. It also mentions the Buffett-style signal, which distinguishes it from sibling tools like buffett_quality_snapshot and disclosure_anomaly.

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 state when to use this tool versus alternatives. Usage is implied from the description of what it does, but no guidance on context or exclusions is provided.

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?

The description discloses the sorting order (listed companies first, then exact match, then short name) and notes that it returns candidates for ambiguous queries. No annotations are provided, so the description carries the burden, and it covers key behavioral traits adequately, though it could mention error handling or empty results.

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 two sentences, both highly informative and front-loaded. The first sentence states the action and resource, the second provides guidance. No unnecessary words.

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 absence of an output schema, the description adequately implies the return of candidate matches and the sorting order. It could be more explicit about the response format (e.g., list of corp_codes with names), but the intended use case is clear.

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 100%, so each parameter has a description. The tool description adds value by specifying the allowed input types for the query parameter (company name, stock code, corp_code) and the usage context, which goes beyond the schema's parameter 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 the tool's purpose: to look up the OpenDART corp_code by company name or stock code. It also distinguishes itself from sibling tools by noting that other tools automatically resolve company names, but this tool is for manual candidate checking when results are ambiguous.

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 provides usage guidelines: it explains that company names are automatically resolved in other tools, and this tool should only be used when automatic resolution results are ambiguous. This helps the agent decide when to invoke this tool versus relying on automatic resolution.

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 fully carries the burden. It discloses parallel fetching, concurrency settings, API quota warnings (daily 20k limit, per-minute quota), and mode behaviors. Also links rcp_no to other tools.

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?

Single dense paragraph covering modes, parameters, and connections. Could be more structured (e.g., bullet points), but every sentence adds value. Concise overall.

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 high schema coverage and no output schema, the description explains core functionality well: modes, parameters, API limits, and tool integration. Lacks output format details but is adequate for selection and invocation.

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 100%, baseline 3. Description adds context: explains how parameters like preset, all_pages, page, size, limit, concurrency map to modes, and warns about concurrency affecting API quotas. This goes beyond 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 searches DART disclosures and specifies three distinct modes (basic, preset, all_pages), distinguishing it from siblings like download_document and get_attachments. Uses specific verb 'search' and resource 'disclosures'.

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?

Explains the three modes and when to use each, including the preset list and parallel fetching. Mentions concurrency and API quota limits. Does not explicitly list when not to use or compare to all siblings, but provides sufficient guidance.

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