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

Annotations declare destructiveHint=true and readOnlyHint=false. Description adds valuable behavioral context about the confirmation requirement (confirm: true) needed for execution, but does not describe return values, error conditions, or side effects beyond this safety guard.

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?

Single well-structured sentence with essential information front-loaded. Every element serves a purpose: action verb, resource specification, domain qualifier, and critical safety requirement.

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 operation, mentions the confirmation safety mechanism. However, lacks output description (no output schema exists) and does not indicate what constitutes success/failure or preconditions like order status.

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 has 100% description coverage with clear Russian descriptions. Description reinforces the confirm parameter requirement but primarily mirrors schema content. Baseline 3 appropriate given schema completeness.

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 specific action (cancel/отменить) and resource (exchange order/биржевую заявку) with domain context (T-Investments). Uses terminology ('биржевую заявку') that implicitly distinguishes from stop orders (sibling cancel_stop_order), though explicit differentiation would strengthen this.

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 critical safety guidance that confirm: true is required for execution. However, lacks explicit when-to-use versus sibling cancel_stop_order or guidance on order state prerequisites (e.g., only active orders).

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?

While annotations declare destructiveHint=true and readOnlyHint=false, the description adds crucial behavioral context that explicit confirmation (confirm: true) is required to execute the cancellation, indicating a safety-gated destructive operation.

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?

Single sentence structure front-loaded with action, zero redundant content. Parenthetical efficiently conveys critical safety requirement without verbosity.

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?

Adequately complete for destructive operation with 100% schema coverage. References domain context (T-Investments) and safety confirmation. No output schema present to require additional description.

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%, establishing baseline 3. Description adds value by emphasizing via 'требуется' that confirm parameter is mandatory (not optional), adding semantic weight beyond the schema's literal 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?

Description provides specific verb 'Отменить' (Cancel) with specific resource 'стоп-заявку' (stop order) and domain 'Т-Инвестициях'. Clearly distinguishes from sibling 'cancel_order' by explicit resource qualification.

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?

Mentions critical prerequisite '(требуется confirm: true)', providing implicit safety guidance. However, lacks explicit comparison to sibling 'cancel_order' regarding when to use stop-order cancellation vs regular order cancellation.

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

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

Annotations declare readOnlyHint=true, covering the safety profile. The description adds minimal behavioral context beyond this—it doesn't mention if accounts are filtered by status (active/inactive), whether this includes archived accounts, or rate limiting considerations.

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?

Single sentence efficiently conveys the tool's purpose with no redundant information. Perfectly sized for a parameter-less read operation.

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?

Adequate for a simple read-only tool with no parameters. While the output schema is missing, the description indicates a 'list' is returned, which provides sufficient context for tool selection despite not detailing the account object structure.

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 present, which per guidelines warrants a baseline score of 4. The description implies no filtering is possible (list all accounts), which aligns with the empty 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 uses a specific verb 'Получить' (Get) with resource 'счетов' (accounts) and domain context 'Т-Инвестициях' (T-Investments). It distinguishes from siblings like get_portfolio (holdings) and get_positions (positions) by focusing on account metadata.

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 explicit when-to-use guidance, prerequisites, or alternatives mentioned. While the tool's purpose is inferable from the name and lack of parameters, there is no guidance on when to prefer this over get_user_info or how it relates to the trading 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 declare readOnlyHint=true, covering the safety profile. The description adds scoping context (limit to companies/companies only, up to 100 tickers implied by parameter), but omits error handling for invalid tickers, data freshness/staleness, whether partial results are returned, or response format details.

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?

Extremely concise at 6 words. Single sentence with action-front-loaded structure. Every word earns its place—no redundancy or filler. Efficiently conveys the essential operation without 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?

Adequate for a simple, single-parameter read-only tool with 100% schema coverage. Given the annotations handle the safety profile and the schema documents the input, the description successfully conveys the core purpose. Minor gap: no mention of output structure, but acceptable given the tool's limited complexity.

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 the parameter 'tickers' well-documented as 'Массив тикеров (до 100)'. The description mentions 'по тикерам' (by tickers), confirming the parameter concept, but adds no syntactic details, format requirements, or examples beyond what the schema already provides. Baseline 3 is appropriate given high schema coverage.

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 Russian description 'Получить фундаментальные показатели компаний по тикерам' uses a specific verb (получить/get), resource (фундаментальные показатели/fundamental indicators), and input method (по тикерам/by tickers). It clearly distinguishes from siblings like get_last_prices, get_candles, and get_tech_analysis by specifying fundamental data rather than price or technical 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?

