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

Annotations indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds context about the output (saved file path) and the data types, but doesn't disclose potential side effects like file creation location, overwriting behavior, or whether it creates files on disk. It doesn't contradict annotations, but the behavioral disclosure is minimal beyond what annotations already imply.

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-structured with a brief purpose statement, use cases, and a clear Args/Returns section. It's slightly verbose with the use-case bullet points, but every sentence adds value. The front-loaded purpose and structured parameter documentation make it easy to scan.

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 moderate complexity (4 params, 1 required, no enums) and the presence of an output schema, the description covers the essential context: what it does, when to use it, parameter meanings, and return value. It lacks details like file format specifics or error conditions, but for an export tool with a simple contract, it's reasonably complete.

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 0%, so the description must compensate. It does: it explains data_type values (chart/flow/financial), code format (6-digit Korean stock code), days default (180), and filename auto-generation. This adds significant meaning beyond the bare schema, though it doesn't specify constraints like days range or filename extension rules.

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 states the tool's purpose: saving single-stock data to an Excel file, with specific use cases (uploading to other AIs or analyzing in Excel). It distinguishes itself from sibling tools like scan_to_excel and save_analysis_to_excel by focusing on single-stock data export, though it doesn't explicitly name those alternatives.

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 provides clear context for when to use the tool (exporting single-stock data for external analysis or AI upload) and lists the data types (chart, flow, financial) that define its scope. It doesn't explicitly state when not to use it or name alternative tools, but the use cases and data_type options give sufficient guidance for an agent to select it appropriately.

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 indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds that the tool consumes no tokens ('토큰 소비 없음') and has no row limit, which is useful behavioral context. It doesn't fully describe file output details, but the annotations already cover the safety profile, and the description adds meaningful context beyond them.

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 compact and front-loaded with the core purpose, then examples, then usage guidance, then parameter details. It is slightly dense with mixed Korean/English but every sentence earns its place. The parameter list is clear and scannable.

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 has an output schema and annotations, the description covers the key context: what it does, when to use it, parameter semantics, and a key differentiator (no token consumption, no row limit). It doesn't mention file format details or where the file is saved, but the output schema likely covers return values, and the description is sufficient for an agent to select and invoke it correctly.

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 0%, so the description must compensate. It does: it explains ticker with examples, period with allowed values and default, interval with allowed values and default, and filename with auto-generation behavior. This is strong compensation for the bare 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?

The description clearly states the tool's purpose: exporting US stock long-term data to an Excel file, with examples ('AAPL 10년치 CSV 저장', 'TSLA 5년 일봉 엑셀'). It distinguishes itself from get_us_chart by noting the 500-row limit and positioning this tool for unlimited rows, backtesting, CSV, and AI uploads.

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 says when to use this tool vs get_us_chart: when long-term data is needed and get_us_chart would truncate at 500 rows. It also gives use cases (backtesting, CSV, other AI uploads). This is strong routing guidance.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds value by documenting parameter defaults (count default 50 max 500, market default ALL) in the args block, which sets expectations for call behavior. No contradictions with annotations.

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 front-loaded with the core purpose, followed by trigger examples, then a compact structured args block. Every line earns its place — no filler. The Korean language matches the target user queries naturally.

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?

For a 3-parameter ranking tool with an output schema, the description is nearly complete: all parameters documented with values and defaults, usage triggers given, and output format is covered by the schema. Minor gap is the lack of explicit sibling differentiation in the description itself, but purpose clarity already handles that.

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 0%, so the description carries the full burden — and it delivers. All three parameters are documented with allowed values and defaults: direction (up/down), market (KOSPI/KOSDAQ/ALL with default), count (default 50, max 500). This fully compensates for the schema's lack of 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 states a specific verb+resource: '등락률순위 — 등락률 상위/하위 종목을 가져옵니다' (change-rate ranking — fetches top/bottom change-rate stocks). This clearly distinguishes it from sibling ranking tools like get_volume_ranking and get_market_cap_ranking by focusing on change rate. The purpose is unambiguous.

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 provides concrete usage context with example queries: '상한가 종목', '급등주', '급락주', '상승률 상위' 같은 질문에 사용합니다 (used for questions like limit-up, surge stocks, sharp declines, top gainers). This gives clear when-to-use guidance, though it stops short of naming sibling alternatives or explicit exclusions.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond annotations: it specifies the data is time-series candlestick data, notes the default count of 120 bars ≈ 6 months, and caps at 500 bars. It also clarifies that indicators are not included unless explicitly requested via a different tool. This adds meaningful behavioral context without contradicting annotations.

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 compact and front-loaded: the first line states exactly what the tool returns. The usage guidance and parameter explanations are concise. The warning about get_multi_chart_stats is placed early. Minor redundancy exists (OHLCV is spelled out twice), and the emoji/formatting is slightly noisy, but every sentence earns its place.

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?

For a read-only chart tool with an output schema present, the description covers the essential context: what data is returned, when to use it, how to route to alternatives, and all parameter semantics. The output schema presumably documents the return shape, so the description needn't explain it. The only minor gap is not explicitly stating that the tool is for Korean stocks (though the example code and Korean labels imply it), and the US alternative is mentioned but not fully elaborated.

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 0%, so the description must compensate. It does: code is explained as a 6-digit stock code with example '005930', timeframe is mapped to day/week/month with Korean labels, and count is explained as number of bars with default 120 ≈ 6 months and max 500. This fully compensates for the schema's lack of descriptions, though it doesn't enumerate every possible value beyond the three timeframes.

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 states the tool returns candlestick OHLCV time-series data (open/high/low/close/volume) for a stock, with a specific verb ('get') and resource ('chart'). It also distinguishes itself from siblings by explicitly naming get_multi_chart_stats for period statistics and get_us_chart for US time-series, and mentions get_indicators for technical indicators. This is a specific, well-differentiated purpose.

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 provides explicit when-to-use guidance: use for queries like '삼성전자 일봉', '3개월 주봉', '월봉 데이터', 'price history'. It also gives a clear exclusion: if only period statistics for multiple stocks are needed, use get_multi_chart_stats instead. It even notes that technical indicators should only be fetched via get_indicators when explicitly requested. This is exemplary usage guidance.

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 readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: it discloses that the earnings surprise table only covers operating profit and net income (since the FnGuide original table lacks sales), which is a specific limitation. This goes beyond the annotations without contradicting them, though it doesn't cover other potential behaviors like rate limits or return format (mitigated by output schema).

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 concise, front-loaded with the core purpose, followed by example queries, a limitation note, and a pointer to an alternative. Each sentence earns its place, and there is no redundancy.

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?

The tool is moderately complex, but with an output schema present, the description covers the essential usage scope (when to use, what data it covers, its limitation) and points to the correct sibling for missing data. An agent has enough context to call it correctly without additional assumptions.

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?

The schema provides only a string type for 'code' with no description (0% coverage). The description compensates fully by specifying the format ('종목코드 6자리') and giving an example ('005930'). This is clear and actionable, making the parameter semantics complete.

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 states the tool provides consensus data: analyst opinions, target prices, and earnings surprise (preliminary vs consensus). It gives specific example queries ('목표가 얼마야', '컨센서스', etc.) and explicitly distinguishes from get_financial for sales figures. This is a specific verb+resource with clear differentiation from a sibling 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?

It explicitly lists when to use the tool (for target price, consensus, analyst opinions, earnings surprise) and when not to (for sales figures, pointing to get_financial). This provides clear context and an alternative, leaving nothing to inference.

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?

Beyond the readOnly/openWorld/idempotent annotations, the description discloses critical behavioral rules: values absent or unsettled are not zero, provisional data must not be mixed with final data, institution_total already includes sub-items so adding them double counts, quantity vs amount measures differ by up to 3.7x, and per-broker availability differences (Kiwoom vs Korea Investment). No contradiction with annotations.

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?

Although lengthy, the description is well-structured and front-loaded: summary, then differentiation from get_flow, then mandatory reading warnings, then Args. Every sentence adds value, and the use of bullets and bold makes the critical data-interpretation traps skimmable.

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?

The tool is complex and the schema is minimal, but the description covers the key pitfalls: zero vs unsettled semantics, provisional/final data, double-counting, units, KR-only scope, broker differences, and parameter constraints. Since an output schema exists, return structure is not required. Nothing an agent needs to call this tool correctly 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?

With 0% schema description coverage, the description carries the full burden and does so thoroughly: code (6-digit KR), codes (max 30, combinable with code), days (default 20, max 120), measure (net_quantity/net_amount meanings), and source (auto|kis|kiwoom with strict fallback behavior). All five parameters are semantically explained beyond the bare 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?

The description opens with '상세수급 - 투자자·기관별 일일 순매매' and clearly identifies the resource: daily net trading by investor/institution. It explicitly distinguishes itself from the sibling get_flow by stating that get_flow covers the basic three groups while this tool provides the detailed brokerage breakdown. The purpose is unambiguous.

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 tool explicitly frames when to use it versus the sibling: 'get_flow provides the basic data's individual/foreign/institutional 3 types, and this tool is the detailed breakdown via brokerage Open API.' It also clearly states the tool is domestic-only: 'KR only. US stocks don't have this data.' This gives the agent direct routing guidance.

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?

