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

The description adds meaningful behavior beyond annotations: it warns that this cancels a REAL standing order, clarifies that only the watcher is removed, and states that already-placed real orders are unaffected. It also documents the return object and the 404 error, giving the agent a full behavioral picture.

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

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

The description is concise and front-loaded: purpose and warning come first, followed by parameters, return shape, scope clarification, and errors. Every sentence adds value, and the important distinction from tossinvest_cancel_order is placed prominently.

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

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

Given the annotations, full schema coverage, and sibling context, the description is complete. It covers purpose, parameters, return shape, error case, destructive warning, and the critical distinction from canceling a real order. An agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description's Args section mostly repeats the schema, adding only a small note that account_seq is resolved automatically for single-account credentials. This meets the baseline but does not substantially exceed it.

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

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

The description states a specific verb ('Cancel') and resource ('standing conditional order') and explains the effect ('stops watching the price'). It clearly distinguishes itself from tossinvest_cancel_order by noting that real orders already placed by a fired condition are untouched and must be canceled separately.

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

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

It explicitly tells the agent when to use this tool versus the alternative tossinvest_cancel_order: this removes the watcher, while real orders from fired conditions need separate cancellation. It also provides a user-confirmation guideline: 'confirm with the user first.'

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 annotations by warning that the order is real and requires user confirmation, explaining partial-fill cancellation semantics, directing the agent to read execution.filledQuantity, and enumerating specific error codes. The idempotentHint is not contradicted because repeated cancels do not change state even if they return 409.

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?

Structured into Args, Returns, and Errors sections with the critical real-order warning front-loaded. Every sentence carries operational value; the length is justified by the destructive nature and the partial-fill edge case.

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

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

Given that an output schema exists, the description still provides the return shape, error semantics, partial-fill behavior, and parameter sourcing. An agent has everything needed to call the tool safely and interpret its result.

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

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

The schema already documents all three parameters at 100% coverage, but the description adds cross-tool sourcing for order_id, auto-resolution behavior for account_seq, and the default output format. This extra guidance helps the agent choose correct values beyond the bare schema.

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

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

States a specific verb ('cancel') and resource ('working order'), and explicitly warns it acts on a REAL order. It is clearly distinct from tossinvest_modify_order and tossinvest_cancel_conditional_order by targeting non-conditional working orders.

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

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

Provides explicit sourcing for order_id ('Get it from tossinvest_list_orders with status='OPEN'') and instructs the agent to confirm with the user before canceling. It does not name alternatives like tossinvest_cancel_conditional_order, but the working-order scope makes the intended use reasonably clear.

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

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

Annotations already signal destructiveHint=true and readOnlyHint=false, but the description adds substantial context: 'REAL' (real-world financial impact), the requirement to 'Confirm every parameter with the user first,' the one-per-symbol limit for OCO/OTO (with specific 422 duplicate-conditional-order error), the trigger price ordering constraint, the confirm_high_value_order requirement at ₩100M, and the full error taxonomy. This exceeds what annotations provide and directly supports the destructive/openWorld profile.

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 longer than average but justified by the tool's complexity (11 params, 3 types, nested objects). It is well-structured with clear section headers (Types, Args, Returns, Errors) and front-loads the core purpose. The Args list is somewhat redundant with the schema since coverage is 100%, but it adds the constraint summaries that the schema lacks. A tighter format could merge redundant bits, but the structure earns its length.

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

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

For a complex conditional-order tool with 11 parameters, 3 enums, nested objects, and three behaviorally distinct types, the description covers everything an agent needs: the three types with their invariants, return shape ({accountSeq, conditionalOrderId, clientOrderId, operation: 'created'}), error conditions with codes, and safety requirements. The output schema exists and return format is described. Nothing essential is missing for correct invocation.

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

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

With 100% schema coverage, baseline is 3, but the description adds cross-parameter constraints absent from the schema: the trigger price inequality 'first.trigger_price > current price > second.trigger_price' for OCO, leg-side restrictions (OCO both SELL, OTO first BUY then SELL), LIMIT/MARKET exclusivity rules, the idempotency behavior of client_order_id (10-minute window, returns original instead of duplicate), and the per-symbol limit. These relationships are critical for correct invocation and are not derivable from the individual property descriptions.

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

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

The description opens with a specific verb+resource statement: 'Register a REAL price-triggered order: watch a symbol and automatically place a buy or sell when the price reaches a trigger.' It clearly distinguishes this from the sibling tossinvest_create_order (immediate orders) by emphasizing the conditional trigger mechanism. The three order types are each defined with their specific behavior.

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 detailed context on when each type is appropriate (OCO = take-profit/stop-loss bracket on existing position, OTO = buy-then-auto-exit) and warns the user to confirm every parameter first. It does not explicitly name alternatives (e.g., 'use tossinvest_create_order for immediate fills') but the behavioral guidance for when this tool is appropriate is clear and strong.

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

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