Provides no guidance on when to use this tool versus alternatives. No mention of why fundamental analysis might be preferred over get_tech_analysis, or when to combine with get_dividends or get_candles. No prerequisites or constraints beyond the schema are described.

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 cover read-only safety (readOnlyHint: true). Description adds valuable context that data comes from 'Т-Инвестиций' (T-Investments), indicating external data source dependency. However, lacks details on return format, pagination, 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?

Single efficient sentence with no redundancy. Immediately identifies operation and scope. Every word 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?

Adequate for a simple data retrieval tool. Mentions specific data source (T-Investments). Given 100% schema coverage and readOnly annotation, only minor gap is lack of output format description (no output schema provided).

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 has 100% description coverage (all 3 parameters documented in Russian). Description itself adds no parameter details, so baseline 3 is appropriate per calibration guidelines for high-coverage schemas.

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?

Clear specific verb 'Получить' (Get) with specific resource 'расписание купонных выплат по облигациям' (bond coupon payment schedules). Explicitly mentions bonds, distinguishing it from sibling get_dividends (stocks) and trading 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?

No explicit guidance on when to use vs alternatives, nor mention that 'from'/'to' parameters are optional while 'tickers' is required. No prerequisites or conditions mentioned.

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

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

Annotations declare readOnlyHint=true. Description adds value by specifying OHLCV data format and T-Investments data source. However, lacks details on pagination, volume limits, or timezone handling that would help predict response size.

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?

Single dense sentence with zero waste. Front-loaded verb, parenthetical clarification of OHLCV acronym, and source attribution maximize information density.

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?

Adequate for a read-only data retrieval tool with 100% parameter coverage. Mentions OHLCV to hint at return structure where no output schema exists, but lacks details on array format, timezone normalization, or trading schedule considerations.

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 excellent Russian descriptions for all 4 parameters including ISO 8601 format examples. Description mentions 'по тикеру' (by ticker) but doesn't add syntax guidance beyond what schema provides; baseline 3 appropriate for complete schema coverage.

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?

Clear verb 'Получить' (Get) with specific resource 'исторические свечи (OHLCV)' and source 'Т-Инвестиций'. Implicitly distinguishes from get_last_prices by specifying 'historical' candles, though explicit sibling comparison is absent.

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 versus alternatives like get_last_prices (real-time vs historical), no mention of maximum date ranges, rate limits, or prerequisites for using different intervals.

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

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

Annotations declare readOnlyHint=true, which the description doesn't contradict. Description adds valuable data provenance (Т-Инвестиции source) not in annotations, but omits behavioral details like rate limits, handling of invalid tickers, or forecast types included.

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?

Single sentence, front-loaded with verb. Zero redundancy or boilerplate. Highly efficient for the information conveyed.

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?

Adequate for a simple read-only tool with single parameter and clear domain. Source attribution (T-Investments) provides necessary context. Could be improved by mentioning return data structure or error behavior, but sufficient given schema completeness and annotations.

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% (tickers fully documented as 'Массив тикеров'). Description mentions 'по тикерам' which aligns with schema but doesn't add semantic depth beyond schema (e.g., exchange suffix format, ticker validation). Baseline 3 appropriate for complete schema coverage.

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?

Specifies exact action (получить/get), resource (consensus forecasts), data source (Т-Инвестиции/T-Investments), and scope (by tickers). Clearly distinguishes from siblings like get_last_prices or get_asset_fundamentals by specifying 'analyst consensus' data type.

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?

Implies usage context through 'analyst consensus forecasts' (suggests use for aggregated opinion data vs raw market data), but lacks explicit when-to-use guidance versus sibling data tools like get_asset_fundamentals or get_signals, and no prerequisites mentioned.

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 adds the data source context ('Т-Инвестиций') which is valuable beyond the annotations. While the readOnlyHint annotation confirms this is safe to call, the description doesn't elaborate on behavior like what happens when no dividends exist in the date range, pagination limits, or currency formatting in the response.

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?

Single sentence, front-loaded with action and resource. No redundant words or tautology. Appropriate length for a simple data retrieval tool.

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

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

