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

With annotations already declaring readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, the description adds useful context beyond annotations: server-side pagination, upstream-defined filter labels, and the need to extract orderbookId from results. No contradiction exists between the description and annotations.

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

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

The description is three short sentences with the core purpose front-loaded. Each sentence earns its place: core action, open-world filter labels, and the critical downstream orderbookId step.

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, idempotent filter tool with an output schema, the description covers the key non-obvious behavioral details: open filter vocabulary, pagination, and using orderbookId before info/detail calls. It does not fully discuss filter combination semantics, but the schema defaults and output schema cover much of that burden.

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

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

Schema description coverage is 0%, and the description does not explain any of the 10 parameters or map concepts like 'leverages' or 'underlying_instruments' to the orderbookId hint. The generic warning that filter labels are upstream-defined helps but does not compensate for the lack of parameter-level documentation.

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

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

The description opens with a specific verb and resource: 'Select certificates by upstream filters with server-side pagination.' This clearly identifies it as a filtered list operation for certificates, but it does not explicitly differentiate it from similar siblings like filter_etfs or filter_warrants.

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 context by instructing the agent to 'Select an orderbookId from results before requesting info or extended details,' which positions this tool as a discovery step before certificate info/detail calls. However, it does not explicitly say when to use this over filter_etfs/filter_warrants or state 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 already cover the safety profile (readOnlyHint, idempotentHint, non-destructive). The description adds behavioral context beyond that: server-side pagination, dynamic upstream-defined filter vocabulary, and the hint that results contain orderbookId. No contradiction with annotations.

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

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

Two short sentences with no filler. The core purpose and pagination are front-loaded, followed by the critical operational hint and routing to get_etf_info. Every sentence adds value.

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

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

For a tool with 11 optional parameters and no schema descriptions, the description is too thin. It lacks per-parameter semantics and pagination/sort details. Although the output schema exists and annotations help, the filter parameter meanings are left largely ambiguous, making autonomous invocation risky.

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. It gives generic guidance to inspect filterOptions for filter values, but doesn't explain pagination parameters (limit, offset), sort parameters (sort_field, sort_order), or the specific meaning of filter fields like issuers, exposures, directions, etc. This is significant under-compensation for 11 parameters.

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

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

The description states a specific verb ('Select'), resource ('ETFs'), and mechanism ('by upstream filters, with server-side pagination'). It clearly distinguishes from sibling filter tools for other instrument types (filter_certificates, filter_warrants) and points to get_etf_info as the follow-up step.

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 useful usage context: inspect returned filterOptions rather than guessing labels, and use get_etf_info for a selected orderbookId. However, it doesn't explicitly contrast with filter_certificates/filter_warrants or state when not to use this tool, so it stops short of full explicit when/when-not guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the description only needs to add extra context. It adds two useful behavioral traits: pagination is server-side, and filter vocabulary values come from an upstream system rather than a fixed enum. This goes beyond the annotations without contradicting them.

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

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

Two short, purposeful paragraphs. The first sentence front-loads the core function and pagination; the second adds the critical downstream dependency. Every sentence earns its place with no filler.

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

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

For a filter/list tool with full annotations, an output schema present, and simple scalar parameters, the description covers the key workflow: paginate, treat filter vocabularies as upstream-defined, and take an orderbookId before asking for details. Nothing essential for calling this tool correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify that sub-type, direction, and issuer vocabulary is upstream-defined and that orderbookIds come from discovery results, which is valuable. However, it does not explain null semantics for filter arrays, allowed sort_field values, or behavior of limit/offset, leaving clear gaps for eight parameters.

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

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

The description states a specific verb and resource: 'Select warrants by upstream filters with server-side pagination.' It also distinguishes itself from the sibling info/detail tools by instructing the agent to 'Select an orderbookId from results before requesting info or extended details,' so an agent can tell it apart from get_warrant_info or get_warrant_details.

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 a clear context for use: it is a filtering/discovery step, not a details endpoint, and it tells the agent to use an orderbookId from the results before proceeding to info or details requests. It does not explicitly name alternatives or say when not to use it, but the downstream workflow is clearly stated.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, lowering the burden on the description. The description adds a useful data-content caveat about investor types, but it does not describe pagination, freshness, or other runtime behaviors; this is adequate but not rich.

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

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

The description is a single front-loaded sentence with no wasted words; the core action and the key limitation are both stated compactly. Every clause 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 annotations covering safety, a complete parameter schema, and an output schema present, the description only needs to establish the tool's domain and data caveat, which it does. Nothing required to invoke the tool correctly is missing.

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

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

Schema coverage is 100%, with the order_book_id property already documented as the Avanza discovery ID rather than instrumentId. The tool description adds no parameter meaning beyond what the input schema already provides, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource ('Get upstream broker buy/sell summaries'), and the trailing caveat ('these do not identify investor types') narrows the semantic scope enough to distinguish it from ownership-related siblings. This is more specific than a bare reading of the name.

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

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

The phrase 'broker buy/sell summaries' implies the intended use case, and the caveat warns not to use it when investor-type detail is needed. However, it names no alternative tools or explicit conditions for choosing another sibling, so usage guidance is only implied rather than stated.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the description's note that 'detail fields are intentionally flexible' adds valuable context about response variability. No contradiction with annotations.

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

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

A single tight sentence front-loads the core action and places the flexibility caveat second. 'Intentionally' adds nuance rather than fluff, though the phrasing could be more specific.

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

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

For a single-parameter, read-only tool with an output schema, the description plus annotations cover the essentials: the conceptual purpose, the parameter source, and output variability. Explicit sibling differentiation is missing but not critical for this simple tool.

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

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