Annotations already mark destructiveHint=true, and the description goes well beyond that by stating 'This spends or liquidates actual money' and requiring user confirmation. It also discloses that the response confirms acceptance, not execution, lists concrete error codes, and explains the 10-minute idempotency window and order-type restrictions. No contradiction with annotations.

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

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

The description is longer than average, but every sentence earns its place: the money-spending warning is front-loaded, parameters are grouped and scannable, and the return semantics, pre-checks, and error codes are clearly separated. There is no filler, tautology, or redundant explanation of the tool's name.

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

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

For a destructive order tool with 11 parameters, the description covers all necessary context: required user confirmation, parameter constraints, mutual exclusivity, idempotency, return shape, follow-up tool, and error conditions. The output schema exists and the description still adds the critical caveat that acceptance is not execution. Nothing essential is missing.

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

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

Schema description coverage is 100%, and the schema already documents every parameter in detail, including tick sizes, mutual exclusivity, the idempotency window, and session restrictions. The description's Args section largely restates this schema content, adding emphasis but little new semantic information. Baseline 3 is appropriate because the schema carries the semantic load.

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?

Opens with 'Place a REAL buy or sell order for a Korean or US stock' — a specific verb and resource with an explicit warning that actual money is involved. This clearly distinguishes the tool from the get/modify/cancel and conditional-order siblings. The title is fully expanded by the first sentence, leaving no ambiguity about what the tool does.

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

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

Provides explicit pre-call guidance: confirm symbol/side/quantity/price with the user, check buying power for buys, sellable quantity for sells, and price limits before ordering. Also directs the agent to tossinvest_get_order to check the eventual fill. It does not explicitly contrast with tossinvest_create_conditional_order or state when not to use this tool, so it falls just short of a 5.

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

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

Annotations (readOnlyHint, idempotentHint, etc.) are consistent with the description. The description adds transparency about the return value (cash-only, excluding margin) and the account_seq fallback, with no contradictions.

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?

Concise and well-structured: brief opening line, bullet-pointed args, and a clear return statement. Every sentence adds essential information without redundancy.

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

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

The description fully specifies what the tool returns (accountSeq, currency, cashBuyingPower) and the meaning of cashBuyingPower (cash-settled, excluding margin). It is self-sufficient for an agent to invoke correctly, despite the output schema not being shown.

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 covers 100% of parameters with detailed descriptions, including enum values and fallback logic for account_seq. The description reinforces each parameter's purpose, providing complete semantic clarity.

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?

Clearly states the tool's function: retrieving available cash buying power in KRW or USD. Unambiguously distinguishes it from sibling tools focused on orders, prices, and other account 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?

Explicitly instructs to check this before placing a buy order and explains the failure mode (422 insufficient-buying-power). Also provides guidance on account_seq fallback, covering when and how to use the tool.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive, so the description does not need to restate safety. It adds significant behavioral context: bars are newest-first, the call is capped at 200 bars, pagination uses `nextBefore` from the previous response, and `nextBefore` is null when no older data exists. This makes the tool's runtime behavior predictable.

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

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

The description is well-structured and front-loaded: core behavior first, then usage context, argument details, return shape, and examples. It is slightly redundant because the Args section largely duplicates the input schema descriptions, but the paging note, examples, and index disambiguation make the extra length worthwhile.

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 six parameters, two enums, pagination, and multiple sibling tools, this description covers everything an agent needs: what the tool returns, the ordering, the 200-bar cap, the paging mechanism, examples for symbol/interval/count, and an explicit exclusion for index candles. The presence of an output schema also reduces the burden of describing return fields, and the description complements it well.

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

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

The input schema already provides 100% parameter coverage, so the baseline is 3. The description adds value beyond the schema by explaining how to use `before` with `nextBefore` for backward pagination, clarifying `adjusted` behavior ('Set false for raw prices'), and offering concrete natural-language to parameter mappings in the examples. It does repeat some schema content, but the added semantics justify a 4.

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 begins with a specific verb-resource statement: 'Get OHLCV candles for one stock, newest bar first.' It clearly identifies the data type (OHLCV candles), the scope (one stock), and the ordering convention. This differentiates it from sibling tools like tossinvest_get_prices, tossinvest_get_orderbook, and especially tossinvest_get_market_indicator_candles.

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 frames this as the tool for historical price analysis with concrete examples like trends, ranges, moving averages, and 'how did X do last month.' It also explicitly routes index-related requests to tossinvest_get_market_indicator_candles instead, giving the agent a clear decision rule among siblings.

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

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

The annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. Beyond that, the description adds rich context: commissionRate is a percentage requiring multiplication by 0.00015, and startDate/endDate have specific null semantics for US and open-ended rates. This is exactly the kind of behavioral detail an agent needs.

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

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

The description is well-structured: purpose first, use cases second, then args and return semantics. It is efficient, though the Args section partly duplicates the input schema descriptions, making it slightly redundant for an agent that can read the schema.

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

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