In addition to the annotations (readOnlyHint, openWorldHint, idempotentHint), the description reveals the tool's data-source behavior (KOSCOM, Naver) and its boundary (does not include company press releases or media articles). This informs correct interpretation of empty results. However, it does not detail pagination, date range, or result ordering, which would further enhance transparency.

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-structured: a one-line definition, a usage-routing paragraph with examples, a critical caveat, and a clear Args section. Every sentence adds value and the most important usage guidance 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?

Given the tool's simplicity (single parameter) and the presence of an output schema, the description covers the essential usage context: source, when to use, and how to interpret empty results. It doesn't specify the number of disclosures returned or time range, but these are likely evident from the output schema, so the description is sufficiently complete.

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?

With 0% schema description coverage, the burden falls entirely on the description. It compensates by defining 'code' as a 6-digit stock code and providing an example ('005930'). This is sufficient for correct invocation, though it omits variations like leading zeros or alternative formats.

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 states the tool's function: '공시목록 — 종목의 최근 거래소 공시 목록' (disclosure list of recent exchange disclosures for a stock). It also specifies the data source (Naver Finance, KOSCOM) and explicitly excludes related but distinct concepts like press releases and media articles, distinguishing it from siblings like get_news and get_reports.

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 gives concrete query examples ('공시', 'IR', '실적 발표', '공정공시', '오늘 왜 오르나(재료 확인)') and adds a critical exclusion: zero disclosures does not mean 'no materials' because press releases and news are not in this list. This effectively routes an agent to use this tool only for exchange disclosures and to consider alternatives for broader news.

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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so safety behavior is covered. The description adds some scope context by listing the returned ETF fields and code examples, but it does not disclose error behavior, validation requirements, or other operational traits. There is no contradiction with annotations.

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 short and front-loaded with a clear summary line followed by a single parameter explanation. Every sentence adds value, with no filler or redundant repetition of the tool name.

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?

For a single-parameter read-only tool with an output schema and safety annotations, the description is largely sufficient. It could be more explicit about this being for Korean/domestic ETFs rather than US ETFs, which would make tool selection fully unambiguous.

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?

The schema's code property has no description, so the description carries the full burden for parameter semantics. It defines code as ETF 종목코드 and provides two concrete examples with fund names ('069500' KODEX 200, '360750' TIGER 미국S&P500). This is useful, though exact format validation rules are not specified.

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 states the tool provides ETF detail information and lists specific fields (기초지수, 보수율, 수익률, 구성종목 TOP10). The Korean ETF code examples imply this is for domestic ETFs, which helps distinguish it from siblings like get_us_etf_info, though it does not explicitly name alternatives.

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 guidance on when to use this tool versus alternatives. The description implies it is for looking up individual ETF details by code, but it never mentions sibling tools such as get_etf_list or get_us_etf_info, nor any exclusions or prerequisite context.

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/openWorld/idempotent, and the description adds valuable behavioral details: sort direction (larger values first), the exclusion of 1/6/12-month returns and dividends from sortable fields, and the need to use get_etf_info for those. No contradiction with annotations.

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?

Despite the length, every sentence adds necessary information. The opening line states purpose, and parameter clarifications are tightly scoped with concrete examples. No filler or redundant restatement of the schema.

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 does not need to document return fields. It covers all inputs, sorting behavior, limitations, and directs the user to the correct sibling tool for missing data. The definition is fully sufficient for correct invocation.

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 0%, so the description carries the full parameter burden. It explains every parameter: category values, keyword semantics and examples, sort_by options with behavior, and limit defaults/maximum. This fully compensates for the schema gap.

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 'ETF 전체 목록 조회' (retrieve full ETF list), naming a specific verb and resource, and immediately states the two filtering dimensions. This clearly distinguishes it from the sibling get_etf_info, which is per-ETF detail.

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?

Explicit guidance is given for when to use keyword vs category, including the instruction not to guess category for theme queries and the limitation that holding-company names not in the ETF name require get_etf_info. This is direct when-to-use and when-not-to-use advice relative to a sibling tool.

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?

Beyond the annotations (readOnly, idempotent, openWorld), the description discloses that when analysis is impossible (outside data range, trading halt, missing supply/demand), it returns a validation status and code rather than fabricating numbers. It also explicitly states it does not assert causation or make trading recommendations. This is significant behavioral context that adds value beyond the annotations.

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-structured: a one-line summary, then usage context, then behavioral notes, then an Args list. It is somewhat long but every sentence adds value. The key purpose is front-loaded. Minor deduction for verbosity in the usage examples, but it remains efficient.

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?

For a read-only tool with an output schema, the description is complete. It covers all parameters, explains edge-case behavior (validation status), and clarifies the tool's limitations. An agent can confidently call this tool correctly without additional information. The presence of an output schema means return values need not be described.

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?

The schema has zero description coverage (0%), but the description's Args section thoroughly explains each parameter: code as a 6-digit stock code, event_date with format options and a recommendation, before with default 5 and max 60, after with default 20 and max 60. This fully compensates for the schema gap and provides meaning beyond the bare schema definitions.

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 states the tool's purpose: it sorts price, volume, and supply/demand reactions around a specific event date. It uses a specific verb (정렬합니다) and resource (주가·거래량·수급 반응), and differentiates from the US counterpart by its focus on Korean events. It also mentions related tools (scan_earnings_season, list_disclosures) that feed into it, giving strong context.

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 gives explicit usage guidance: it tells the agent to pass the disclosure acceptance date from scan_earnings_season or list_disclosures, and explains it is for time-axis alignment, not for causal claims or buy/sell decisions. However, it does not explicitly contrast with the sibling get_event_reactions (plural), so it's not fully exhaustive but clear enough.

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 mark readOnly/idempotent/non-destructive; description adds behavioral caveats: past reaction does not predict future, Naver list contains market notices, same-day events are grouped, and only one candle/flow fetch is used. No contradiction with annotations.

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?

Each sentence earns its place: purpose, differentiation, warnings, then Arg list. Front-loaded with the one-line value proposition, and the caveats are kept as brief warnings rather than digressions.

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?

For a 6-param batch tool with an output schema, the description covers all invocation semantics: defaults, limits, type filtering, and interpretation warnings. The output schema handles return shape, so nothing necessary for correct use 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 description coverage is 0%, so description carries full parameter burden. It explains code format, max_events default/max and grouping, before/after defaults and caps, include_types categories and example, and exclude_types precedence after include. This is far beyond schema field names.

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?

Description opens with '공시반응이력 — 최근 공시들에 이 종목이 어떻게 반응해 왔는지 한 번에' and contrasts with single-date get_event_reaction, making the batch-scope purpose explicit. It states a specific verb+resource and differentiates from the sibling 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?

Gives concrete example questions and an explicit comparison: get_event_reaction looks at one date, requiring 8 calls for 8 disclosures, while this tool computes multiple event dates in one call. It also warns about non-corporate market notices and recommends include_types, which is actionable when-to-use guidance.

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 mark the tool read-only, idempotent, and non-destructive, and the description adds substantial behavioral context: it returns roughly 3,500 characters per stock and can consume 78% of the token budget with just 5 stocks. This goes beyond what annotations provide and helps an agent plan its context window.

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 short, front-loaded with the core purpose, uses a callout for the critical token warning, and ends with a clear parameter definition. Every sentence carries useful information; there is no filler.

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?

For a one-parameter tool with an output schema and safety annotations, the description is complete. It covers what is returned, when to use it, when not to use it, its token cost, and the exact input format. No critical information 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?

Although the input schema gives 0% property description coverage, the description fully documents the single parameter: code is a 6-digit stock code with the example '005930'. This compensates completely for the schema gap.

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 the resource ('재무지표') and specifies the exact scope: one stock's entire set of financial indicators with 19 items across annual and quarterly trends. It explicitly contrasts itself with the sibling get_financial_batch, so an agent can distinguish them without opening schemas.

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?

It gives explicit when-to-use guidance: questions involving PER, PBR, financial statements, market cap, or undervaluation. It also gives a direct alternative: use get_financial_batch for multi-stock comparisons, with a concrete token-cost warning that explains why.

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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context: it returns a consolidated table, covers a specific metric subset, and avoids the token overhead of repeated calls. No contradiction with annotations.

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 front-loaded with a one-line summary, then gives clear usage guidance and parameter details. The token-cost measurement sentence is extra but reinforces the sibling-tool selection rule. No redundant 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?

For a single-parameter batch read tool with an output schema, the description fully covers what data is returned, when to use it versus alternatives, and the input format/limit. Nothing needed to invoke it correctly 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 description coverage is 0%, so the description must compensate. It defines codes as a 6-digit stock code list with a maximum of 30 items, which is essential validation the schema lacks. It does not address empty-list or invalid-code behavior, but it is sufficient for the single parameter.

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 states the tool returns core financial metrics (PER/PBR/ROE/operating margin/debt ratio/dividend) for multiple stocks in one table. It also explicitly distinguishes this from the per-stock get_financial 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?

