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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds a genuine constraint — results are scoped to whatever the configured credentials can see — but says nothing about pagination, ordering, or what an empty result means when credentials have no accounts.

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 sentence, front-loaded with the verb and resource, and the credential-scoping qualifier is the only extra detail — 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 zero-parameter read-only list tool with annotations covering safety, this is nearly complete. The only real gap is the absence of an output schema combined with no mention of what an account record contains (e.g. account number, type), which an agent needs to chain into follow-up account-scoped calls.

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?

Zero parameters, so there is nothing for the description to explain; baseline 4 applies. The schema correctly accepts an empty object only.

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?

“List Toss Securities accounts” is a specific verb+resource, clearly distinct from sibling resources like holdings, orders, or prices. It doesn't explicitly name a sibling it is meant to precede or replace, but the resource is unique enough that confusion is unlikely.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase “available to the configured Open API credentials” hints at a prerequisite/discovery role, but the description never says when to call this versus sibling account-scoped tools such as toss_get_holdings or toss_get_buying_power. Usage is only implied.

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 destructiveHint=false, so the safety profile is covered. The description adds little behavioral context beyond the currency requirement and does not explain whether buying power is real-time, includes fees, or reflects settled cash versus margin.

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 short sentences with no wasted words. The core purpose is front-loaded, and the currency constraint follows immediately.

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 two-parameter read tool with full schema coverage and safety annotations, the description is largely complete. It could mention the accountSeq prerequisite from the schema or what buying power represents, but no critical information 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?

Schema description coverage is 100%, and both parameters are fully documented in the schema. The description reiterates the currency enum meaning but adds no new detail beyond the schema, so the baseline of 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 states a specific verb and resource: 'Get available buying power for an account.' It is clear what the tool does, but it does not explicitly differentiate itself from related sibling tools such as toss_get_holdings or toss_get_sellable_quantity.

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 clarifies that currency is required and maps KRW to Korean stocks and USD to US stocks. However, it does not state when to use this tool versus alternatives, nor does it mention that accountSeq may require calling toss_get_accounts first—that guidance appears only in the schema.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the interval granularity and the KRX/US scope, but says nothing about the 200-candle cap, how 'before' paginates, default ordering, or timezone/date semantics of the returned candles.

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 front-loaded sentence with no filler; the scope qualifiers (interval options, single symbol, market coverage) are packed efficiently with zero 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?

There is no output schema, so the description should at least sketch the OHLCV return shape, but it does not. Combined with zero-coverage parameters and no pagination or adjustment notes, an agent has to guess at how to page history and what 'adjusted' changes.

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 parameter meaning, yet it only explains symbol and interval. The three remaining parameters — count (1–200), before (ISO date-time cursor) and adjusted (split/dividend adjustment) — are entirely undocumented anywhere, and 'adjusted' in particular is ambiguous without explanation.

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 (Get), a specific resource (OHLCV candles), the supported granularities (1-minute or daily) and the symbol universe (one KRX or US stock symbol). This also implicitly separates it from toss_get_market_indicator_candles, which handles indicators rather than individual stock symbols.

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 only implied by the verb and resource — an agent can infer this is the tool for charting a single symbol. There is no explicit guidance on when to prefer it over toss_get_prices or toss_get_market_indicator_candles, and no mention of prerequisites or pagination workflow.

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, non-destructive, open-world operation, so the description need not repeat that. However, it adds no behavioral context about what commission data is returned, whether it is real-time or account-specific, or any auth/rate-limit constraints.

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 front-loaded sentence with no wasted words. It is concise, though arguably too terse given the lack of usage and return-value 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 simple one-parameter read tool with full schema coverage and annotations, the definition is minimally adequate. It lacks any explanation of what commission information includes or how it should be used, but no output schema exists to carry that burden instead.

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 accountSeq parameter already includes useful guidance to call toss_get_accounts first and ask the user if ambiguous. The description adds nothing beyond the schema, so 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 ('Get') and resource ('trading commission information') scoped to an account. It is clear what the tool does, but it does not distinguish this from sibling account-information tools such as get_accounts or get_buying_power.

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 no guidance on when to use this tool versus alternatives, nor does it explain prerequisites. The only usage detail comes from the schema's accountSeq note, not the description.

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 destructiveHint=false, so safety is covered. The description adds meaningful behavioral context beyond annotations: the account discovery prerequisite and the rule to ask the user when multiple accounts are ambiguous. It does not describe return format, but no output schema exists and the tool is a simple read.

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 sentences, front-loaded with purpose followed by prerequisite and ambiguity handling. Every sentence earns its place with no wasted 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 simple read-only fetch with annotations and no output schema, the description covers the key prerequisite and ambiguity handling. It could be more complete by explaining where conditionalOrderId comes from (e.g., toss_get_conditional_orders), but otherwise 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?

Schema coverage is 50%: accountSeq has a description (which merely duplicates the main description), while conditionalOrderId has no description in schema or description. The description adds no meaning for conditionalOrderId, such as where to obtain the identifier. It does not fully compensate for the undocumented parameter, so it earns a baseline 3.

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: 'Fetch one conditional-orders by identifier.' The singular 'one' implicitly distinguishes it from the sibling list tool toss_get_conditional_orders, though that sibling is not named explicitly. Minor grammar issue ('one conditional-orders') does not impede understanding.

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 clear prerequisite: call toss_get_accounts first when accountSeq is required, and provides ambiguity handling by telling the agent to ask the user. This is actionable context, but it does not explicitly state when to use this tool versus toss_get_conditional_orders, leaving that inference to the agent.

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, non-destructive, open-world behavior, and the description adds real value beyond them: the pagination contract (preserve nextCursor/hasNext) and the non-obvious quirk that OPEN status causes limit/cursor to be ignored. Output shape is not described, but no output schema exists and the pagination note covers the main unknown.

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

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

