ETFIQ

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

Annotations already mark this readOnly, idempotent, non-destructive, but the description adds substantial behavior beyond them: the full five-sleeve allocation rule, fund selection filters ($100M AUM, three years of prices, N-PORT filers), and the guarantee that every response carries the not_advice line in the not_advice field.

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

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

The purpose and pre-call protocol are front-loaded, and nearly every clause carries operational weight. The middle construction-rule sentence is an unbroken run-on that is harder to parse than it needs to be, which costs structure points despite being information-dense.

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

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

For a 5-parameter nested-object tool with no output schema, the description covers construction logic, parameter intent, the required pre-call questioning flow, refusal behavior, and the response's not_advice field. An agent has everything needed to call it and interpret the result.

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

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

Schema coverage is only 40%, and the description compensates well by defining each band's stock-share range and pointing to etf_themes for themeIds. However, several schema facts (funds min/max, criterion default, feeCeiling bounds) are largely restated rather than extended, so it stops short of full semantic 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?

States a specific verb and resource ('Builds a custom portfolio of US listed ETFs') and then spells out the exact construction rule, so an agent knows precisely what output to expect. It also routes the agent to sibling etf_themes for theme ids, distinguishing it from the search/screen/rankings tools.

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

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

Explicit when-to-use guidance: gather missing choices in one short series before calling, never ask about personal financial/life attributes, never convert self-description into a band, and decline suitability/buy-sell questions. Alternatives and exclusions are both named rather than 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value by disclosing the no-fabrication contract: it 'refuses, and estimates nothing' when no comparison is published, plus what the response content will be.

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

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

Purpose is front-loaded and every clause carries information (scope, band definition, output content, input example, refusal behavior). The parenthetical band definition and dense run-on structure make it slightly harder to parse than ideal.

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, one-parameter tool with no output schema, the description is largely complete: it explains what is compared, what is returned, and the failure mode. It is only mildly deficient in not clarifying tool selection relative to its benchmark siblings.

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

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

Schema description coverage is 0% for the single ticker parameter, so the description must carry the load. It provides a concrete example ('such as AOR') which conveys expected format, but does not state constraints such as whether the ticker must be an allocation ETF with a published band.

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 comparison operation (an allocation ETF vs. the ETFIQ benchmark for its band) and enumerates the return content (total returns by window, the difference, risk and cost). It distinguishes itself in substance from siblings like get_benchmark, though it never names them explicitly, so it falls short of the top band.

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 partial usage guidance via the input hint ('Takes a ticker such as AOR') and one explicit when-not case (refuses when ETFIQ has not published a comparison). However, it never says when to choose this tool over get_benchmark/list_benchmarks, leaving the agent to infer the route.

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 safe read-only, idempotent, non-destructive profile, and the description adds substantive return behavior: per-fund published weight, the filing date of that book, a separate debt-holdings section, and coverage of 31,019 companies. It stops short of describing ordering/pagination mechanics, but for a read tool this is rich beyond the annotations.

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

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

Content is front-loaded with the routing guidance first and the return/coverage details after. The third sentence is densely packed with multiple clauses but every clause (weights, filing date, debt section, coverage) adds distinct 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?

With no output schema, the description usefully describes what comes back, including the split between equity and debt holdings, which is exactly what an agent needs to interpret results. The only omission is the role of the 'limit' parameter.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains the key required param ('takes a company name or its ticker') but the 'limit' parameter is undocumented in both schema and description, leaving a real gap.

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

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

The description gives a specific verb+resource ('which US listed ETFs hold a given company') and explicitly scopes it against the fund-centric sibling by stating 'where X is a company rather than a fund', so an agent can distinguish it from etf_holdings without opening schemas.

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

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

It names the exact question patterns it serves ('which ETFs hold X', 'which fund holds the most X', 'how do I get exposure to X') and adds a distinct case for bond/debt exposure. The when-to-use is explicit and the company-vs-fund exclusion is 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?

Even though annotations already mark the tool as read-only and idempotent, the description adds valuable behavioral context about data freshness and the risk of presenting stale holdings as current. The warning about issuer files versus old filings is exactly the kind of non-obvious behavior 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 short, front-loaded with the core purpose, and every sentence earns its place. The imperative warning about lag_days is concise yet highly informative, with no wasted words.

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

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