Given the read-only annotations, full schema coverage, and an output schema, the description is complete. It explains the return shape, the meaning of commissionRate, and the null behavior of date bounds, so an agent can correctly interpret results without additional inference.

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

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

Schema coverage is 100%, and the schema already documents account_seq fallback behavior and response_format meaning. The description's Args section mostly restates this, adding little beyond the schema. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 the account's trading commission rates for the Korean and US markets.' This clearly distinguishes it from the many sibling get_* tools, none of which target commission rates.

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 use cases: 'Use this to estimate trading costs before ordering, or to explain the gap between gross and after-cost profit in holdings.' It doesn't name alternative tools or exclusions, but for this read-only commission tool the use-case guidance is clear and sufficient.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, and the description adds substantial behavioral context beyond that: it can retrieve active or finished orders, 404 behavior, and the critical caveat that modifying an order issues a new ID and voids the old one. This is exactly the kind of behavioral disclosure that helps an agent avoid stale-ID mistakes.

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

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

The description is well-structured with clear sections (overview, args, returns, errors). Every sentence carries useful information, and the most critical operational warning about ID invalidation is prominently included. No filler or redundancy.

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

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

The description is fully complete for this tool: it covers parameter sources, optional fallback behavior, response shapes for legs, status enums, error scenarios, and the important ID lifetime caveat. Combined with the annotations and output schema, an agent has everything needed to call this tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by specifying that conditional_order_id should come from a create/modify response or list call, and that account_seq is automatically resolved for single-account credentials. This enriches the schema's minimal 'Conditional order identifier.' description.

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

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

The description states a specific verb ('Get'), a specific resource ('full detail of one conditional order'), and a clear scope ('by id, active or finished'). It clearly differentiates from sibling tools like tossinvest_list_conditional_orders (list vs. detail) and tossinvest_get_order (regular orders vs. conditional orders).

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

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

The description gives clear context for use: it explains where valid IDs come from (create/modify response or tossinvest_list_conditional_orders) and warns that modifying a conditional order invalidates the old ID, telling the agent to always use the most recent ID. It does not explicitly state when-not-to-use or name alternatives, so it stops short of a 5.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond that: the rate refreshes once a minute, validFrom/validUntil bound the quote window, the rate is indicative and may differ from the settled order rate, and a 404 error is possible. No contradiction exists.

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

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

The description is compact yet information-dense. It is front-loaded with the core purpose, then covers usage, parameters, return fields, caveats, and errors without redundancy. Every sentence adds value.

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

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

For a four-parameter read tool with an output schema, this description is exceptionally complete. It explains the return field semantics, the time-window behavior, the indicative-rate caveat, and error conditions. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents parameters well. The description adds useful semantic value beyond the schema, especially the example 'base='USD', quote='KRW' gives won per dollar' and the clarification that date_time is optional and omitted for the current rate.

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 the KRW <-> USD exchange rate, refreshed once a minute.' It clearly identifies the operation and the unique data it returns, distinguishing it from the many market-data and order sibling tools.

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

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

It explicitly advises when to use the tool: 'Use this to convert between the KRW and USD figures that holdings and orders report separately.' This gives clear context and prevents confusion with other quote/price tools, even though no alternative tool is named.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint: false; the description adds valuable behavior beyond that: KRW and USD are reported separately and never summed, profitLoss includes AfterCost net variants, and no holdings returns zeroed totals with an empty item list. No contradiction with annotations.

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

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

The description is front-loaded with the main purpose and organized into clear sections for args and returns. The return-object explanation is genuinely useful, but the Args list duplicates the fully documented input schema, making the description slightly longer than strictly necessary.

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

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

It covers account selection behavior, symbol filtering, response format, return shape, per-currency handling, net-vs-gross profit/loss, coverage exclusions, and empty-result behavior. For a complex read-only portfolio query, nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, and the description's Args section largely restates what the schema already says: account auto-resolution, symbol restriction with recomputed totals, and response_format default. It adds no materially new parameter semantics, so the baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Get the account's stock holdings with per-symbol detail and aggregate valuation.' It also explicitly labels itself 'the portfolio tool,' which distinguishes it from the many market-data, order, and account siblings.

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

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

It gives clear context for when this tool is relevant ('what is owned, at what average cost, worth how much') and states exclusions ('Covers KR and US stocks only — overseas derivatives and bonds are excluded'). It also points to tossinvest_get_exchange_rate when a single currency figure is wanted. It does not enumerate alternatives for every sibling, but the routing context is sufficient.

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 indicate readOnly, idempotent, openWorld, and non-destructive behavior. The description goes further by explaining amount representation as KRW strings, foreigner aggregation across registered/unregistered, market-wide buy/sell equality, provisional current-day data, checking updatedAt, and the 400 unsupported-symbol error.

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

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