The description gives explicit when-to-use guidance: any multi-stock comparison or valuation request should use this batch tool instead of calling get_financial repeatedly. It also states get_financial should only be used when full single-stock time-series indicators are needed.

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?

Beyond the readOnly/openWorld/idempotent annotations, the description discloses meaningful behavior: returned values include source and base date, unavailable indicators like CET1/LCR/NSFR are not invented but mapped to required_reports, and cross-regulatory-regime aggregation is deliberately avoided. This gives the agent a precise mental model of the tool's limits and output guarantees.

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-structured: a clear one-line summary, a contextual framing sentence, three scannable bullets, and a compact Args section. Every sentence adds useful information, and the most important scoping constraints are 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?

Given a single well-documented parameter, rich annotations, and an output schema, the description covers all invocation-relevant aspects: when to use it, what data it returns, what it refuses to fabricate, and how to format the symbol. The behavioral and scoping notes make it self-sufficient for correct selection and use.

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?

The schema only defines 'symbol' with 0% description coverage, so the description carries the full burden. It fully compensates by defining the accepted formats: Korean 6-digit stock codes (e.g., '105560') or US tickers (e.g., 'JPM'), with concrete examples for both.

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 identifies a specific resource (financial-firm regulatory capital and asset soundness) and a clear purpose: answering queries like 'KB금융 자본비율', 'JPM CET1', and '충당금 얼마나 쌓았나'. It distinguishes this tool from the manufacturing-style CFO runway path, which makes its scope easy to separate from more general financial-data siblings.

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 tells the agent when to use the tool: for financial companies where the manufacturing-type CFO runway does not apply, and for regulatory capital/asset soundness questions. It also states when not to merge or compare across regulatory regimes, though it does not explicitly name sibling tools as alternatives.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the batch usage warning, which is behavioral guidance, but does not disclose other traits like return format or pagination. Given the annotations, a score of 3 is appropriate—it adds some value but not rich behavioral context.

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 concise and front-loaded with the core purpose. The warning about batch usage is prominent and clear, followed by usage examples and argument definitions. Every sentence serves a purpose, with no wasted words.

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 that an output schema exists, the description doesn't need to explain return values. It covers the essential aspects: what the tool does, when to use it (including the batch alternative), and parameter semantics. It also includes example queries that ground the tool's context. The description is complete enough for an agent to call it correctly.

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 0%, so the description carries the burden of explaining parameters. It does explain code as a 6-digit stock code and days as the number of days with a default of 20. This compensates for the missing schema descriptions, though it could be more detailed about the exact behavior of days.

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 states the tool's purpose: retrieving investor supply-demand trends (net buy/sell by individual/institution/foreigner). It provides concrete example queries and explicitly differentiates from the sibling get_flow_batch by stating when not to use this tool. This distinguishes it effectively from similar tools.

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?