Given this is a straightforward read operation with three well-documented parameters and readOnly annotations, the description is sufficient. However, no output schema exists and the description doesn't hint at the return structure (dividend amounts per share, dates, currencies), which would be helpful 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?

With 100% schema description coverage (all parameters documented with types, formats, and constraints), the baseline is 3. The description doesn't add additional semantic context beyond the schema (e.g., it doesn't explain that dates default to all-time if omitted), but it doesn't need to given the excellent schema coverage.

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 the specific verb 'Получить' (Get/Obtain) with the clear resource 'дивидендные выплаты' (dividend payments) and source 'Т-Инвестиций' (T-Investments). It effectively distinguishes from siblings like get_bond_coupons (bond payments) and get_candles (price data) by specifying dividends specifically.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., when to use get_asset_fundamentals instead), nor does it mention prerequisites like date range requirements or the fact that from/to dates are optional while tickers are required.

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

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

Annotations declare readOnlyHint=true, confirming the safe read semantics implied by 'Получить' (Get). The description adds temporal context ('текущие' / current) and domain scope ('Т-Инвестициях'), but omits behavior details like cache duration, handling of invalid tickers, or rate limits that would help an agent predict outcomes.

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?

Single sentence, no redundancy, immediately conveys the operation and scope. Efficient structure with the verb 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 simple read tool with single parameter and no output schema, the description adequately covers the domain (T-Investments) and operation. However, absence of return value description or error behavior leaves gaps since no output schema is provided to compensate.

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 'tickers' fully documented as an array of strings (1-100 items). The description mentions 'по тикерам' (by tickers), aligning with the schema but not adding syntax, format, or example details beyond the structured definition. With complete schema coverage, 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?

Specific verb+resource: 'Получить текущие рыночные цены' (Get current market prices). The temporal qualifier 'текущие' distinguishes from historical data siblings (get_candles), and domain 'Т-Инвестициях' scopes the data source. Does not explicitly name alternatives but implicitly differentiates via 'current'.

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 get_order_book (which also contains price data), get_candles (historical), or get_asset_fundamentals. No mention of prerequisites (e.g., market hours) or limitations.

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 aligns with readOnlyHint=true (uses 'Получить'/Get). It adds valuable domain context by defining what 'margin attributes' specifically includes (liquid portfolio, initial margin) and identifies the external system (T-Investments), but doesn't address error handling, rate limits, or data freshness.

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?

Single dense sentence that front-loads the action. The parenthetical specifics (liquid portfolio, initial margin) efficiently clarify the return value. No wasted words, though slightly information-dense.

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?

Appropriately complete for a simple read-only tool with one parameter. Compensates for missing output schema by defining the semantic content of the return value (liquid portfolio, initial margin). Given the low complexity and presence of annotations, no further elaboration is necessary.

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 description coverage, the schema fully documents the accountId parameter. The description doesn't add parameter-specific details beyond what's in the schema, which warrants the baseline score of 3 for high-coverage schemas.

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 action (Получить/Get) and resource (margin attributes), specifying exactly what data is returned (liquid portfolio, initial margin). It distinguishes implicitly from sibling tools like get_portfolio by focusing specifically on margin-specific metrics, though it doesn't explicitly name alternatives.

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

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

Provides prerequisite guidance by noting that accountId can be obtained via get_accounts. However, it lacks explicit guidance on when to use this tool versus similar siblings like get_portfolio or get_positions, and doesn't specify when not to use it.

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

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

Annotations declare readOnlyHint=true, covering the safety profile. The description adds valuable domain context (T-Investments platform specificity) and clarifies the calculation applies to both buying and selling, but omits behavioral details like error conditions (e.g., invalid ticker), caching, or calculation methodology.

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?

Single sentence efficiently conveys purpose without redundancy. Front-loaded with the action verb, zero wasted words, appropriate length for a focused calculation tool.

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

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

Given the tool's focused scope (3 simple parameters, read-only operation, no output schema), the description adequately covers the calculation intent. Lacks only explicit connection to order placement workflow (relevant given post_order sibling exists) and return value details (though no output schema exists to require this).

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

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

Schema description coverage is 100% (all 3 parameters documented). The description does not duplicate parameter details but implies their usage through the calculation context. With full schema coverage, baseline 3 is appropriate as the schema carries the semantic 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?