Although the description is dense, every sentence adds distinct value: purpose, output structure, amount semantics, investor aggregation, provisional data caveat, and error behavior. No filler or redundant phrasing is present.

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

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

The description fully covers the tool's purpose, parameters, output structure, data semantics, provisional-data caveat, and error handling. Given the output schema and annotation context, nothing needed for correct invocation is missing.

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

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

Schema coverage is 100%, but the description adds meaningful semantics beyond the schema: net flow = buyAmount - sellAmount, institution subcategories sum to institution totals, and the meaning of 'foreigner' across registered and unregistered investors. It also clarifies the response_format distinction between markdown summary and raw JSON payload.

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

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

The description clearly states the tool gets KRX buy/sell value broken down by investor type for KOSPI/KOSDAQ, newest first. This specific verb and resource distinguish it from sibling tools such as get_trades, get_candles, and get_rankings.

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 frames the use case: 'answers are foreigners buying or selling?' and the classic Korean-market flow question. It does not explicitly name alternative tools to avoid, but the clear purpose provides strong contextual guidance for when to select this tool.

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

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

The description discloses critical behavioral traits beyond the annotations: all times are ISO 8601 in KST (+09:00) for both markets (US converted), the exclusion of after-hours single-price and closing-price sessions, holiday behavior (all four null), and error handling (invalid date returns 400). These details are not present in the annotations and materially affect how an agent interprets results. No contradiction with annotations.

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

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

The description is structured with clear sections (Args, Returns, Errors) and every sentence contributes necessary information. It front-loads the core purpose and usage before diving into details. There is no filler or redundancy; each line earns its place.

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

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

Given the tool's complexity (multiple markets, timezone conversion, exclusions, error behavior) and the presence of an output schema, the description fully equips an agent to call it correctly. It explains the return structure, the exact fields for each market, the meaning of nulls, and the error condition. No essential information is missing.

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

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

Schema coverage is 100% and each parameter already has a description, but the tool description adds meaningful context: the date parameter is explicitly clarified as the US local date for the US market, and the response_format default is reinforced. The country parameter's meaning (KRX/NXT vs US) is explained in the schema, and the description reiterates the timezone conversion nuance that is not in the schema. This adds genuine value beyond structured 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?

The description states a specific verb ('Get'), a precise resource (trading-session hours), and the exact scope (Korean or US market across three business days: previous, current, next). It is unambiguous and clearly distinct from sibling tools like order management or price queries. The title reinforces the purpose without tautology.

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

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

Explicitly states when to use: 'Use this to answer

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 indicate read-only, idempotent, non-destructive behavior. The description adds valuable operational details such as error codes, unsupported intervals, and the fact that bond OHLC values are yields in percent. No contradiction with annotations.

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

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

The description is well-organized with Args, Returns, and Errors sections. It is compact, avoids fluff, and each line adds necessary information for correct usage.

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

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

The description covers the return shape, error conditions, format options, and the special interpretation of bond yields. No important usage detail is missing for an agent to call this tool effectively.

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?

Input schema already covers all parameters with descriptions. The description adds meaningful extra guidance, especially the pagination mechanism via 'nextBefore' and the explicit restriction that '1m' is invalid for bond symbols.

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?

Clearly states it retrieves OHLCV history for Korean indices and treasury yields, distinguishing the resource and scope from other market data tools. The verb and target are specific and unambiguous.

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

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

Provides clear usage context including valid symbols, interval restrictions, max bar count, pagination behavior, and special bond yield semantics. Does not explicitly contrast with sibling tools, but the intended use case is well 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 mark the tool as read-only, idempotent, and non-destructive, so the description only needs to add behavior beyond that. It does: it discloses the closed symbol catalog, the meaning of yield values in percent, the exact return shape, and the 400 unsupported-symbol error. No contradiction with annotations.

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

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

The description is well structured with clear sections for supported symbols, args, return value, sibling routing, and errors. Every sentence adds information, and the most important scoping detail 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?

For a read-only data-fetching tool, the definition is complete: it fully specifies symbols, units, return shape, error behavior, and the alternative for stock symbols. Given the annotations and output schema, no critical operational detail is missing.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds meaningful extra context by enumerating the accepted symbol catalog, clarifying units (points vs. percent yields), and giving explicit usage examples for response_format. This raises it above the 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 opens with a specific verb and resource: getting the current level of Korean market indices and treasury yields. It also names the exact supported symbols and contrasts itself with tossinvest_get_prices, making its purpose unmistakable among many sibling tools.

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

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

The description explicitly states the tool's supported catalog and says 'For individual stocks use tossinvest_get_prices — this endpoint rejects stock symbols.' This gives clear when-to-use and when-not-to-use guidance with a named alternative.

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

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

Annotations already cover readOnly/idempotent/non-destructive behavior. The description adds value by noting the order can be in 'any state', disclosing the 404 error for unknown ids, and summarizing what fields the response contains. No contradiction with annotations.

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

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