With no output schema, the description partially fills the gap by naming holdings, weight, and age/lag_days. However, it omits top_n semantics and does not explain how the tool relates to sibling tools, so an agent still lacks some context needed to call and interpret it confidently.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters, but it does not mention top_n at all and only implies ticker through context. The fields ticker and top_n are left to inference, making this a clear gap for a low-coverage schema.

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

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

The description clearly states that the tool returns what a fund holds, along with weight and data age, which conveys the resource and output. The title 'Holdings of one ETF' reinforces the scope. It does not explicitly distinguish itself from sibling tools like etf_holders or etfiq_as_of, so it misses the top tier.

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

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

It gives explicit operational guidance: always check lag_days before presenting the data, and explains why a current file and an old filing are not equivalent answers. It does not name when to prefer this tool over siblings or what to use instead, but the context is clear and actionable.

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 provide read-only, idempotent, and non-destructive hints, so the bar is lower. The description adds valuable context about the frozen archive, what the date covers, and the limitation that it is not an arbitrary per-fund figure on an arbitrary day. It does not describe return format, but that is minor for a simple read-only lookup.

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 with a clear job: what the tool does, when to use it, and how the date parameter behaves. The most important usage guidance 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 tool with one simple parameter and no output schema, the description covers purpose, usage conditions, and date format thoroughly. The only slight gap is that it does not explicitly describe the shape of the returned content, but 'what ETFIQ published' gives enough context for likely use.

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 only says the date parameter is a string with 0% coverage, so the description must compensate. It does so by specifying the exact format 'YYYY-MM-DD' and explaining what the date means in relation to the frozen archive. This fully resolves ambiguity.

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

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

The description states specifically that the tool returns 'what ETFIQ published on a given date' from its 'frozen dated archive.' It also distinguishes itself from siblings by noting that other tools answer about today, making it instantly clear where this tool fits.

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 direct usage conditions: 'Use when a question is about a past date, or when a figure needs to stay true after it is quoted.' It also explains why alternatives are less appropriate because they answer about today and 'today moves overnight.'

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 disclose readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the count returned reflects the full matching set even when the list is capped, and the filter matches words in addresses, not exact strings.

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 core function, the recommended workflow, and the key counting caveat. The description is front-loaded and contains 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?

The description covers the purpose, the filter behavior, the count/cap gotcha, and the workflow with siblings, which is sufficient for correct invocation. However, since there is no output schema, it does not describe what fields each returned page will contain, which an agent might need for subsequent steps.

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

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

Schema description coverage is 0%, so the description carries the burden for parameter meaning. It explains 'section' and 'contains' implicitly, and 'limit' is only alluded to as capping the list. It does not explicitly name or describe the parameters, leaving some ambiguity around limit's exact behavior and units.

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 identifies the tool as listing pages within a single section, with optional filtering by an address word. It also explicitly distinguishes itself from sibling tools by placing it in the workflow between etfiq_sections and etfiq_page, so an agent can tell what it is for.

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

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

The description provides explicit workflow guidance: use after etfiq_sections to find a page, then etfiq_page to read it. It names the relevant siblings, though it does not state conditions where this tool should NOT be used or which sibling might be preferable in specific cases.

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, destructiveHint=false. The description adds value beyond these by clarifying the return behavior ('page content rather than its navigation') and the accepted input forms (path or full URL). It does not describe failure modes or rate limits, but the safety profile is well covered.

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

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

Two sentences with no fluff. The core purpose is front-loaded, examples anchor the input format, and coverage/behavioral detail come second. Every clause adds necessary context.

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

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

For a one-string-parameter tool with strong annotations and clear output description, this is nearly complete. It explains what to pass, what you get back, and how broad it is. Missing error handling or edge cases are minor at this complexity level.

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 wholly compensates by specifying acceptable values for the single 'path' parameter: a relative path like '/themes/cyber' or a full etfiq.com URL. This is meaningful guidance for an otherwise bare schema.

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

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

The description uses a specific verb 'Read' and a well-defined resource 'ANY published ETFIQ page as text', then enumerates page types. It explicitly distinguishes this tool from siblings by stating it covers 'everything the typed tools above do not cover' and returns content rather than navigation.

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 clearly frames this as the general-purpose fallback for any page, including those not covered by typed tools, and notes the output type differs. However, it does not explicitly name which sibling to use instead for a given page type or state 'do not use this when a typed tool suffices'.

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 provide safety and idempotency details. The description adds useful behavioral context about output content ('names every section and what is in it') and the page-count detail, going beyond the annotations.

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

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