Description clearly states the tool calculates maximum lot quantities for buy/sell operations, with specific domain context (Т-Инвестиции/T-Investments). Verb ('Рассчитать') and resource ('лоты') are explicit, distinguishing this from sibling retrieval tools like get_orders or get_portfolio.

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 explicit when-to-use or when-not-to-use guidance is provided. While the purpose implies use before trading (likely prior to post_order), the description does not state prerequisites, alternatives, or workflow positioning relative to sibling tools like get_margin_attributes.

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

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

Annotations declare readOnlyHint=true, confirming safe read operation. Description adds domain context ('Т-Инвестициях' / T-Investments) helping identify this as brokerage transaction history, but lacks details on what operation types are returned, result ordering, or time range limits.

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

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

Single sentence of 6 words is appropriately dense and front-loaded with the action and resource. However, extreme brevity sacrifices behavioral details that would help an agent understand result semantics and pagination.

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?

Adequate for a read-only history retrieval tool with well-documented input schema. Missing output semantics (what operations are included) but acceptable given annotations confirm read-only safety and siblings suggest this is transaction history distinct from active orders.

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% with detailed parameter descriptions including cross-references (accountId) and format examples (ISO 8601). The description text itself adds no parameter-specific guidance, warranting the baseline score for well-documented schemas.

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?

Uses specific verb 'Получить' (Get) with resource 'историю операций' (operation history) and scope 'по счёту в Т-Инвестициях' (by account in T-Investments). Clearly distinguishes from sibling tools like get_accounts (lists accounts) and get_portfolio (current positions), though could clarify what 'operations' encompasses (trades, fees, dividends, etc.).

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 no guidance on when to use this tool versus alternatives like get_orders or get_portfolio. No mention of date range requirements, pagination behavior, or that accountId should be obtained from get_accounts (though this appears in parameter schema descriptions, not the main description text).

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, confirming safe read-only access. Description adds valuable context by specifying the data source (T-Investments) and clarifying 'стакан заявок' means 'биржевой стакан' (exchange order book). However, lacks details on error handling for invalid tickers or rate limiting.

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?

Single efficient sentence with zero waste. Front-loaded with the action verb, parenthetical clarification immediately defines the financial instrument type, and source attribution is clear.

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?

Adequate for a simple read-only retrieval tool with two well-documented parameters. However, lacks description of the order book structure (bids/asks) that would be returned, which is relevant given 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 coverage is 100% with clear descriptions for both ticker and depth parameters. Description mentions 'по тикеру' reinforcing the primary parameter, but adds no additional semantic information about the depth parameter or formatting constraints 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?

Uses specific verb 'Получить' (Get) and resource 'стакан заявок' (order book), with scope 'по тикеру' (by ticker) from T-Investments. Implicitly distinguishes from sibling get_orders (user orders vs exchange order book) and get_last_prices (depth vs prices), though lacks explicit sibling contrast.

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 no guidance on when to use this tool versus alternatives like get_last_prices or get_candles, nor does it mention prerequisites such as requiring a valid ticker from T-Investments markets.

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 specifies the 'active' state filter, which is useful behavioral context not present in the tool name. However, with readOnlyHint annotating the safety profile, the description carries a lighter burden—it doesn't elaborate on pagination, rate limits, or what constitutes 'active' beyond the single word.

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, dense Russian sentence with zero filler. It front-loads the action verb immediately followed by the resource type and scope, making every word essential.

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 getter with one required parameter, good annotations (readOnlyHint), and clear scope, the description is nearly complete. It lacks output schema documentation, but given the tool's simplicity and the clarity of 'active orders,' this is acceptable for selection and 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 description coverage for the single accountId parameter, the baseline is 3. The description mentions 'по счёту' (by account) which aligns with the parameter, but doesn't add syntax details, validation rules, or format examples beyond what the schema already provides.

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 ('Получить'/Get) and clearly identifies the resource as 'active exchange orders' (активные биржевые заявки), which distinguishes it from sibling tools like get_stop_orders (stop orders) and get_operations (historical trades). The 'биржевые' (exchange) qualifier specifically distinguishes these from stop 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 provides no explicit guidance on when to use this tool versus alternatives (e.g., get_stop_orders for conditional orders, cancel_order for removing orders) or any prerequisites beyond the implicit need for an account ID. While the schema references get_accounts for the parameter, the description lacks 'when-to-use' 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 declare readOnlyHint=true confirming safe read operation. Description adds domain context (T-Investments) but does not disclose what portfolio data includes (cash, securities, totals) or behavioral details like caching.

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?