Three compact sentences, front-loaded with the core action and the pagination contract. The accountSeq sentence duplicates the schema field description verbatim, which is mild waste, but nothing else is padded.

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 five parameters, 20% schema coverage, and no output schema, the definition covers the riskiest behaviors (pagination, OPEN-status quirk, account prerequisite) but leaves the CLOSED path, the status semantics, and the returned item shape undescribed. Adequate to call correctly, not complete enough to predict results.

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 20%, so the description must carry more weight; it does clarify that limit/cursor are inert under OPEN status and that cursor is tied to nextCursor, which is useful. However, the status enum values (OPEN vs CLOSED) and the symbol filter are left unexplained, and the accountSeq sentence is a verbatim restatement of the schema description rather than added meaning.

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?

Starts with a specific verb and resource ("List conditional-orders"), and the plural form distinguishes it from the singular sibling toss_get_conditional_order. It does not explicitly name that sibling, so the differentiation relies on naming conventions rather than an explicit statement.

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 prerequisite guidance ("call toss_get_accounts first" when accountSeq is required) and an ambiguity policy ("if multiple accounts are ambiguous, ask the user"), which is genuinely actionable. It stops short of stating when to use this tool versus toss_get_orders for regular orders or toss_get_conditional_order for a single order.

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, non-destructive, open-world behavior, so the safety profile is covered. The description adds only that dateTime is optional, but doesn't say what the default is (latest rate?) or whether historical dates return an error or nearest value.

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 short, front-loaded sentences with no filler. The purpose comes first and the parameter note second.

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 lookup tool with annotations covering safety and an enum-constrained schema, the description is largely sufficient. A brief note on the default behavior when dateTime is omitted would close the remaining gap, especially since no output schema exists.

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 parameter meaning. It does clarify that dateTime is optional and ISO 8601, which helps, but baseCurrency vs quoteCurrency direction is left ambiguous (the 'KRW/USD or USD/KRW' phrasing doesn't map clearly to the two fields).

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 ('Get ... exchange rate') and names the supported pairs (KRW/USD, USD/KRW), which matches the schema enums and separates it from price/candle siblings. It does not explicitly contrast with neighbors, so it stops short of 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 only implied: fetch a current rate, or supply dateTime for a point-in-time rate. There is no statement of when to prefer this over toss_get_prices or other market-data tools, and no 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 cover the read-only, non-destructive, open-world profile, so the description only needs to add context — and it does, by disclosing that the accountSeq requirement is waived by an environment variable. However, it says nothing about what a holdings record contains or how the response is shaped, leaving the caller to guess.

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 short sentences, front-loaded with the resource fetch, with no filler. It is efficient, though so terse that the second sentence's config caveat reads as unexplained.

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 tool with no output schema, the description is barely sufficient: it never describes the returned holdings, never explains the symbol filter, and leaves the required-vs-optional accountSeq tension for the agent to resolve against the schema.

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%: accountSeq is documented in-schema while symbol has no description at all, and the description does not explain that symbol filters holdings to a single instrument. Worse, the description's 'accountSeq is optional' conflicts with the schema's required list, which the text neither explains nor resolves.

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 ('Get account holdings') that an agent can distinguish from siblings like toss_get_accounts or toss_get_orders. It does not explicitly name those siblings, so differentiation is inferred rather than stated.

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 guidance is conditional: accountSeq is optional when TOSSINVEST_ACCOUNT is configured. There is no statement of when to call this versus toss_get_accounts (which the schema itself points to) or what the tool is appropriate for beyond the name.

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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds that the payload includes session hours, not just dates, but says nothing about holidays, timezone, or whether future dates are accepted.

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 short sentences, front-loaded with the capability, with zero filler. The second sentence is a terse fragment rather than a properly structured clause, which slightly limits readability but wastes nothing.

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, single-optional-param tool with no output schema, the definition is minimally adequate. It leaves the agent guessing about response shape (holiday list vs. session hour objects) and default date behavior.

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 parameter burden; it does communicate that date is optional and uses YYYY-MM-DD format. It doesn't say what the default behavior is when date is missing (e.g., today) or whether the date must be a trading day.

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 (get Korean market calendar and session hours), and the word 'Korean' implicitly separates it from the sibling toss_get_us_market_calendar. It stops short of explicitly naming the alternative, so sibling differentiation relies on inference from the name.

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?

No guidance on when to use this versus toss_get_us_market_calendar or the price/candle tools, and no mention of what happens when date is omitted. The only usage-adjacent fact is that date is optional.

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, non-destructive, open-world access. Beyond that, the description discloses the 200-bar cap, newest-first ordering with an explicit first/last element convention, two distinct 400 error codes and their triggers, and the governing rate-limit group. These are concrete behavioral traits an agent cannot infer from annotations alone.

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 core identity and return-shape facts are front-loaded, followed by symbol/interval constraints and then error behavior, which is a sensible ordering. It is slightly long, and the closing rate-limit-group line is closer to metadata than guidance, but no sentence 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?

With no output schema, the description does the necessary work by describing the candle payload (OHLCV), the 200-bar ceiling, and the sort order. The remaining gap is pagination via `before` and the exact candle field names, which is a meaningful omission for a paginated time-series endpoint but not a blocking one.

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 carries the full parameter burden. It compensates well for `symbol` (catalog of 8, 400 on unknown) and `interval` (per-symbol constraints), and the 200-bar cap implicitly covers `count`'s maximum. However, `before` — a date-time pagination cursor — is never mentioned, and neither is the default for `count`, leaving two of four parameters undocumented anywhere.

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 first two sentences state a specific verb and resource: retrieve OHLCV candle chart data for market indicators (domestic indices and government bonds). It immediately distinguishes itself from the sibling `toss_get_candles` by scoping the target to market indicators rather than individual stocks, so an agent can choose between them without opening a 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?

The description explicitly routes the agent: for individual stock candles, use `GET /api/v1/candles`, and for symbols outside the 8-symbol catalog, the server returns 400 `unsupported-symbol`. It also states per-symbol interval rules (1m only for KOSPI/KOSDAQ; KR_BOND_* only 1d, otherwise 400 `invalid-request`), which is exactly the kind of when-to-use/when-not guidance 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?

Annotations already declare readOnly/openWorld/non-destructive, and the description layers genuinely new behavior on top: amounts are KRW integers with no currency field, buy/sell totals balance at market level, foreigner is the combined registered+unregistered total, institution amounts equal the sum of the 7 sub-categories, and intraday records are provisional until market close (check updatedAt). This is unusually rich disclosure for a read tool.

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 one-line purpose followed by scannable bullets, each carrying distinct information rather than restating the schema. Minor noise: breakdown is written with backticks like a parameter even though it is a response field, which can briefly mislead.

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 describe returns, and it does: the four investor categories, buy/sell amount fields, the 7-way institution breakdown, updatedAt freshness signal, and nextUntil paging. Combined with the symbol restriction and currency notes, an agent has everything needed to call and interpret it.

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 burden, and it does for three of four parameters: interval is explained as the aggregation unit, until as the nextUntil cursor, and symbol with an explicit supported-values restriction. The count parameter (1-100) is never mentioned, leaving its default and role 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?

States a specific verb+resource (투자자별 매매대금 조회) scoped to KRX markets only, and the body clarifies it is market-wide aggregate data broken down by the four investor classes. It is distinguishable from the stock-level sibling toss_get_stock_investor_trading by the KOSPI/KOSDAQ market framing, though it never names that sibling 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?

Gives concrete usage constraints (only KOSPI/KOSDAQ, otherwise 400 unsupported-symbol) and pagination mechanics (pass response nextUntil as until) plus a caveat about provisional intraday figures. However, it offers no guidance on when to pick this over toss_get_stock_investor_trading or the other market-indicator siblings, leaving the choice 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, openWorldHint, and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral facts: a 200-symbol batch ceiling and a specific 400 `unsupported-symbol` failure mode for out-of-catalog symbols, plus the MARKET_INDICATOR rate-limit group. Return format and pagination behavior are not described.

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 content is front-loaded and compact, with the symbol constraint and error behavior in the second paragraph and the rate-limit group bolded at the end. The opening sentence largely restates the title, costing a little efficiency.

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, read-only lookup with full annotation coverage and no output schema, the description covers input format, limits, error behavior, and rate limits. The only meaningful omissions are the enumerated symbol list (external reference) and any hint about the returned price fields.

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 single `symbols` property has no description, so the description must carry the load — and it does, explaining comma separation, the 200-item limit, and that values come from an 8-symbol catalog. The catalog itself is deferred to a parent group description rather than enumerated here, which leaves a small 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 gives a specific verb+resource: it retrieves current prices for market indicators, explicitly scoped to domestic indices and government bonds. That scope distinguishes it in practice from toss_get_prices (stocks) and toss_get_market_indicator_candles, although no sibling is named directly.

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 supplies concrete operational guidance: up to 200 symbols per call, comma-separated formatting, and that only the 8 symbols in the Market Indicators catalog are accepted. It does not explicitly say when to prefer this tool over toss_get_prices or the candles sibling, but the domain constraint provides clear selecting 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, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description contributes the account-resolution prerequisite and user-clarification behavior, but says nothing about error behavior or whether a missing order returns null versus throwing.

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?

Short and front-loaded, but sentences two and three are a copy of the accountSeq schema description, so the description's body duplicates structured data already supplied. It is compact but partly 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?

For a two-parameter read tool with no output schema, the essentials are present: how to resolve accountSeq and what to do when ambiguous. It is incomplete on how to source orderId and on how this differs from toss_get_conditional_order, both of which 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 description coverage is only 50%, and the description merely repeats the accountSeq schema text verbatim rather than adding anything. The orderId parameter — the primary identifier — is entirely undocumented in both schema and description, so there is no hint where an agent obtains a valid orderId.

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 with cardinality ('Fetch one orders by identifier'), which implicitly distinguishes it from the sibling list tool toss_get_orders. The grammar slip ('one orders') is minor but the single-vs-list scope is only implied, never named.

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 prerequisite chain ('call toss_get_accounts first') and an ambiguity policy ('ask the user'), which is real operational guidance. It never says when to pick this over toss_get_orders or toss_get_conditional_order, so tool selection among siblings is still 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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds the market scope (KRX or US) and that it operates on a single symbol, but says nothing about orderbook depth, bid/ask level counts, or real-time vs delayed data — behavior an agent would likely want.

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 front-loaded sentence with zero padding. It is efficient, though the terseness is close to underspecification rather than true economy.

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, no parameter descriptions and no annotation detail on data freshness, the description should say more about what an orderbook response contains and how to interpret it. As written, an agent can call it but cannot predict its output shape.

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 partially by implying symbol is a KRX or US stock identifier, but it never states the format (e.g., KRX numeric code vs US ticker) or how the market is inferred.

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 orderbook data') plus the scope ('one KRX or US stock symbol'), so an agent knows exactly what it retrieves. It does not, however, distinguish itself from adjacent siblings such as toss_get_prices or toss_get_trades, which also expose per-symbol market data.

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 when-to-use/when-not guidance and no mention of alternatives like toss_get_prices or toss_get_trades, even though several siblings overlap in scope. The only context an agent can infer is from the resource name 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds important behavioral detail beyond annotations: preserve nextCursor/hasNext for pagination, OPEN regular orders ignore limit/cursor, and account selection prerequisites. It stops short of fully describing the response shape or rate 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 four compact sentences with no wasted words. It is front-loaded with the core action ('List orders') and follows with the most important operational constraints.

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 7-parameter read-only tool with no output schema and only 14% schema description coverage, the description covers critical pagination and account-access behavior but does not fully document most parameter semantics. An agent can call it correctly in common cases but may still need to inspect the schema for other fields.

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 very low at 14%, so the description must compensate. It clarifies accountSeq sourcing and the conditional irrelevance of limit/cursor for OPEN orders, but leaves status values, symbol format, and from/to date semantics unexplained.

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 uses a specific verb and resource ('List orders'), making the core purpose clear. However, it does not differentiate from sibling tools like toss_get_order for a single order or toss_get_conditional_orders, so an agent must infer the boundary.

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 clear operational guidance: call toss_get_accounts first when accountSeq is required, select the intended account, and ask the user if ambiguous. It does not state when to use this tool instead of the single-order sibling, so alternatives are still implied rather than explicit.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the KRX/US applicability scope, which is useful context, but says nothing about return format or rate 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?

A single efficient sentence with the resource and scope front-loaded. No waste, though it is terse to the point of omitting any param or usage 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?

For a simple read-only lookup with annotations carrying the safety profile, the definition is roughly adequate. It is missing symbol format guidance and any hint of the returned limit values, which would complete the picture for a 0%-coverage parameter.

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 single 'symbol' parameter is undocumented in structured fields. The description names the symbol concept and its KRX/US markets but gives no format or case/prefix guidance to 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 (Get) and resource (upper and lower price limits) scoped to one KRX or US stock symbol. It distinguishes itself from broad price tools like toss_get_prices by naming the specialized resource, though it doesn't explicitly contrast with any 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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative is named. The only usage signal is the implied scope of 'price limits', leaving the agent to infer when this beats toss_get_prices.

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, destructiveHint=false and openWorldHint=true, so the safety profile and external-data nature are covered. The description adds two genuinely useful behavioral facts: the hard cap of 200 symbols per call and that symbols may span both KRX and US markets. It says nothing about response shape, currency handling, delayed vs. real-time data, or per-call rate 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?

One sentence, front-loaded with the action and resource, with constraints stated inline. Nothing is padded or restated from the title.

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 input side is adequately covered for a one-parameter read tool, but with no output schema and no annotations describing return values, the description never indicates what a "price" comprises (last, bid/ask, currency, timestamp, market-open state). An agent can call it correctly but cannot predict the payload.

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 schema coverage at 0%, the single parameter is undocumented in structured data, so the description carries the burden — and it does: `symbols` is a comma-separated string, capped at 200, and accepts KRX or US tickers. It still doesn't show the expected ticker format (e.g., '005930' vs 'AAPL', case sensitivity, exchange suffixes), which is the main remaining ambiguity.

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 ("Get current prices") and scopes it by market (KRX or US) and batch size (up to 200 symbols), which distinguishes it in practice from historical tools like toss_get_candles. It stops short of naming a sibling outright, so an agent must infer the split between current quotes and candles/last-trade data.

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 word "current" implies this is the real-time/snapshot quote tool rather than the historical one, which is a usable usage cue. However, there is no explicit when-to-use/when-not statement and no alternatives (e.g., toss_get_orderbook, toss_get_price_limits) are routed to, leaving the agent to infer boundaries.

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, non-destructive behavior, but the description adds substantial extra context: a documented error code for the realtime+TOP_GAINERS combination, the fact that fewer than `count` results can come back because failed quotes are excluded, empty `rankings` with null `rankedAt` instead of an error, and a rate-limit group. That's exactly the kind of failure-mode disclosure annotations don't 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?

A summary sentence followed by tight bullets, each carrying distinct information (unsupported combo, aggregation basis, basePrice/changeRate meaning, count shortfall, empty-result shape). No sentence restates the title and nothing is padded.

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 5-parameter tool with no output schema and no schema-level parameter docs, the description is unusually complete: it covers output shape, error conditions, and the meaning of returned fields like basePrice/changeRate. The remaining gap is `excludeInvestmentCaution` and any default for `count`, both left to 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?

With 0% schema description coverage the description must carry parameter meaning, and it does for `type` (grouped enum semantics), `duration` (realtime unsupported for top gainers/losers), and `count` (100 max, effective count may be lower). `excludeInvestmentCaution` is never mentioned, and `marketCountry` is only named as a filter without further elucidation.

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 ('주식 랭킹 조회') and scopes the result ('상위 100위까지 제공'), keyed to market/duration/type. It never explicitly distinguishes itself from the sibling toss_get_sector_rankings, so an agent must infer that this is per-stock ranking rather than per-sector.

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 concrete conditions: TOP_GAINERS/TOP_LOSERS reject duration=realtime with a 400 unsupported-ranking-duration, and TOSS_SECURITIES_* types use different aggregation bases than MARKET_*/TOP_* types. What's missing is routing guidance naming which sibling to use instead when the caller wants sector-level or individual price data.

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 readOnlyHint/openWorldHint annotations, it specifies behavior: changeRates always has exactly 6 entries in duration order (1d→1y), missing periods come back as null changeRate (e.g., a market with no constituents), values are decimal ratios, and unknown sectorId returns 404 `sector-not-found`. It also discloses the rate-limit group (SECTOR), giving the agent context for both error and quota handling.

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 content is front-loaded in one lead sentence and then bulleted, and every bullet adds real information about nulls, ordering, decimal units, or errors. The opening line repeats the title, which is minor waste.

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 still adequately describes the return structure (basic info fields; performance.changeRates with fixed length, ordering, units, and null semantics), plus the error case and rate-limit group. An agent can call this confidently and interpret the result without more information.

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 schema coverage at 0%, the description compensates by explaining that marketCountry governs only performance.changeRates while basic info is market-agnostic, and that sectorId values not present in the sector list yield a 404. It doesn't explain the sectorId pattern or the enum values, but the schema carries those constraints.

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?

It names a specific verb and resource (섹터 상세 조회) and enumerates the returned content: basic info (name, hierarchy, one-line summary) plus period-based change rates. This makes it clearly distinct from siblings such as toss_list_sectors, toss_get_sector_rankings, toss_get_sector_stocks, and toss_get_sector_etfs, without the agent needing to compare 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 explains data scoping (basic info is market-independent; only performance.changeRates is market-specific), but it never explicitly says when to use this tool instead of the sibling list, rankings, stocks, or ETFs tools. The mention that unknown sectorId from `GET /api/v1/sectors` returns 404 only hints that sector IDs come from the list endpoint, without saying so.

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

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

Annotations already declare this a safe read, but the description adds substantial context beyond them: sort order by prior-quarter market cap with null-market-cap ETFs appended, delisted ETFs excluded, only symbol and name returned, and a specific 404 `sector-not-found` failure mode. It even names the rate-limit group.

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-loads purpose, then uses a tight bullet list where each item carries distinct information (ordering, return shape, exclusion, error). The opening line largely restates the title, which is the only wasted text.

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 explain the return value itself — it does, stating that only symbol and name are provided plus the ordering rule. Combined with the exclusion and error notes, an agent has everything needed to call this 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 carry parameter meaning, and it does: `marketCountry` is framed as the market filter and `sectorId` is tied to the sector listing with a documented 404 on unknown IDs. The regex pattern on sectorId is left entirely to the schema, which is a minor 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 and resource: returns all ETFs classified in the given sector, filtered by marketCountry. It also pins down scope explicitly with '(하위 섹터 미포함)', which separates it from the broader sector tools without the agent needing to open any 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?

Gives clear routing away from this tool for adjacent data needs — prices via `GET /api/v1/prices` and stock basics via `GET /api/v1/stocks` — and notes the sectorId must come from `GET /api/v1/sectors`. It does not explicitly name `toss_get_sector_stocks` as the alternative for constituent stocks, leaving that to inference from the name.

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 read-only, non-destructive profile, and the description goes further: it caps results at 100 and warns the count may be lower, explains that sparse sectors are filtered out, specifies nullability rules for tradingAmount/marketCapitalization versus always-present changeRate, and notes US amounts are KRW-converted. It does not describe pagination or ordering within ties, and the rate-limits group is named without any limit value, so it stops short of full behavioral disclosure.

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 framing sentence followed by tight bullets, each carrying a distinct operational fact (scope, exclusion rules, ranking basis, currency handling, empty-result behavior). Nothing is repeated and the most important constraint is front-loaded.

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

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

With no output schema, the description steps in and describes the response shape (a rankings array, per-item currency, per-field nullability, possible short counts). Combined with the scope and empty-result rules, an agent has enough to call it and interpret results 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 carry the parameter meaning — and it does for the most opaque one, mapping TOP_GAINERS to changeRate and MARKET_TRADING_AMOUNT to tradingAmount. marketCountry and duration are left to their self-explanatory enum values, and the description references a `depth` field that is not actually a parameter of this tool, which is a minor mismatch.

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 (섹터 랭킹 조회) and immediately narrows the scope to sector rankings by market, duration and ranking basis, with top-100 coverage. The scope note on 대분류/중분류 (depth 0/1) vs 소분류 clearly separates it from stock-level siblings such as toss_get_rankings and toss_get_sector_stocks.

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 explains edge-case outcomes (a combination with no data returns an empty rankings array rather than an error) but never tells the agent when to pick this tool over sector siblings like toss_list_sectors, toss_get_sector or toss_get_rankings. Usage is implied by the scope 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?

With annotations only covering read-only/non-destructive semantics, the description still adds real behavior: intraday cumulative `volume`/`tradingAmount` with nulls when no quote exists, KRW conversion for US names with per-item `currency`, exclusion of delisted stocks, the exact 404 error code, and the rate-limit group `SECTOR`. That is well beyond what the structured fields 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 opening sentence carries the core semantics, and the bullets are condensable but each is unique information (null handling, currency conversion, delisting exclusion, error behavior). No sentence simply restates a structured field.

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?

Because no output schema exists, the description must carry return-value semantics, and it does: sort order, nullability, currency fields, and exclusion rules are all covered. What remains unstated is the shape of each item (field listing) and whether results are truncated—the only real gap for an agent to call it confidently.

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: it identifies `marketCountry` as the market-basis filter and `sectorId` as needing to be a listed sector id. However, it does not explain what KR vs US actually selects (the listing market vs the currency) or the `sectorId` format, so the 0% coverage gap is only partly closed.

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 definition gives a specific verb and resource plus its scope: all common stocks in a sector, sub-sectors included, filtered by `marketCountry`, sorted by market cap descending. That level of detail (common stocks only, delisted excluded) makes it distinguishable from `toss_get_sector_etfs` and `toss_list_sectors` 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 sets a clear precondition: `sectorId` must come from the sector list (`GET /api/v1/sectors`), otherwise you get 404 `sector-not-found`; this implicitly routes the agent to `toss_list_sectors` first. It never explicitly says when to prefer a sibling such as `toss_list_stocks` or `toss_get_sector_rankings`, so it falls short of full alternative 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 and destructiveHint=false, so the safety profile is covered. The description adds only the per-symbol-per-account scoping; it does not explain what 'sellable' excludes (e.g., pending sell orders, unsettled trades) or what a zero result means, which is real behavioral context for a trading API.

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 front-loaded sentence with no filler, appropriate for a two-parameter query. It is perhaps over-terse for the semantics it needs to convey, 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?

There is no output schema, so the description should clarify what the returned quantity represents (settled vs. pending, per-account scope) and any preconditions. Instead it leaves the core domain meaning of 'sellable quantity' undefined, which matters for a brokerage read 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 coverage is 50%: accountSeq is well described in the schema (call toss_get_accounts first, ask user if ambiguous), but symbol has only a regex pattern. The description restates that one symbol and one account are required without adding format, case-sensitivity, or meaning beyond the schema fields.

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 ('Get sellable quantity') scoped to one symbol in an account, which is more precise than the title. It does not distinguish itself from related siblings such as toss_get_holdings or toss_get_buying_power, which also expose position/available-quantity information.

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 guidance on when to use this tool versus toss_get_holdings (held quantity) or toss_get_buying_power (cash available), which an agent could easily confuse with it. The only implied usage comes from the phrase 'one symbol in an account'.

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?

Goes well beyond the readOnly/openWorld annotations: T+1 data lag with latest record being the prior business day, aggregation of 자기신용 + 유통금융, integer share units, null for a missing side on a given day, and a named rate-limit group. These are exactly the constraints an agent needs before calling.

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-loads the purpose, then uses bullets for market support, aggregation/units, the stockLoan clarification, null semantics, and pagination, plus bolded freshness note. It is long but each bullet carries distinct information; only the rate-limit group line adds little.

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 still names the returned fields (new/repayment/balance quantities, balance ratio, loan-to-collateral ratio) and the nextUntil cursor, covers error behavior and data latency. Only the `count` parameter's behavior is left unstated, a minor gap.

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 how `until` is used for pagination via nextUntil and that `symbol` must be a KR instrument, but says nothing about `count` (its meaning or the 1-100 bounds), leaving one of three parameters 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?

States a specific verb and resource (daily time-series of credit trading trends for KR stocks) and enumerates the two series it returns (marginLoan, stockLoan) with their fields. It also explicitly distinguishes stockLoan from the sibling securities-lending dataset, so an agent can tell the two apart without opening a 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?

Gives clear applicability (KR stocks only, other markets return 400 unsupported-market) and an explicit pagination procedure via nextUntil -> until. It does not contrast against other trading-flow siblings such as investor trading, program trades, or short selling, so the when-not guidance is incomplete.

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/non-destructive, and the description goes well beyond them: pagination via nextUntil→until, intraday provisional values that are null for individual/institution breakdown/otherCorporation/foreignerHolding/cfd, per-field update timing (evening vs T+1 vs next-morning), updatedAt semantics, and the rate-limit group. 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?

Front-loads the core purpose before the bulleted constraints, and each bullet adds distinct operational value (market scope, quantity units, basis differences, null semantics, pagination). The data-timeliness paragraph is long but earns its place by explaining field-level latency.

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 and no parameter descriptions, the description supplies the returned fields (netBuyVolume, foreignerHolding, cfd, updatedAt, nextUntil), the unit convention (integer share counts), and the pagination mechanism. Everything an agent needs to call and interpret the result is present.

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. It explains `until` well (feed the previous response's nextUntil) and implies `symbol` is a KR code, but never documents `count` (pagination page size, max 100) or the symbol format/pattern, leaving two of three parameters under-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?

States a specific verb+resource (investor-by-investor trading trend as a daily volume time series) plus the exact scope (KR stocks only) and the four investor categories returned. It also explicitly distinguishes itself from the sibling endpoint toss_get_market_indicator_investor_trading by noting the different aggregation basis (registered foreigners only vs combined).

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 usage boundary (KR only, other markets return 400 unsupported-market) and contrasts its basis with the market-indicators investor-trading sibling. It stops short of a full when-to-use-this-vs-that routing sentence for the broader sibling set, but the exclusions are explicit.

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 annotations it discloses the failure mode (400 unsupported-market), the measurement universe (KRX only, NXT excluded), the unit (integer share counts), the netBuyVolume = buy − sell sign convention, the absence of a value/amount axis, and intraday refresh behavior before market close. These are exactly the traits an agent cannot infer from structured fields.

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 short lead sentence states the action and the time-series shape, then bullet points carry constraints and pagination, with bold labels for timeliness and rate limits. Dense but front-loaded and scannable. Minor redundancy between the first sentence and the second, which restate the daily-series framing.

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 describe returns itself, and it does: the arbitrage/nonArbitrage buckets, the netBuyVolume semantics, and the `nextUntil` continuation field are all named. Combined with the market coverage, units and refresh caveats, an agent has enough to call and page through this correctly; the undescribed `count` parameter is the only notable gap.

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 parameters, and it only partly does. It explains `until` well as the cursor taken from the previous response's `nextUntil`, but `count` is never described (no meaning, no default, only the schema's 1–100 bounds) and `symbol` gets no format guidance beyond being a KR ticker.

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+resource (program-trading trend lookup) and specifies the shape of the result: a daily volume time series for a KR stock, split into arbitrage and nonArbitrage buy/sell/net volumes, newest first. That scope clearly separates it from siblings like toss_get_stock_investor_trading, toss_get_stock_short_selling and toss_get_stock_credit_trades, which cover different flow dimensions.

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 boundaries: KR-only (other markets return 400 unsupported-market), KRX trades only with NXT excluded, and no monetary axis. That is clear context for when this tool applies. It never names a sibling alternative or says what to use when the caller actually wants amount-based or NXT-inclusive data, so it stops short of full 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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds a real behavioral constraint – a 200-symbol batch cap and accepted market coverage – but says nothing about what happens with invalid symbols, partial results, or lookup failures against the external API.

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 front-loaded sentence with zero filler; the verb, resource and constraints appear in the first clause. 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 no output schema, the agent has no idea what 'master data' returns (name, market, currency, lot size, trading status?), which is the main thing an agent needs before choosing this over toss_get_prices. The input side is complete, but the return side is opaque.

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% (the single parameter is just typed as string), so the description must carry the burden, and it does: it specifies comma-separated format, the maximum of 200 entries, and that symbols may be KRX or US. It stops short of showing a concrete example format, which would have completed the picture.

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 ('Get') and resource ('stock master data') plus the scope boundaries (up to 200 comma-separated KRX or US symbols). It is distinguishable from most siblings, though it never contrasts itself with toss_list_stocks, which could plausibly be confused with 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 gives operational constraints (batch cap of 200, comma-separated format, KRX/US coverage), which hints at how to use it. It offers no explicit when-to-use/when-not guidance and never names an alternative such as toss_list_stocks for enumeration, leaving routing 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/destructive annotations, it discloses currency semantics (all values KRW, no currency field), the exact error behavior for unsupported markets, the pagination contract, data freshness (daily finals land that evening), and the rate-limit group name. That is a lot of operationally relevant context, though it says nothing about row limits or what an empty/edge response 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?

Front-loaded one-line purpose followed by tight bullets grouped by market scope, currency, disambiguation, and pagination, plus bolded freshness and rate-limit notes. Slightly repetitive in restating the trend-inquiry phrase in the first two sentences, but no bullet 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?

No output schema exists, yet the description names the returned measures and the `nextUntil` field an agent must consume to page. Combined with the market restriction, currency note, and freshness caveat, an agent has everything needed to call it and interpret the response.

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 carry the load; it does explain `until` as a pagination cursor fed from `nextUntil`, which is the least obvious of the three. `symbol` and `count` (1–100) are never described in prose, so those two remain documented only by JSON-Schema type/constraint metadata.

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 ('대차거래 동향 조회') scoped to KR symbols with a daily time series, and names the exact data returned (체결·상환·잔고 수량, 잔고 금액). It also explicitly separates itself from the nearby credit-trades/stockLoan dataset, which is the most likely confusion among 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 an explicit inclusion boundary (KR only) plus the failure mode for anything else (400 `unsupported-market`), and points at the alternative dataset (`GET /api/v1/stocks/{symbol}/credit-trades` → `stockLoan`) so the agent can route correctly. Pagination continuation via `nextUntil` → `until` is spelled out, 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?

Goes well past the readOnly/openWorld annotations: documents the 400 `unsupported-market` failure mode, that all amounts are KRW with no currency field, the exact denominator definition for the ratio fields (including pre/post-market sessions), the null-vs-0 behavior when the denominator is missing or zero, and data timeliness (daily confirmed values land in the evening). This is exactly the operational context annotations cannot carry.

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 one-line purpose, then well-organized bullets grouped by market/currency/ratio/pagination caveats, plus bold emphasis on data timeliness. Slightly redundant in restating the title before expanding it, but no bullet 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?

Without an output schema, the description usefully names the response fields an agent needs (`nextUntil`, `shortSellingVolumeRate`, `shortSellingAmountRate`) and their edge-case values, and discloses the rate-limit group. The remaining gap is input-side: no default page size or `count` behavior, which matters for a paginated list endpoint.

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 the burden. It explains `until` as a pagination cursor fed from the response's `nextUntil`, and implies `symbol` is a KR ticker, but it never describes `count` (range 1–100, no stated default) or clarifies that `until` is an exclusive/latest-first bound. Two of three parameters remain partly 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?

States a specific verb and resource ('공매도 동향을 일별 시계열로 조회') plus exactly what is returned (short-selling volume/value with ratios) and in what order (최신순). The KR-only scope further narrows it against siblings, though no sibling is named explicitly (e.g. vs. toss_get_stock_securities_lending or toss_get_stock_credit_trades, which are the closest analogous datasets).

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 by the market restriction ('국내(KR) 종목만 지원합니다') and by the pagination recipe for follow-up calls, but there is no explicit statement of when to prefer this over sibling trading-trend tools. An agent must infer the choice from the domain vocabulary alone.

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 readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description contributes the market-scope constraint (KRX or US) and that exactly one symbol is inspected, but says nothing about what the returned flags mean, their categories, or whether an empty result is possible.

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 front-loaded sentence with no filler; the scope constraint follows immediately after the verb and resource.

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 read tool with no output schema, the description is mostly sufficient to trigger a correct call, but the agent still lacks any picture of what 'buy warning flags' contains or whether they vary by market, which matters for interpreting results.

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%, and the description only partially compensates by clarifying that the symbol is a single KRX or US ticker. It adds no format guidance beyond the schema's regex pattern (e.g., suffix conventions for Korean vs US listings), leaving the sole parameter under-documented.

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 ('Get buy warning flags') plus the scope ('one KRX or US stock symbol'), which separates it from sibling data tools like toss_get_price_limits or toss_get_stock_short_selling. It does not name a sibling directly, 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 phrase 'buy warning flags' implies a pre-trade risk check, but the description never states when to reach for this versus related tools (price limits, short selling, program trades) or any prerequisite conditions. Usage is inferable 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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the useful non-schema fact that count falls back to a Toss API default. It doesn't mention latency, real-time vs delayed data, or pagination behavior.

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 tight sentences with the main purpose front-loaded and the count caveat second. No filler, though the sentence about count could have been folded into the first for even better flow.

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?

A simple read-only market-data tool with no output schema, so the description needn't explain return values, but it also doesn't say what a trade record includes or whether data is real-time. Adequate but with clear gaps for an agent that needs to interpret results.

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 parameter meaning. It explains count's default and cap (though the cap of 50 is already in the schema's maximum), but says nothing about the symbol parameter's expected format beyond 'KRX or US stock symbol' – no ticker pattern examples or market-specific formatting.

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 (recent trades for one KRX or US symbol) and names the scope constraint. It doesn't explicitly distinguish itself from nearby siblings like toss_get_stock_program_trades or toss_get_candles, but the resource is specific enough to be identifiable.

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?

