국내 주식·채권 MCP (Korea Stocks & Bonds)

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive behavior, so the safety profile is covered. The description adds real behavioral value beyond that: it discloses the upstream data source (FSC public data) and enumerates the returned sections, which effectively serves as a return contract given there is no output schema. It omits any note on rate limits or how much history is returned.

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?

One front-loaded sentence led by the resource and scope, then a compact enumeration of returned data, ending with a provenance note. Nothing is repeated and every clause carries information an agent would otherwise have to discover by calling.

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 read-only lookup with full schema coverage and no output schema, the description supplies exactly the missing piece: what the response contains. An agent can decide to call this and know what to expect without further inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with both `bond` (ISIN or name) and `price_days` (default 60, max 1000) already documented in the schema. The description's mention of 'daily quotes' loosely maps to `price_days` but adds no format or interpretation detail beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource (single bond issue detail) and then enumerates the exact payload: issuance terms (seniority, options, guarantee, coupon, payment cycle), agency ratings, daily quotes (price, yield, traded face value), principal/interest schedules, and same-issuer bonds. This clearly separates it from the list-oriented sibling `bonds` and the date-oriented `bond_calendar`.

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 '한 종목' (one issue) framing implies this is the detail lookup after finding a bond elsewhere, but the description never names an alternative tool or states when not to use it. Usage is inferable from scope rather than explicitly guided.

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 cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, but the description adds genuinely important data-quality context: past dates are actual payments (actual=1) while future dates are projected calculated values that do not account for holidays. That caveat materially changes how an agent should present results; only return formatting/pagination is left unaddressed.

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?

Three short, front-loaded sentences with no filler; purpose comes first, then the actual-vs-projected caveat, then the unit definition. The 'per_10k = ...' clause appears without being framed as a response field, which costs a little clarity but not much length.

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?

There is no output schema, and the description helpfully explains the key per_10k unit and the actual/projected distinction, which is more than most definitions offer. However, for a 5-parameter tool it leaves min_grade and the meaning/filtering behavior of bonds and stock entirely unexplained, so an agent cannot confidently use the optional filters.

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 only 40%, so the description should compensate, but it says nothing about from/to formatting, the bonds ISIN list, the stock code/name parameter, or min_grade. The 'per_10k' explanation actually describes a response field, not an input parameter, so it does not close the parameter gap (min_grade is undocumented in both schema and description).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource and verb: a bond interest and principal payment schedule within a date range ('기간 내 채권 이자·원금 지급 일정'). An agent can tell it apart from generic siblings like calendar or bond without opening the schema, though it never explicitly contrasts itself with bond/bonds/calendar.

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 only usage signal is the implicit 'within the period' framing from the required from/to dates. There is no statement of when to prefer this over sibling tools such as bonds, bond, or calendar, and no prerequisites or exclusions are given.

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 a safe, read-only, idempotent, closed-world query, so the bar is lower, and the description still adds real behavior: it discloses the result fields (coupon %), cycle, coupon_10k per KRW 10k face, next coupon date, last trade price/yield, and 20-day trade count, plus the important caveat that yields for thinly traded names can be extreme outliers. It omits defaults for sort/limit, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two densely packed sentences: the first front-loads scope and filter axes, the second enumerates return fields and ends with the outlier caveat. Nothing is redundant, though the long comma-separated field list is harder to scan than a short structured block would be.

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 17 optional parameters and no output schema, the description carries the burden well by describing the returned metrics and the data-quality caveat. Gaps remain around default sort order, result cap behavior (limit max 300), and the meaning of the truncation/rank ordering, but an agent can call it correctly from what is given.

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 47%, so the description must compensate, and it does map many of the 17 parameters onto the listed filter axes (issuer/query, stock, yield, coupon, years, grade, rank, pay month, liquidity, kind, no_option). It still leaves sort, ascending, and limit undocumented in prose, and does not clarify set semantics like whether min_grade is inclusive-level or band.

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?