Single sentence with action front-loaded. Appropriate length for the tool's complexity, though extremely minimal with no elaboration on scope or contents of the returned portfolio.

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?

Sufficient for a simple 2-parameter read operation with good annotations. Identifies the brokerage system context. Lacks completeness regarding output structure, but no output schema exists to reference.

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 has 100% description coverage with clear Russian descriptions (accountId references get_accounts, tickers explains filtering). Description adds no parameter details, but baseline 3 is appropriate given complete schema documentation.

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?

Uses specific verb 'получить' (get) with resource 'портфель клиента' (client portfolio) and identifies the domain 'Т-Инвестиции' (T-Investments). However, it does not distinguish from sibling tool 'get_positions' which likely returns similar holdings 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?

No explicit guidance on when to use this versus 'get_positions' or other sibling tools. No mention of prerequisites or workflow (though the accountId schema description references get_accounts).

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

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

Annotations declare readOnlyHint=true. Description adds value by specifying the scope of returned data (three specific asset classes) and source system (T-Investments), but omits caching behavior, rate limits, or error conditions.

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?

Single dense sentence efficiently communicates action, resource, content types, and source system. Parenthetical enumeration prevents ambiguity without verbosity.

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?

Adequate for a simple read-only tool with one parameter. Description clarifies return contents but lacks output schema details and sibling differentiation that would be necessary for complex filtering or mutation tools.

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% with accountId fully documented including cross-reference to get_accounts. Main description adds no parameter details, but baseline 3 is appropriate given schema completeness.

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?

Uses specific verb (Получить/Get) and resource (positions), with clear parenthetical enumeration of asset types (money, securities, futures). Falls short of distinguishing from sibling 'get_portfolio' which likely overlaps in functionality.

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 explicit guidance on when to use this versus alternatives like 'get_portfolio'. While the parameter schema references get_accounts as a prerequisite, the main description lacks when-to-use context or exclusion criteria.

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 readOnlyHint already declaring the operation safe, the description adds minimal behavioral context beyond naming the data source ('T-Investments'). It omits what constitutes a signal, pagination behavior, rate limits, or what happens when no signals 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?

Single concise sentence with no redundancy, though front-loaded with the critical verb and resource. However, extreme brevity comes at the cost of explanatory power for a multi-parameter financial tool.

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

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

Absent output schema and zero description of return values leaves critical gaps—agents cannot know what signal data structure, fields (price, confidence, timestamps), or format to expect upon successful 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% with clear Russian-language descriptions for all 5 parameters (tickers, date range, direction, limit). The description does not add parameter semantics, but the schema documentation is complete enough that additional text is unnecessary.

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 specific action (get) and resource (trading signals from T-Investments), but lacks differentiation from sibling tools like get_tech_analysis or get_consensus_forecasts that also provide trading-related 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?

Provides no guidance on when to use this tool versus alternatives (e.g., when to prefer signals over technical analysis or consensus forecasts), nor any prerequisites or filtering recommendations.

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

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

Annotations declare readOnlyHint=true, and the description confirms this is a read operation ('Получить'). It adds valuable scope context by specifying only 'active' stop orders are returned, which implies executed or cancelled orders are excluded. However, it lacks details on rate limits, pagination, error cases (e.g., invalid accountId), or the specific types of stop orders included.

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 zero redundancy. It efficiently conveys the essential function without extraneous words.

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

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

For a read-only tool with a single required parameter and no output schema, the description adequately covers the primary function. The mention of 'active' provides necessary filtering context. It is complete enough given the tool's simplicity, though additional behavioral details would enhance robustness.

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 description coverage and a single parameter, the baseline is appropriate. The description does not add semantic details beyond the schema (e.g., account ID format, where to obtain it), but the schema is self-sufficient for this simple case.

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 action (get/obtain), the resource (active stop orders), the target (by account), and the system (T-Investments). It implicitly distinguishes from the sibling 'get_orders' by specifying 'stop orders', though it could be improved by explicitly contrasting with regular orders or clarifying what constitutes a stop order in this context.

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

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

There is no guidance on when to use this tool versus alternatives (e.g., 'get_orders' for regular orders, 'cancel_stop_order' to manage them). It does not mention prerequisites, conditions for use, or when not to use it.

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

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