Schema coverage is 100%, and the schema already explains that order_book_id is the Avanza order-book ID from discovery, not instrumentId. The description adds no parameter-level meaning, so baseline 3 is appropriate.

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

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

Description states a clear verb-resource pair ('Get extended certificate details') and signals a distinction from get_certificate_info via 'beyond info'. However, 'extended' and 'flexible' remain vague, so it doesn't fully specify what is included.

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?

'Beyond info' implies this is for richer detail than the basic info endpoint, but it never names the sibling tool or states explicit conditions for choosing this over get_certificate_info or filter_certificates. No when-not-to-use guidance is provided.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral caveat that data is not guaranteed real-time, but it does not elaborate on freshness, caching, or other response 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?

The description is a single compact sentence that front-loads the action and resource, then adds an important caveat without wasted words. Every part 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?

For a one-parameter read-only tool with an output schema and strong annotations, the description is nearly complete. The real-time caveat is important and present; the only notable gap is not explicitly routing the agent away from get_certificate_details or toward a real-time alternative.

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 single parameter's schema description already fully explains that order_book_id is the Avanza order-book ID from discovery and not the separate instrumentId. The tool description adds no additional parameter-level detail, so baseline 3 applies given 100% schema coverage.

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

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

The description uses a specific verb ('Get') with a clear resource ('certificate identity and latest available market data'). It is clear that this is a certificate-specific info tool and thus distinct from stock/ETF/fund/warrant info tools, though it does not explicitly differentiate from the close sibling get_certificate_details.

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

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

The phrase 'latest available market data' implies an appropriate use case, and 'not guaranteed real-time' signals a limitation. However, it does not explicitly state when to use this tool versus get_certificate_details or a real-time quote tool, and it names no alternatives or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context beyond annotations: it states that missing sections are omitted rather than fabricated, that no unit conversions are made, and that data preserves upstream field names. These are important trust-related behaviors that an agent needs to know.

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-loaded with the core purpose. Each sentence adds meaningful information: the scope, the data preservation behavior, verified metric names, the available_metrics clarification, the missing-sections behavior, and the no-conversion guarantee. No wasted words, though the metric name list could be seen as slightly verbose.

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

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

Given the output schema exists and annotations cover the safety profile, the description is reasonably complete. It explains the key behavioral guarantees (no fabrication, no unit conversion, field name preservation) and provides verified metric names. The main gap is that it doesn't explain the selection parameter's four enum values in plain language, but the enum names are fairly self-explanatory.

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

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

Schema description coverage is only 20%, with only order_book_id having a description. The description compensates somewhat by listing verified metric names (sales, netProfit, profitMargin, etc.) and explaining that available_metrics lists names, not sibling series. However, it doesn't explain the selection parameter's four enum values or the limit/offset pagination semantics beyond what the schema shows.

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 ('Page one metric') and resource ('annual, quarterly, TTM or quarter-only financial section'), which clearly identifies the tool's function. It distinguishes itself from siblings by focusing on financial metrics rather than certificates, funds, or orderbook data, though it doesn't explicitly name a sibling alternative.

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

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

The description provides clear context on when to use this tool: when you need a single financial metric across different reporting periods. It doesn't explicitly state when not to use it or name alternatives, but the scope is well-defined enough that an agent can infer appropriate usage. The mention of 'available_metrics lists names, not sibling series' helps clarify what the tool returns.

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

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

The description goes far beyond the annotations by disclosing that missing data is omitted rather than represented as empty history, that records contain financialYear, reportType, value and optional date, that ex/payment dates are not inferred, that available_metrics only lists names, and that units/scales are upstream-defined. These are exactly the non-obvious behaviors an agent needs to interpret 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?

The description is compact and dense, with each sentence adding a distinct piece of operational context. No filler words or repetitive statements are present.

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

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

An output schema exists and the annotations cover the read-only/idempotent safety profile, so the description does not need to restate return formats or safety. It provides the missing behavioral and data-shape context. It is slightly incomplete on pagination semantics and on when to use this tool versus other financial-data tools, but the core invocation needs are covered.

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

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

Schema coverage is only 25%, so the description must compensate. It does for the metric parameter by listing the three accepted metric values, which is critical because the schema only provides a generic string pattern. It does not clarify the semantics of limit/offset or how pagination relates to 'Page one', but order_book_id is already described 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 description identifies the resource as a dividendsByYear metric and names the three supported values (dividendPerShare, directYieldRatio, dividendPayoutRatio), so an agent knows what kind of data get_dividends returns. It stops short of a clear verb ('retrieves', 'lists', 'returns') and relies partly on the tool name for the action.

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

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

No explicit guidance is given for when to choose this tool over alternatives. The note that 'sibling series are excluded' describes output scope rather than routing the agent to another tool. There are no conditions, exclusions, or named sibling 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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that detail fields are upstream-defined and flexible, informing agents that the response shape may vary. This is useful but minimal; no mention of rate limits, errors, or other behavioral specifics.

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

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

Two short sentences with no filler. The key differentiator ('beyond info') is front-loaded, and the second sentence warns of flexible fields. Every sentence 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 one parameter, output schema present, and annotations covering safety, the description is adequate for an agent to invoke correctly. The 'upstream-defined and flexible' caveat warns of variable response fields, which is important. It does not explain what 'extended' entails, but the output schema resolves the return structure.

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

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

Schema coverage is 100% and the parameter description clearly distinguishes order_book_id from instrumentId. The tool description adds no further semantic value for the parameter, so baseline 3 is appropriate.

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

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

States a specific verb ('Get') and resource ('extended ETF details'), and explicitly contrasts with 'info', which maps to sibling get_etf_info. However, 'extended' and 'flexible' are vague and do not specify what additional data is returned.

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?