Explicitly states when to use this tool versus get_flow_batch ('If there are 2 or more stocks, don't repeat this tool; use get_flow_batch instead'). Also gives example natural language queries that should trigger this tool, making usage context clear.

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?

Beyond the read-only/idempotent annotations, the description adds meaningful behavior: server-side asyncio.gather parallelism, batch size cap of 30 codes, day limits per mode, and the summary=True deep-mode behavior with 5/20/60-day cumulative metrics. It also describes what changes between daily rows and summary mode, which is far more than the annotations convey.

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-structured and front-loaded: purpose, performance benefit, usage context, then parameter details. Each sentence adds information, including the summary-mode walkthrough and max limits. There is no filler or redundant repetition of schema fields.

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 presence of an output schema and read-only annotations, the description is complete for practical invocation. It covers when to use the tool, how parameters behave in each mode, the batch limit, and the relationship to get_flow. Nothing essential for correct selection or invocation 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 description coverage is 0%, so the description carries full responsibility for parameters. It fully documents codes (list, max 30), days (default 5, max depends on mode: 20 daily / 60 summary), and summary (toggle between daily rows and cumulative summary). Every parameter is semantically explained.

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 states a specific action and resource: parallel bulk lookup of investor supply/demand (institutional/foreign net buying) for multiple stocks. It also distinguishes itself from the sibling get_flow by emphasizing batch parallelism and naming get_flow as the single-stock alternative.

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 gives concrete use cases ('did foreigners buy these stocks together', 'compare supply/demand of watchlist stocks') and explicitly contrasts with calling get_flow N times. It lacks an explicit 'when not to use' statement, but the context is clear enough that an agent can route correctly.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds that it returns current index values, which is useful context, but doesn't disclose details like whether it returns both indices together or separately, or the exact response format. With annotations covering the safety profile, a 3 is appropriate.

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 compact and front-loaded, with the core purpose stated first and example queries following. It's slightly redundant with the title and could be more concise, but every sentence earns its place by clarifying usage context.

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?

For a zero-parameter read-only tool with an output schema present, the description is largely complete. It tells the agent what the tool does and when to use it. The only minor gap is not specifying whether the response includes both indices in a single call or if separate calls are needed, but the output schema likely covers this.

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?

The tool has zero parameters, so the schema provides no parameter documentation. The description compensates by explaining what the tool returns (KOSPI and KOSDAQ current values) and giving example queries. With 0 params, baseline 4 is correct, and the description adds meaningful context about the tool's scope.

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 states a specific verb and resource: 'get_index' retrieves current index values for KOSPI and KOSDAQ. It clearly identifies the tool's purpose and distinguishes it from sibling tools like get_price or get_market_clock, though it doesn't explicitly name a sibling alternative.

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 provides clear context for when to use this tool, listing example queries like '코스피', '코스닥', '시장 지수', and '오늘 시장 어때'. It implies this is the go-to tool for Korean market index queries, though it doesn't explicitly state when not to use it or name alternatives.

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 declare readOnlyHint=true and idempotentHint=true, but the description adds rich behavioral context: `volume.latest` refers to the last bar not today, `bars_ago` vs `days_ago` distinction, null handling for insufficient history, `trade_value_est_krw` as an estimate, and the `in_progress_bar` caveat that judgments may change before market close. These go well beyond the annotations.

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?

Although lengthy, every sentence adds unique value: purpose, usage, key field definitions, parameter details, and data caveats are all present without redundancy. The structure is logical, starting with the core purpose, then usage, then field semantics, then parameters. No wasted words.

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?

The tool is complex (many indicators, parameter variations, and edge cases), yet the description covers all critical aspects: when to use, what indicators are included, key field meanings, parameter ranges and defaults, and the incomplete-bar caveat. With an output schema present, the return format is handled separately, so nothing an agent needs to call correctly 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 description coverage is 0%, so the description carries the full burden. It provides concrete examples (code '005930'), default and range for days (260, 30–500), the full list of include keys split into snapshot and structure categories, timeframe options, and an example of params override. This compensates entirely for the schema's lack of 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 states it provides technical indicator judgments (이평선·RSI·MACD·볼린저·스토캐스틱 등) and explicitly differentiates it from chart visualization (get_chart) and raw OHLCV data. It specifies the exact use case: screening, condition filtering, and status judgment when numeric comparisons are needed.

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 gives explicit when-to-use guidance ('숫자 비교가 필요할 때만 호출') and when-not-to-use ('차트 시각화용 아님'), naming the alternative tool (get_chart). It also explains the token-saving benefit, leaving no ambiguity about selection.

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 readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds that only aggregated judgment values are returned (not time series) and that params overrides are common to all stocks, which are useful behavioral traits. However, it does not detail output structure or potential performance/rate-limit implications, though the output schema exists to fill some of that 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 description is well-structured: a concise header with the core purpose, a warning line clarifying what it is not, and a tidy argument list with defaults. It is front-loaded, every sentence earns its place, and the formatting improves scannability.

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 complexity (5 params, nested objects, output schema present), the description provides enough to call it correctly: parameter defaults, allowed timeframe values, and references to get_indicators for indicator details. It clarifies return type and differentiates from siblings. It does not explain the exact output schema, but the output schema itself covers that, so the description is adequately complete.

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 0%, so the description must compensate. It lists all 5 parameters with explanations: codes (max 100), days (default 260), include (default values, referencing get_indicators), timeframe (allowed values), and params (override, common to all). This adds meaning beyond the bare types. It could specify include key options more explicitly, but it points to get_indicators for details, which is acceptable.

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 states the tool's function: it computes indicators for multiple stocks (up to 100) in parallel, specifically for screening. It distinguishes itself from get_indicators (single-stock) and get_chart (visualization) by naming them explicitly, making the purpose unambiguous.

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?

Explicit guidance is given: use this instead of calling get_indicators N times, and use get_chart for visualization. It also clarifies that it returns aggregated judgment values only, not time series/candles, preventing misuse. The mention of '스크리닝 핵심' (core for screening) sets context for when to use it.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds substantial behavior beyond that: broker-vs-Yahoo data source variability, the KR-bar requirement of a broker connection, "검증된 능력만 활성화된다" (only capability-verified features are enabled) indicating feature gating, strict-mode semantics for source (no fallback on failure), and session limiting to "regular". These are the operational traits an agent needs to predict what will happen at call time.

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?

Well-structured and front-loaded: a one-line purpose title, a compact usage-context paragraph, then a scannable Args block with each parameter on its own line. Every sentence earns its place, though the title's parenthetical "증권사 연결 필요 구간 있음" slightly overlaps with the paragraph that elaborates the broker-connection condition, and the text is dense enough that it requires careful reading.

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?

For a complex 9-parameter tool with zero schema-level parameter descriptions, the definition is nearly complete: it covers data source availability, per-parameter semantics with defaults and enums, session limitations, fallback/strict behavior, and sibling routing. Return structure is handled by the existing output schema, so nothing an agent needs to invoke this tool correctly 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 description coverage is 0%, so the description carries the full burden, and it fully delivers: all 9 parameters are documented with allowed values (interval set, market KR|US), constraints (venue: KRX fixed for KR, NYS|NAS|AMS for US via broker), defaults (row_limit 120, completed_only True, date = latest trading day), and behavior nuances (auto source fixes to one primary broker; explicit broker is strict). No parameter is left undocumented.

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 resource and scope: "분봉차트 — 국내·미국 분봉/시간봉 OHLCV" (intraday/hourly OHLCV for KR and US markets), which clearly identifies what the tool returns. It also names the sibling alternatives it is not — "일·주·월봉은 기존 get_chart / get_us_chart 를 사용" (daily/weekly/monthly should use get_chart/get_us_chart) — so an agent can distinguish it from the get_chart sibling without inspecting schemas.

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 gives explicit conditions for use: users connected to a broker (Korea Investment or Kiwoom) receive KR/US intraday bars; unconnected users get US-only bars from Yahoo, with KR bars requiring broker connection. It also states the exclusion explicitly — daily/weekly/monthly candles belong to get_chart/get_us_chart — providing both when-to-use and when-not-to-use guidance with named alternatives.

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 safety, and the description adds valuable behavioral context: same bar data as the chart with no source mixing, distinct key names, lookback_high/low not being 52-week values, bars_ago counted in bars, and estimated trade values. This goes beyond the annotations without contradicting them.

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 front-loaded with the definition and the most critical caveats (bars vs days, key-name differences), followed by a compact Args list. Every sentence adds needed information, and the bulleted key-name warnings are dense and directly prevent misinterpretation.

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?

For a 10-parameter nested-object tool with an output schema, the description is nearly complete: it covers all parameters, gives defaults and enums, and clarifies important output-name semantics without restating the schema. It falls slightly short of 5 because four parameters depend on get_intraday_chart documentation and the params override is underspecified.

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?

With 0% schema coverage, the description carries the full parameter burden and mostly succeeds: it gives market and interval enums, bars default and range, include default list, and delegates venue/session/completed_only/source to get_intraday_chart semantics. The only weak spot is 'params: 지표 파라미터 오버라이드', which lacks format or key details.

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 precise label, '분봉지표 — 분봉/시간봉 기준 기술지표 (JSON)', naming the resource and scope. It explicitly says daily indicators belong to get_indicators, so the tool is clearly distinguished from its closest sibling.

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 when to use this tool (intraday/minute/hour bars) and when not to ('일봉 지표는 기존 get_indicators 사용'). It also clarifies the bars-not-days unit and references get_intraday_chart for shared parameter semantics, giving the agent clear routing guidance.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat safety. It adds semantic context about the data types (customer deposits, credit balance, funds) but does not disclose any additional behavioral traits such as pagination, rate limits, or error conditions. Given the annotations cover safety, the added context is useful but not extensive, warranting a 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?

The description is succinct: a title line, a one-sentence analogy, a one-sentence use case, and a parameter note. It front-loads the core concept and provides necessary details without padding. Every sentence earns its place, and the structure is easy to scan.

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 has an output schema (not shown but present), the return format is covered. The description explains what the tool does, when to use it, and the only parameter with its constraints. There are no nested objects or complex requirements. It is complete for an agent to invoke correctly.

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?

The schema has one parameter 'days' with no description (0% coverage). The description fully compensates by explaining it as '조회할 거래일 수 (기본 20, 최대 100)' – number of trading days to query with a default of 20 and a max of 100. This adds meaning beyond the bare integer type and is sufficient for correct invocation.

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 states the tool's purpose: it shows the trend of investor deposits (customer deposits, credit balances, funds) representing money waiting in the market. It explicitly contrasts with get_flow ('who bought' vs. 'how much buying money'), distinguishing it from a key sibling. The verb 'get' and resource are clear, and the Korean phrasing is unambiguous.

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?

It provides explicit usage guidance by stating the questions it answers ('예탁금 늘고 있어?', '신용잔고 추이') and contrasts it with get_flow, implicitly telling the agent when to choose this tool over that sibling. It clearly implies the condition for use: when the user asks about deposit levels or credit trends, not stock supply/demand.

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 readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable behavioral detail: data availability depends on the stage (e.g., 확정공모가 only appears after demand forecast), and missing values are returned as empty, not zero. This exceeds annotation coverage and provides crucial context for interpreting results.

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 remarkably concise—two sentences plus example queries—and front-loads the purpose. Every sentence adds value, with no filler or redundancy. It is well-structured and easily parsed.

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 simplicity and the presence of an output schema, the description covers the key behavioral aspects: stage progression and missing-value policy. It does not enumerate all possible fields, but that is adequately handled by the output schema. The description is sufficient for an agent to call and interpret the tool correctly.

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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters; instead, it explains output semantics (stage-dependent fields and missing-value handling), which is appropriate for a parameterless tool.

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 states the tool's purpose: it returns a list of IPO stocks by stage (review, demand forecast, subscription, listing). It includes example queries ('이번 주 청약 뭐 있어', '공모주 일정') that make the intended use immediately obvious. No sibling tool covers IPO schedules, so it is well-differentiated.

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 gives example questions that trigger this tool, establishing clear usage context. It does not explicitly state when not to use it or name alternatives, but given the absence of competing IPO tools among siblings, the guidance is adequate.

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?

The annotations already establish read-only, idempotent, non-destructive behavior, and the description adds substantial non-obvious context: the result head shows total market count and rank range, there is a 1-minute intraday cache, rank boundaries can shift causing overlaps/gaps, and the ranking includes non-stock rows such as REITs, funds, DRs, and halted stocks with a '구분' column and per-type counts. This is exactly the kind of behavioral disclosure agents need.

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 information-dense and well structured: purpose, example queries, result notes, pagination strategy, caveats, and Args. It is front-loaded with purpose and each paragraph earns its place, though the pagination/caching sections could be tightened slightly without losing essential detail.

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 minimal schema descriptions and a complex paginated ranking tool, the description is remarkably complete. It explains how to get the whole market, how to fetch a specific rank band, how to read the head/tail counts, what non-stock rows mean, and how the cache affects results. An output schema exists, so not re-listing return fields is acceptable.

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 0%, so the description has the full burden for parameter semantics, and it fully delivers. It documents market values with defaults and exclusions, count with default and maximum, and page with a concrete mapping example ('page=2, count=500 이면 501~1000위'). No parameter is left ambiguous.

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+resource statement identifying the tool as a market-cap ranking fetcher. It also gives concrete example queries ('대형주', '시가총액 TOP', '코스피 대장주') that make its purpose immediately clear and distinguish it from sibling ranking tools like get_volume_ranking and get_change_ranking.

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 gives clear usage guidance: example phrases, how to paginate for the full market versus a specific rank band, and an explicit exclusion ('ALL 미지원'). It does not explicitly name sibling alternatives to prefer instead, but the examples and market-cap framing make intended use clear enough.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds domain-specific behavior beyond that: it explains the meaning of `current_session`, `sessions`, `next_session`, and that `is_open` only indicates regular market hours. It also discloses the 2026-09-14 aftermarket session addition and the absence of premarket. This is valuable context not present in annotations.

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 a single paragraph that is dense but efficient. The first sentence states the primary purpose and returns. Subsequent sentences add necessary nuance about session semantics and specific dates. No wasted words; every sentence carries important 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?

Given zero parameters and the presence of an output schema, the description is complete. It explains what fields are returned (current_session, sessions, next_session, is_open) and clarifies the Korean aftermarket/premarket status, which is essential for correct interpretation. No missing information an agent would need to call this tool correctly.

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?

The tool has zero parameters, so the baseline is 4. The description does not need to add parameter meaning since there are none. It correctly focuses on explaining what the tool returns rather than parameters.

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 states it fetches Korean and US market status, holidays, and recent/next trading days. It names the specific resource (market clock) and the verb '조회' (query). It distinguishes itself from siblings by being the only tool for market session/time information, with no overlap with any other 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?

It explicitly states when to use: '종목 분석 전 데이터 기준시각을 확인할 때 사용합니다' (use when checking data reference time before stock analysis). It also gives specific contextual details about Korean market sessions and the meaning of fields. It does not mention when not to use, but given its uniqueness among siblings, alternatives are not necessary.

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 establish read-only, idempotent, non-destructive behaviorikuha. The description adds valuable context beyond annotations: it reads from local log files, includes legacy logs from a second directory, and aggregates per-tool statistics. This meaningfully enriches behavioral understanding.

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-structured: a one-line purpose, a short usage context, a focused bullet list of output metrics, relevant log-file details, and a clear parameter explanation. Every sentence adds necessary information without redundancy.

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?

The description is complete for a single-parameter read-only metrics tool. It explains what will be returned (metric categories), where the data comes from, how the sole parameter behaves, and its limits. An output schema exists, so the exact return shape need not be spelled out.

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 0% and the schema only says 'days' is an integer. The description compensates fully by defining the units (days), default value (1, meaning today only), and maximum (30). This is exactly the parameter-level guidance an agent needs.

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 states a specific verb and resource: it aggregates and displays MCP tool usage statistics for recent N days. The bullet list of metric types (call count, latencies, tokens, cache hit rate, errors) makes the tool's purpose unmistakable and distinct from all sibling tools, none of which are usage metrics.

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?

It explicitly identifies the intended context as debugging/optimization, giving the agent a clear when-to-use signal. It doesn't name alternatives, but there are no obvious sibling tools serving the same purpose, so exclusions are less necessary.

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 (readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false) already establish a safe, read-only profile. The description adds substantial semantic caveats beyond that: the tool does not determine cause but only arranges facts chronologically; zero disclosures does not mean no material since press releases/articles are not disclosures; and partial failure is reported as '조회 실패' (unknown), not absence. These nuances materially affect how an agent interprets results and go well beyond what annotations convey.

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 front-loaded with the core purpose and use cases, followed by behavior caveats. Every sentence carries functional weight — the caveats about cause determination, zero-disclosure interpretation, and partial failure are all genuinely necessary for correct usage. It is somewhat dense and long, but there is no filler or repetition.

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?

For a single-parameter aggregator with an existing output schema, the description is complete: it covers what is aggregated, when to use it, what it does not do, result interpretation caveats, and the parameter format. The output schema covers return structure, and annotations cover the safety profile, so nothing an agent needs to invoke it correctly 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 description coverage is 0%, so the description must compensate for the parameter documentation gap. The Args section provides code: '종목코드 6자리 (예: "036090")' — specifying the 6-digit format and giving a concrete example. This is sufficient compensation for a single parameter, though the description could optionally add validation guidance (e.g., leading zeros).

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 precise statement of the tool's function: it aggregates price, trading-volume multiples, articles, exchange disclosures, and securities-firm reports in chronological order. It explicitly names the sibling tools it replaces (get_price, get_disclosure, get_flow) and lists concrete user questions ('오늘 왜 오르나', '급등 이유') that this tool answers first, making its purpose unmistakable and clearly differentiated from siblings.

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?

Usage guidance is explicit and prescriptive: it instructs the agent to use this tool FIRST for 'why did it move' queries and explicitly warns NOT to chain get_price → get_disclosure → get_flow separately. It also routes to get_intraday_chart for a specific follow-up need (verifying whether article timing precedes price reaction), providing both when-to-use and when-not-to-use guidance with alternatives named.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behaviorally meaningful context beyond the annotations: parallel lookup, aggregate-only returns (no time series), a 100-code cap, and the screening-oriented filter semantics. It stops short of discussing partial-failure or invalid-code behavior for a batch call, so a 4 is appropriate.

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 compact and front-loaded: purpose first, then a warning with sibling routing, then a concrete screening use case, then parameter definitions. Every line earns its place, and the formatting (⚠️ for exclusions, ⭐ for key use case) makes the structure scannable.

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?

For a two-parameter tool with an output schema and strong annotations, the description is complete: it explains what it returns and does not return, when to use it versus get_chart, the screening scenario, parameter defaults, and the 100-item limit. No information an agent needs to invoke it correctly 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 description coverage is 0%, so the description carries the full burden for parameter meaning, and it delivers: codes is explained as a stock-code list with a 100-item maximum, and days is explained as lookback period with a default of 260 (= 52 weeks). Both parameters are fully clarified despite having no schema-level 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 names a specific verb and resource (bulk chart stats) and enumerates the exact aggregate fields returned: current price, high, low, drawdown, and period return. It explicitly differentiates itself from get_chart by stating it is not time-series and returns aggregates only, so an agent can distinguish it from siblings without opening schemas.

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 gives explicit when-to-use guidance: use it instead of N individual get_chart calls, and it is essential for screening filters like drawdown_pct/period_return_pct (with a concrete example '52-week high -30%'). It also states the exclusion condition — candles/OHLCV belong to get_chart. Nothing is left to inference.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful constraints: max 30 codes, and token efficiency. It doesn't describe error handling or partial-result behavior, but given the annotations, this is adequate.

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 slightly verbose but every sentence earns its place: purpose, usage examples, efficiency note, and parameter details. It is front-loaded with the core function and uses a clean Args block. Could be tightened, but it is well-structured.

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 format is covered. The description covers when to use, the parameter meaning, and a constraint. It doesn't explicitly state this is for Korean stocks, but that is implied by the code format and the sibling get_us_multi_price. Missing minor edge cases, but overall sufficient.

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?

The schema has 0% coverage for the parameter description, but the description explicitly defines 'codes' as a list of Korean stock codes, sets a maximum of 30, and gives concrete examples (e.g., ['005930', ...]). This fully compensates for the schema gap.

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 states a clear verb ('fetches basic info for multiple stocks at once') and specifies the exact data fields (price, change rate, volume). It also differentiates itself from the sibling get_price by explicitly framing itself as the bulk alternative, so an agent can immediately tell it apart.

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 provides explicit usage examples ('Show me current prices for these stocks'), names the alternative (get_price) and the condition for choosing this tool (multiple vs individual calls), and even highlights token efficiency. It also calls out a specific scenario (comparing N screening results). This is complete guidance.

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?

The description discloses data quality nuances beyond annotations: two sources with different timestamp accuracy, approximate times for name search, potential mixing of same-name articles, and late tagging for today's articles. It also notes that company press releases are not disclosures. This adds substantial behavioral context that annotations (readOnlyHint, openWorldHint) do not cover.

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 organized with clear sections: purpose, usage, source distinctions, and args. It uses bullets for the source details, making it scannable. Every sentence adds value—no filler. It is appropriately sized for the complexity of the 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?

Given the tool's complexity (two sources, timing caveats, three parameters with no schema descriptions) and the presence of an output schema, the description is complete. It covers what the tool does, when to use it, parameter semantics, and behavioral quirks, leaving nothing an agent needs to call it correctly.

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 0%, so the description fully compensates. The Args section defines each parameter: code (6-digit example), limit (default 10, max 30), and today_only (Korean date filter). This is essential and clearly stated, giving the agent everything needed to fill the parameters correctly.

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 clear statement: '종목뉴스 — 한국 주식 종목의 최근 기사' (stock news — recent articles for Korean stock), and explicitly names the two sources (Naver stock news and name search). It also distinguishes itself from get_move_context and get_disclosure, making the purpose unambiguous and differentiated from siblings.

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?

It provides explicit usage triggers ('무슨 뉴스 있어', '기사 찾아줘', '재료가 뭐야') and an explicit when-not-to-use ('오늘 왜 오르나' → get_move_context). It also clarifies that get_disclosure returning zero does not imply no articles, which is a valuable routing rule.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, read-only operation. The description adds context beyond annotations: it's a snapshot (not a time series), and for NXT-listed stocks, it shows KRX regular market as default with NXT as a separate block, not mixing the two markets. This is useful but not exhaustive; it doesn't mention data freshness, delay, or exact return format, though an output schema exists.

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 concise and front-loaded with the core purpose. The exclusions are placed early, which is helpful. However, it includes some redundancy: the NXT explanation is a bit verbose, and the example could be trimmed. Still, it's efficient overall, with no wasted sentences.

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 simplicity (1 parameter, no nested objects) and the existence of an output schema, the description is quite complete. It covers the key aspects: single stock, snapshot nature, and the NXT market handling. The main gap is not specifying how to interpret the output, but that's covered by the output schema. It could also mention that it's for Korean stocks explicitly, but the example and NXT context make it inferable.

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?

The input schema has only one parameter (code) with 0% schema description coverage, so the schema itself provides no description for what 'code' means. The description compensates by explaining the parameter: '종목코드 6자리 (예: "005930")' (6-digit stock code, e.g., '005930'). This adds meaning beyond the schema's bare 'code' property, which is great for a single-parameter tool.

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 states the tool's purpose: retrieving a current market snapshot (today's OHLC + volume) for a single stock. It specifies the resource (stock price) and the verb (get), and it differentiates from siblings by explicitly noting that multi-stock queries should use get_multi_stocks and historical queries should use get_chart. However, it doesn't explicitly mention that it's for Korean stocks, though the example (005930) and NXT context imply it.

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 provides explicit guidance on when to use this tool: for queries like 'What is Samsung Electronics' current price?' It also clearly states exclusions: if multiple stocks, use get_multi_stocks; if historical data needed, use get_chart. This is a strong usage guideline, directing the agent away from inappropriate uses.

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 mark this as read-only and idempotent; the description adds meaningful behavior beyond that: it warns about token consumption, explains why summary mode is usually sufficient, and discloses that image-rendered PDFs may be unreadable and will result in a clear failure message with a link instead of fabricated text.

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 front-loaded with the core purpose, then uses a compact warning, a clear table, and brief rationale paragraphs. No sentence is redundant; each adds either usage context, failure-mode awareness, or parameter semantics.

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 output schema exists and the annotations already cover safety, the description covers every operational need: required parameter, mode defaults, optional parameter behavior, token-cost warning, sibling routing, and failure handling for image-based PDFs. Nothing necessary for correct invocation 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 description coverage is 0%, but the Args section fully compensates: nid is tied to get_reports output, mode is explained with all three values including Korean aliases and defaults, and max_chars is explicitly optional with behavior defined when omitted.

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?

