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

Annotations declare readOnlyHint=true, which is consistent with 'Get', but the description adds substantial behavioral context: share-count derivation differences between KR and US, PER fallback logic, null-ratio handling, nightly ingest job, no FX conversion, K-IFRS vs US-GAAP caveats, and snapshot-not-real-time status. These are exactly the kind of non-obvious behaviors an agent needs to interpret results correctly.

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 long but extremely well structured with clear sections: Args, Returns, Examples, Caveats, Use when, and Errors. The core purpose and metrics are front-loaded, and every paragraph adds distinct value. The examples and error explanations earn their place in a tool with this much computational nuance.

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, the description covers all needed context: supported identifiers, return object shape, calculation rules, fallback behavior, error cases, use vs. non-use cases, and accounting/FX caveats. An agent can determine whether to call this tool, how to pass parameters, and how to interpret the result without external lookup.

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?

Although the input schema already covers both parameters 100%, the description goes further: it explains company resolution priority ('exact ticker > 6-digit code > exact name > partial name'), the candidate-list error behavior for ambiguous partial matches, the response_format default, and the meaning of ratio units (percent). This materially helps an agent form correct argument values.

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 opens with a specific verb and resource: 'Get the latest valuation snapshot for one KR or US company from the local finbridge database.' It enumerates the exact metrics returned (market cap, PER, PBR, PSR, ROE, debt ratio, CAGRs) and explicitly contrasts itself with raw-statement tools like get_dart_financials/get_edgar_financials, so there is no ambiguity about what this tool does.

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 'Use when' section explicitly states the intended scenarios: 'assessing one company's valuation/quality at a glance, or comparing it to its own market.' It also names exclusions and alternatives: 'Don't use for many-company ranking (use screen_companies / query_db) or raw statements (get_dart_financials / get_edgar_financials).' This gives an agent clear routing criteria.

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