'Beyond info' implies use when basic info from get_etf_info is insufficient, providing clear context. It does not name the alternative tool explicitly or give a when-not condition, but the context is enough for an agent to infer the appropriate choice.

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

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

Annotations already cover the read-only, idempotent, and non-destructive nature, so the description carries a lighter burden. It adds a meaningful behavioral caveat: 'not guaranteed real-time', informing the agent that the quote may be delayed—a detail not present in the annotations. This is useful additional 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 description is a single, focused sentence that front-loads the action and resource, followed immediately by the only caution worth knowing. There is no filler or redundant 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 single-parameter read-only tool with a full output schema and comprehensive annotations, the description adequately covers the action, resource, and a key data-freshness caveat. Nothing essential for correct invocation is missing.

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

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

The schema provides 100% coverage for the single parameter, including the key clarification that order_book_id is an Avanza order-book ID and not the separate instrumentId. The description adds no parameter-level detail, but the schema already does the heavy lifting, so a baseline 3 is appropriate.

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

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

The description clearly states the action ('Get') and the resource ('ETF identity, listing and latest available quote'), making the tool's purpose specific and understandable. However, it does not distinguish itself from the sibling get_etf_details or other get_*_info tools, so an agent may need to inspect schemas to choose between 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?

There is no guidance on when to use this tool versus alternatives like get_etf_details, get_stock_info, or get_certificate_info. The description only states what it does without giving any selection criteria, prerequisites, or 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?

Beyond the readOnly/idempotent annotations, the description discloses that points are in source order, x/y values retain upstream meaning, y is not assumed to be NAV or return, and offset/limit slice the chosen period. This adds meaningful behavioral context not available in the annotations.

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

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

The description is three sentences, each carrying distinct information: purpose, data semantics, and pagination/date behavior. There is no filler, and the key 'raw' and 'without aggregation' qualifiers are front-loaded.

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

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

With an output schema present and readOnly/idempotent annotations covering the safety profile, the description covers the essential calling concerns: raw vs aggregated, source order, x/y meaning, and offset/limit behavior. It does not restate schema fields and leaves only minor gaps around pagination starting points.

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

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

Schema description coverage is only 25%, so the description must compensate. It adds meaning for offset/limit as slicing the chosen period and implies time_period as the period selection, but it does not explain time_period enum values or precise pagination boundaries. Partial compensation for the low schema coverage.

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

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

The description opens with 'Get a page of raw fund dataSerie points in source order, without aggregation,' which names a specific verb, resource, and the defining qualifier 'without aggregation.' It clearly distinguishes this from any aggregated chart sibling and confirms it is fund-specific.

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 the use case through 'raw' and 'without aggregation,' but it never explicitly states when to choose this tool over alternatives or when not to use it. No sibling tools or exclusions are mentioned, leaving the guidance implicit.

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

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

Annotations already cover the read-only, idempotent, open-world, and non-destructive profile. The description adds valuable data-behavior context beyond those annotations: the meaning of 'startDate' and, more importantly, the warning that the 'change' field retains upstream scale and may not match fund-guide development fields. This prevents unit misinterpretation, which annotations could not 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?

Two sentences with no fluff. The purpose is front-loaded, and the second sentence provides a necessary caveat about output field semantics. Every sentence 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?

For a single-parameter tool with full schema coverage and an output schema, this description is complete: it explains the purpose, differentiates the output type from chart points, and adds the critical scale warning. Nothing essential is missing for an agent to call it correctly.

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

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

The only parameter, order_book_id, is fully documented in the input schema with 100% coverage. The description's mention of startDate and change refers to response fields, not to the input parameter, so it adds no extra parameter-level meaning. Baseline 3 is appropriate because the schema already carries the full burden.

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

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

The description states a specific action and resource: 'Get available fund performance periods'. It also explicitly contrasts with 'individual chart points', which distinguishes it from the sibling get_fund_chart without ambiguity.

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

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

The phrase 'rather than individual chart points' clearly signals when not to use this tool and implies that get_fund_chart is the alternative. However, it does not explicitly name the sibling tool or give a fuller when-to-use scenario, so it stops short of a perfect 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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety and mutability profile is covered. The description adds the output content but no additional behavioral traits such as potential missing descriptions, data-source caveats, or response quirks. It also does not contradict the annotations.

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

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

The description is a single, front-loaded sentence with no filler or redundancy. It is appropriately sized for a one-parameter, read-only tool with an output schema.

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

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

Given the tool's simplicity, one required parameter, rich read-only annotations, and the presence of an output schema, the description is essentially complete for invocation. It would be marginally stronger if it also pointed users to sibling tools like get_fund_info when broader fund data is needed.

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

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

Schema description coverage is 100%, and the order_book_id parameter is already well documented in the schema, including the note that it is not the separate instrumentId. The description itself adds no parameter semantics, which is acceptable because the schema already carries the full burden.

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

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

The description uses the specific verb 'Get' and clearly names the resource ('fund') and the returned content ('investment description and category explanation'). It is clear what the tool returns, but it does not explicitly differentiate itself from sibling tools like get_fund_info or other fund-related retrievers, so it stops short of a 5.

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

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

The description provides no guidance about when to choose this tool over alternatives such as get_fund_info, get_fund_holdings, or get_fund_chart. The only usage hint (the order-book ID being from discovery rather than the separate instrumentId) appears in the input schema, not in the description, and it addresses parameter handling rather than tool selection.

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 idempotentHint, but the description adds substantial behavioral detail: portfolioDate is source date not retrieval time, missing dates are not inferred, missing allocations are null while reported empty arrays remain [], and values are returned without unit conversion. This is meaningful context beyond the structured annotations.

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

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

