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

Annotations declare readOnlyHint=true, but that only covers side-effect safety. The description adds valuable behavioral context beyond annotations: KRW-to-USD conversion using FRED annual-average rates, the output row structure (per-metric, per-year with kr_krw, kr_usd, us_usd, ratio), the FX rates used, accounting-basis caveats, and the default metrics list. It does not explicitly say it makes network calls to multiple sources, but the source naming implies this adequately.

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-organized with a clear opening sentence, a concise args list, a return-format summary, concrete examples, and an exclusions/error section. It earns its length because it packs essential routing and usage information. Slightly lower than 5 because the args list partially duplicates the schema, but the duplication is acceptable for 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?

Given the tool's complexity (cross-source data retrieval, FX conversion, multi-year, multi-metric comparison), the description covers nearly everything an agent needs: what it compares, what it returns, the identifiers it accepts, the annual-only limitation, and a fallback path to sibling search tools. The output schema exists, so the description correctly avoids restating return values field-by-field. It doesn't mention pagination or rate limits, but that is not critical for a comparison 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 100%, so the schema already thoroughly documents all five parameters. The description adds meaningful semantics on top: it clarifies the accepted identifier formats for kr_company (name / stock code / corp_code) and us_company (ticker / name / CIK), gives concrete example values, and explains how response_format affects output. It also lists the default metrics, which are not fully enumerated in the schema. This goes beyond the schema's mechanical 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 action (compare), the two resources (KR and US company financials), the data sources (OpenDART, SEC EDGAR), accounting standards (K-IFRS, US-GAAP), and the FX conversion method (FRED DEXKOUS). It distinguishes itself from the individual get_dart_financials and get_edgar_financials siblings by focusing on cross-market comparison.

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 what the tool is for, provides concrete input examples, and adds crucial exclusions: 'Don't use for quarterly data (annual only) or non-KR/US companies.' It also gives error handling guidance ('unknown company names suggest using search_dart_company / search_edgar_company first'), which helps an agent choose between this tool and the sibling search tools.

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