No guidance on when to use this versus toss_get_candles, toss_get_orderbook, or the various specialized trade tools. There are no exclusions or prerequisites stated beyond the symbol scope.

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 openWorldHint=true, so the safety profile is covered and the description only needs to add context. It adds the useful scope note that session hours are included in the response, but a key behavior is left unspecified: with the optional date absent, it's unclear whether the tool returns today's schedule, a full-year calendar, or something else. This gap is especially relevant for a calendar tool.

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 tight sentences with no wasted words, and the main purpose comes first. The second sentence is a clipped fragment ('date is optional...'), but it is still readable and 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?

This is a simple read-only tool with one optional parameter and no output schema, so the description does not need to explain the response. However, the description provides nothing on what the calendar returns, such as holiday listings, half-days, or timezone format, and it omits the default behavior when no date is given. That leaves the definition barely adequate.

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 schema gives only type, format, and pattern, while the description supplies the two facts that matter: the date is optional and interpreted in US local time. It still does not state what omitting the date yields. That makes this modest-added-value rather than full compensation.

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 gets a US market calendar and session hours. The 'US' qualifier effectively distinguishes it from the sibling toss_get_kr_market_calendar, even though the description never names that sibling. The resource boundary is clear, but it doesn't describe what the calendar contains, such as holidays or early closes.

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?