Three tight sentences: the first states the purpose and limitation, the second clarifies date semantics, the third covers null/empty and unit behavior. Every sentence carries essential information with no filler.

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

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

For a single-parameter read-only tool with an output schema, the description covers the most likely sources of confusion: date interpretation, missing vs empty arrays, and unit conversion. Nothing else is needed for correct invocation.

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

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

The only parameter, order_book_id, is fully documented in the schema with a clear description distinguishing it from instrumentId. Schema coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning, but none is needed.

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 action on a specific resource: 'Get reported country, sector and holding allocations'. It also explicitly disambiguates from a complete position ledger, which helps an agent distinguish this from a broader holdings request. This is more specific than the tool name alone and differentiates from siblings.

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

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

The description implies usage for reported allocation data but gives no explicit direction on when to choose this tool over siblings like get_fund_info or get_fund_sustainability. The 'not a complete position ledger' phrase is a scope qualifier rather than a routing guideline, so guidance 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, openWorldHint, idempotentHint, and non-destructive behavior. The description adds value beyond those by disclosing data-freshness limitations ('Not guaranteed real-time') and that currency and tradeability remain unknown, which are genuinely useful behavioral caveats not captured by the annotations.

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

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

The description is compact and front-loaded: the core purpose appears first, followed by important limitations and then sibling routing. Every sentence contributes useful information, with no redundant or filler content.

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

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

For a single-parameter tool with a full output schema and rich annotations, the description supplies everything an agent needs: what data is returned, known limitations, and when to use alternatives. It is complete without over-explaining.

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

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

The schema already documents the single parameter thoroughly, including the pattern and the caveat 'not the separate instrumentId.' With 100% schema description coverage, the tool description adds little param-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description names a specific verb and resource: 'Get fund identity, latest available NAV, fees, risk and allocations.' It also distinguishes itself from get_fund_holdings and get_fund_chart by stating exactly what those siblings are for, which prevents an agent from confusing this tool with closely related ones.

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 explicit routing guidance: use get_fund_holdings for allocations only and get_fund_chart for raw history. It also adds usage-relevant caveats about missing currency/tradeability and non-real-time data, so an agent knows the limits of this tool before invoking it.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints, so the description's zero waste is fine. The description adds the key behavioral nuance that data is 'latest available' and not real-time, which is valuable beyond annotations. However, it does not disclose potential data lag or update frequency, which openWorldHint implies. Since annotations cover the safety profile, 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?

A single sentence that immediately states the primary action and a crucial qualifier. There is zero filler, and the key distinction (not real-time) is front-loaded. Every word earns its place.

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

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

The output schema exists, so return format is covered by the schema. The description lacks details about data freshness, timezone, or any caveats about availability for certain funds, but for a single-parameter, annotation-rich read tool, the description is minimally sufficient but could be more informative.

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

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

The schema description covers 100% of the parameter (order_book_id) with explicit meaning and contrast to instrumentId, so baseline is 3. The description adds no additional parameter detail beyond what the schema provides, but that is acceptable given full coverage.

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

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

The description clearly states it retrieves fund ESG and sustainability data with the specific qualifier 'latest available' and explicitly notes it is not a real-time assessment. This distinguishes it from other fund tools like get_fund_description or get_fund_chart, making the purpose unambiguous.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives, and does not mention any conditions or complementarity with other tools. It only states what it does, leaving the agent to infer usage context.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds 'detail fields are intentionally flexible', which is somewhat useful context but does not disclose any additional behavioral nuances, such as return format variations or potential missing fields. Given the annotations cover safety, this is adequate but not rich.

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 very short with minimal waste, but it is too under-specified. It could be more informative without being verbose. The phrase 'intentionally flexible' adds some value but overall it is not effective.

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 an output schema, but the description is too vague to convey what extended details might include or how they differ from base info. An agent cannot predict what fields will be returned or when to use it. For a complex domain with many siblings, this is insufficient.

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

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

The schema description coverage is 100%, and the parameter is well-documented (order-book ID from discovery, not instrumentId). The description does not add anything about the parameter beyond the schema, so baseline 3 is appropriate.

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

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

The description says 'extended contract details beyond info' which is vague. It doesn't specify what kind of contract (future or forward) or what extended details means. The name mentions 'future_forward' but the description is ambiguous and could apply to any instrument. There is no distinction from sibling tools like get_future_forward_info.

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 does not specify when to use this tool versus get_future_forward_info or other detail tools. It only hints at 'extended' but doesn't explain what scenario requires it. An agent would not know if this is for futures vs forwards, or what extra fields to expect.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: 'Option names, values and nested detail fields are intentionally flexible.' This tells the agent that the response schema is not fixed and may vary, which is valuable beyond the annotations. No contradiction with annotations.

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

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

Two sentences with no wasted words. The first sentence states the purpose and timing; the second sentence adds a critical behavioral caveat. Information is front-loaded and every sentence 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?

For a zero-parameter, read-only tool with an output schema and strong annotations, the description is nearly complete. It explains the purpose, timing, and flexibility of the response. The only minor gap is that it doesn't describe what specific filter options are returned (e.g., maturity dates, underlying assets), but the 'intentionally flexible' note and output schema mitigate this.

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

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

The tool has zero parameters, so there are no parameter semantics to document. The description correctly notes that the output fields are flexible, which is the relevant semantic information. With 0 params, a baseline of 4 is appropriate, and the description adds value by warning about flexible field names.

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

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