The description is well-structured with a clear opening, usage guidance, parameter list, return shape, and error note. Every section serves a purpose and no redundant filler is present.

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

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

The description covers purpose, when to use it, parameter origins, response structure, and error behavior. With rich schema annotations and an output schema, nothing critical is missing for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds useful context beyond the schema by explaining that order_id comes from create/modify/cancel/list_orders calls and that account_seq is auto-resolved for single-account credentials. This helps the agent supply correct 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?

The description uses a specific verb and resource: 'Get the full detail of one order by id, in any state.' This clearly distinguishes it from list_orders (which lists many) and from create/modify/cancel tools, making its scope unambiguous.

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

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

The description explicitly states when to use this tool: 'to confirm what happened after placing, modifying or cancelling — especially to read the fill result.' It also tells where order_id comes from. It does not explicitly name alternatives or state when not to use it, but the context is clear enough.

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

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

Beyond the readOnly/idempotent annotations, the description discloses meaningful behavior: asks are ascending by price, bids descending, arrays may be empty outside trading hours, and unknown symbols produce a 404 stock-not-found error. This lets the agent anticipate output shape and failure modes.

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

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

The description is well structured with a front-loaded purpose, a usage sentence, an Args block, a Returns block, and an Errors line. It is compact and information-dense, with no irrelevant digressions; the duplication of schema details is presented efficiently enough to keep the description self-contained.

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 order-book lookup with rich annotations and a full schema, the description covers the operational context, return semantics, ordering guarantees, empty-case behavior, and error handling. Nothing needed to call the tool correctly is missing.

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

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

Schema coverage is 100%, so the baseline applies. The description repeats the symbol format and response_format options but adds no new meaning beyond what the JSON schema already documents; the schema already explains KRX/US formats, the enum, and the default.

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

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

The description opens with a specific verb and resource — 'Get the current bid/ask ladder (호가) for one stock' — and explicitly distinguishes itself from tossinvest_get_prices, which returns the single last-traded price. An agent can immediately tell what this tool does and what it is not.

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 states exactly when to use the tool ('to judge liquidity and spread before choosing a limit price') and names the alternative with a concrete selection criterion: use tossinvest_get_prices for a single last-traded price because it is cheaper and supports batching. This gives clear routing guidance.

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

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about a 404 error and the purpose of the data, but does not introduce any contradiction or require extra behavioral disclosure beyond the annotations.

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

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

The description is concise and well-structured, with a clear purpose sentence, a practical usage hint, and no redundant or unnecessary content.

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

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

Given only two simple parameters, a full output schema, and comprehensive annotations, the description provides enough context for an agent to invoke the tool correctly, including an error case and a practical use case.

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

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

The schema descriptions already cover the parameters fully, including the symbol format and response_format enum. The description does not add substantial new parameter meaning beyond what the schema provides, 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 clearly states the tool gets today's upper and lower price limits for one stock, using a specific verb and resource. It is distinguishable from sibling tools like get_prices and get_orderbook by focusing on price limits.

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

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

The description explicitly says to check this before placing a limit order and explains that out-of-band prices are rejected. It does not explicitly name alternatives, but the use case is clear enough for an agent to know when to select this tool.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description adds meaningful behavioral detail beyond that: cost context ('cheapest way'), batching behavior, the exact return shape, the decimal-string currency behavior, null timestamps for untraded symbols, and the 404 stock-not-found error. No contradiction exists between the description and annotations.

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

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

The description is well-structured and front-loaded with the core purpose, followed by usage guidance, parameter details, return shape, examples, exclusions, and error behavior. Every section earns its place; the examples are illustrative rather than redundant, and nothing is verbose or irrelevant.

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 price lookup tool, the description covers all essential operational context: symbol formats, batching limits, response format options, return structure, currency/timestamp semantics, error handling, and when not to use it. Given the rich annotations and full schema coverage, nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds useful semantic detail: it clarifies KRX symbols are 6 digits ('005930') while US symbols are tickers ('AAPL'), reinforces max 200 symbols, and states the response_format default. This goes slightly beyond the schema, warranting a 4 rather than a 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 opens with a specific verb and resource: 'Get the latest traded price for one or more Korean (KRX) or US stocks.' It also differentiates itself from siblings by explicitly stating it is for current prices, not indices or bond yields, and points to tossinvest_get_market_indicator_prices for those. Examples map natural language queries to concrete symbols, reinforcing what the tool does.

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

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

It explicitly tells the agent when to use this tool: 'This is the cheapest way to answer "what is X trading at"' and advises batching up to 200 symbols rather than looping. It also gives a clear exclusion: 'Don't use for indices (KOSPI/KOSDAQ) or bond yields — use tossinvest_get_market_indicator_prices.' This is direct 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 mark it read-only, idempotent, and non-destructive, but the description adds rich behavioral context: cumulative volume/amount over duration, basePrice/changeRate measured from period start for gainers/losers vs previous close otherwise, the possibility of fewer than count items due to failed lookups, empty list with null rankedAt as a normal state, and explicit error codes. This goes well beyond what annotations or schema provide.

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 structured into clear sections (purpose, args, returns, reading numbers, symbols, errors) and is front-loaded with the core purpose. Every sentence earns its place; there is no fluff or repetition. Despite its length, it remains scannable 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?