No indication of when to call this rather than toss_get_kr_market_calendar or the market-indicator tools, and no prerequisites or exclusions. The parameter is optional, yet the description never says what omitting date returns, so the agent cannot infer the usage mode either. Only the tool name itself signals the target case.

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 annotations, the description discloses ordering guarantees (depth ascending, then numeric sectorId ascending), the fact that one stock can belong to multiple sectors, hierarchy reconstruction via `parentSectorId`, data volatility, and the SECTOR rate-limit group. These are behavioral traits an agent cannot infer from 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?

One-line summary followed by four tight bullets, each covering a distinct concern (classification model, hierarchy fields, sort order, caching/consumption). Front-loaded and every line carries information the agent would otherwise have to discover empirically.

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 carries the burden of describing the return shape — and it does, explaining the hierarchical fields, ordering, and cardinality relationship to stocks. Nothing an agent needs to call this zero-parameter tool and use its results 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?

The tool takes no parameters, so the schema offers nothing to explain and the baseline is 4. The description does go further by defining the semantics of returned fields (`depth` levels 0/1/2 and `parentSectorId` traversal), which is useful context even though it strictly concerns output rather than inputs.

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 (섹터 목록 조회) plus the scope: the entire Toss Securities sector classification returned with hierarchy in one call. The closing note that other sector APIs take their `sectorId` from this list distinguishes it from neighbors like toss_get_sector and toss_get_sector_stocks without needing 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?