The description states a specific verb ('Get') and resource ('current upstream filter options') with a clear purpose ('before selecting futures/forwards'). It distinguishes itself from sibling tools like get_future_forward_info and get_future_forward_details by focusing on filter options rather than instrument details. However, it doesn't explicitly name a sibling alternative, so it's clear but not fully differentiated.

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 when to use this tool: before selecting futures/forwards, to fetch filter options. This gives clear context for the agent. It doesn't explicitly state when not to use it or name alternatives, but the 'before selecting' phrasing provides adequate usage guidance for a zero-parameter tool.

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

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds a useful but thin behavioral caveat: data may not be real-time. It does not disclose anything further about data freshness, authorization, or response 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?

A single sentence with no filler. The main purpose is front-loaded and the important freshness caveat is appended compactly without redundancy.

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

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

For a one-parameter, read-only getter with a rich schema and an available output schema, this description is largely complete. The main gap is not naming alternatives for real-time data or distinguishing from the closely related get_future_forward_details, but that is more of a usage concern.

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

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

Schema description coverage is 100%, and the order_book_id parameter is already well explained in the schema, including the clarification that it is not the separate instrumentId. The tool description itself adds no parameter-level meaning, so the baseline applies.

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

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

The description uses a clear verb 'Get' and specifies the resource: contract identity and latest available market data. It is unambiguous about what is returned. However, it doesn't explicitly distinguish it from get_future_forward_details, relying mainly on tool naming for 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?

The caveat 'not guaranteed real-time' implies when this tool is not suitable, and the phrasing suggests it is for retrieving identity plus a market snapshot. But it names no alternative for real-time data and gives no explicit when-to-use versus when-not-to-use guidance.

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

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

Annotations already declare readOnly, openWorld, and idempotent behavior. The description adds concrete open-world semantics: failure to match is not proof of invalidity, and the tool will not fall back to a similar result. This goes beyond the annotations and prevents a common agent misinterpretation.

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

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

Three short sentences, front-loaded with the core matching operation and followed by two necessary caveats. There is no filler or redundant restatement of the tool name or schema.

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

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

With one well-documented parameter, an output schema already present, and annotations covering safety and open-world behavior, the description adds exactly the missing operational caveats. Nothing essential for calling the tool correctly is absent.

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

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

Schema coverage is 100% and the parameter description already clarifies that order_book_id is the Avanza discovery ID, distinct from instrumentId. The tool description does not add new parameter-level meaning; 'exact' and 'at most 50 candidates' describe behavior more than parameter semantics.

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 ('Match') and a precise resource scope ('exact order_book_id among at most 50 search candidates'). It also draws a clear behavioral boundary by warning that it never substitutes the first or a similarly named search result, which distinguishes it from broad search-oriented siblings.

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

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

The intended use is clear: call this tool when you have an exact order_book_id from discovery and want to match it exactly. The description does not explicitly name an alternative tool or state when-not-to-use, but the exact-match language and candidate cap provide sufficient routing context.

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

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

The description goes well beyond the read-only/idempotent annotations by explaining independent array slicing, separate metadata counts, no point alignment, no aggregation/unit conversion, the separation of data fields from wrapper pagination keys, and the lack of real-time guarantees. This gives an agent a strong behavioral model of the tool.

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

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

The description is compact and front-loaded with the core purpose. Each subsequent sentence adds meaningful behavioral context without filler. The structure is efficient and easy to process.

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

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

Given the output schema exists and annotations cover safety, the description provides substantial context: raw data nature, slicing behavior, data layout, and real-time caveat. It is not fully complete because it could offer more explicit guidance on when to choose this over similar orderbook or chart tools, but the critical invocation details are 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 only 25%, so the description must compensate. It does add meaning for limit/offset by explaining independent slicing and separate metadata counts, but it does not explain time_period semantics or clarify the relationship between order_book_id and the data. The schema already covers order_book_id, so the partial compensation is adequate but incomplete.

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

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

The first sentence uses a specific verb and resource: 'Get raw OHLC and market-maker data for traded products.' It also explicitly distinguishes this from stock/fund chart tools, making the purpose clear and differentiating it from sibling chart endpoints.

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

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

The description clearly indicates when this tool applies—raw data for traded products—and explicitly excludes stock/fund charts. However, it does not name specific sibling alternatives like get_stock_chart or get_fund_chart, nor does it provide explicit when-not-to-use conditions beyond the stock/fund exclusion.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds only a minor behavioral detail ('latest available') but does not explain data freshness, timezone handling, or update cadence. No contradiction with annotations.

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

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

A single front-loaded sentence with no filler or redundancy. It states the operation and the resource immediately, and every word earns its place.

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

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

For a one-parameter, read-only tool with an output schema, complete annotations, and full schema coverage, the description covers the essentials. The only notable gap is the lack of usage guidance, but the schema annotations and output schema compensate for most operational needs.

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

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

Schema description coverage is 100% and the single parameter order_book_id is already well-documented, including the note that it is not the separate instrumentId. The description adds no additional parameter meaning, so the baseline baseline of 3 is appropriate.

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

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

The description states a specific verb ('Get') and a concrete resource ('marketplace status and trading hours'), which clearly distinguishes it from the sibling tools, none of which mention marketplace status or trading hours. It tells an agent exactly what resource this tool is about without ambiguity.

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

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