First line states the exact action and scope: reads the PDF body of exactly one securities report. It explicitly contrasts itself with get_reports, so an agent can immediately tell which tool handles lists/summaries vs. deep single-report reading.

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 explicit when-to-use guidance: only for deep reading of a single report, while get_reports suffices for lists and short summaries. It also gives a mode-selection table with user-phrase examples, a clear default (summary), and guidance to avoid multi-call token exhaustion.

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 readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds count defaults/maximums and query-mode distinctions, but it does not disclose additional behavioral traits such as auth requirements, rate limits, or result ordering. With annotations present, the added behavioral context is adequate but not rich.

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-structured and front-loaded with the purpose, followed by usage triggers and parameter details. There is slight redundancy between the prose explanation and the Args section, but each paragraph earns its place and the format is scannable.

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 annotations and output schema, the description is complete enough for an agent to invoke the tool correctly. It covers parameter semantics, mutual exclusivity of `code` vs `kind`, allowed enum values, count limits, and example queries. No essential missing information prevents correct selection or invocation.

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?

The input schema is bare with 0% description coverage, so the description carries the full burden. It thoroughly explains `code` as a 6-digit stock code, `kind` with all enum values (market, invest, economy, debenture, industry, company), and `count` with default and maximum. This fully compensates for the schema's lack of parameter 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 states the tool retrieves brokerage research reports across stocks, market, industry, and economy. It distinguishes stock-specific usage via `code` from category-based usage via `kind`, but it does not explicitly contrast with sibling tools like `get_report_content` or `get_consensus`.

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?

