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

Even with readOnlyHint/openWorldHint annotations, the description adds substantial context about output ordering (exact-match first, then shares/funds/bonds), the 'note' field behavior on truncation, and the tradable_only fallback, all of which go beyond what annotations 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 structure front-loads the purpose and return shape before the Args list; some sentences are dense but each earns its place. Slightly verbose in the return-value paragraph, which an output schema would have covered, but the tool has none.

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

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

For a 4-param search tool with no output schema, the description covers return structure, field list, ordering, truncation notes and all parameters, giving the agent everything needed to invoke and interpret 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?

Although schema description coverage is 0%, the description fully compensates: it documents each of the four parameters (query formats, full enum of instrument_kind, tradable_only semantics including delisted boards, and the 1-200 limit range) in detail beyond what the schema 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 clearly states a specific verb (Search) and resource (instruments) with multiple accepted query identifiers (ticker, name, ISIN, FIGI). It partially distinguishes itself from siblings like get_instrument_by/get_share_by by being a broad text search rather than a single-identifier lookup, though it doesn't explicitly name those alternatives.

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

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

The description gives concrete guidance on when to use this tool ('narrow the search with instrument_kind', the many-listings caveat, and the non-tradable fallback behavior), which helps an agent choose this over a precise lookup. It doesn't explicitly name alternative tools or when-not-to-use conditions.

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 the safety profile (readOnlyHint=true, openWorldHint=true), so the description adds value by decoding domain semantics: type enums and the 1970-01-01 closedDate sentinel. It doesn't mention rate limits, auth scope, or ordering, but the added interpretation of returned fields is genuinely useful 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?

Front-loaded with the core purpose in the first line, followed by the ID-dependency note and a compact enum glossary. Every element earns its place; only the trailing sentinel note could arguably be folded into the type list.

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

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

With no parameters and no output schema, the description carries the burden of explaining the return, and it does reasonably well: account IDs, types, statuses, and the closedDate sentinel. It stops short of describing the full object shape, but an agent has enough to call and consume 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to document or compensate for, and it introduces no parameter confusion.

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: listing all user investment accounts with types and statuses. It positions itself as the prerequisite lookup ('Returns account IDs needed for other operations'), which implicitly distinguishes it from siblings like get_portfolio or get_positions, though it never names an alternative explicitly.

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

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

The sentence 'Returns account IDs needed for other operations (portfolio, positions, operations)' clearly signals when to call this first, giving the agent actionable context. No explicit when-not-to-use condition or named alternative is provided, 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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuinely behavioral detail beyond the schema: the default window is the last 30 days through now, and to_date is inclusive. It says nothing about return shape or pagination, so the added value is modest.

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

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

One front-loaded sentence stating purpose, followed by a tight arg list. No filler, no restatement of the tool name, and every line carries information the schema lacks.

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 three well-documented parameters, the definition is nearly complete. The only gap is that there is no output schema and the description does not say what the history looks like (a dated series of accrued-interest values), which an agent might reasonably want to know.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it does: instrument_id accepts ticker/FIGI/ISIN/UID, both dates are YYYY-MM-DD, defaults are 30 days ago and now, and to_date is inclusive. That is more meaning than the bare-name schema properties provide.

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 accrued coupon interest (NKD) history for a bond.' The scoping to accrued interest (NKD) history cleanly separates it from neighboring bond tools such as get_bond_coupons and get_bond_events without needing to name them.

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

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

Usage is implied by the documented arguments (per-bond, date-windowed history) and the defaults make the typical call obvious, but there is no explicit when-to-use statement, no exclusions, and no pointer to an alternative tool for coupon schedules or prices.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses the asset-UID vs instrument-UID keying and conversion, that each result item carries its assetUid, that result order matches request order, and the critical semantics that a value of 0 means 'no figure available' rather than a true zero. These are exactly the behaviors an agent could misread from the data alone.

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

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

Front-loaded with purpose, then behavioral caveats, then the argument – a sensible order where nearly every sentence earns its place. Minor redundancy in the 'Args:' block restating the parameter name already in the schema keeps it from a 5.

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

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

With no output schema, the description correctly compensates by explaining result shape (items carry assetUid, order mirrors the request) and value semantics (0 = missing figure). For a single-parameter read tool, nothing needed to invoke or interpret it correctly is missing.

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

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

Schema description coverage is 0%, so the description carries the full burden and does: it specifies comma-separated format and the accepted identifier types (tickers, FIGIs, ISINs, instrument UIDs, asset UIDs). This fully compensates for the bare schema.

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

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

States a specific verb (Get) and resource (fundamental financial data) and enumerates the exact metrics returned (P/E, P/BV, EPS, ROE, revenue, market cap). The enumerated metric set makes it unmistakable against siblings like get_stock_snapshot, get_consensus_forecasts, and get_asset_reports, so an agent can select it without opening either schema.

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

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

Provides a clear negative constraint – 'Bonds and funds have no fundamentals' – which tells the agent when this call is fruitless, plus the UID-conversion caveat that governs correct use. It stops short of naming an alternative sibling for those asset classes or for forecast-style data, so full explicit routing is absent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the date-window scope and defaults (now to one year ahead) but says nothing about result ordering, pagination, or what happens when the issuer has no reports. With annotations carrying the load, a 3 is appropriate.

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

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

Front-loaded one-sentence purpose followed by a compact Args block with no filler. Efficient, though the Args block uses a code-doc style that is slightly redundant with the schema field list.

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 three-parameter read tool with no output schema, the description covers purpose, parameter formats and defaults, and the nature of the returned data (earnings report dates). Only fine-grained response details, like ordering or absence handling, are unstated.

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

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

Schema description coverage is 0%, so the description must carry all parameter meaning, and it does: instrument_id accepts ticker, FIGI, ISIN or UID; from_date and to_date are documented with YYYY-MM-DD format, inclusivity, and defaults. This fully compensates for the bare schema.

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

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

States a specific verb and resource: 'Get upcoming and past earnings report dates for an instrument's issuer.' An agent can distinguish this from sibling data tools like get_dividends or get_asset_fundamentals. It doesn't explicitly name an alternative, so it falls just short of 5.

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

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

There is no explicit when-to-use guidance and no mention of alternatives among the many sibling quote/asset tools. Usage is only implied by the tool name and purpose sentence.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description adds one genuine operational nuance — that the id format (ticker/FIGI/ISIN/UID) is auto-detected — but says nothing about pagination, error behavior, or how multiple listings are resolved.

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 returned-field list is front-loaded in sentence one, followed by a compact Args block for the three parameters. No filler or repetition; it could be marginally tighter but every 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?