The description gives no explicit when-to-use guidance, prerequisites, or alternatives. There is no statement about when to prefer this tool over siblings like get_stock_quote or get_orderbook, so the agent must infer usage from the name and purpose alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds genuine value beyond those by disclosing the output's nature: fields are upstream passthrough (not a fabricated aggregation) and summary fields describe the full source history rather than the current page. This is useful, non-contradictory behavioral context for an agent consuming the result.

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 primary action is front-loaded in the first sentence, and the whole description is compact. Minor style blemishes (uncapitalized 'data' and 'Not' at sentence starts, and a run of short fragments in the second sentence) keep it from a 5, but there is no wasted verbiage.

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 low-complexity paged read (3 params, 1 required, no nesting) with an output schema present and annotations covering safety, the description covers what matters: pagination behavior, output nature, and scope exclusion. The main gaps—unnamed sibling alternatives and no explicit limit/offset explanation—are minor given the strong structured metadata, so it lands just above baseline.

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 low at 33% (only order_book_id is described), so the description should compensate. The phrase 'Page Avanza ownersPoints in source order' implicitly covers limit/offset semantics by signaling pagination behavior, but it never explicitly explains what limit and offset do. The description partially compensates for the coverage gap but not fully, warranting a mid score.

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

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

The description gives a specific verb+resource ('Page Avanza ownersPoints in source order') that distinguishes this from the many get_* siblings spanning certificates, funds, futures, stocks, and warrants. However, there is tension with the tool name: 'get_number_of_owners' implies a count, while the description explicitly says there is no fabricated top-level owner count. That naming mismatch slightly muddies the purpose, keeping it from a 5.

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

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

The only usage guidance is the negative scoping clause 'Not market-wide ownership,' which tells the agent what this tool is not for. No specific alternative sibling is named, nor are selection conditions given (e.g., when to prefer get_stock_info or get_orderbook). The context is implied rather than explicit, so it stops at a 3.

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

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

Annotations already establish read-only, idempotent, safe behavior; the description adds meaningful behavioral caveats: empty levels are valid responses, and the data may not be real-time. These are exactly the non-obvious facts an agent needs to interpret call 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?

Two short sentences carry the essential information and are front-loaded with the core action. There is no filler or repetition of annotation/schema content.

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

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

For a one-parameter read-only tool with a full output schema and comprehensive annotations, the description covers the only remaining judgment points: data freshness and validity of empty levels. Nothing needed for correct invocation is missing.

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

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

Schema description coverage is 100%, and the schema itself includes a disambiguating note that order_book_id is a discovery ID rather than the separate instrumentId. The tool description adds no parameter semantics of its own, so the high-coverage baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource ('Get latest available buy/sell depth'), which clearly identifies the tool as an order-book depth reader. The mention of buy/sell depth distinguishes it from sibling quote, trade, and instrument-info getters without requiring schema inspection.

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

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

It implies when to use it: when latest available order-book depth is needed, and cautions that data is not guaranteed real-time, signaling it may not be appropriate for freshness-critical calls. It stops short of naming alternatives or explicit 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?

Beyond the readOnly/openWorld annotations, the description discloses important snapshot behavior: 'Separate page requests may observe a changed snapshot' and 'total is the current source count.' These caveats tell the agent that pagination results are not stable, which is exactly the kind of behavioral context annotations alone do not 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?

Three short, purposeful sentences front-load the core action and then add essential caveats. There is no filler or repetition of structured metadata.

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 an output schema availableable and order_book_id already described in the input schema, the description covers the main non-obvious context an agent needs: snapshot mutability, paging order, and the meaning of total. Nothing critical for a correct call 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 only 33%, and the tool description contains no parameter-level guidance. It implies limit/offset via 'page through,' but does not explain how those parameters interact with the changing snapshot; the schema only supplies defaults and bounds.

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

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

The description opens with a specific verb and resource: 'Page through the latest available trade snapshot in upstream order.' It also states a clear non-goal, 'Not a complete trade history', which separates it from broader history or order-book tools in the sibling list.

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

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

It gives clear context: this is a snapshot-pagination tool, not a complete history or guaranteed real-time feed. It does not explicitly name an alternative tool or define a precise when-not-to-use branch, so it stops short of full alternative guidance.

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

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

The description adds substantial behavior beyond the readOnly/idempotent annotations: source ordering, unprocessed timestamp/ratio values, preservation of upstream fields, pagination semantics, and the exact meaning of offset zero. This is exactly the kind of behavioral context agents need.

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

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

Three concise sentences, each adding distinct value: paging behavior, data fidelity, and offset semantics. The most important information is front-loaded and there is no filler.

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

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

For a paginated read-only history endpoint with an output schema available and a single required parameter, the description covers the key behavioral ambiguities: source order, pagination, and what the data does not represent. Nothing critical 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 low at 33%, but the description compensates for the offset parameter by explaining that offset zero is the beginning of source order and not necessarily newest. The limit parameter is adequately constrained by the schema's default and bounds, and order_book_id is already described 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 description opens with a specific verb and resource: 'Page shortSellingHistory in source order'. This makes the tool's function immediately clear and distinguishes it from the sibling tools, none of which target short-selling history.

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

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

The description gives clear context: this is a paginated history endpoint in source order, not a full-history dump or latest-value summary. It does not name explicit alternatives, but the scope is precise enough that an agent can decide when to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: pagination in source order, absent fields omitted, no normalization applied, and units/record details upstream-defined. This goes beyond the annotations and helps the agent set expectations about the returned data.

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-loaded with the core purpose, then adds routing guidance and behavioral caveats. Every sentence adds information; there is no filler. It could be slightly more structured, but it is appropriately sized for a tool with 5 parameters and multiple selection modes.

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

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

Given the output schema exists and the annotations cover safety, the description covers the key decision points: what this tool returns, how pagination works, what is excluded, and how to route to alternatives. It does not explicitly state when to use this tool versus get_company_financials beyond the dividends/financial-statements note, but the sibling list and the description's specificity make the boundary reasonably clear.

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

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