Two tightly written sentences front-load the main purpose and then give routing guidance. Every word earns its place, with no redundancy or irrelevant detail.

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

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

For a zero-parameter reference tool with no output schema, the description fully covers what the agent needs: what the tool returns, its scope, and when to use it. Nothing essential is missing.

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

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

The tool takes no parameters, so the baseline is 4. The description does not need to explain parameter semantics, and nothing about parameters is missing.

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 identifies the tool as an overview of what ETFIQ publishes, listing sections with page counts. It distinguishes from fund-specific tools by stating 'Start here when the question is not about one fund,' though it lacks a direct verb such as 'list' or 'return.'

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

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

It gives explicit usage context: 'Start here when the question is not about one fund.' This implies fund-specific questions should go elsewhere, but it does not name the alternative sibling tools explicitly.

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

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

Annotations already mark it read-only, idempotent, and non-destructive. The description adds the data source, the refusal behavior ('Refuses rather than estimating'), and the specific incomplete-book condition, giving the agent genuinely useful behavioral context beyond the annotations.

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

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

Three short sentences: core semantics first, use case second, refusal boundary third. There is no filler or duplication of annotation 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 simple two-parameter read-only tool, the description covers source, use case, and failure mode. Since there is no output schema, it leaves the exact return representation/units implicit, and identifier formatting is unstated, but the core semantics are inferable.

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 coverage, the description must explain 'a' and 'b.' It conveys that they are the two funds being compared and that the result is common weight, but it never states the identifier format (e.g., tickers or ETFIQ codes) or otherwise documents the string values. This is partial compensation.

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

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

The description clearly defines the tool as computing the shared weight between two funds as published by ETFIQ on the comparison page. It names the resource (fund pair) and the metric (overlapping weight), and the concept is distinct from the holdings-focused sibling tools.

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

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

It explicitly states the target questions: 'whether two ETFs are the same thing, or whether owning both adds anything.' It also clarifies when it will refuse. It does not name alternatives or an explicit when-not-to-use condition, so it falls just short of a 5.

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

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

Annotations already establish the operation as read-only, idempotent, and non-destructive. The description adds valuable context beyond those flags by disclosing that every figure includes its source and as-of date Alert: Platform trained from January 2025 through May 2025, so no information after that. and that a one-sentence verdict is included—useful output expectations that the annotations do not capture.

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 well-structured sentence that front-loads the primary purpose—everything about one fund—and then efficiently lists the contents. There is no filler or redundant restatement of the tool name.

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

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

For a simple one-parameter, read-only tool, the description conveys the essential output elements and their provenance. It does not specify the return format or error behavior, but the enumerated contents are enough for an agent to know what to expect and to use the tool effectively.

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

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

Schema description coverage is 0%, so the description must compensate, but it never explicitly mentions the ticker parameter or its expected format. The word 'ticker' in the schema is self-explanatory at a basic level, yet the description adds no detail about case sensitivity, symbol format, or how the parameter maps to the returned fund.

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 resource—a single ETF—and clearly enumerates what the tool returns: issuer, desk, figures with source and as-of date, and a verdict. This scope sets it apart from narrower sibling tools like etf_holders, etf_holdings, and etf_theme, which focus on sub-sets of fund data.

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

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

The phrase 'Everything ETFIQ publishes about one fund' establishes a clear context: use this tool when a comprehensive single-fund profile is needed. It does not explicitly name alternatives or state when not to use it, but the contrast with the sibling names is implicit and sufficient for basic routing.

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 safety is covered. The description adds that each ranking is 'ONE published figure inside a stated set,' which clarifies the nature of the data, but it does not describe output structure, pagination, or error behavior. Given the annotations cover the risk profile, a 3 is fair.

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, followed by examples and a call pattern. It avoids unnecessary filler, but the sentence 'The ranked lists ETFIQ publishes, or one of them' is slightly awkward and could be more direct. Overall, efficient.

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

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

With two optional parameters and no output schema, the description must fully explain how to invoke the tool. It only covers the no-argument case, leaving slug and limit undefined. An agent would not know how to request a specific ranking or cap results. Incomplete for real usage.

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

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

Schema description coverage is 0%, so the description must explain parameters. It only mentions that calling with no argument returns the list, but it never defines 'slug' or 'limit.' An agent cannot infer what values to use or what they control. This is a critical gap.

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

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