Annotations provide readOnlyHint=true. Description adds data source context ('Т-Инвестиций') and enumerates available indicators, but lacks disclosure on rate limits, error handling, or date range 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?

Single sentence with action-fronted structure. Every element earns its place: verb, resource specification, parameter hint (indicators), and source. Zero 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?

With 100% schema coverage and readOnly annotations, the description adequately covers purpose and source. No output schema exists, but for a standard data retrieval tool, the description provides sufficient context.

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

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

Schema coverage is 100% with complete parameter documentation. Description reinforces the indicator options by listing them explicitly, but does not add semantic meaning beyond what the schema already provides.

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

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

Description uses specific verb 'Получить' (Get) with clear resource 'технический анализ' and lists specific indicator types (BB, EMA, RSI, MACD, SMA), distinguishing it from generic price data tools like 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?

No explicit guidance on when to use this tool versus alternatives (e.g., get_candles for raw price data) or prerequisites for the ticker parameter.

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

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

Adds data source attribution ('из Т-Инвестиций') beyond the readOnlyHint annotation, but omits what the schedule includes (trading hours, holidays, sessions) and lacks return format details.

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?

Single sentence, six words, front-loaded with action verb. Efficient structure but undersized given tool complexity and absence of output schema documentation.

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?

Minimal viable coverage for a read-only endpoint. Critical gaps regarding response structure (what defines a trading schedule) and differentiation from related trading status tools, though schema compensates for input requirements.

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 has 100% coverage with clear ISO 8601 documentation. Description adds no parameter semantics (default values, exchange code specifics), warranting baseline score.

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?

Clear verb ('получить'/get) and resource ('расписание торгов'/trading schedule from T-Investments), but fails to distinguish from sibling get_trading_status which returns current market state versus this tool's historical/future timetable 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?

No when-to-use guidance, prerequisites (required date range), or differentiation from similar market data tools like get_trading_status or get_candles.

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 'readOnlyHint: true' annotation already establishes this is a safe read operation. The description adds value by specifying the data source ('Т-Инвестиций'), but lacks details about what trading status values mean (e.g., 'normal_trading', 'auction', 'suspended') or caching behavior. With annotations covering safety, this is minimally sufficient.

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?

Description is a single efficient sentence front-loaded with the core action. While appropriately brief for a simple read operation, it borders on underspecified—one additional sentence explaining the status semantics would improve utility without sacrificing conciseness.

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 this is a single-parameter read tool with safety annotations, the description adequately covers the basics. However, without an output schema, the description should ideally clarify what constitutes 'trading status' (enumeration values, meaning of different states) to prepare the agent 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?

Input schema has 100% description coverage with the 'tickers' parameter documented as 'Массив тикеров'. The tool description does not add examples, format specifications (e.g., 'TCSG' vs 'TCSG.MM'), or explain the 1-50 item limit. At 100% schema coverage, baseline score 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 retrieves 'trading status' (статус торгов) by ticker from T-Investments, providing specific verb and resource. However, it fails to differentiate from the sibling tool 'get_trading_schedules'—users cannot determine whether this returns current market state (e.g., active/suspended) versus calendar schedule 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?

The description provides no guidance on when to use this tool versus alternatives like 'get_trading_schedules' or 'get_last_prices'. There is no mention of prerequisites, rate limits, or specific scenarios where trading status is needed versus other market data tools.

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

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

Annotations declare readOnlyHint=true. Description adds valuable behavioral context beyond safety profile by specifying exactly what profile attributes are returned (tariff, qualified investor status), helping agent understand data scope without output schema.

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

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

Single front-loaded sentence with parenthetical precision. Zero redundancy. Every word earns its place: action verb, resource, domain, and specific field enumeration.

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 0-param read-only endpoint, description adequately covers purpose and return data scope (tariff, qual status). Lacks explicit mention of authentication requirement or response structure, but sufficient given tool simplicity.

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 per input schema, triggering baseline score of 4. No parameter description needed or expected.

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?

Specific verb 'Получить' (Get) with clear resource 'информацию о профиле пользователя' (user profile information). Specifies domain (T-Investments) and distinguishes from trading-oriented siblings like get_orders or get_portfolio by focusing on user metadata (tariff, qualified investor status).

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 explicit when-to-use or alternative comparison (e.g., vs get_accounts), but parenthetical specification of returned fields (tariff, qual status) provides implied usage context for when agent needs user configuration 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?