With no output schema, the description usefully enumerates the returned fields, and it covers all input parameters at 0% schema coverage. Gaps remain around listing disambiguation, error cases, and the behavior of non-ticker id types, but nothing essential to invoking the tool is missing.

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

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

Schema description coverage is 0%, so the description must carry the burden, and it does document all three params: id accepts ticker/FIGI/ISIN/UID, id_type is only needed with INSTRUMENT_ID_TYPE_TICKER, and class_code selects a board (e.g. "TQBR"). It slightly under-describes the other three enum values and is mildly in tension with the FIGI default, but overall it compensates well for 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 opens with a specific verb+resource ('Get detailed bond info') and enumerates the returned fields (maturity date, coupon rate, nominal, ACI, issue size, risk level), so an agent knows exactly what this tool produces. It does not explicitly differentiate itself from nearby siblings like get_bond_coupons, get_bond_events, or get_instrument_by, which keeps it at 4 rather than 5.

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

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

Usage is only implied: the tool fetches a bond's detail profile, so an agent infers it should be called when bond detail is needed. There is no statement of when to prefer this over get_instrument_by, find_instrument, list_bonds, or the more specialized get_bond_coupons/get_bond_events, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds default date-range behavior and inclusivity, plus a deprecation warning, but omits things like pagination, result limits, or auth requirements.

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

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

One front-loaded sentence states what is returned, followed by a compact args block with no filler. Every line earns its place, and nothing is redundant given the empty schema descriptions.

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

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

For a 4-param tool with zero schema coverage and no output schema, the description supplies formats, defaults, and deprecation guidance needed to invoke it correctly, and it sketches the return shape. Only minor gaps remain (no pagination/limit expectations).

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

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

Schema description coverage is 0%, so the description carries the full burden — and it does: it documents all four params including the accepted instrument_id formats (ticker, FIGI, ISIN, UID), date format YYYY-MM-DD, inclusive to_date, defaults, and the deprecated figi. This fully compensates for the schema gap.

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

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

The description names a specific verb and resource — 'Get bond coupon payment schedule' — and enumerates the returned content (dates, amounts, coupon periods). This is clearly distinguishable from siblings like get_bond_events, though it doesn't explicitly reference them.

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 choose this over get_bond_by, get_bond_events, or get_accrued_interests. The only directional hint is internal (use instrument_id instead of the deprecated figi), which is a parameter note rather than tool-selection 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 and openWorldHint, so safety is covered; the description adds real behavioral context beyond them: the default date window, that zero/empty event fields are omitted, and that amortization arrives as MTY events with operationType 'OA'/'OM'. It does not discuss rate limits or result size, but the added disclosure is substantial.

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

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

Front-loaded with the core purpose, then progressively detailed behavioral notes and an Args block. Almost every sentence earns its place, though the OA/OM amortization detail is niche and the prose is 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?

With no output schema, the description compensates by describing returned event fields (couponInterestRate, operationType, value in percent of nominal) and the omission rule for empty fields. Nothing essential to correct invocation appears missing.

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

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

Schema description coverage is 0%, so the description carries the full burden and does so: instrument_id accepted formats (ticker/FIGI/ISIN/UID), each type enum value decoded, date format YYYY-MM-DD, inclusive to_date, and the API-chosen defaults. This exceeds what the bare schema conveys.

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

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

States a specific verb+resource ('Get bond events') and enumerates the event classes (coupon, offer/call, maturity, conversion). It also explicitly distinguishes itself from the sibling get_bond_by by noting the latter lacks couponInterestRate. An agent can route correctly without opening a schema.

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

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

Gives clear context: without dates the API returns only a window around today, so a distant maturity or offer requires an explicit range. It names get_bond_by for contrast, but does not mention the sibling get_bond_coupons or when that would be preferable, so the when-not guidance is incomplete.

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

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

Annotations only cover read-only and open-world; the description carries deep behavioral context beyond that: the volume-in-lots convention, the buy/sell split columns being conditionally present, the last_candle_complete flag meaning the close is a live price, bond pricing in percent of nominal, split/consolidation recalculation behavior, and the per-interval API span limits plus payload-size warnings. This is exactly the kind of non-obvious operational 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 response shape is front-loaded before the behavioral caveats, and nearly every sentence carries load — the split-adjustment and bond-pricing notes are non-obvious and worth their space. The trailing interval enumeration is somewhat redundant against the schema enum, a minor bloat in an otherwise dense, well-ordered description.

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

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

There is no output schema, so the description must explain returns — and it does, spelling out the columns list, row ordering, and the optional volumeBuy/volumeSell fields. Combined with the covered stability flags and API limits, an agent has everything needed to call this correctly and interpret the 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?

With 0% schema description coverage, the description has to carry the parameters and largely does: instrument_id accepts ticker/FIGI/ISIN/UID, from_date defaults to 30 days ago, to_date is inclusive and defaults to now, and interval is explained with additional acceptable values. It loses a point because the interval value list substantially repeats the schema enum rather than adding new meaning beyond 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?

Opens with a specific verb and resource: 'Get historical candles (OHLCV) for an instrument.' That is unambiguous and distinct from siblings like get_close_prices or get_last_prices in substance. However, it never explicitly names or contrasts those adjacent price-retrieval siblings, so the agent must infer the boundary itself.

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

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

Usage context is implied through the API span limits and the advice to 'ask for weekly or monthly candles instead' when data volume is too large, which is genuine when-to-do-X guidance. But it never states when to prefer this tool over get_close_prices, get_last_prices, or get_stock_snapshot, nor any preconditions such as required instrument resolution.

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 only cover readOnlyHint and openWorldHint, so the description adds real value: one record per identifier in request order, the exact error shape substitut ed for unmatched identifiers, and the non-obvious fact that bond prices are in percent of nominal rather than money. Missing only details such as how non-trading days are handled.

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 behavior is front-loaded in the first sentence, followed by the output-contract detail and then the argument format. No sentence is filler and nothing important is buried.

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

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

With no output schema, the description steps in to describe the return structure and error records, and it documents the single required parameter. Only minor gaps remain, such as behavior on non-trading days or on an empty instrument list.

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

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

Schema description coverage is 0%, so the description carries the full burden and does so well by listing the four accepted identifier forms (tickers, FIGIs, ISINs, UIDs) and the comma-separated format. It does not, however, show any example value or say whether mixed identifier types are permitted.

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

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

