기업집단현황공시(J004) 정합성 자가점검

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

No annotations are provided, so the description carries the full behavioral burden. It discloses key behaviors: the tool cannot read unsent drafts, it returns not_checkable when financial statements are not found, it gives unit-error hints for ~1000x differences, and it may produce structural false positives for generic totals. This gives the agent realistic expectations beyond the schema.

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 purpose statement followed by concise bullets. Every bullet adds meaningful constraint or behavior, and warnings are front-loaded. It is slightly long, but the length is justified by the domain complexity.

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 complex tool with no output schemacompress, the description is quite complete: it covers what is checked, what is not checked, key limitations, and the not_checkable outcome. The compare_rcept_nos and include_generic_totals semantics are covered in the schema. It could more explicitly describe the output shape, but this is not a blocking gap.

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 parameters are already well documented. The description adds no per-parameter detail beyond the schema, which is acceptable under the baseline, but it also does not enrich the meaning of rcept_no or max_issues beyond what the schema already provides.

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 a specific action and resource: it recalculates all mechanically re-calculable items in the J004 filing to find discrepancies. It also clearly scopes the tool to submitted DART filings via rcept_no, distinguishing it from generic search/read/duty-check 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 gives strong usage boundaries: only already-submitted filings with a receipt number are checked; draft files are not readable; it checks internal consistency only, not accounting truthfulness; and include_generic_totals is flagged as experimental with false-positive risk. It does not explicitly name alternative sibling tools, so it stops short of a 5.

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