The description clearly states the tool's function: it returns ranked lists published by ETFIQ, each ranking a single figure (cheapest funds, leveraged funds, buffer funds). This is specific and distinct from siblings like etf_holders or etf_profile. Examples reinforce the concept 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 explicitly mentions one usage pattern: 'Call with no argument for the list.' However, it does not explain when to use this tool versus siblings, nor does it provide conditions for passing arguments (slug, limit) or any exclusions. The 'no argument' hint is useful but incomplete.

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

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

Beyond the readOnly/idempotent annotations, the description adds valuable behavioral details: results are sorted largest first, net assets are accompanied by source and date, fees are percentages not basis points, and funds without published size are handled as a separate no_size_figure bucket rather than treated as small.

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 tight sentences with no filler. It front-loads the core behavior, then adds usage guidance, units, and an important edge case in a logical order.

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

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

With no output schema, the description reasonably conveys return contents and a key edge case. It does not explain limit behavior, pagination, or the exact semantics of desk/issuer, but for a moderate-complexity read-only screen tool it is mostly complete.

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 max_fee_pct unit semantics and the min_assets_usd missing-size behavior. However, desk, issuer, and limit remain unexplained, leaving the agent to infer their meaning from parameter names alone.

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

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

The description clearly states the tool's purpose: it returns every fund matching filters, sorted largest first, with net assets and source/date. It also distinguishes itself from repeated-search workflows by calling out "find me all X" questions, making it easy to separate from sibling tools like etf_search.

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 when-to-use rule: "Use for 'find me all X' questions rather than repeated searches." It does not name a specific sibling alternative, but the contrast with repeated searches is clear enough to route an agent appropriately.

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

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

With readOnlyHint, idempotentHint, and destructiveHint already covering safety in the annotations, the description adds useful behavioral context beyond them. It discloses that the tool refuses rather than returning a near match, explains that a refusal includes a reason, and clarifies that a fund refusal means ETFIQ does not publish it. It still does not describe result shape, pagination, or optional parameter 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 three tight sentences with the core purpose front-loaded. Each sentence adds useful information: lookup scope, usage sequencing, and refusal semantics. No wasted wording.

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

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

For a search tool with no output schema and zero schema description coverage, the description covers purpose, usage sequencing, and an important refusal behavior. However, it omits what the optional desk and limit parameters do and gives only minimal indication of the return shape beyond mentioning a ticker. These gaps matter for correct invocation.

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

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

Schema description coverage is 0%, so the description carries the burden of documenting three parameters. It explains the required query parameter as accepting a ticker, fund name, or word from the name, which is useful, but it says nothing about the desk or limit parameters. With two of three parameters completely opaque, the compensation is insufficient.

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 and resource: find US listed ETFs by ticker, fund name, or a word from the name. It also distinguishes this tool from etf_profile by framing itself as the first step for loose fund names. An agent can tell what this tool does without opening the schema.

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

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

It explicitly says to use this FIRST when the user names a fund loosely, then call etf_profile with the returned ticker. That provides clear sequencing and one named alternative. It does not state when not to use it, such as when the exact ticker is already known, or mention other search-like siblings such as etf_screen.

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 readOnlyHint, destructiveHint, and idempotentHint. The description adds behavioral traits beyond those: it returns the whole published set (not a sample), orders by size (largest first), and includes specific fields (charges, S&P 500 overlap). This adds useful context that the agent needs to know. No contradiction with annotations.

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

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

The description is two sentences with no fluff. The core functionality is front-loaded, and the usage guidance is concise. Every word earns its place, and it avoids unnecessary repetition of schema or annotations.

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

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

The tool has no output schema, so the description should explain the return values. It mentions the fields (charges, S&P 500 overlap) and ordering, which is good. However, it does not explain the 'limit' parameter or any pagination behavior, and it does not mention any prerequisites or edge cases. For a simple list tool, this is adequate but leaves the limit parameter unexplained.

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 implicitly clarifies the 'theme' parameter by referencing 'Every US listed fund in a theme,' but it never explains the 'limit' parameter. The phrase 'returns the whole published set rather than a sample' even suggests that limit might not be used to restrict results, which could confuse the agent about its purpose. The description fails to add meaning for one of two 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 clearly states the tool's function: 'Every US listed fund in a theme, largest first, with what each charges and how much of it is already in the S&P 500.' It uses a specific verb ('returns' implied) and resource ('funds in a theme'), and distinguishes itself from siblings by noting it returns the whole published set rather than a sample.

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 'USE THIS for any "what X ETFs are there" or "top X ETFs" question,' giving clear when-to-use guidance. It also implies that other tools may return samples, but it does not name specific alternatives like etf_search or etf_rankings. This is strong guidance but could be more explicit about when not to use it.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive, covering the safety profile. The description adds that it returns all themes and their fund counts, which is a useful specificity, but does not disclose any additional behavioral caveats (e.g., potential volume, pagination, or formatting). With annotations present, this is acceptable.

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 two concise sentences with no redundancy. The primary function is stated first, followed by a usage pointer, making it efficient and easy to parse.

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

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