States a specific verb and resource with scope: 'previous trading session close prices for instruments'. That is meaningfully narrower than siblings like get_last_prices or get_candles, though it never names those alternatives to sharpen the distinction.

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

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

The description explains what the tool returns but never says when to use it over get_last_prices, get_candles, or get_stock_snapshot, nor does it state any prerequisites or exclusions. Usage must be inferred from the resource name alone.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the key quirk that there is no server-side instrument filter, that the tool internally pages through the whole universe, and that it returns {"error": ...} when nothing matches. It also flags page_number as deprecated and ignored, which is exactly the kind of behavioral detail annotations cannot convey.

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

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

Front-loads purpose, then the mechanism paragraph that justifies the unusual paging design, then a compact Args block. Every sentence adds information an agent needs; nothing is padding.

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

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

With no output schema, the description still names the returned payload (target price, recommendation, analyst count) and the failure shape, and it explains pagination and the internal scan limit. Nothing material is missing for correct invocation or result interpretation.

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

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

Schema description coverage is 0%, so the description carries the full burden and does: instrument_id accepts ticker/FIGI/ISIN/instrument UID/asset UID, page_limit defaults to 100 with non-positive meaning 100, max_pages defaults to 50 and must be at least 1, and page_number is a deprecated no-op. Every parameter's type and edge-case behavior is explained.

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

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

States a specific verb and resource (analyst consensus forecast for one instrument) and enumerates the returned fields: target price, recommendation, analyst count. That is enough to distinguish it from generic sibling tools, though it never explicitly contrasts itself with the adjacent get_forecast_by, leaving some overlap 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?

Usage is implied rather than stated: supply an instrument identifier and receive the matching consensus item. There is no explicit when-to-use/when-not guidance and no pointer to get_forecast_by or the other forecast/instrument lookups as alternatives, so an agent must infer routing from the descriptions of the 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the useful fact that the id format is auto-detected, but says nothing about return shape, partial results, or edge cases (unknown ticker, ambiguous listings). With annotations present the bar is lower, but this adds little behavioral context.

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

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

The prose is terse and front-loaded, but it is formatted as a Python docstring with an Args block that duplicates the schema structure. No wasted filler, though the structure is not optimized for an LLM reader.

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 lookup with 3 parameters and no output schema, the description covers identifier formats and the disambiguation hole adequately. It is missing any hint about the response content or behavior on multiple matching listings, which an agent would want.

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

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

Schema description coverage is 0%, so the description carries the burden for all three parameters. It documents id (multi-format, auto-detected), id_type (conditional on class_code/ticker), and class_code (board like "TQBR"). This is helpful, but the id_type enum values themselves are only in the schema, and the conditional relationship between id_type and class_code is stated imprecisely.

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

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

States a specific verb+resource: retrieve detailed currency instrument info by an identifier. It's distinguishable from list_currencies (list all) and from get_instrument_by (generic instrument), so the agent can route correctly. Not a full 5 because it doesn't explicitly name how it differs from its nearest sibling get_instrument_by.

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?

Some implied guidance is embedded in the parameter notes (id_type only needed with ticker, class_code to disambiguate multiple listings), but there is no explicit when-to-use-this-vs-alternatives statement. No routing away from get_instrument_by, find_instrument, or list_currencies.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the exact return fields (record date, payment date, dividend per share, yield, currency) and the default date window applied when the caller omits dates.

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

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

Front-loaded with purpose, then returns, then args — a sensible order with no filler. Slightly redundant in that the returns line and the args block use different formats, but every sentence carries information.

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

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

With no output schema, the description correctly compensates by enumerating return fields, and it documents all three parameters plus their defaults. For a simple read-only lookup this is close to complete; pagination or behavior for instruments without dividends is unaddressed but minor.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it does well: it explains that instrument_id accepts ticker/FIGI/ISIN/UID, gives the YYYY-MM-DD format for both dates, marks to_date as inclusive, and supplies both defaults. Only the required-vs-optional status is left to the schema.

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

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

States a specific verb (Get) and resource (dividend payment history and upcoming dividends) scoped to an instrument. The resource is clearly distinct from sibling tools like get_bond_coupons or get_asset_fundamentals, so an agent can distinguish it at a glance.

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 never says when to use this tool versus alternatives, nor does it state prerequisites or exclusions. The default date windows ('2 years ago' to '1 year ahead') imply a historical-plus-forward-looking use case, but this is inference rather than guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the returned field set, which is useful since no output schema exists, but says nothing about failure behavior for an unknown id, rate limits, or whether funds other than ETFs are covered.

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

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

Front-loaded one-line purpose followed by a short Args block; no filler sentences. It is slightly longer than strictly necessary because the schema already carries the enum and defaults, but the added param explanation earns its place given 0% schema coverage.

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

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

For a read-only single-instrument lookup with no output schema, the description covers purpose, return fields, and all three parameters adequately. The remaining gaps (not-found behavior, ETF vs fund scope, identifier precedence conflicts) are modest.

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

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

Schema description coverage is 0%, so the description carries the burden and largely meets it: it explains that id accepts ticker/FIGI/ISIN/UID with automatic recognition, that id_type is only needed for ticker lookups, and that class_code selects a board (e.g. "TQBR"). The id_type sentence is awkwardly worded ('Only needed with class_code: INSTRUMENT_ID_TYPE_TICKER'), which slightly muddies the actual constraint, but all three params get meaningful context.

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 detailed ETF/fund info') and enumerates the fields returned (management fee, tracking index, rebalance frequency). It is distinguishable from get_share_by/get_bond_by by resource, though it does not explicitly contrast itself with list_etfs or get_instrument_by.

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

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

Usage is implied: the tool is for looking up a single ETF by an identifier, and the id/id_type/class_code notes hint at how to disambiguate a listing. However, there is no explicit when-to-use-this-vs-alternatives guidance, e.g. vs list_etfs for enumeration or find_instrument for search.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. Beyond that, the description adds essentially nothing the name doesn't already convey: no pagination behavior, no indication of ordering, no statement about whose favorites (authenticated user) or what a favorite contains.

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

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

A single efficient sentence with no filler and the key nouns front-loaded. It is appropriately sized, though it is arguably under-specified rather than maximally tight.

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 no-parameter, read-only list tool with no output schema, the description is minimally adequate: it conveys what is returned. It omits any indication of result shape (e.g., identifiers vs. full instrument objects) or ordering, which an agent might reasonably want before calling.

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

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

