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

Annotations only declare readOnlyHint=true, so the description carries the real behavioral load and does so well: it defines the four status values and their meaning, mandates that compound conditions such as 'the higher of' be preserved as structure rather than collapsed to one number, and specifies numeric precision (0-1 decimals; value or range; floor/ceiling/guideline/target) plus ISO 8601 UTC date formats with the +9h Japan offset. It does not state the response envelope or how many records are returned, which is the remaining gap.

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 English content is dense but well front-loaded: resource first, then fields, then status semantics, then formats. However, the Japanese text restates the English almost verbatim, including the ISO-date explanation twice, which is pure duplication for a single-locale reader and inflates the definition considerably.

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 must describe the return payload, and it largely does: field meanings, precision rules, the four-state status vocabulary, and the structural requirement for compound conditions. For a one-parameter read tool this covers nearly everything an agent needs, short of naming sibling alternatives.

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?

There is a single required parameter with 100% schema description coverage ('4-digit Japanese ticker code / 4桁の証券コード (e.g. "7203" = Toyota)'), so the schema already does the work. The description adds no constraint on symbol, such as whether a 5-digit code or an EDINET code is accepted or what error occurs for an unknown ticker. Baseline 3 applies.

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 names a specific resource with scope: 'Verified dividend policy of one Japanese company,' and enumerates the content (DOE / payout ratio / total return ratio targets, progressive-dividend stance, minimum dividend, effective period, quotes). That distinguishes it implicitly from payment-history siblings like get_dividends and get_dividend_changes. It never names a sibling explicitly, so it stops short of a 5.

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?

There is no explicit when-to-use or when-not-to-use statement and no named alternative (e.g. list_dividend_policies for screening many companies, get_dividends for actual paid amounts). Usage is only implied by the enumerated content and by the 'status' semantics. The one strong guideline — not_collected means 'not collected,' NOT 'no policy' — is interpretation guidance rather than tool selection guidance.

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