Given the tool's complexity (6 parameters, 4 enums, output schema), the description covers all operational aspects: return shape, edge cases (fewer than count, empty lists), error conditions, cross-tool guidance, and data interpretation. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% with descriptions for every parameter, but the description adds substantial extra meaning: it explains each 'type' enum value's sorting metric and market scope, clarifies 'duration' is in trading days, and details how to interpret the returned numbers. It enriches the schema without redundancy.

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

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

The description opens with a precise statement: 'Get a top-100 stock leaderboard by traded value, traded volume, or price change, for the Korean or US market over a chosen period.' It then provides usage examples ('what is moving today') and names the tool as the discovery tool, clearly distinguishing it from siblings like tossinvest_get_prices or tossinvest_get_candles.

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

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

It explicitly frames itself as the discovery tool and gives example queries. It also directs the agent to pass symbols to tossinvest_get_stocks to resolve names, and warns about unsupported duration/type combinations. This gives clear when-to-use and even when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral details beyond that: shares tied up in open sell orders or unsettled are excluded, exceeding it yields a 422 error, and KR quantities are whole shares while US quantities can be fractional. No contradiction with annotations.

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

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

The core purpose is front-loaded and the explanation is efficient. Each sentence adds useful information about behavior, errors, or return values. The Args section is slightly redundant with the input schema, but the overall length is reasonable for a tool with this much behavioral nuance.

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

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

The description covers the main use case, the key caveat (unsettled/open-order shares), the failure mode, the return shape, and the KR/US fractional distinction. Combined with full schema coverage and an output schema, there are no meaningful gaps an agent would need to guess about.

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

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

Schema description coverage is 100%, so the schema fully documents all three parameters. The description's Args list mostly restates what the schema already says, including the optional behavior of account_seq and the default of response_format. It adds no significant new parameter-level meaning beyond the schema.

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

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

The description names a specific verb and resource: 'Get how many shares of one symbol can be sold right now.' It also distinguishes itself from holdings by explaining that the sellable quantity can be lower than the holding quantity when shares are tied up or unsettled. This makes it easy for an agent to tell this tool apart from siblings like tossinvest_get_holdings.

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

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

The description gives clear usage context: 'Check it before selling' and warns that exceeding the quantity fails with 422 insufficient-sellable-quantity. It also clarifies that this is not the same as holding quantity. It does not explicitly name an alternative tool, but the situational guidance is strong enough for an agent to decide when to call it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds substantial behavioral context: symbol-only lookup, no price data, status enum meanings (SCHEDULED/ACTIVE/DELISTED), KR-only koreanMarketDetail, and the exact 404 error for unknown symbols. This goes well beyond the annotations without contradicting them.

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

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

The description is well-structured and front-loaded: purpose, usage guidance, args, return shape, exclusions, and errors are each in logical order. While the Args block partially duplicates the schema, the sections on return fields, enums, and error behavior add genuine value, and no sentence feels wasteful or irrelevant.

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

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

The description is thorough for a tool of this complexity: it covers parameter constraints, output structure and enums, KR-specific detail, usage boundaries, and error behavior. Given the rich annotations and output schema, nothing essential is missing for an agent to correctly select and invoke this tool.

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

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

Schema description coverage is 100%: both `symbols` and `response_format` are fully described in the input schema, including the max-200 constraint, no-spaces rule, enum values, and default. The description's Args section largely restates this information and adds no meaningful new semantic detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific verb and resource: 'Get reference/master data for one or more symbols', listing the exact fields returned. It also explicitly distinguishes itself from siblings by noting it does NOT search by company name and returns no prices, directing agents to tossinvest_get_prices for prices. This makes its purpose unambiguous relative to similar data tools.

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

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

Provides explicit usage scenarios: resolve what a symbol actually is, verify listing/tradability before ordering, and compute market cap via shares outstanding. It also states clear exclusions ('does NOT search by company name', 'returns no prices') and names the alternative tool for prices, giving agents concrete when-to-use and when-not-to-use guidance.

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

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

The description communicates the read-only, idempotent nature beyond the annotations by detailing the expected empty-result behavior, the 404 stock-not-found error, and the update frequency. No hidden side effects or contradictions exist.

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

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

The description is well-organized with a front-loaded purpose, followed by parameters, return shape, warning enums, edge cases, and errors. Every sentence adds value, and the bullet-style layout makes it easy to scan.

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

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

Given the provided output schema information, the description fully documents the return structure, all warningType values, the meaning of null endDate, the empty-list success case, and the error condition. No material gaps remain for an agent to invoke and interpret the tool correctly.

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

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