Schema description coverage is only 20%, so the description must compensate. It explains the 'metric' parameter with examples (priceEarningsRatio, earningsPerShare) and clarifies that available_metrics lists the selected section's names. It also explains the 'selection' parameter by enumerating the ratio categories. The order_book_id parameter is described in the schema itself, so the description doesn't need to repeat it. This is strong compensation for the low schema coverage.

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

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

The description states a specific verb ('Get'), a specific resource ('one named metric within a ratio section'), and the pagination behavior ('paginated in source order'). It also names the selection variants (annual, quarterly, quarter-over-quarter, TTM, company annual ratios) and gives concrete example metrics, which distinguishes it from sibling tools like get_company_financials and get_dividends.

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

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

The description explicitly says 'For dividends or financial statements use the dedicated tools,' which routes the agent away from this tool when appropriate. It also clarifies that sibling series and keyRatios summary sections are intentionally excluded, so the agent knows not to expect aggregated data here.

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 the tool read-only, idempotent, and non-destructive. The description goes well beyond that by revealing important behavior: raw points without aggregation, source ordering, pagination semantics relative to the selected period, response metadata covering the full upstream period, isolation of upstream fields under 'data', and the real-time freshness caveat. This is substantial added 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 description is four dense sentences with no filler. The core purpose is front-loaded, and each subsequent sentence adds a distinct piece of behavioral or structural information that an agent needs for correct use.

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

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

Given the output schema exists and the annotations cover safety, the description provides the remaining necessary context: pagination semantics, metadata boundaries, response field isolation, and freshness limitations. An agent has enough information to select and invoke the tool correctly.

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

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

Schema coverage is low at 25%, so the description must compensate. It does partially by explaining the offset/limit relationship to time_period and clarifying that they do not form a date range. The order_book_id parameter is already described in the schema, but limit and time_period get little semantic help beyond defaults and enum values. The description adds meaningful interpretation for the pagination parameters, though not exhaustive detail for every parameter.

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

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

The description uses a specific verb and resource: 'Get a page of raw stock OHLC points in source order, without aggregation.' This clearly distinguishes the tool from siblings like get_stock_quote or get_stock_info by emphasizing raw, unaggregated OHLC data. It also frames the tool as paginated, which is a distinct behavior.

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

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

The description gives clear usage context by explaining that offset/limit slice the selected period rather than a date range, and that data is not guaranteed real-time. It does not explicitly name alternatives or state when not to use the tool, but the semantics are clear enough for an agent to infer appropriate 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: 'Data is not guaranteed real-time' and the fact that it returns identity/listing/company/ratios plus latest quote. This helps the agent set expectations about data freshness and scope.

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

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

Three sentences, each earning its place: the first defines scope, the second gives discovery and alternative routing, the third sets data-freshness expectations. No filler or repetition of schema details.

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

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

For a single-parameter read-only tool with a rich output schema, the description covers the essential context: what the tool returns, how to obtain the ID, when to prefer a sibling, and data freshness. The output schema handles return-value details, so nothing critical is missing.

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

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

Schema coverage is 100%, so the schema already documents the parameter. The description adds meaning by explaining the parameter's role in the discovery flow ('Use search_instruments to select an order_book_id') and the schema itself clarifies it is not the separate instrumentId. This goes beyond the raw schema and helps the agent supply the correct value.

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

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

The description states a specific verb ('Get') and a clear resource ('stock identity, listing, company, ratios and latest available quote'), which distinguishes it from pricing-only tools like get_stock_quote. It also names the discovery tool (search_instruments) for obtaining the required ID, making the tool's role unambiguous.

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

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

The description explicitly tells the agent when to use this tool vs alternatives: 'For pricing only, prefer get_stock_quote' and 'Use search_instruments to select an order_book_id.' This is direct routing guidance that prevents misuse and clarifies the discovery workflow.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable caveats beyond annotations: not guaranteed real-time, inspect isRealTime/upstream timestamps, and the semantics of null vs. zero. This meaningfully helps the agent interpret results.

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

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

Every sentence earns its place: the first states the purpose and scope, the second adds a real-time caveat, the third clarifies null/zero semantics. No filler or repetition of schema content.

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

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

For a single-parameter, read-only tool with an output schema and rich annotations, the description provides all essential context: what data is returned, what is excluded, real-time limitations, and how to interpret missing vs. zero values. Nothing critical is missing.

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

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

Schema description coverage is 100%, and the schema already explains that order_book_id is an Avanza order-book ID, not the separate instrumentId. The description does not add new parameter-level detail, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Get'), a resource ('stock prices and trading data'), and a scope ('without company details'), which clearly distinguishes it from company-focused siblings like get_stock_info or get_stock_analysis. It does not explicitly name a sibling, but the purpose is unmistakable and not a tautology.

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

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

The description implies when to use the tool: when you need price/trading data but not company details, and when real-time accuracy is not required. However, it does not explicitly point to an alternative or give an exclusion ('use get_stock_info for company details'), leaving some inference to the agent.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description does not need to restate safety. The only extra behavioral note, 'detail fields are intentionally flexible,' largely repeats what openWorldHint already communicates, and no error, variation, or response semantics are disclosed beyond that.

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 one short, front-loaded sentence with no filler. The sibling distinction and flexibility caveat each earn their place, though 'beyond info' could be more explicit about what 'extended' means.

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 one well-documented parameter, safety annotations, and an output schema present, the tool is easy to invoke safely. However, the description does not clarify what 'extended details' include or provide practical guidance on when to choose this over get_warrant_info, leaving a real gap despite the schema richness.

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

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

Schema description coverage is 100%, and the schema already explains that order_book_id is the Avanza order-book ID from discovery and not the separate instrumentId. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

Description uses a specific verb ('Get') and resource ('warrant details') and distinguishes itself from the sibling get_warrant_info by saying 'beyond info'. However, 'extended ... beyond info' is imprecise about what extra fields or data are actually returned.

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

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