The tool takes zero parameters, so there are no parameter semantics to document. This is the baseline case where the description cannot and need not add parameter detail.

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 list of user's favorite instruments.' An agent immediately knows it returns a user-scoped collection of favorited instruments. It does not differentiate itself from sibling list-style tools like list_shares or get_positions, but the purpose itself is unambiguous.

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

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

There is no guidance on when to use this tool versus the many sibling retrieval tools, nor any mention of prerequisites, scope, or alternatives. The agent must infer that this returns the caller's favorites rather than any filtered instrument list.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower. The description still adds value by enumerating the returned fields (analyst name, target price, recommendation, date), which is genuinely useful given there is no 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?

Front-loaded with the purpose, then return value, then args — a sensible ordering for a single-param tool. The Args block is slightly redundant with the schema but not wasteful at this size.

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

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

For a one-parameter read-only lookup, the description covers purpose, accepted identifier formats, and return shape. The main omission is routing relative to the sibling forecast tool, but otherwise an agent has what it needs to call this correctly.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does: it specifies that instrument_id accepts a ticker, FIGI, ISIN, or UID. That accepted-format detail goes meaningfully beyond the bare 'Instrument Id' title in the schema.

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

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

States a specific verb and resource: 'Get investment house price forecasts for an instrument.' An agent can tell it retrieves analyst forecast data, though it does not distinguish itself from the sibling get_consensus_forecasts, which sounds closely related.

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, when-not-to-use, or alternatives are mentioned. The presence of get_consensus_forecasts as a sibling makes the missing differentiation a real gap, since an agent cannot tell which forecast tool to pick.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered and the bar is lower. The description adds the shape of the returned info and notes that id format is auto-recognised, but says nothing about failure modes when a contract is not found or how multiple listings resolve.

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 a single summary sentence followed by a compact, well-structured Args block where each entry earns its place. No filler or repetition.

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

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

With no output schema and zero schema description coverage, the description steps in to name the key returned fields and documents all three parameters. It is adequately complete for a read-only lookup, missing only error/multi-listing behavior.

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

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

Schema description coverage is 0%, so the description carries the full burden and does so well: id is explained as accepting ticker/FIGI/ISIN/UID with automatic detection, id_type is scoped to the ticker case, and class_code is explained as the board selecting one listing. This meaningfully compensates for the schema gap, though the phrasing of the id_type/class_code dependency is slightly muddled.

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

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

States a specific verb+resource ('Get detailed futures contract info') and names the returned fields (expiration, basic asset, margin requirements). This clearly distinguishes it from the bond/share/ETF lookups among its siblings, though it never explicitly contrasts with list_futures or get_instrument_by.

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 tool-level when-to-use guidance: nothing tells the agent when to reach for get_future_by versus get_instrument_by, find_instrument, or list_futures. The only usage hints are parameter-level (id_type only needed with a ticker class_code), which is not the same as routing guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real value beyond that by enumerating the returned fields and explaining that the identifier kind is auto-detected, which tells the agent what it will receive. It omits any note on lookup failures or unknown-identifier behavior.

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

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

Front-loaded with purpose, then a Returns block, then an Args block, so an agent can scan it quickly. Every section earns its place, though the phrasing 'Only needed with class_code: INSTRUMENT_ID_TYPE_TICKER' is muddled and slightly hard to parse.

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

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

With no output schema, enumerating the return fields is exactly the right compensation, and the identifier-handling behavior is covered. The main gap is the absence of guidance distinguishing this from its many sibling lookup 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 0%, so the description carries the full parameter burden and largely succeeds: it explains that `id` accepts ticker/FIGI/ISIN/UID with automatic recognition, and clarifies the roles of `id_type` and `class_code`. It does not mention the INSTRUMENT_ID_TYPE_POSITION_UID enum value and the `id_type` sentence is slightly garbled.

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

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

States a specific verb+resource ('Get detailed instrument info by its identifier') and enumerates the returned fields, so the agent knows it is a general instrument lookup rather than a market-data or portfolio tool. It does not explicitly distinguish itself from the sibling find_instrument or the type-specific get_bond_by/get_share_by/get_etf_by, leaving the generic-vs-specific choice to inference.

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 conditional guidance for two parameters ('Only needed with...', 'to pick one listing out of several'), which implies usage context. However, it never states when to call this generic tool versus find_instrument or the per-asset-type siblings, so the routing decision is only implied.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds meaningful behavior beyond them: one record per requested identifier in request order, each carrying ticker and classCode, an inline error object for unmatched identifiers, and the bond pricing convention (percent of nominal, not money). These are non-obvious runtime traits that an agent could not derive from 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?

Front-loaded with the core purpose, then structured expansion for return shape, error handling, and the domain-specific bond caveat; the Args block adds the parameter detail. Every sentence carries information, with only minor redundancy in restating the argument 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?

With no output schema, the description takes on return-shape disclosure and does it: record-per-identifier, ordering, field contents, and error placeholders. The main residual gap is pricing semantics for non-bond instruments (which price is used, staleness/currency), plus no note on batching limits.

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

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

Schema description coverage is 0% and the schema only labels the field 'Instrument Ids', so the description carries the burden and does so well by enumerating the acceptable identifier forms (tickers, FIGIs, ISINs, UIDs) and the comma-separated format. It stops short of delimiter/escaping edge cases, but it substantially compensates for 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?

States a specific verb and resource ('Get last trade prices') plus the scope ('for one or more instruments'), which is clear enough for an agent to distinguish from list/find siblings. However, it never contrasts itself with the obviously adjacent sibling get_close_prices, so sibling differentiation is left to inference.

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

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

There is no when-to-use, when-not-to-use, or alternative-tool guidance at all. The closest sibling, get_close_prices, is never mentioned, and no condition is given for choosing last trade price versus close price or candle 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context by naming the returned attributes, but says nothing about permissions, rate limits, or formatting of the margin values. With annotations carrying the safety burden, this is a modest but real addition.

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

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

The description is compact and front-loads the purpose before the args list. The single-sentence summary plus a brief Args block contains no filler, though the Args boilerplate is slightly redundant for a one-parameter 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?

There is no output schema, but the description compensates by enumerating the key returned fields, and annotations cover the read-only/open-world nature. For a 1-parameter read tool this is nearly complete, missing only minor operational details.

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

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

Schema description coverage is 0%, so the description must compensate, and it does partially: it identifies the single parameter as an Account ID and points to get_accounts as its source. That is adequate for a 1-parameter tool but adds no format or validation detail.

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?

Names a specific verb ('Get') and a precise resource ('margin trading attributes for an account'), then enumerates the returned data (liquid portfolio value, starting/minimal margin, funds sufficiency). This is distinguishable from generic siblings like get_portfolio or get_positions by its margin-specific scope, though it never explicitly contrasts with them.

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

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