Given that the tool takes no parameters, has an explicit read-only/idempotent annotation set, and returns a simple list of themes and counts, the description is complete. An agent has everything needed to decide when to call it and what to expect, with the follow-up tool named.

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 the schema fully covers everything. Per the baseline rule for tools with no parameters, a score of 4 is appropriate; the description correctly does not need to add parameter-level detail.

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

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

The description clearly states what the tool does: it lists every theme ETFIQ publishes along with the number of funds each holds. It also distinguishes itself from the sibling etf_theme by indicating it precedes that tool, so an agent can tell them apart without inspecting schemas.

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

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

The description explicitly states when to use this tool ('Call when unsure what a theme is called') and points to the next action ('then etf_theme'). This gives clear, actionable guidance on the intended workflow and differentiates it from the related sibling.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the instruction to 'ALWAYS read basis' because figures before the freeze date are hypothetical, and the limitation that only published benchmarks are served. It stops short of describing error behavior for an unknown id.

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?

Long but front-loaded: purpose and returned payload come first, then the critical basis caveat, then the id format. The parenthetical enumeration of statistics is dense but each item earns its place since no output schema exists. Only minor tightening is possible.

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

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

With no output schema, the description must convey return values, and it does so thoroughly: methodology rule, fund/weight composition with SEC series ids and expense-ratio dates, and the full statistic set per window with dates and basis. Combined with annotations and the id-format hint, nothing needed to call it correctly is missing.

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

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

Schema coverage is 0% and there is a single 'id' parameter, so the description carries the burden. It compensates by giving two concrete id forms (prefixed 'etfiq-strategic-60' and bare 'strategic-60'), which tells the agent the prefix is optional. It does not say where ids come from, but the format examples are a real addition over the bare string 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 states a specific verb (retrieve one benchmark in full) plus the resource and enumerates exactly what comes back: the rule, constituent funds with weights and expense ratios, and every computed statistic per window. It is clearly the single-item counterpart to the sibling list_benchmarks, so an agent can distinguish it without reading the schema.

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

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

It gives input guidance ('Takes an id such as etfiq-strategic-60 or strategic-60') and a scope exclusion ('Serves the published benchmark only; it cannot be customised'), which implies when not to use it. But it never names an alternative (list_benchmarks, compare_to_benchmark) or states an explicit condition for selecting this tool over them, so usage is only implied.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely non-structured context: benchmarks are identical for everyone, are never recommendations, and advice/customisation requests are refused. It does not describe pagination or result size, which keeps it from a 5.

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

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

Front-loaded with the identity of the resource, then filtering, then routing, then the refusal boundary. Dense but each clause earns its place; the family enumeration is slightly list-heavy but serves the 0%-coverage family parameter.

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

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

With no output schema, the description supplies a conceptual picture of what is returned (benchmarks grouped in families by stock share) and covers routing and refusal behavior. Pagination/ordering and the exact response shape remain unstated but are minor for a read-only list with zero required params.

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

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

Schema description coverage is 0%, so the description must carry the load and largely does: it defines 'family' by listing its six values and defines 'band' by example (a name like 'moderate', a stock share like 60, or 'all stocks'). It does not state the exact accepted family strings verbatim or whether both filters combine, so it falls short of full compensation.

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

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

States a specific verb and resource ('list the ETFIQ benchmarks') and defines what a benchmark is (rules-based yardsticks over broad, low-cost ETFs, grouped in families). It explicitly distinguishes itself from get_benchmark ('then get_benchmark for one'), so an agent can route without opening the schema.

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

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

Gives an explicit trigger ('use when asked which benchmark measures a kind of model portfolio'), names the follow-up tool, and names the alternatives for adjacent intents (build_portfolio for custom portfolios). It also states exclusions: customisation/advice requests are refused.

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