It provides concrete query triggers such as '리포트', '증권사 분석', and '애널리스트 의견', plus an example of a market-sentiment question. It clarifies when to use `code` vs `kind`, but it does not name alternatives or state when not to use this tool.

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?

Adds substantial behavior beyond the readOnly/idempotent annotations: results are returned in descending order by 등락률, the header and footer expose pagination context, and the 5-minute cache plus ordering drift can cause overlapping or missing boundary stocks. This is exactly the kind of operational nuance an agent needs.

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?

Long but tightly structured: core purpose and examples come first, followed by important caveats and then parameter details. Every sentence carries operational value, and the warnings about pagination and cache are essential rather than filler.

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?

The description covers matching, ordering, pagination, caching, and full-sector retrieval strategy. Since the output schema and annotations already cover return shape and safety, nothing critical is missing for correct invocation.

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?

With 0% schema description coverage, the description fully compensates: sector_name is explained with examples, count gets default and maximum values, and page is illustrated with page=2, count=30 yielding positions 31-60. No parameter is left ambiguous.

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: 특정 업종에 속한 종목 리스트를 가져옵니다, and gives concrete example queries like 통신장비 업종 종목 and 제약 섹터 종목. The sector-scoped semantics clearly distinguish it from sibling tools like get_theme_stocks or list_sectors.

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?

Explicitly says when to use it, including sector-name partial matching and example user questions. It also gives detailed pagination strategies for full-sector retrieval, but it does not explicitly name alternative tools to use for non-sector lists, so exclusions are implied rather than stated.

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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the description correctly avoids repeating those. It adds substantial behavioral context beyond annotations: the median is used instead of mean (with rationale), negative PER values are excluded from aggregation (with count noted), sample_median is used when the sector exceeds the aggregation cap, and top_n only affects the display table, not the aggregation denominator. These are non-obvious behaviors that materially affect how results should be interpreted. No contradiction with annotations.

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 organized into clear sections: purpose, usage examples, statistical methodology, aggregation behavior, and parameter explanations. It uses bold and bullet-like formatting to front-load key facts (median, exclusions, code shortcut) and includes concrete examples. While it is long, every sentence earns its place – no fluff or redundancy. The structure makes it easy for an agent to extract the critical information quickly.

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 (aggregation logic, edge cases, multiple usage modes), the description is comprehensive. It covers the statistical basis (median), exclusions (negative PER), fallback behavior (sample_median), the role of top_n, and the code-based alternative. Since an output schema exists, the description need not explain the return format. There are no missing pieces that would prevent correct invocation or interpretation.

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 0%, so the description bears full responsibility for parameter documentation. It explains each of the four parameters in detail: sector_name (with examples and the condition that it can be omitted if code is given), top_n (default 40, max 80, display-only), kind (sector vs theme), and code (6-digit code that auto-detects the sector). It also clarifies the relationship between parameters (code overrides sector_name) and the effect of top_n. This fully compensates for the bare 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?

The description clearly states the tool aggregates PER, PBR, and ROE for a sector/theme and shows a stock's relative position (premium/discount). It gives concrete example queries and explicitly differentiates from get_financial by noting it provides a comparison baseline that individual stock metrics cannot. The verb (get) and resource (sector valuation) are specific and unambiguous.

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?

It explicitly states when to use this tool: for questions like 'average PER of a sector' or 'is this stock cheap within its sector?' It also says get_financial cannot answer these, routing the agent away from the sibling. It provides two usage modes (by sector name or by stock code) and a caveat about ETF/ETN not having sectors. This is clear guidance with an explicit alternative.

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?

Beyond the annotations, the description discloses substantial behavioral detail: responses are split into per-kind blocks with independent status/provider/granularity/data_as_of, non-ok status means data was not received rather than missing, granularity differs by provider, units follow measure_units, and observed_at must be used for intraday timing. It also clarifies the lending-vs-short-selling distinction. No contradiction with the read-only/idempotent annotations.

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?

Though long, the description is tightly organized: a brief opening, a set of high-value 'must-read' bullets, and a compact Args list. Every sentence contributes operational meaning, and the most critical interpretation warnings are front-loaded. There is no filler or repetition.

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?

For a tool with 6 parameters, 0% schema coverage, and an output schema, the description is remarkably complete: it explains response structure, status semantics, granularity, units, timing, provider limitations, and domain pitfalls. It gives an agent everything needed to both request and correctly interpret the data.

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 0%, so the description must carry the full parameter burden, and it does: all six parameters are explained with types, constraints, defaults, and enums (e.g., code is a 6-digit KR code, codes max 30, days defaults to 30, source is auto|kis|kiwoom, kinds includes program_trading|short_selling|credit|securities_lending|foreign_holding|cfd). This fully compensates for the bare input 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?

The opening line clearly names the resource ('수급압력' / supply pressure) and enumerates the exact data categories: program trading, short selling, credit, securities lending, and foreign holdings. The scope is explicitly limited to KR equities. However, the description lacks an explicit verb and never differentiates itself from sibling tools like get_flow or get_detailed_investor_flow, 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?

The description gives explicit when-not-to-use guidance, such as '대차잔고는 공매도 실행이 아니다' and the warning that KIS securities lending is market-level only and must not be used for per-stock answers. It also states source-selection behavior ('auto 는 주 사용 증권사 하나에 고정') and the KR-only boundary. This is strong, actionable usage guidance despite not naming sibling tools.

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?

Beyond the readOnly/idempotent annotations, it discloses important behavior: results are sorted by change rate descending, truncating with count pushes laggards to the end, the header contains total and range, and the tail provides page= continuation. It also warns about the page ordering consequence for undervalued-stock use cases.

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 purpose, then behavior, then a clearly labeled Args section. It is slightly verbose and contains a typo ('뒤쪽 쪽으로'), but each section earns its place for the complexity being described.

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?

The description covers all the semantics an agent needs to call this tool: scope, ordering trap, pagination, max count, token-saving option, and an alternative for market-cap ranking. The presence of an output schema means return-value structure does not need to be restated, and the existing annotations cover safety.

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 schema description coverage is 0%, the description documents all four parameters: theme_name with examples, count with default and max (30/500), include_reason with token-saving benefit and recommendation, and page with a concrete paging example (page=2, count=30 => 31~60).

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 verb and resource: '특정 테마에 속한 종목 리스트를 가져옵니다' (fetch list of stocks belonging to a theme). It gives concrete query examples and notes partial theme-name matching, so an agent can distinguish it from tools like list_themes or ranking tools.

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 states when to invoke it (e.g., '반도체 테마 종목', '2차전지 관련주', 'AI 테마주') and routes to an explicit alternative when a market-cap-based population is needed: '시가총액 기준 모집단이 필요하면 get_market_cap_ranking을 쓰세요'. It also gives scenario-specific advice for finding undervalued stocks via count/page settings.

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 establish the read-only, idempotent, non-destructive nature of the tool, and the description adds behavioral detail by enumerating what is returned: mean/high/low price targets, buy/hold/sell distribution, and recent upgrade/downgrade actions. No contradiction with annotations.

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 compact and front-loads the tool's purpose, then gives examples, return contents, and argument guidance. The bilingual repeat of 'US analyst ratings / price target / rating' adds slight redundancy but does not bloat the entry.

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?