Usage is implied by the narrow resource ('margin trading attributes'), and it helpfully tells the agent where account_id comes from ('get from get_accounts'). However it gives no explicit when-to-use or when-to-prefer-alternatives guidance relative to portfolio/position 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 only give readOnlyHint and openWorldHint, and the description goes well beyond them: no paging, a hard 1000-operation truncation surfaced via a leading "note", zero/empty fields omitted, canceled orders included in results, prices unadjusted for splits, and quantity vs quantityRest semantics. This is unusually rich behavioral disclosure for a read tool.

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

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

Front-loads the core purpose, then the return shape, then caveats, then the args list — a logical order with no filler sentences. It is on the long side and a few clauses (e.g. the split-adjustment aside) could be tightened, but almost every sentence carries decision-relevant information.

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

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

For a 5-param tool with no output schema and no meaningful parameter documentation in the schema, the description supplies everything needed: return field list, truncation behavior, filter semantics, and the paging escape hatch to the sibling tool. 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 description coverage is 0%, so the description must carry the full burden, and it does: every one of the 5 params is documented with format (YYYY-MM-DD), defaults (14 days ago / now), inclusive semantics for to_date, the full enum for state, and the non-obvious fact that figi also accepts ticker, ISIN or UID.

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 list of operations (transactions) for an account within a date range") and enumerates exactly what kinds of records come back. An agent can distinguish it from the sibling get_operations_by_cursor purely from 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?

Explicitly names the alternative (get_operations_by_cursor) and the condition that selects it (paging needed / range longer than a week or two). It also warns to pass state="EXECUTED" before summing money and quantities, and that the 1000-operation cap silently drops older data — all actionable when-to-use guidance.

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

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

Annotations only declare readOnly/openWorld, but the description discloses rich behavior: zero/empty fields are omitted, duplicate operations under one id are merged within a page, canceled orders carry positive payment while executed are negative, prices are not split-adjusted, and partially executed orders split quantity/quantityDone/quantityRest. This is far beyond what the annotations 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?

Front-loaded with the pagination contract, then Args, then return-value semantics. It is long and dense, but nearly every sentence adds distinct value; the volume is justified by the missing output schema and the complex domain, with only minor 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?

With no output schema, the description fully specifies return fields (id, type, state, date, payment, price, commission, yield, quantities, childOperations, tradesInfo, etc.), pagination contract, and operation-type enumeration. An agent has everything needed to call and interpret it correctly.

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

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

Schema coverage is 0%, so the description carries the full burden and does so: it documents every Arg including formats (YYYY-MM-DD), defaults (1 year ago, 50, now), ranges (1-1000), the ~28,000-char payload note, filter semantics for instrument_id/operation_types/state, and the error case for unknown types.

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 operations) and identifies the distinguishing trait (cursor-based pagination, better for large histories). It clearly differentiates from get_operations by pagination style, though it never names the sibling explicitly.

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

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