The phrase 'beyond info' implies this tool is for callers needing more than get_warrant_info provides, but there is no explicit when-to-use or when-not-to-use statement, and no alternative is named. The agent must infer the selection 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, idempotentHint, and destructiveHint, so the safety profile is covered structured data carries the burden. The description adds meaningful behavioral context beyond annotations: 'not guaranteed real-time' is a data-freshness behavior that materially affects invocation expectations. This goes 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 description is a single concise sentence with zero filler: purpose and caveat each earn their place and are front-loaded. No redundant phrases or needless elaboration are present, making it a model of concise yet informative writing.

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

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

Given the low complexity (one required parameter, output schema available, no nested objects), the description plus structured fields is quite complete. The purpose, identity-latest-data scope, freshness caveat, and param semantics are all covered. It falls slightly short only in not explicitly routing to siblings for real-time use cases, which was already penalized in usage_guidelines.

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

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

Schema description coverage is 100% and the parameter is well documented with the crucial 'Avanza order-book ID from discovery; not the separate instrumentId' note. The tool description itself adds no parameter semantics beyond the schema, so the baseline 3 applies per the rubric since the structured data already carries the 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?

Description states a specific verb and resource with concrete scope: 'Get warrant identity and latest available market data'. It conveys what the tool returns, though it does not explicitly differentiate itself from the very similar sibling get_warrant_details. The non-real-time caveat further sharpens the meaning, earning a 4.

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 over alternatives like get_warrant_details or get_orderbook. The 'not guaranteed real-time' caveat implies a limitation for live-data use cases, but no alternative is named and no exclusionary context is provided. This leaves the agent to infer usage entirely on its own.

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=true, idempotentHint=true, destructiveHint=false), so the description adds genuine behavioral value beyond them: server-side pagination behavior, the ISO YYYY-MM-DD date format requirement, and the notable disclosure that 'the matrix response retains flexible upstream fields, not an invented flat schema.' This last point is genuinely useful and non-obvious behavioral context for handling the response. No contradiction with annotations.

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

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

Two dense sentences, both front-loaded and purposeful. The first sentence gives the core purpose and key constraints (pagination, date format); the second adds the sibling routing hint and the response-shape caveat. No wasted words, every sentence earns its place.

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

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

Given an output schema exists (so return values are covered), annotations are complete, and the sibling pointer handles filter vocabulary, the description is quite complete. It covers pagination, date format, and the non-flat response shape. Minor gaps remain: no statement of what defaults return in practice or how filter params combine, but these are inferable from schema defaults and the sibling pointer.

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 effectively 0%, so the description must compensate. It does add meaning for end_dates (ISO YYYY-MM-DD format, beyond the schema's generic 'format: date') and for limit/offset (server-side pagination). However, it does not explain semantics for option_types, sort_field, sort_order, or the relationship between filters, which the sibling pointer only partially addresses. The description partially compensates for the coverage gap but not fully.

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: 'Select futures/forwards with server-side pagination and ISO YYYY-MM-DD end dates.' This clearly identifies it as a list-style query tool for futures/forwards, distinguishable from singular siblings like get_future_forward_info and get_future_forward_details. It doesn't explicitly name a sibling it is not, but the plural resource and reference to get_future_forward_filter_options provide adequate 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?

The description gives an explicit routing pointer: 'Use get_future_forward_filter_options for current filter vocabulary,' telling the agent which sibling to consult for valid filter values before using this tool. It provides clear context for when the tool is appropriate (selecting futures/forwards with pagination) but lacks explicit when-not guidance versus the info/details siblings. Clear context with one alternative pointer, no exclusions.

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

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

Even with annotations already declaring readOnly, openWorld, idempotent, and non-destructive behavior, the description adds substantial behavioral detail: at most 50 candidates per page, upstream vs local filtering, exclusion of FAQ/unknown types/invalid IDs, ordering of type/ID filtering before limit, and precise meaning of totalNumberOfHits, candidatesExamined, and upstreamTotalNumberOfHits. It also discloses that no additional pages are fetched and that search is not an authoritative registry.

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 dense but mostly front-loaded, with the core purpose in the first sentence and behavioral caveats following. Every sentence contributes real information, though a few expressions like 'All excludes FAQ' are terse enough that they may require a second read.

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

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

The description provides strong coverage of search scope, page size, filtering order, hit-count semantics, and limitations, and the output schema exists so return-value documentation is not needed. It lacks only an explicit routing statement about when to prefer this search tool over filter_* or get_*_details siblings, and it does not give query syntax examples for combined filters.

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

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

With 0% schema description coverage, the description compensates by explaining query semantics ('names, tickers or ISINs', 'Select by name, type, exchange, ISIN and currency') and by clarifying limit and instrument_type behavior ('One page of at most 50 candidates', 'stock/fund filtering upstream; other types are filtered locally'). It does not provide a precise syntax for combining the query fields, so some parameter behavior remains underspecified.

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

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

The description begins with a specific verb+resource construction: 'Search names, tickers or ISINs and return compact instrument identities.' It clearly distinguishes the tool from the many sibling get/filter tools by emphasizing that it returns search results and identities rather than deep instrument details. The closing caveat, 'Search is not an authoritative ID registry,' further differentiates it from ID-resolution tools like get_instrument_by_order_book_id.

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 text gives clear context about what kinds of lookups are supported: search by name, type, exchange, ISIN, or currency, while warning that rank alone should not be the sole selection criterion. It does not explicitly name sibling alternatives such as filter_etfs or get_stock_info, so the when-to-use-vs-alternatives guidance is mostly implied rather than explicit.

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