"장내 회사채·금융채 찾기 (KRX 상장, 만기 전)" gives a concrete verb (찾기) plus the resource, venue (KRX listed) and universe bound (pre-maturity), so an agent knows this is a screening tool over listed bonds. It does not explicitly contrast itself with the sibling `bond` (single-bond detail) or `bond_calendar`, 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?

Usage is implied through the enumerated filter dimensions (issuer, yield, coupon, remaining term, grade, subordination, pay month, liquidity), which tells the agent what this tool is good for. There is no explicit statement of when to prefer it over `bond` or `bond_calendar`, and no note that all filters are optional / results are a ranked screen.

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 cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), and the description adds genuinely useful behavior beyond them: the series is stitched together from several periodic reports, and missing quarterly figures are computed from cumulative values, which tells the agent the data is derived rather than reported. It still says nothing about output shape or how gaps/partial history are represented.

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 operation and the derived-data caveat, then the long topic list, which is justified because it supplies the missing topic parameter documentation. The dense bullet-style enumeration is efficient, though the single-sentence run-on makes it slightly harder 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?

For a 6-parameter read-only analytical tool with no output schema and strong annotation coverage, the description covers what the tool produces, the topic space, and the discovery fallback. What remains (exact return shape) is acceptable to omit given there is no output schema to defer to and the tool is read-only and idempotent.

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 83%, so the baseline is 3, but the description goes further by supplying the semantics of the otherwise undocumented 'topic' parameter through a full value taxonomy and by explaining the empty-topic mode switch. Example values for dim (DS, HBM, 미주) and freq behavior add a bit more, though the description does not clarify how dim/item interact with topic.

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: a quarterly/annual time series built by concatenating multiple periodic reports, with quarterly values derived from cumulative figures when absent. The enumerated topic taxonomy (segment, product_sales, region_sales, capacity/production/utilization, capex, rnd, market_share, inventory, cost_by_nature, sga, raw_materials, material_prices, backlog, channel) makes it unmistakable versus siblings like financials or earnings.

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 a concrete discovery path: leaving topic empty returns the list of topics available for that company, which tells the agent how to explore before querying. It does not explicitly state when to prefer financials or earnings over this tool, so the routing guidance is strong but not complete.

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 that this is a read-only, idempotent, non-destructive, closed-world query, so the description does not need to repeat that. Instead, it adds useful information beyond the annotations: the data source is DART disclosures, and the results include disclosure links. This context helps set expectations for trust in the data and for what the response will contain.

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 consists of two compact clauses, with the core identity (dividend schedule) stated up front and the scoping rule attached. There is no filler. However, the parenthetical DART note compresses several distinct facts, while information that actually matters for correct calling, such as the broader kinds enum, is left out.

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 has five parameters, no output schema, and no required fields, so the description needs to carry considerable context, and it does cover the data source, the output link feature, and the default scope. It is still incomplete in one important way: the schema supports AGM, EGM, and earnings events, while the description presents the tool as strictly dividend-focused. Nothing explains limit or result ordering.

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 description adds real meaning to the stock parameter by stating that omitting it returns results for the entire market, which the schema does not say. However, it does not explain the non-dividend values in the kinds enum (정기주총, 임시주총, 실적발표), and it does not explain limit at all; together with 60% schema description coverage, a baseline 3 is appropriate.

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 this tool returns a dividend calendar covering record dates, payment dates, and shareholder-registry dates sourced from DART disclosures, which is a specific verb-plus-resource statement. However, the schema kinds enum also permits 정기주총, 임시주총, and 실적발표 (AGM, EGM, earnings release), and the description never mentions these events. The description therefore makes this tool look narrower than it really is, though it still avoids confusion with siblings such as bond_calendar and earnings.

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 one concrete usage rule, namely that omitting stock broadens the query to the whole market. Beyond that, the description gives no explicit guidance on when to choose this tool over sibling tools such as earnings, shareholders, or bond_calendar, even though these siblings overlap with this tool's scope. The intended usage is 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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety behavior is covered. The description contributes provenance and freshness ("최근 정기보고서", "모두 DART 공시 기반", original-text quotes with DART links), which is genuinely useful, but it says nothing about behavior when a ticker is unknown, when a company has no recent report, or about response size/latency.

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 routing cue is front-loaded in the first clause, followed by a compact enumeration of outputs and a source note. It is one dense sentence with no filler, though the parenthetical asides make it slightly heavy on first read.

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?