'Better for large histories' gives a clear selection condition against the sibling get_operations, and it adds actionable usage notes (pass state="EXECUTED" before summing money). It stops short of explicitly naming the alternative or stating when-not-to-use, so it falls under 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 readOnlyHint=true and openWorldHint=true, so the safety and world-access profile is covered without the description. The description adds a useful domain-specific note ('A bond's prices are in percent of its nominal, not in money'), which is genuine behavioral context. However, it does not cover return structure, pagination, or rate limits. With annotations handling the core behavioral flags, this is adequate at 3.

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 purpose, followed by a key domain note and a clean parameter block. Every sentence adds information and there is no redundancy.

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

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

For a read-only tool with two parameters and no output schema, the description covers purpose, both parameter meanings, and a domain-specific pricing caveat. Smaller gaps remain, such as the response shape and whether the order book is live or snapshot, but the essential information is present.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it documents both parameters, including accepted identifier formats (ticker, FIGI, ISIN, UID) and a valid depth range (1-50) with its default. The only gap is the absence of a format example for instrument_id.

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 order book (market depth) for an instrument') and enumerates the returned components (bids, asks, last price, spread). It is clearly distinguishable from siblings like get_last_prices or 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?

The tool's domain (market depth) implies its usage context, but the description contains no explicit when-to-use or when-not-to-use guidance relative to alternatives. No routing conditions or prerequisites are 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 already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the enumerated return fields (order_id, direction, type, status, price, quantity, instrument info) and confirms the tool is scoped to pending orders only, which is genuine added context, but it says nothing about ordering, limits, or pagination.

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 definition is short and front-loaded with the purpose, followed by clearly labeled Returns and Args sections. Every line carries some information, though the Args line is near-redundant with the parameter 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?

With no output schema, the description correctly compensates by listing return fields, which is the main gap it needed to fill. However, for a filtered list tool it omits result limits, ordering, and the absence of pagination, leaving the agent unsure how complete the returned list is.

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

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

Schema description coverage is 0% for the single required parameter, and the description supplies only 'account_id: Account ID', which merely restates the parameter name. No format, sourcing, or example is given to compensate for the schema's silence, so the description adds no meaning.

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

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

States a specific verb and resource ('Get list of ... orders') plus a scope qualifier ('active (pending)'), which implicitly separates it from the single-order sibling get_order_state and the historical get_operations. It does not name those siblings, so an agent must still infer the boundary, but the purpose itself is unambiguous.

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

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

There is no indication of when to use this versus get_order_state or get_operations_by_cursor, nor any prerequisites or exclusions. The only guidance is the parenthetical '(pending)', which implies a filter but is not framed as a use condition.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the content of the response (execution status, filled quantity, average price), which is genuinely useful since there is no output schema, but it says nothing about auth requirements, freshness/real-time behavior, or error cases for an unknown order.

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

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

Short and front-loaded, with the purpose stated before the Args block. The Args list duplicates the schema field titles, adding a little redundancy, but the overall text stays tight.

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

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

For a two-param read tool with readOnly annotations and no output schema, the definition is mostly sufficient: it names the key returned fields. It falls short only on ID format and the failure case of an invalid or unknown order_id.

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

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

Schema description coverage is 0%, so the description must compensate, but it does not: 'account_id: Account ID' and 'order_id: Order ID' merely restate the parameter names. No format, expected ID type, or relationship between the two params is given.

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

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

States a specific verb (Get) and resource (detailed status of a specific order) and enumerates the returned content: execution status, filled quantity, average price. The singular 'specific order' implicitly separates it from the sibling list-tool get_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?

No when-to-use guidance, no mention of alternatives like get_orders, and no prerequisites (e.g., an existing/open order). Usage is only inferable from the tool name and return fields.

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

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses genuinely useful behavior: zero/false fields are omitted, deprecated fields are dropped, expectedYield/dailyYield are money rather than percentages (but the portfolio-level one is a percentage), bond averagePositionPrice/currentPrice are per-bond money, and positionUid is the true position key. This is exactly the extra context annotations cannot carry.

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

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

Fairly long but information-dense and front-loaded: purpose first, then field enumeration, then unit/semantics caveats, then args. Given there is no output schema, the field-level detail earns its place; only marginal redundancy remains.

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

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

With no output schema and zero parameter descriptions, the description compensates by describing the return shape, field meanings, unit conventions, position keying, and where to source account_id. It is complete enough for an agent to call and interpret the result correctly.

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

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

Schema description coverage is 0%, so the description must carry the load. It adds real value for account_id ('get from get_accounts'), but for currency it only restates the enum values and default already present in the schema, leaving the gap only partly closed.

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

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

States a specific verb and resource ('Get full portfolio for an account') and enumerates the payload (totals by asset type, all positions with prices, yields, quantities), so the agent knows exactly what it gets. It does not explicitly contrast its scope with the sibling get_positions, so it stops short of full sibling differentiation.

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

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

There is no explicit when-to-use/when-not statement, but it does route the agent to the prerequisite tool ('account_id ... get from get_accounts') and clarifies how its bond price units differ from get_last_prices, get_candles and get_order_book. That is implied usage rather than a stated selection rule.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations: zero or false fields (blocked, exchangeBlocked) are omitted, balance is a string integer truncated to whole units, and positionUid is identified as the key shared with portfolio and operations. These are exactly the quirks an agent needs to parse results correctly.

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

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

Front-loads the purpose, then the sibling distinction, then the result-format caveats. Every sentence earns its place, though the balance/positionUid explanation is dense and could be tighter.

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

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

With no output schema, the description must explain the return shape, and it does: omitted fields, string-typed truncated balances, and the positionUid key. An agent can call and interpret this tool correctly from the description alone.

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

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

Schema description coverage is 0%, so the description carries the load, and it does say where account_id comes from (get_accounts). That is useful provenance, though it stops short of any format or validation detail.

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 all positions in an account') and enumerates the covered asset classes (securities, futures, options, cash balances). It explicitly contrasts itself with the sibling get_portfolio, so an agent can route between them without opening either schema.

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

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

Names the alternative (get_portfolio) and the condition that distinguishes it: raw balances without price calculations. It also points to get_portfolio for exact fractional quantities. It does not spell out a full when-not-to-use rule, 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuinely behavioral detail beyond the schema: the id format is auto-detected across ticker/FIGI/ISIN/UID. It says nothing about error behavior for unknown ids, rate limits, or coverage of the open-world lookup, so it only partially goes past 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 first sentence front-loads the purpose and the return fields, and the Args block is compact with no filler. Structure is efficient, though the embedded arg list is slightly dense and could be tighter for a three-parameter 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?

With only three parameters, no output schema, and no nested objects, the description supplies what an agent needs: the fields returned and the meaning/constraints of each identifier argument. Missing only the sibling routing (why this tool over get_instrument_by) to be fully self-sufficient.

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

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

Schema description coverage is 0%, so the description carries the full burden and does document all three parameters: the accepted identifier formats plus auto-detection for id, the conditional requirement for id_type, and a concrete board example ('TQBR') for class_code. It loses a point because the id_type note ('only needed with class_code: INSTRUMENT_ID_TYPE_TICKER') sits awkwardly against the enum's other values and the FIGI default, leaving a small ambiguity.

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

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

The description gives a specific verb+resource ('Get detailed share (stock) info') and enumerates the returned fields (sector, dividend yield, IPO date, issue size, country), so the agent knows exactly what a 'share' lookup yields. It does not, however, distinguish itself from sibling lookups such as get_instrument_by, get_bond_by, or list_shares, leaving the 'share vs. other instrument type' routing implicit.

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 Args block gives real parameter-level guidance ('id is recognised automatically', 'id_type only needed with TICKER', 'class_code to pick one listing out of several'), which implies the call pattern. There is no when-to-use-this-vs-an-alternative guidance and no mention of siblings like get_instrument_by or list_shares, so tool-selection context is absent.

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 only cover readOnly/openWorld safety, and the description goes well beyond that: it discloses the error contract ({"error": ...} when no share matches), the ambiguity-resolution fields returned (ticker, class_code, uid, asset_uid, name), and a subtle semantic caveat that current_price appears only while today's session is open and is not a close. These are behavioral traits an agent could not infer from 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 one-line purpose is front-loaded and the composed-call rationale follows immediately. It is somewhat long across four blocks, but nearly every sentence carries non-redundant information; only the wrapper-composition sentence could be trimmed without losing much.

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

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

With no output schema, the description fully specifies the return shape (resolved identifiers plus price, fundamentals, consensus), the error case, and the meaning of last_close/last_close_date/change_pct/current_price. An agent has everything needed to call it and interpret the 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?

Schema description coverage is 0%, so the description carries the full burden and does so: ticker accepts a ticker, name, ISIN, or FIGI and prefers an exact match over the first search hit; candle_days is defined as the number of daily trading sessions the change spans with a default of 5; class_code is explained with a concrete example ('TQBR'). All three parameters gain meaning not present in the schema.

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

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

The opening sentence names a specific verb and resource ('Get a one-call overview of a share') and enumerates the exact content returned: fundamentals, recent price change, analyst consensus. It also explicitly identifies itself as a composite of named sibling calls, which lets an agent distinguish it from find_instrument, get_asset_fundamentals, get_candles, and get_consensus_forecasts without opening any schema.

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

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

It states the selection condition clearly: use this instead of the five underlying calls to avoid separate round trips and manual ticker → UID → asset UID resolution. The alternative routing is explicit, but there is no when-not guidance (e.g. that callers wanting only fundamentals or only candles should use the granular siblings directly).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description goes further by documenting the return structure (one item per interval with timestamp and indicator-specific value keys) and defaults like the 90-day lookback and inclusive to_date, which the annotations do not supply.

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

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

Front-loads purpose and return shape, then presents parameters as a clean labeled list. It is on the long side, but for an 11-parameter tool with no schema descriptions nearly every line carries required information, so 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?

With no output schema and 11 parameters, the description covers both the return payload shape and all argument semantics, including defaults and per-indicator applicability. An agent has everything needed to construct a valid call and interpret the response.

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

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

Schema description coverage is 0%, so the description carries the full burden and does so comprehensively: it defines every one of the 11 parameters, names the enum values for indicator_type, interval, and type_of_price, gives defaults, and flags indicator-specific applicability (deviation = BB only, fast/slow/signal_smoothing = MACD only, MACD ignores length).

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 technical analysis indicators') and enumerates exactly which indicators (SMA, EMA, RSI, MACD, BB) for an instrument. It is immediately distinguishable from siblings like get_candles or get_last_prices.

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

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

Usage is implied by the indicator taxonomy rather than stated: there is no explicit 'use this when you need X' or exclusion against get_candles/get_stock_snapshot. It does add one cross-tool hint (the interval naming differs from get_candles and CANDLE_INTERVAL_* names are also accepted), which is genuinely useful routing information, but no when/when-not framing.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-data scope are covered. The description usefully adds that an empty exchange returns all exchanges and that to_date is inclusive with a 7-day default window, but says nothing about response shape, ordering, or rate limits. Adds some value over annotations, not a lot.

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

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

The purpose sentence is front-loaded and the Args block is terse, with no wasted prose. The documentation is appropriately sized for a three-parameter read tool, though the Args formatting reads slightly like docstring boilerplate.

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

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

With no output schema the description sensibly names the returned fields (trading hours, auction times, clearing times) and fully documents the three optional inputs. Return structure, ordering, and timezone semantics for the times are not addressed, which is the only real gap for an otherwise simple read tool.

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

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

Schema description coverage is 0%, so the description carries the full burden and largely discharges it: it gives the exchange format with concrete examples ("MOEX", "SPB"), the date format (YYYY-MM-DD), and defaults for both date fields. It does not clarify what an empty from_date/to_date means beyond the stated default, keeping it short of a 5.

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

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

States a specific verb and resource (get trading schedules for exchanges) and enumerates exactly what the data contains: trading hours, auction times, clearing times. An agent can distinguish it from the sibling get_trading_status, which is a different concept (current session status vs. scheduled hours).

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

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

There is no when-to-use guidance, no stated prerequisites, and no named alternative among the many siblings. The Args block only documents inputs; nothing tells the agent in what situation this tool is the right choice versus get_trading_status or others.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered and the description's job is lighter. It does add that the response reflects 'current' status and includes fields like tradeable and auction phase, which is useful context. It stops short of saying anything about freshness/latency, exchange session dependency, or failure behavior for invalid instruments.

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 purpose in the first clause, followed by a compact illustration of the payload. The 'Args:' block is slightly boilerplate for a one-parameter tool but costs little. No wasted sentences.

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

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

With no output schema, the description is the only place return values can be explained, and it gives only a partial sketch ('tradeable, auction phase, etc'). The 'etc' leaves the actual shape unknown. For a simple read-only, single-parameter status tool this is minimally viable, but it under-delivers on the return contract.

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

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

Schema description coverage is 0%, so the description carries the full burden for the single parameter, and it does so well by naming the four accepted identifier formats (ticker, FIGI, ISIN, UID). That is exactly the kind of syntax information the bare schema lacks. It doesn't state whether formats can be mixed or which is preferred.

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 current trading status for an instrument') and enumerates the payload ('is it tradeable, auction phase, etc'), which lets an agent distinguish it from list/lookup siblings. It does not, however, differentiate itself from the adjacent get_trading_schedules tool, so the boundary between the two remains ambiguous.

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

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

There is no when-to-use, when-not-to-use, or alternative guidance. The closest sibling, get_trading_schedules, is never mentioned, and the agent is left to infer whether this returns a live flag or a calendar. Nothing tells the caller what happens if the instrument is halted or unknown.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the returned attribute categories, which is useful, but says nothing about authentication requirements, whether it returns the calling user or a resolved user, or how missing/unavailable fields are represented.

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

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

A single front-loaded sentence with a colon-delimited field list; every token carries information and nothing is repeated from the name or annotations.

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

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

With no input parameters and no output schema, the description's enumeration of returned attributes is exactly the compensating detail an agent needs. The remaining gap is that it never states whose user record is fetched, which matters for a zero-arg tool in a portfolio/accounting API.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies a no-argument call, and there is nothing for it to disambiguate beyond that.

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+resource ('Get user information') with an enumerated list of what the payload contains (tariff, qualified investor status, premium status, risk level), which is more specific than the bare name. However it does not distinguish itself from nearby siblings like get_accounts, get_margin_attributes, or get_portfolio, so an agent cannot tell from the description alone where user attributes end and account attributes begin.

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 statement of when to call this tool, whose user it returns (current caller vs. arbitrary user), or when a sibling such as get_accounts or get_margin_attributes would be the better choice. Usage must be inferred entirely from the tool name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by enumerating the returned limit categories, but says nothing about freshness, per-account scoping caveats, or whether limits are per-asset-class, so it stays at an adequate level rather than a rich one.

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 purpose and return contents in one sentence, with the parameter note kept short. The 'Args:' block largely duplicates the schema property name, but the sourcing hint 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?

With no output schema, the description compensates by naming the returned fields, and it resolves the one required parameter's provenance. For a simple read-only getter this is close to complete; only the absence of any guidance on when this tool applies versus related account endpoints keeps it short of full.

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

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

Schema description coverage is 0% and the single parameter is bare in the schema, so the description must carry the load. It does: it identifies account_id as an account identifier and tells the agent exactly where to obtain it (get_accounts), which is actionable 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?

States a specific verb+resource ('Get available withdrawal limits for an account') and enumerates the exact quantities returned (free cash, blocked amounts, futures guarantees), which separates it from similarly named siblings like get_margin_attributes and get_portfolio without the agent needing to open a schema.

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

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

The description implies usage (fetch limits for a given account) and usefully names the prerequisite source for account_id ('get from get_accounts'), but never states when to prefer this over alternatives such as get_margin_attributes or get_portfolio, nor any exclusions.

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

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

Annotations mark this as readOnly and openWorld, but the description adds substantial operational context beyond them: the approximate result size, that it exceeds a model's context, that clients may save it to a file or refuse it, and that INSTRUMENT_STATUS_ALL causes the API to drop the connection. This is exactly the kind of behavioral disclosure annotations cannot 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 purpose is front-loaded in sentence one, followed immediately by the critical size/failure warning and then alternatives. Every sentence earns its place by preventing a likely misuse, despite the definition being longer than typical.

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

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

With no output schema and only annotations covering safety, the description explains the return scale, the failure mode of the larger status, and the correct alternative tools. Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining instrument_status. It does so by defining INSTRUMENT_STATUS_BASE as 'tradeable' and warning that INSTRUMENT_STATUS_ALL is 38 MB and fails, which adds meaning beyond the bare enum values. The default value is only implicit, keeping this just short of 5.

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

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

The description states a specific verb+resource: 'Get the full reference list of bonds: every field of every bond.' It also distinguishes this tool from siblings by naming find_instrument and get_bond_by as the targeted alternatives. An agent can immediately tell this is a bulk reference dump, not a search or detail lookup.

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 this is 'A dump for scripts, not something to read,' gives the reason (about 1,600 bonds and 2.4 MB of JSON, with INSTRUMENT_STATUS_ALL at 38 MB), and routes the agent to find_instrument with instrument_kind="bond" or get_bond_by for particular bonds. Both when-to-use and when-not-to-use are covered with concrete alternatives.

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

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the extra burden. It adds concrete payload context (~15 instruments, ~13 KB base, roughly double for INSTRUMENT_STATUS_ALL), which genuinely helps an agent decide whether to fetch. It stops short of describing field structure or any paging/auth traits, so not a 5.

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

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

Purpose is front-loaded in the first line, size context follows, and the argument semantics are placed last. Every sentence earns its place with no filler or repetition.

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

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

For a one-parameter read-only listing tool with no output schema, the description supplies purpose, payload size, and enum meaning, which is enough to invoke it correctly. It would be fully complete if it hinted at what an instrument record contains, since no output schema exists to cover that.

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

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

Schema description coverage is 0%, so the description must explain the single enum. It clarifies that INSTRUMENT_STATUS_BASE means tradeable and ties ALL to the doubled payload size, adding real meaning beyond the bare enum values. The default (BASE) is not restated, and ALL is only characterized by size, keeping it below a 5.

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

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

"Get list of all available currency instruments" states a specific verb (get/list) and resource (currency instruments), which cleanly separates it from the sibling list_shares, list_bonds, list_etfs, and list_futures. An agent can tell exactly what this returns without opening the schema.

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

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

The description gives size guidance ('small enough to read') which implies this tool is for bulk-fetching the whole currency set, but it names no alternative and states no when-to-use/when-not conditions. Siblings like find_instrument or get_currency_by are never referenced as the search path for a single instrument.

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 only declare readOnlyHint and openWorldHint; the description adds the operational traits that matter — ~280 funds, ~300 KB vs 2.3 MB of JSON depending on status, exceeding typical model context, and that clients may save or refuse the result. That is real behavioral disclosure beyond the annotation layer.

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

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

Two dense paragraphs: the payload warning is front-loaded right after the purpose statement, and the routing sentence follows. The size figures are specific and load-bearing rather than filler; no sentence is redundant.

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

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

With no output schema, the description supplies what the return looks like (all fields of all funds), how large it is under each parameter value, and how a client is likely to handle it. An agent has everything needed to decide whether to call this or a narrower sibling.

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

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

Schema description coverage is 0%, so the description must carry the parameter meaning, and it does gloss INSTRUMENT_STATUS_BASE as the tradeable subset and contrasts it with ALL, including the size difference. It does not spell out what INSTRUMENT_STATUS_ALL includes beyond 'everything', so it stops short of full compensation.

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

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

States a specific verb and resource ('Get the full reference list of ETFs and funds: every field of every fund') and immediately marks itself as a bulk dump rather than a lookup, which distinguishes it from get_etf_by and find_instrument without opening any schema.

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

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

Explicitly frames the use case ('A dump for scripts, not something to read') and routes the agent to alternatives with the exact parameter to supply: find_instrument with instrument_kind="etf" for finding funds, get_etf_by for a single fund. When-to-use and when-not-to-use are both stated.

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

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

Annotations only cover readOnlyHint/openWorldHint, but the description adds critical operational context: ~530 contracts, 700 KB (BASE) to 3.5 MB (ALL) of JSON, exceeding model context, with the realistic outcome that a client saves to file or refuses the result. This is exactly the behavioral disclosure annotations cannot 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?

Front-loaded with purpose and sizing caveat, then alternatives, then args. The size figures (700 KB / 3.5 MB) are precise and decision-relevant rather than padding, and no sentence is redundant.

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

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

With no output schema, the description adequately characterizes the return (all fields of ~530 contracts, payload size). Combined with the size warning and alternatives, an agent has what it needs, though it could note pagination/streaming absence explicitly.

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

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

Schema description coverage is 0%, so the description must carry the load, and it partly does by glossing the enum values: BASE = 'tradeable' versus ALL. It doesn't explain the tradeable/non-tradeable distinction beyond one word, but the added meaning over the raw enum is genuine.

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 ('full reference list of futures contracts: every field of every contract') and explicitly scopes it as a bulk dump. It names the siblings it is not (find_instrument, get_future_by), so an agent can distinguish it from the other list_*/get_*_by tools without opening any schema.

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

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

Explicitly states when NOT to use it ('a dump for scripts, not something to read') and names two concrete alternatives with the exact selector argument (find_instrument with instrument_kind="futures", get_future_by for one). Both the routing condition and destination are given.

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

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

Annotations only cover readOnly/openWorld, but the description adds the decisive operational traits: ~1,900 shares, 2 MB with BASE / 8 MB with ALL, far more than fits in a model's context, and that clients may save to file or refuse the result. This is exactly the kind of behavioral disclosure that prevents a bad invocation.

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

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

Front-loads the core definition, then the size warning, then the alternative tools. Every sentence carries a distinct, actionable fact with no filler or repetition.

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

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

With no output schema, the description still characterizes the return payload (every field of every share) and its magnitude, plus the practical consequence for context limits. Nothing an agent needs to decide whether to call this 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 0%, so the description must compensate and largely does, glossing INSTRUMENT_STATUS_BASE as '(tradeable)'. It leaves INSTRUMENT_STATUS_ALL unglossed (presumably including non-tradeable instruments), so the enumeration semantics are only half explained.

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

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

States a specific verb and resource with explicit scope: 'Get the full reference list of shares (stocks): every field of every share.' It also distinguishes itself from the sibling lookup tools by name (find_instrument, get_share_by), so an agent can differentiate without opening schemas.

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

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

Explicitly frames the tool as 'A dump for scripts, not something to read' and routes the agent elsewhere: 'To find particular shares use find_instrument, and get_share_by for the details of one.' Both the when and the when-not are stated with named alternatives.

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