The annotations already declare readOnlyHint=true indicating a safe read operation, but the description adds no behavioral context beyond this. It does not disclose what specific withdrawal limits are returned (daily, per-transaction, currency-specific), error conditions for invalid accounts, or whether the limits are real-time or cached.

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 single-sentence description is appropriately front-loaded with no redundant words. However, it is minimally informative rather than richly concise, lacking supporting details that could help agent reasoning without sacrificing clarity.

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

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

For a single-parameter read-only tool without output schema, the description adequately identifies the core function but remains minimal. It does not hint at the return data structure (whether limits are amounts, time windows, or arrays) which would be helpful given the absence of an output 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?

With 100% schema description coverage, the parameter accountId is fully documented in the schema itself. The description mentions 'со счёта' (from account) implicitly referencing the parameter but adds no semantic clarification beyond what the schema already provides. Baseline 3 is appropriate when schema carries full 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 uses a specific verb (получить/get) and resource (лимиты вывода средств/withdrawal limits) clearly identifying this as a retrieval operation for account withdrawal constraints. It effectively distinguishes from sibling tools like get_portfolio or get_accounts by specifying the exact financial data being accessed.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites (though the schema notes accountId can be obtained via get_accounts). There is no indication of when NOT to use it or how it relates to withdrawal execution flows.

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?

While annotations declare destructiveHint=true, the description adds crucial behavioral context: the two-phase execution model (preview mode vs actual execution), what happens without confirm (returns preview only), and the confirmation requirement. This safety-critical workflow detail is valuable behavioral disclosure beyond the structured annotations.

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

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

Every element earns its place: the main clause defines the action/resource, while the parenthetical efficiently packs the critical confirmation workflow instruction. No redundancy or tautology. The Russian phrasing is appropriately dense for a financial API operation.

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 100% schema coverage and presence of destructive annotations, the description adequately covers the critical confirmation complexity unique to this trading tool. It explains the preview-vs-execution behavior well. Minor gap: no mention of output structure (though none defined) or specific error conditions/trading restrictions that might occur.

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 description coverage, the baseline is 3. The description adds significant semantic value specifically for the 'confirm' parameter, explaining the two-step execution workflow (preview then confirm) that isn't fully captured by the schema's brief description. However, it adds minimal context for other well-documented parameters like ticker or direction.

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 action verb ('Выставить'/'Place') and clearly identifies the resource (exchange order/'биржевую заявку') and scope (T-Investments). It effectively distinguishes from sibling tools like cancel_order and get_orders by specifying this creates new orders, and implicitly from post_stop_order by specifying 'exchange order' (биржевую заявка) versus stop 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 provides explicit, critical usage context in the parenthetical: the confirmation workflow requires calling first without confirm, then with confirm:true. This is a clear 'when-to-use' pattern for the confirm parameter states. However, it lacks explicit comparison to sibling alternatives (e.g., distinguishing from post_stop_order) or prerequisite mentions (though schema references get_accounts).

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 destructiveHint=true and readOnlyHint=false. The description adds valuable safety context that explicit confirmation is required, which helps the agent understand the guarded nature of the operation. Does not elaborate on conditional execution behavior or financial risks.

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?

Extremely efficient single sentence with parenthetical for the critical constraint. No extraneous words, front-loaded action verb, appropriately scoped for a trading API.

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?

Covers the essential safety prerequisite (confirm flag) for a destructive financial operation. However, given the complexity of stop orders (conditional triggers, stop-loss vs take-profit mechanics), the description could benefit from mentioning that this creates a deferred/conditional order rather than immediate execution.

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 has 100% description coverage, establishing baseline 3. The description emphasizes the confirm parameter requirement, but does not add semantic detail beyond what the schema already provides for the 10 parameters.

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

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

Clearly states the specific action (выставить/place) and resource (стоп-заявку/stop order) and domain (Т-Инвестиции). Distinguishes from sibling 'post_order' by specifying 'stop order' vs presumably regular 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?

Specifies the critical invocation constraint that confirm: true is required for execution. However, lacks explicit guidance on when to choose this tool over 'post_order' (stop orders vs immediate orders) or primer on stop-loss vs take-profit selection.

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