For a single-ticker read-only retrieval tool with an output schema, the description gives enough to select and call it correctly: US scope, ticker argument, and the kinds of questions it answers. It doesn't discuss coverage limitations or data freshness, but the output schema and annotations cover much of the rest.

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?

With 0% schema description coverage, the description compensates by explaining the single parameter: 'ticker: US 티커 (예: NVDA)' — indicating the accepted format and providing an example. For one required parameter this is sufficient; more detail on case or exchange suffix would be nice but is not essential.

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 states the tool returns US analyst price targets and ratings (목표주가 + 투자의견) and lists specific outputs: mean/high/low targets, buy/hold/sell distribution, and recent upgrades/downgrades. It is specific about the resource and the example queries, though it does not explicitly contrast itself with sibling tools like get_consensus or get_us_info.

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?

It provides concrete query patterns such as 'AAPL 목표가', 'NVDA analyst rating', and 'Tesla buy/hold', telling an agent exactly when to invoke this tool. It does not state when not to use it or name preferred alternatives, but the usage context is clear.

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 readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral details beyond those: default period (3mo), default interval (1d), prepost applying only to intraday, and a max row limit of 5000 with a recommendation to export large datasets. No contradiction with annotations.

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 short intro, example queries, and an Args list. It is slightly verbose due to bilingual repetition ('US stock chart OHLCV' and '미국 주식 시계열 캔들 데이터'), but every major section earns its place by adding routing or parameter value.

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 five parameters, one required, and an output schema present, the description covers all necessary invocation details: valid enum values, defaults, the intraday-only prepost behavior, and the large-data fallback. No critical information needed to call the tool correctly 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 description coverage is 0%, so the description carries the full burden for parameter understanding. It fully compensates by documenting every parameter: ticker format with example, period allowed values and default, interval allowed values and default, prepost semantics, and limit default/max. This is exactly the compensatory value needed.

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 identifies the tool as 'US stock chart OHLCV' and 'US historical price data,' making the resource and data type clear. It also distinguishes itself from siblings by positioning itself as the US time-series entry point and explicitly naming get_chart for Korean data. Example queries like 'AAPL 차트' and 'NVDA history' remove ambiguity about intended use.

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 states when to use the tool ('US 시계열 진입점') and gives concrete query examples. It also provides an explicit alternative for large data (export_us_to_excel, token 0). It does not exhaustively compare against nearby siblings like get_us_price or get_intraday_chart, but the guidance given is sufficient for common routing.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that it returns history, ex-date, and yield, and mentions a default limit of 12, which is useful behavioral context. However, it doesn't disclose details like pagination or data range limits.

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 compact and front-loaded with the core purpose, followed by example queries and parameter explanations. The bilingual content adds a bit of redundancy but is not excessive. Every sentence serves a purpose.

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?

For a simple read-only tool with 2 parameters and an output schema, the description is largely complete. It covers what the tool returns, example usage, and parameter semantics. The output schema exists, so return values need not be described. Minor gaps like data range or pagination are not critical for this 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 description coverage is 0%, so the description must compensate. It explains 'ticker' as a US ticker with examples and 'limit' as the number of recent dividends to display with a default of 12. This adds meaning beyond the bare schema, but the schema itself is simple and the description covers both parameters adequately.

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 states the tool returns US dividend history, ex-date, and yield, with a specific verb ('get') and resource ('US dividends'). It distinguishes itself from siblings by focusing on dividend data, though it doesn't explicitly name a sibling alternative.

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 provides example queries ('AAPL 배당', 'KO dividend yield', 'SCHD 배당 이력', 'ex-date') that indicate when to use this tool. It doesn't explicitly state when not to use it or name alternatives, but the examples give clear usage context.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about what data is returned (next earnings date + EPS surprise history) and why it matters. No contradiction with annotations. It doesn't disclose limitations like data freshness or ticker-format strictness, but with strong annotation coverage a 3 is appropriate.

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 purpose before examples. The example queries and the one-line context about US earnings being key events each earn their place. Slightly verbose with the Korean translations of English terms, but nothing is wasted.

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?

Has an output schema, so return-value details don't need description coverage. With a single required parameter that's documented with an example, and clear purpose plus usage examples, an agent has enough to call it correctly. Minor gap: no guidance on how the two data components (date vs surprise history) are shaped.

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 0%, so the description must compensate for the undocumented ticker parameter. It does document 'ticker: US 티커 (예: "NVDA")' with a concrete format example. However, this is minimal — it doesn't explain ticker casing rules, exchange suffixes, or validity constraints beyond the example. The description adds some value but doesn't fully compensate for the coverage gap.

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+resource: 'US earnings calendar — 다음 실적 발표일 + 최근 EPS 서프라이즈 이력' (next earnings date + recent EPS surprise history). This clearly distinguishes it from price, chart, and financials siblings. However, it doesn't explicitly differentiate from get_us_event_reaction, which could overlap in scope.

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 ('AAPL 실적 언제', 'NVDA earnings date', 'Tesla 다음 실적') that signal when to use it, plus context that US quarterly earnings are key price events. But it never names an alternative tool or states when NOT to use this tool, leaving some ambiguity against get_us_financials or get_us_event_reaction.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds value by specifying the returned data categories (top holdings, sector weights, asset allocation). It does not discuss pagination, error handling, or other behaviors, but given the annotations cover the main traits, a 3 is appropriate.

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 compact and front-loaded with the main purpose, followed by example queries and a brief parameter note. It avoids unnecessary detail. The bilingual format (Korean/English) is slightly redundant but not harmful. Overall, it is efficient and well-structured.

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?

For a single-parameter read-only tool with an output schema, the description is fairly complete. It states the type of data returned and gives usage examples. It does not mention that it is specifically for US ETFs, but the tool name already conveys that. It could note that the ticker must be a US-listed ETF, but this is minor given the examples and schema availability.

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?

The schema has no description for the ticker parameter (0% coverage), so the description must compensate. It does so by explaining the ticker is an ETF ticker and providing concrete examples (SPY, QQQ, VOO, SCHD). This adds meaningful guidance beyond the raw schema, though it could also specify format or uppercase requirement.

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 states it provides US ETF details including top holdings, sector weights, and asset allocation. It distinguishes itself from siblings like get_us_info (general stock info) and get_etf_info (potentially non-US ETF) by specifying 'US ETF' and the exact content types. Example queries further clarify its scope.

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 provides concrete example queries ('SPY 구성종목', 'QQQ holdings', 'VOO 섹터', 'ETF 보수') that indicate when to use the tool. However, it does not explicitly mention alternatives or state when not to use it, such as for non-US ETFs or price data. The context is clear but lacks explicit exclusions.

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 readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context: it uses only completed daily candles (excludes in-progress), and it automatically aligns the reaction based on session (pre/post). This goes beyond the annotations and helps the agent understand the tool's internal logic.

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 front-loaded with a clear one-line summary, followed by a concise rationale for the BMO/AMC distinction, and then a structured argument list. It is compact and every sentence earns its place. The structure makes it easy to scan and understand.

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?

The description covers the core logic and all parameters. Since an output schema exists, return value details are not needed. It does not explicitly mention edge cases like missing earnings data or handling of 'unknown' session, but the tool is fairly self-contained. It is complete enough for an agent to call correctly.

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 0%, but the description compensates fully with an explicit 'Args' section. It explains each parameter: ticker (US ticker), event_date (announcement date in YYYY-MM-DD), session (auto/pre/post/unknown with semantics), and after (number of trading days after, default 5, max 20). This is essential because the schema provides no descriptions, and the description fills the gap completely.

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 states a specific purpose: aligning US stock price reaction to the correct trading day based on earnings announcement session (BMO/AMC). It clearly distinguishes from generic get_event_reaction by focusing on US earnings and session-aware alignment. The verb '정렬' (align/sort) and resource '주가 반응' (price reaction) are specific and unambiguous.

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 explains the context (US earnings with pre/post market announcements) and the automatic alignment logic, making it clear when to use this tool. However, it does not explicitly name alternatives or state when not to use it, though the specificity implicitly excludes generic event reactions. It could be improved by referencing sibling tools like get_event_reaction for non-US events.

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?

