depreciation_adjustment

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuine behavioral context beyond them: it states that incomplete or inconsistent facts return an error with the missing inputs instead of computing, and it discloses the 12-month fiscal-year-only constraint and the 2016–2026 year range.

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 언제/입력/결과 structure is well organized and front-loads purpose before inputs. The 입력 list, however, restates parameter meanings that are already fully documented in a 100%-coverage schema, adding some redundancy for a 19-parameter tool.

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, and the description compensates by enumerating the return contents (세무조정·상각범위액·회사계상액·기말 상각부인누계액·세무상 미상각잔액·판단·근거) plus the error path. For a complex 19-parameter statutory calculation, purpose, timing, inputs, outputs, and failure behavior are all covered.

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 per-parameter descriptions already carry the baseline burden. The description still adds cross-parameter logic not obvious from the schema: method='무신고' requires asset_class, useful_life or rate is required, prior_disallowed is negative for 감가상각의제 △유보, and the 즉시상각의제 thresholds (600만원, 300만원 pre-2019, 5% book value, sub-3-year periodic repair) that tie several inputs together.

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 opening line names a specific tax computation (법인세 감가상각 시부인), the exact comparison it performs (개별 자산별 상각범위액 vs 회사계상액), and the governing statutes. This clearly distinguishes it from sibling adjustment tools such as bad_debt_adjustment or entertainment_adjustment, which target entirely different tax adjustments.

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 '언제' block gives explicit conditions for use: 감가상각비 세무조정 (상각부인액·시인부족액·전기 부인액 추인·감면법인 의제상각) and 세무상 미상각잔액 산출. It provides clear context but names no exclusion conditions or alternative tools, which is a minor gap given the sibling list contains no directly competing depreciation tool.

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