The schema already covers both parameters with format examples and enum values. The description adds practical meaning by explaining the response_format choice as compact markdown versus complete raw JSON, which goes slightly beyond the schema.

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

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

The description clearly states the tool retrieves active trading warnings and volatility-interruption flags for a single stock symbol, framing it as a pre-purchase safety check. This distinguishes it from sibling tools that handle prices, orders, or 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?

It explicitly advises checking this tool before buying unfamiliar stocks and clarifies that an empty warning list is a valid result, not an error. It also notes the update cadence for VI flags versus exchange designations, giving the agent concrete timing 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?

Beyond the readOnly and idempotent annotations, the description discloses key behavioral details: results are limited to the current session, newest first, returns an empty list before the first trade, and returns a specific error code for unknown symbols. This gives the agent strong expectations about edge cases without needing to call the tool blindly.

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

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

The description is well-structured and front-loaded: the core purpose appears in the first sentence, followed by use context, scope limitation, parameters, return shape, empty behavior, and errors. Every section adds useful information and there is no redundant filler.

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

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

The description effectively covers what the tool returns, the parameter constraints, the current-session limitation, empty-list behavior before the first trade, and error handling for unknown symbols. Given the tool's moderate complexity and the presence of annotations, this is a complete and self-sufficient definition.

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

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

The input schema already fully documents all three parameters with descriptions, defaults, and constraints, so schema coverage is 100%. The Args section mostly restates the schema, though it adds a concise clarifier that symbol means exactly one symbol. This is adequate but does not add substantial meaning beyond the schema.

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

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

The description clearly states the tool fetches today's most recent executed trades for one stock, newest first. It specifies the resource (trades), the scope (current session), and the ordering, distinguishing it from historical archive tools without ambiguity.

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

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

It explicitly says the tool is useful for gauging very recent momentum and actual traded sizes, and warns that it only covers the current session and is not a historical trade archive. It does not name a specific alternative tool for historical data, but the exclusion is clear enough for an agent to avoid misusing it.

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

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

Annotations already declare this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond annotations: only BROKERAGE (종합매매) accounts are exposed, child accounts are not usable, an empty list means no brokerage account, and the ACCOUNT group rate limit is 1 request/second. No contradictions.

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

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

The description is compact yet information-dense. It front-loads the core purpose and usage guidance, then uses labeled sections for args, returns, caveats, and rate limit. Every sentence earns its place; the structure helps an agent scan quickly.

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

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

For a discovery tool, the description covers all relevant guidance: output format, return shape, account scope limitations, empty-list semantics, automatic resolution of a single account, and rate limiting. An agent can correctly decide when and how to call this tool without needing additional context.

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

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

The only parameter, response_format, is fully documented in the schema with enum, default, and description. The description's 'Args' line restates the default but adds no meaning beyond the schema. Schema coverage is 100%, so the baseline 3 applies.

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

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

The description opens with a specific verb and resource: 'List the Toss Securities accounts reachable with the configured credentials.' It also explains the accountSeq field's role in every account-scoped tool, distinguishing this discovery tool from the many sibling tools that consume account_seq. No ambiguity or tautology.

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

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

Explicit guidance is given: 'Call this first when you do not know which account to act on.' It further tells the agent when it can skip manually passing account_seq ('When exactly one account exists, other tools resolve it automatically'), which refines the decision of whether to call this tool at all.

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

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

Annotations already mark the tool as read-only and idempotent, and the description adds substantial behavioral detail beyond that: it covers pagination via nextCursor and hasNext, explains the OPEN/CLOSED status groupings, discloses that no server-side type filter is available, and explains that triggeredOrderId links to a real order readable via tossinvest_get_order. No contradiction with annotations exists.

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

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

The description is long but well-organized into a concise opening sentence, an Args section, and a Returns section. Every section earns its place given the tool's complexity, though some parameter details are redundant with the schema. It is front-loaded with the core purpose and scope.

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 six-parameter tool with an output schema, the description is exceptionally complete: it explains all parameters, the return object structure, condition leg fields, pagination, and how to follow up on triggered orders. It also covers edge cases like the absence of a server-side type filter, making it sufficient for an agent to invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real value by mapping status values to underlying sub-statuses (WATCHING, PAUSED, ORDERING, ORDERED vs COMPLETED, EXPIRED) and restating key constraints like limit range and default. It repeats some schema details but the status breakdown and pagination behavior improve clarity.

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 the account's conditional (price-triggered) orders." It also clarifies the tool's broad scope by stating it returns conditional orders from every channel, including those created in the Toss Securities app, which clearly differentiates it from plain list-orders or get-one-order tools.

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

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

