Compare financial statements for up to five Korean companies from DART disclosures by fiscal year, report type, and consolidated or separate basis, preserving company-level failures and omissions.
최대 5개 기업을 같은 사업연도·보고서·연결/별도 기준으로 조회합니다. 회사별 실패와 누락을 보존합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | 사업연도. 접수연도와 구분 | |
| fs_div | No | CFS 연결, OFS 별도. 자동 대체 없음 | CFS |
| report | No | annual | |
| companies | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does 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.