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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description adds a genuinely non-obvious behavioral trait: per-company failures and omissions are preserved rather than aborting the whole batch, which tells the agent to expect partial 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?

Two short, front-loaded sentences with no filler: the scope ('same year/report/basis, up to 5 companies') comes first, followed by the failure-semantics caveat. Nothing is redundant, though it is extremely terse.

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 carries some burden for return shape, and it only hints at it via 'failures and omissions preserved' – it does not say what is returned per company or how a missing company is represented. Adequate but leaves a real gap for an aggregation 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 coverage is only 50% (report has no schema description) and the schema already explains year, fs_div, and the accepted company identifier formats. The description compensates by clarifying that year/report/fs_div apply uniformly across all companies on a single basis, which is the key semantic of this tool rather than a restatement of fields.

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 gives a specific verb (조회) and resource (up to 5 companies' financials) plus scope constraints: same fiscal year, same report, same consolidated/separate basis. It distinguishes this batch-comparison tool from single-entity siblings like get_financial_summary, but never names those siblings explicitly.

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 phrase '최대 5개 기업을 같은 … 기준으로' implies the comparison use case (multiple companies viewed on one consistent basis), but there is no explicit when-to-use vs. get_financial_summary/get_full_financial_statements guidance and no stated exclusions or 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?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The description adds genuinely non-obvious behavioral details beyond annotations: absent or ambiguous accounts are returned as null, and quarterly figures are returned separately from cumulative figures. Since there is no output schema, this return-shape disclosure is valuable, though it omits pagination/error behavior.

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

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

Three short sentences, front-loaded with the account scope, then the null convention, then the quarterly/cumulative return split. No filler, no repetition of the title.

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 carries the burden of describing returns and does so for the null convention and the quarterly/cumulative split. It remains silent on how fs_div/report interact with the returned figures and on the meaning of ambiguity, leaving a modest gap for a read-only lookup 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 75% and both enums (fs_div, report) are documented in the schema itself, so the schema does most of the work. The description's mention of separate 분기/누적 amounts loosely maps to the report parameter but adds no format, default, or substitution guidance beyond what the schema already states (e.g., '자동 대체 없음').

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?

States a specific verb (조회) and resource (표준계정: 매출·영업이익·순이익·자산·부채·자본), making the scope of the summary unambiguous. However, it never distinguishes itself from the sibling get_full_financial_statements or compare_financials, so an agent must infer when the summarized set is preferred over the full statements.

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 when-to-use instruction and never names an alternative, despite four closely related siblings (notably get_full_financial_statements). Nothing tells the agent when the standard-account summary is the right call versus pulling complete statements.

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?

Annotations already declare this a read-only, idempotent, non-destructive, open-world call, so safety is covered. The description adds the behavioral note that results are paginated and must be continued via offset/limit, which is genuinely beyond the annotations, but says nothing about ordering, totals, or truncation 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?

Two short sentences, no filler, with the core action stated first and the pagination instruction second. Nothing is 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?

For a 7-parameter tool with no output schema and under-half schema coverage, the description is on the thin side. The pagination hint is helpful, but the meaning of the statement type and fs_div options, plus the relationship to the summary sibling, are absent.

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?

With only 43% schema description coverage, the description should compensate, yet it only addresses offset/limit. The enum parameters statement, report, and fs_div are left undocumented in both schema and description, so an agent gets no semantic explanation of what BS/IS/CIS/CF/SCE mean or how fs_div fallback behaves.

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?

States a concrete verb and resource (retrieve full financial statement accounts plus original amounts), and the word '전체' implicitly contrasts with the sibling get_financial_summary. It stops short of naming that sibling or the boundary explicitly, so the distinction must be inferred.

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?

Provides one clear usage rule — that offset/limit are for continuing a paged read — but gives no guidance on when to choose this tool over get_financial_summary or compare_financials, and no exclusions or 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds useful return behavior ('유사 기업 후보' plus the exact DART ID), but says nothing about the limit/pagination behavior or fuzzy-match behavior that the '유사 기업 후보' wording implies.

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 compact sentences, front-loaded with the action and followed by the outcome. No filler or 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?

There is no output schema, so describing the return (candidate list plus exact DART number) is valuable and mostly sufficient. The only gap is the undocumented limit parameter and pagination behavior, a minor omission for a search 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 coverage is only 50%: the query parameter is described, but limit has no description anywhere. The description echoes the query input types already stated in the schema (company name, stock code) without covering the limit parameter, so it only partially compensates for the gap.

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?

States a specific verb and resource ('회사명·종목코드로 기업을 검색합니다') and adds the resolution outcome ('정확한 DART 고유번호'). It is clearly a lookup tool distinct from the financial/disclosure siblings, though it never names them explicitly.

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?

Usage is only implied: the agent can infer this is the identifier-resolution step before calling get_financial_summary or search_disclosures. There is no explicit when-to-use statement, no mention of when not to use it, and no reference to alternatives.

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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is lower; the description still adds real behavioral context: the default recent-30-day scope, that pagination state is preserved, and that document bodies are not fetched (only metadata/links). That is meaningful beyond the annotations.

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?

Three short sentences with no filler, and the core purpose is front-loaded before the default-window and no-body-read details. Slightly terse on the pagination phrase, but efficient 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?

For a read-only search tool with no output schema, the description conveys the general return shape (list + links, no body) but leaves the return structure, pagination fields, and most parameter semantics unexplained. Adequate but with clear gaps given the 6-parameter surface.

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 only 33% across 6 parameters, so the description is expected to compensate, but it explains none of them (page, page_size, start_date, end_date are undocumented, and the company/type formats are left to the schema). Only the implicit 30-day default hints at the date 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?

States a specific verb+resource: retrieving corporate disclosure lists and original-document links per company. It is distinguishable from the financial-statement siblings (get_financial_summary, get_full_financial_statements), though it does not explicitly name what search_company does differently.

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?

Gives an implied usage context (a per-company disclosure search with a default 30-day window) but offers no explicit when-to-use/when-not guidance and does not name an alternative tool for reading full document bodies, which it gestures at with 'does not read the body'.

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