Beyond the readOnly/openWorld/idempotent annotations, the description adds valuable caveats: a zero-match result does not mean the term is absent, unfound categories are 'unconfirmed' rather than 'absent', and both-empty mode returns only a document list. These disclosures materially shape an agent's interpretation of results.

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 bulleted structure is efficient and front-loaded, with each behavior and parameter earning its place. The 'SL-04' label adds little value but does not significantly hurt clarity.

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 and 5 parameters, the description covers all necessary guidance: parameter semantics, mode behavior, output limits, omission semantics, and document handling. An output schema exists, so not detailing return fields is acceptable.

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?

With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose: ticker for CIK lookup, accession_no as the SEC receipt number from get_us_filings, find as a keyword, analyze as the dilution/contract mode, and document as the file to read, including default behavior.

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 states the tool's purpose: searching keywords in US SEC filing text and structuring dilution/contract clauses by category. It also specifies what the tool does not do (does not return the full text) and distinguishes itself from the filing-list sibling by requiring an accession_no from get_us_filings.

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 gives clear usage context: use find for keyword excerpts, analyze for dilution/contract structuring, leave both empty for a document list, and use document to read a specific file. It also includes an explicit exclusion ('does not return full text'), though it does not name alternative sibling tools directly.

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 convey read-only/idempotent behavior, and the description adds substantial operational context beyond them: SEC identifies issuers by CIK, share classes like GOOGL/GOOG normalize to the same issuer set, the requested ticker is preserved in metadata, and full search completion requires coverage_complete=true. It also discloses the segmented older-page mechanism.

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 information-dense but well structured, front-loading purpose and example queries before explaining pagination and parameters. Every sentence earns its place, and there is no redundant repetition of annotations or schema.

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?

For a tool with pagination, CIK normalization, form filtering, and a companion detail tool, the description covers all invocation-relevant behavior. It provides the termination condition, segment navigation, parameter defaults, and routing to get_us_filing_detail, so an agent can call it correctly without additional context.

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 0%, but the Args section documents every parameter in detail: ticker, limit with default and max, forms with examples, page as a segment file name, and offset with its default. This fully compensates for the schema's lack of parameter 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 states that the tool returns the US SEC EDGAR filing list, including accession numbers and original URLs, and gives concrete example queries. It also distinguishes itself from the sibling get_us_filing_detail by explicitly directing body/exhibit reading to that 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?

Usage guidance is explicit: use for queries like 'AAPL 10-K', 'RIVN latest filings', '8-K', and 'SEC filing'. It tells the agent to call get_us_filing_detail with the accession number when body/exhibits are needed, and it fully explains pagination via page/offset and the completion condition.

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 readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds what data it returns (P/E, PEG, P/B, ROE, margins, etc.) but does not disclose data source, update frequency, currency, or limitations. This is acceptable but not rich behavioral context.

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 front-loaded with the tool's purpose, then provides example queries and a compact list of returned metrics, followed by the Args note. The English/Korean repetition is minor and aids clarity for bilingual queries, so no sentence feels wasted.

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?

For a simple one-parameter tool, the description covers what the tool does, what it returns, and how to specify the ticker. An output schema exists and the annotations handle safety semantics. Missing details like data source or refresh cadence would be nice but are not required for correct invocation.

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 0%, so the description must compensate. The Args section explicitly defines ticker as a US ticker and gives the example 'AAPL', which adds meaning beyond the bare schema property. It could add formatting or validation guidance, but for a single ticker parameter the provided semantics are sufficient.

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 states a specific resource and scope: US stock financials and valuation ratios (PER, PBR, PEG, ROE, dividend). It also lists the metrics returned, which separates it from price, chart, earnings, and news tools among the siblings. It is clear, though it does not explicitly name or contrast a sibling alternative.

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 gives concrete example queries such as 'AAPL PER', 'Apple 재무', 'NVDA valuation', and 'forward P/E', making it clear when an agent should choose this tool. It does not state exclusions or when to prefer a sibling like get_us_financial_statement or get_financial, so it stops short of a full 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 readOnlyHint=true and idempotentHint=true, so the tool is known to be read-only. The description adds meaningful behavioral context beyond annotations: it states that only key rows are extracted (Total Revenue, Net Income, etc.) and specifies default values for statement_type ('income') and period ('annual'). These details help the agent understand what the tool returns and how it behaves with missing parameters.

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 concise and well-structured: it starts with the purpose, gives example queries, explains the key-row behavior, and then lists arguments. It is front-loaded with the essential information. The mix of Korean and English is a minor readability issue, but the structure is clear and every sentence adds value.

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 existence of an output schema, the description does not need to explain return values. It covers the parameters, allowed values, defaults, and the behavior of extracting key rows. It does not mention ticker format or potential limitations, but these are likely standard and covered elsewhere. The description is sufficiently complete for an agent to call the tool correctly.

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?

The schema has 0% description coverage, so the description carries the full burden. It lists all three parameters (ticker, statement_type, period) and provides allowed values and defaults for statement_type and period. This fully compensates for the schema's lack of descriptions, giving the agent all needed information to construct a valid call.

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 states it provides US financial statements (income/balance/cash_flow) and gives example queries. It specifies the resource and three statement types, making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like get_us_financials or get_financial, which could lead to confusion about which tool to choose.

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 gives concrete usage examples in Korean ('AAPL 손익계산서', 'NVDA 현금흐름표', etc.) and states '같은 질문에 사용합니다' (use for questions like these). This provides clear context for when to use the tool, though it does not mention when not to use it or point to alternatives. It is adequate but could be more explicit about exclusions.

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 read-only, idempotent, and non-destructive behavior. The description adds meaningful context by specifying the data source and nature of the holdings (13F institutional and mutual fund holdings), which goes beyond the structured annotations.

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 compact, front-loaded with core meaning, and uses every line for a purpose: definition, example queries, and parameter hint. No filler or redundant explanation is present.

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?

For a single-parameter, read-only tool with an output schema, the description covers what the tool returns and how to invoke it. Additional details like filing-period coverage would be nice but are not necessary for correct use.

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?

The schema has no description for 'ticker', and the description adds only 'US 티커' (US ticker). This is minimal but adequate for a single required string parameter; adding an explicit example like 'AAPL' would strengthen it.

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 states the resource precisely: US institutional holders and 13F holdings, backed by example queries like 'AAPL institutional holders' and 'Vanguard 보유'. It is clearly distinct from close siblings like get_us_insider or get_us_short, even without naming them explicitly.

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?

It explicitly maps the tool to natural-language questions such as 'AAPL institutional holders', '13F holdings', and 'who owns'. This gives clear when-to-use context, though it does not mention alternative tools or circumstances where it should not be used.

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 readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the specific content fields (sector, industry, market cap, business summary) but does not disclose any additional behavioral aspects like return format, error conditions, or limitations. It neither contradicts nor significantly extends beyond the annotations.

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 compact and well-structured. The main purpose is front-loaded in the first line, followed by usage examples and the parameter definition. Every sentence serves a clear function with no redundant wording.

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?

For a single-parameter, read-only info tool with an output schema and comprehensive annotations, the description covers the essential aspects: what it does, when to use it, and how to specify the ticker. The return format is not described, but the output schema presumably handles that, so the description is sufficiently complete.

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?

The input schema has no descriptions (0% coverage), but the description explicitly explains the only parameter: 'ticker: US 티커 (예: "AAPL", "NVDA")'. This provides meaning and examples that the schema lacks, effectively compensating for the schema gap.

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 states it provides US company profile info (sector, industry, market cap, business summary) and gives concrete example queries ('Apple 어떤 회사', 'NVDA 사업 설명'). This verb+resource combination distinguishes it from price, financials, earnings, and news tools among the many siblings.

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 lists example questions that indicate when to use it, but it does not explicitly name alternatives or state when not to use it. For instance, it doesn't say 'for financial statements use get_us_financials' or 'for price use get_us_price'. The guidance is implied through the provided examples rather than explicit exclusions.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds that it returns Form 4 and a net buy summary but does not explain what '순매수' (net buy) means or how it is computed. It also does not describe the output format beyond that. Since annotations cover the safety profile, a 3 is appropriate.

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 concise but poorly structured: it mixes Korean and English, includes an 'Args:' line that duplicates the schema, and uses a colon-heavy format. The main purpose is front-loaded, but the bilingual content and redundancy reduce clarity.

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 a single parameter and an output schema (indicated as present), the description covers the basics: what data is provided and example queries. However, it does not explain the 6-month summary calculation, any limitations (e.g., only US tickers), or how the output is structured beyond the schema. It is adequate but not complete.

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 0% (no description in the schema for ticker). The description only says 'ticker: US 티커', which adds minimal meaning beyond the schema's type and title. It does not specify formats, examples, or constraints. Given low coverage, the description should compensate more, but it does not.

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 states the tool provides US insider trading Form 4 data and a recent 6-month net buy summary. This is a specific resource and function, and it is distinct from sibling tools like get_us_filings or get_us_news. It does not explicitly compare to siblings but is clear enough.

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 gives example queries (e.g., 'AAPL insider trading', 'NVDA 내부자 매수') that imply when to use it. However, it does not explicitly state when not to use it or suggest alternative tools for other insider-related needs, such as filings detail. The guidance is implicit via examples.

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