There is no output schema, so the description must carry the return-value burden — and it does, naming each returned block (segments, quarterly trend, cited earnings-change reasons with links, overview, dividends, record date). What is missing is data-freshness granularity (which quarter's report) and empty/error behavior, but for a single-parameter read tool this is nearly 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 100% and the single `stock` parameter is fully documented in the schema with format and examples ('005930', '삼성전자'). The description adds no additional meaning about ticker resolution (e.g., market prefix, name ambiguity), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"종목 한눈에 — 특정 종목 질문은 여기서 시작" states the resource (a single stock) and that this is the entry point, and then enumerates the concrete payload (segment breakdown, quarterly trend, stated reasons for earnings changes, business overview, dividends/buybacks, upcoming record date). It is unambiguously about one company, but it never contrasts itself with the many overlapping siblings (financials, earnings, business_trend, shareholders), which is the only thing keeping it from 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?

"특정 종목 질문은 여기서 시작" is a real when-to-use cue for single-stock questions, and the DART-source note bounds the domain. However, there is no when-NOT-to-use and no routing to alternatives such as earnings for detailed quarterly figures or price for quotes, so the agent must infer boundaries by inspecting sibling names itself.

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 declare this as a read-only, idempotent, closed-world operation, so the safety profile is fully covered. The description adds real context on provenance (DART periodic reports) and on how the company-stated causes are returned as original sentences with [S#] source markers and DART links. It does not cover behavior when a quarter lacks segment data or stated reasons, or any limits on history depth.

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?

It is front-loaded with the core question ('실적이 왜 바뀌었나') and then compactly lists the returned content in one dense sentence. Nothing is redundant, though the list of metrics and citation mechanics is packed tightly enough that a reader has to parse carefully.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing return values, and it does so concretely: the metrics, the period-over-period comparisons, the segment breakdowns, and the citation format with source tags and links. The data source is also disclosed. Only edge-case behavior (no data, missing segment disclosure, non-periodic filers) is left unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%; both 'stock' and 'period' are documented in the schema with concrete format examples ('005930', '2026Q2', '2026.06'). The description adds only the implicit notion of '한 분기' granularity and the default-to-latest behavior is stated in the schema, not the description, so this is the baseline case where the schema does the work.

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: a single-quarter earnings analysis based on DART periodic reports, and it enumerates the concrete contents (consolidated revenue, operating profit, net income, YoY/QoQ, segment breakdowns, stated change reasons). The scope is unambiguous, but it never names or contrasts itself with the closest sibling, 'financials', so an agent must infer the boundary on its own.

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 a concrete triggering question ('영업이익이 왜 늘었어?') that maps directly to the tool's intent, which is strong context for selection. It stops short of explicit exclusions, saying nothing about when to prefer 'financials' for raw statement figures or 'filing'/'search_filings' for the underlying document.

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, closed-world behavior, so the bar is lower. The description still adds real behavioral context the annotations cannot: every figure carries a source marker [S#], output is a normalized/curated rendering rather than raw disclosure, and check provides validation. It stops short of describing truncation behavior or failure modes in prose.

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 resource and the value proposition, and every clause earns its place, including the long section enumeration which is functionally necessary. The single run-on paragraph with em-dashes makes it denser than ideal, but nothing is wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing returns and does so: normalized tables, company narrative, change drivers, per-number citations, and a size cap. Remaining gaps are minor – the semantics of the check section and what happens with an invalid section name are not explained.

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 60% and the biggest gap is sections, which is a free-string array with no enum; the description compensates by enumerating the accepted section values (drivers, segment, sga, backlog, texts, check, etc.), which is substantial meaning beyond the schema. It also explains list=true, while stock, period and max_chars are already fully documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: reading normalized periodic disclosure reports (annual/half/quarterly) rendered in a standard template, including tables, company narrative and change drivers. An agent can tell this is a structured report reader rather than a raw filing search, though it never names the sibling it should be preferred over (search_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?

Gives useful in-tool routing: use sections to fetch only the parts needed, and list=true to get the report list instead of content. But it offers no guidance on when to choose this over siblings such as search_filings, financials or earnings, and no prerequisites are 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?

Beyond the read-only and non-destructive annotations, it discloses the DART source, units in KRW 100 million, coverage beginning in 2015, and the derived nature of Q4 figures. These details help the agent interpret the data and its limitations.

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 source, units, and coverage, then efficiently organized by frequency. The dense metric lists and parenthetical Q4 explanation all convey useful invocation or interpretation details.

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?

It covers the outputs unusually well for a definition without an output schema, making basic calls with stock and freq straightforward. However, two optional parameters remain semantically incomplete, and the lack of sibling differentiation leaves some tool-selection ambiguity.

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 description substantially expands on freq beyond its short schema description, but adds nothing about years or statement. In particular, statement's IS/BS/CF effect on the returned metrics and the role or default of years remain unclear.

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 financial trends from DART periodic reports and enumerates the annual and quarterly metrics supplied. It also specifies units and historical coverage, but does not explicitly distinguish the tool from siblings such as earnings or business_trend.

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 separate freq=A and freq=Q sections give clear guidance for choosing annual versus quarterly output and explain the Q4 calculation. There is no guidance on when related sibling tools would be preferable or when the optional statement parameter should 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 readOnly, idempotent, non-destructive, closed-world, so safety needs no restating. The description adds genuinely non-obvious behavior: the KRX/Financial Services Commission provenance, T+1 freshness (not intraday), and that splits/mergers are adjusted — the last being critical for interpreting historical returns. It loses a point for leaving the `realtime` flag's behavior unexplained while simultaneously asserting the data is not real-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?

A single dense paragraph that front-loads the metrics produced, then tacks on index values, source/freshness caveats, and the adjustment note. Every clause carries information an agent needs; nothing is 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 an 8-parameter tool with zero required parameters and no output schema, the description does well on return shape (it lists the output columns and metrics). However, it does not resolve the key ambiguities an agent faces: whether stock and index are mutually exclusive, what makes a valid call with no arguments, and how `realtime` interacts with the stated non-real-time guarantee.

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 75%, so the schema already documents from/to/limit/interval/intraday and the index enum. The description reinforces the index values and enumerates the candle fields, but adds no syntax or selection logic for `stock` vs `index`, and says nothing about what `realtime: true` would do.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (stock/index price series) and enumerates the derived metrics it returns — period return, excess return vs index, MDD, volatility, high/low, and OHLCV candles. That is far more specific than the title '주가 흐름' alone. It falls short of a 5 because it never names or contrasts a sibling (e.g. financials, company, rank) that an agent might otherwise pick for price-adjacent questions.

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 context is implied rather than stated: '다음 영업일 반영(장중 실시간 아님)' tells the agent this is end-of-day data, which effectively rules out intraday use cases. But there is no explicit when-to-use / when-not-to-use routing, and no guidance on the stock-vs-index choice despite both parameters existing.

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 safety is covered. The description adds that the scope is the full universe of stocks and that theme filtering matches on business-description text, but it says nothing about default result count, default sort direction, or what an empty result looks like.

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 purpose clause is front-loaded and the example questions at the end are high-value. The middle sentence re-enumerates all eighteen metrics, largely duplicating the `by` enum; it doubles as terminology mapping, so it is not pure waste, but it is the longest and least necessary part.

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 12-parameter screening tool with no output schema, the description never says what comes back — rank order, whether each row carries the metric value and ticker, or how many rows by default. Default behaviors (min_mcap floor for ratio rankings, ascending defaults for PER/PBR/debt) exist only inside schema field descriptions, leaving a reader of the description alone under-informed.

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 83%, so the baseline is 3, but the description earns a bump by translating opaque enum tokens into business meaning (cancel_12m = 자사주 소각 최근 1년, sh_yield = 주주환원수익률, payout = 배당성향). It also surfaces that market/industry/theme act as narrowing filters, which the bare schema does not frame.

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 — rank all stocks ('전 종목을 한 지표로 줄 세우기') — and names the exact axis of ranking plus the narrowing dimensions (market, industry, theme). This clearly separates it from sibling lookup tools such as company, financials, and price, which return one entity rather than an ordered cross-section.

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 closing clause gives concrete trigger questions ('배당 많이 주는 회사', 'ROE 높은 회사'), which effectively tells the agent when this tool is the right choice. It stops short of naming alternatives or exclusions (e.g. 'use company for a single ticker'), so it is clear context rather than explicit 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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral information: theme queries are ranked by term frequency in business descriptions, which an agent could not infer from any structured field.

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?

Three short sentences with zero filler: purpose first, usage trigger second, non-obvious ranking behavior last. Every sentence carries distinct 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?

With no output schema, the description could say more about the result shape (e.g., that matches come back as stock entries with tickers), but for a simple two-parameter search it covers purpose, usage trigger, matching fields, and theme ranking adequately.

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 only 50% (only query is documented), but the description compensates by spelling out what query matches — name, code, sector, group name, theme — well beyond the schema's bare '검색어'. The optional limit parameter remains unexplained in both schema and description, which keeps it from a 5.

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 (find stocks) and enumerates the matchable fields: name, ticker code, sector, group name, and theme. This clearly separates it from siblings like company (a single known ticker), rank, and search_filings, though it never names those alternatives outright.

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 a concrete when-to-use trigger — reach for this before a ticker-keyed lookup tool like company. There is no explicit when-not or named alternative, so it stops short of a 5.

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

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

Annotations already establish read-only, idempotent, closed-world behavior. The description adds useful temporal scope (drivers across all periods, business descriptions from latest reports) and sentence-level scope, but does not describe result structure, pagination behavior, or ranking beyond what the schema already says.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences plus examples, front-loaded with the search scope and content types. There is no redundant filler; each element helps the agent decide whether and how to search.

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 9-parameter search tool with no output schema, the description gives enough purpose and scope to invoke it correctly, while schema descriptions cover parameter details. It could say more about returned sentence metadata and how results are organized, but those gaps are minor.

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 89%, so parameters such as topic, metric, direction, sort, and per_company are already well documented. The description adds example query terms ('HBM', '가동률 하락', '판가 인상') that help formulate the query parameter, but adds little semantics for the other filters. Baseline 3 is appropriate.

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: sentence search across all stocks' periodic reports, with enumerated content types (performance-change reasons, MD&A, business/industry descriptions). The examples and closing use case make it clearly distinguishable from generic search or filing retrieval 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?

Gives a clear use case: '어떤 회사들이 어떤 이유를 대는지 찾을 때' and explains that drivers cover all periods while business descriptions come from the latest reports. It does not explicitly name alternatives such as the generic search or filing tools, nor 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds the data source (DART disclosures) and the default that both sections are returned, but says nothing about year-range effects, coverage limits, or result shape.

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?

It is a single dense but front-loaded line, with sections delimited clearly and no filler. Some domain abbreviations (DPS, 자사주) assume familiarity, but nothing is redundant.

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 only three parameters and no output schema, the description covers enough: what each section yields, the default behavior, and the data provenance. Minor gaps remain around how 'years' scopes each section and what the records look like.

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 section enum has no per-value description; the description supplies it by defining what 'returns' and 'ownership' contain and stating the default is both. This meaningfully compensates for the 67% schema coverage gap, though it does not clarify how 'years' interacts with the returns section.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (shareholder returns and ownership data) and enumerates the concrete fields returned per section (DPS, total dividend, treasury share acquisition/disposal/cancellation, largest-shareholder stake change). An agent can distinguish it from siblings like financials or company without opening the schema.

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 implies usage by explaining what each section returns and that both are returned by default, which helps an agent pick a section. But it gives no explicit when-to-use versus alternatives such as financials or company, and no exclusions.

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