The description gives clear context for when this tool is useful: it captures all conditional orders regardless of origin and tells the agent to filter by type manually because no server-side filter exists. It references a related tool (tossinvest_get_order) for reading triggered orders, but it does not explicitly name alternatives like tossinvest_list_orders or state when not to use this tool.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds substantial context beyond annotations: OPEN returns all working orders in one shot and ignores cursor/limit, CLOSED honors pagination, and filledQuantity is 0 when nothing has filled and must be checked on CANCELED and REJECTED orders.

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

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

The description is front-loaded with the core purpose, then organized into an Args list and focused behavioral notes. Every sentence earns its place, and the paging and status-vocabulary warnings are concise and high-value.

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

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

Given the output schema already exists, the description still explains return-shape essentials, pagination semantics, and status vocabularies. Nothing needed for correct invocation appears to be 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?

Even though schema coverage is 100%, the description adds meaning the schema cannot express: the status argument is a group label distinct from orders[].status, cursor/limit are ignored for OPEN, and account_seq has an automatic fallback resolution. This materially improves correct parameter use.

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

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

States a specific verb and resource: 'List the account's orders, filtered by lifecycle group.' It clearly explains the OPEN/CLOSED grouping and goes beyond the title, but it does not explicitly differentiate itself from sibling tools such as tossinvest_get_order or tossinvest_list_conditional_orders.

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

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

Provides clear context for using the status argument, date filters, pagination, and response_format. It does not explicitly say when to prefer this tool over siblings, but the description gives enough operational guidance that an agent can invoke it correctly.

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

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

The description goes well beyond the annotations: it warns the order is real, requires user confirmation, explains that modification works by cancel-and-recreate, that a new conditionalOrderId is issued, and that the old one stops working. It also discloses that omitted legs are dropped. This matches and enriches destructiveHint=true and idempotentHint=false.

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 longer than typical but front-loads the critical warning and the cancel-and-recreate behavior before the parameter list. The Args and error sections are dense and actionable, though the parameter list partly repeats schema information. For a destructive, high-value tool, the length is justified.

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

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

For a 10-parameter mutation with nested objects and an output schema, the description covers the new ID in the return, required vs optional legs, type switching rules, expiry requirement, error cases, and the high-value confirmation flag. Nothing an agent needs to safely call this tool is left to guesswork.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds actionable cross-parameter guidance: omitted legs are dropped, expire_date is required here even if optional in clients, account_seq resolves automatically for single-account credentials, and OCO/OTO accept LIMIT only. These details materially improve correct invocation beyond the schema alone.

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

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

The description opens with 'Replace an existing conditional order's settings,' naming a specific verb and resource, and the body clearly distinguishes this from create/cancel operations by explaining that modification re-specifies an existing order and issues a new ID. This is unambiguous in the context of siblings like tossinvest_create_conditional_order and tossinvest_cancel_conditional_order.

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 clearly tells the agent when to use the tool: on an existing conditional order, after user confirmation, with all desired legs re-specified. It also explains the high-stakes consequences of use, such as cancel-and-recreate behavior and the old ID stopping working. It does not explicitly list sibling alternatives or when-not-to-use, but the context is strong enough to avoid confusion.

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 flag destructiveHint=true and idempotentHint=false; the description adds substantially more: the imperative 'confirm the new terms with the user first,' the US-stock 400 us-modify-quantity-not-supported rejection, and the hard rejection of orders ₩3,000,000,000 or more. Error codes (409 already-filled/already-canceled/already-modified/already-processing, 422 modify-restricted, 404 order-not-found) and the return shape { accountSeq, orderId, operation: 'modified' } give the agent concrete recovery paths.

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 action and the real-order safety warning, followed by scannable Args/Returns/Errors sections. The length is justified for a real-money destructive tool, though the Args section partially duplicates the already-detailed schema descriptions. Every sentence earns its place overall.

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 mutation tool with 7 parameters and real-world consequences, the description covers preconditions, per-market behavior, high-value confirmation flow, return payload, and all documented error paths. The output schema exists, so return values need no further detail. Nothing an agent needs to call it correctly and safely is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The Args section nevertheless adds actionable meaning beyond the schema: the specific 400 error for US quantity, the ₩100M/₩3B thresholds governing confirm_high_value_order, and account_seq auto-resolution for single-account credentials — details that change call construction, not just labeling. It does not fully compensate for everything, but it adds genuine value above an already-rich schema.

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

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

Opens with a specific verb+resource statement — "Change the price (and, for Korean stocks, the quantity) of a working order" — that precisely names the action and target. The safety-critical framing "This alters a REAL order" makes it unmistakable that this is a mutating tool, clearly distinct from sibling create/cancel/read tools. The title 'Modify an open order' aligns perfectly with the description.

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?

States the precondition explicitly: the order 'Must still be working; get it from tossinvest_list_orders with status='OPEN'.' This tells the agent how to source a valid order_id and when this tool applies. It does not explicitly name alternatives or exclusions (e.g., 'use tossinvest_cancel_order to remove an order instead'), so it stops short of a 5, but the context is clear.

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