Gives concrete usage context: use this list as the source of `sectorId` inputs for other sector APIs, and cache it once a day since it rarely changes. It does not explicitly name the sibling tools it complements nor state when not to call it, so it falls short of full when/when-not 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 cover the read-only, non-destructive, open-world profile, and the description adds genuinely new behavior: no pagination, result size up to thousands of rows (~2,800 for NASDAQ, ~30KB gzipped), daily batch refresh with low volatility, tradable-only coverage, and the STOCK_ALL rate-limit group.

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?

Bold-labeled sections (정렬, 응답 규모, 관련 API) with the purpose front-loaded make it skimmable, and each block carries actionable information. The only waste is the opening sentence duplicating the title before the slightly fuller restatement.

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 4-parameter read-only list tool with no output schema, the description covers everything an agent needs: sort order, absence of pagination, expected response volume, caching cadence, rate-limit group, and the natural next call. Missing enum glosses are minor against this coverage.

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 load; it names three of the four parameters (status, securityType, commonShare) and explains their shared semantics as universe filters, with market implied as the exchange selector. It stops short of clarifying enum value meanings (e.g., SCHEDULED vs DELISTED) or the commonShare boolean's effect, leaving some interpretation to the enum literals.

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 ('마켓(거래소)별 종목 리스트를 조회') with explicit scope: the full universe of tradable symbols per market, no pagination. It also differentiates from the sibling toss_get_stocks by naming the follow-up call for per-symbol detail, so an agent can distinguish the two without opening a 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?

Restricts use to universe construction ('종목 유니버스 구성 용도') and names the alternative (GET /api/v1/stocks) with the condition that selects it (needing name, currency, listing status). It further advises a once-per-day fetch plus local caching, which tells the agent not to call this per-request.

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