afterns

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds non-obvious behavior: a hard 14-day maximum range, US Eastern date semantics, default next-7-days window, sort order, and that the result renders as a calendar card. No permission or rate-limit caveats are given, keeping it at 4.

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?

Front-loaded with the core action and constraints, then usage examples and output hint. The group enum is repeated from the schema and the example-query list is dense, but each sentence carries routing or constraint information.

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?

An output schema exists, so return values need no prose; annotations cover safety; all four parameters are documented in-schema and reinforced by the description. An agent has everything needed to call this correctly, including defaults and range limits.

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 baseline is 3; the description still adds value by enumerating the group values as human-readable sectors and by imposing the 14-day range constraint that the schema does not express. Default behavior for `to` aligns with the schema description rather than adding new detail.

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?

States a specific verb and resource ("List upcoming US earnings reports for a date range") plus scope qualifiers: 14-day cap, US Eastern dates, and sort order (largest/most-watched first). This is clearly distinct from get_earnings_call_summary and get_earnings_reactions, which cover past calls/reactions rather than upcoming dates.

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?

Provides concrete user-question triggers in two languages ("이번 주 실적 발표 일정", "Which chip stocks report next week?"), which gives strong usage context. It does not name alternatives or state when not to use it versus get_earnings_reactions or search_stocks, 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.

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds valuable context beyond that: the coverage limit of ~220 companies and the exact output composition including Korean translation with English original.

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?

Front-loaded with the core action and output structure, followed by useful example utterances and a coverage caveat. Dense but every element serves selection or invocation; the examples are justified by the bilingual use case.

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?

An output schema exists, so return values needn't be spelled out, yet the description still sketches the summary structure helpfully. Combined with the coverage limit and example queries, an agent has enough to call it correctly; only explicit sibling differentiation is missing.

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 both parameters (stock, lang) are fully documented in the schema, establishing a baseline of 3. The description's mention of Korean translation with English original loosely reinforces the lang parameter but adds no syntax or format detail beyond the schema.

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?

States a specific verb (summarize) and resource (latest earnings call/release) with clear scope: US companies, ~220 majors. The output shape (takeaway, positives, concerns, quotes) further distinguishes it from siblings like get_earnings_calendar and get_earnings_reactions.

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?

Provides concrete example queries in both Korean and English that show the intended invocation context, plus the availability constraint (~220 major companies). It does not explicitly contrast with sibling tools or state when not to use it, keeping it 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.

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

Annotations already declare this as a safe, idempotent, closed-world read, so the safety profile is covered. The description goes further by disclosing the 12-report cap, the timezone convention (Korea and US Eastern), and that the response renders as an interactive card with chart, stats, and earnings-call takeaways — useful context beyond annotations, though it omits any latency or data-freshness expectations.

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?

Front-loaded with the core capability, then the sample questions, then the historical-data caveat, then the output format — a sensible ordering. The three example questions are somewhat redundant with each other, but they usefully anchor both languages.

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 an output schema present, the description needn't explain return values, yet it still characterizes the card presentation. For a 3-parameter read tool with full schema coverage and rich annotations, this is essentially complete; the only gap is not clarifying how it relates to the earnings-calendar and call-summary siblings.

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 ticker/name formats, the ko/en enum, and the 1-12 limit are all already documented. The description reinforces the 'up to 12 most recent' bound and the stock scope but adds no syntax or behavior the schema doesn't already carry, so the 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?

States a precise verb and resource: how a US stock moved the day after each of its recent earnings reports, EPS beat/miss, and the next earnings date. The scope (up to 12 reports, US stocks, historical only) plus the concrete example questions make it immediately distinguishable from a bare calendar or call-summary tool.

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?

Sample questions (in Korean and English) show exactly the kind of query this answers, and the explicit negative constraint 'Historical data only; it does not predict prices' warns off misuse. It stops short of naming when to prefer get_earnings_calendar or get_earnings_call_summary, so routing among siblings is still inferred.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine value by disclosing Korean-name/nickname resolution and the name→ticker direction of the operation. It stays silent on ambiguous or partial matches (single vs. multiple results), which is the main remaining behavioral unknown.

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?

Two sentences, both load-bearing: the first defines what is searchable and demonstrates the non-obvious Korean alias behavior; the second gives the usage trigger. Nothing is redundant and the core capability is front-loaded.

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 full annotation coverage, 100% schema description coverage and an output schema, the description need not explain returns or safety. It is complete for selecting and calling the tool; only disambiguation behavior on fuzzy or multi-match queries is left implicit.

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 both `query` and `lang` are already documented with examples and enum meaning. The description restates the query semantics (ticker, company name, Korean names) but adds no new detail, and says nothing about the `lang` parameter. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb and resource ("Find US-listed stocks") with a clear scope constraint (US-listed) and concrete resolution examples (구글 → GOOGL). It does not reference the sibling tools, but the purpose is distinct enough from the earnings-oriented siblings that confusion is unlikely.

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?

"Use when the user names a company and you need its ticker" gives a clear triggering condition tied to user intent. There is no explicit when-not guidance or mention of alternatives (e.g. what to do if the user already has a ticker, or if resolution fails).

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