ETFIQ

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

With no annotations, the description carries the burden. It discloses a key behavioral trait: the data can be stale and lag_days must be checked. It also hints at two different data sources (issuer file vs filing) that produce different answers. This is valuable beyond the schema.

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

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

Two sentences, front-loaded with the core purpose and a critical warning. The warning is emphasized with 'ALWAYS'. No wasted words, though the second sentence is a bit 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?

The description covers the core purpose and a critical caveat, but with no output schema and no parameter documentation, an agent may not know what top_n does or what the return structure looks like. The lag_days warning is helpful but incomplete for a tool with 0% schema coverage.

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 explains the meaning of the output (holdings by weight, age) but does not explain the parameters: ticker is obvious, but top_n is not described at all. The description adds no parameter-level 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?

The description states a specific verb+resource: it returns what a fund holds, by weight, and the age of that data. It distinguishes itself from siblings by emphasizing the holdings/weight focus and the lag_days caveat, 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 gives clear context: ALWAYS read lag_days before presenting the data, and warns that issuer file reads and filings are not the same answer. It doesn't explicitly say when to use this tool vs alternatives, but the lag_days instruction is a strong usage guideline.

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 no annotations provided, the description carries the behavioral burden. It discloses that the data comes from a frozen dated archive, covers pieces written that night, and is not a per-fund lookup. It could go further by describing the response shape, but for a simple archive retrieval it is reasonably transparent.

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 short sentences, each earning its place: function, usage condition, input format, and scope caveat. It is front-loaded and contains no filler or repetition.

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

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

For a one-parameter tool with no output schema, the description is complete: it explains what the tool returns, when to use it, how to format the date, and a key boundary. Nothing necessary 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 only parameter, date, has no schema description and 0% schema coverage. The description fully compensates by specifying the exact format 'YYYY-MM-DD' and clarifying that the date selects what ETFIQ published on that date. This is far more than the input schema alone provides.

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

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

The description clearly states the tool's function: retrieving what ETFIQ published on a given date from a frozen dated archive. It also differentiates itself from sibling tools by noting that every other tool answers about today, making the temporal scope unmistakable.

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 when to use the tool: for past-date questions or when a figure needs to remain stable after being quoted. It also contrasts with 'every other tool here' and includes an exclusion ('not an arbitrary per-fund figure on an arbitrary day'), which helps an agent route correctly.

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

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

With no annotations, the description must carry behavioral disclosure on its own. It reveals a non-obvious behavior: the returned count reflects the full matching set even when the list itself is capped. For a simple read-only listing tool, this is meaningful and sufficient, although it does not describe defaults or output format.

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, each earning its place: the scope, the workflow, and the important cap/count caveat. No filler or repetition of schema fields.

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 3-parameter list tool with no annotations and no output schema, the description covers purpose, workflow, and the key behavioral quirk. It falls slightly short on explicitly connecting 'limit' to the cap and specifying what list items contain, but the workflow and sibling tools keep it practically usable.

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 prose must explain the parameters. It conveys the meaning of 'section' (the enclosing section) and 'contains' (matching an address word), and the 'capped' phrase hints at 'limit', but the limit parameter is never explicitly named or defaulted, and matching details are left vague. This is adequate but 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 states a clear resource ('pages inside one section') and an optional address-word filter, and it differentiates the tool from etfiq_sections and etfiq_page by placing it in a workflow. It lacks an explicit imperative verb such as 'lists', relying on the tool name for that, which keeps it just 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?

It explicitly tells the agent to 'use after etfiq_sections to find a page, then etfiq_page to read it', giving an unambiguous sequence and naming the relevant sibling tools. This is stronger than merely implying a context, so it fully meets the when/alternative criterion.

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?

No annotations are present, so the description carries the burden of behavioral disclosure. It does establish that the tool is read-only and returns page content rather than navigation. However, it does not mention failure modes, authentication requirements, extraction caveats, or pagination behavior, leaving meaningful gaps.

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, each earning its place: the first defines the core purpose and gives examples, the second explains parameter format, and the third clarifies scope and output behavior. The most important information is front-loaded with no redundancy.

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

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

Given the low complexity of a one-parameter page reader, the description provides enough to select the tool, format the input, and anticipate the output. The main omissions are error handling and output format details, but the 'as text' and 'rather than its navigation' phrasing covers the essentials despite the absence of an output schema.

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

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

The schema provides only a bare string parameter with no description, but the tool description compensates well by explaining that `path` accepts either a relative path like /themes/cyber or a full etfiq.com URL. This adds concrete format guidance and an example beyond the schema, though it still does not specify URL edge cases.

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

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

The description opens with a specific verb-resource pair ('Read ANY published ETFIQ page as text') and gives concrete page-type examples. It also explicitly distinguishes this generic tool from the specialized siblings by stating it covers 'everything the typed tools above do not cover.'

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 conveys when to use this tool: for any published ETFIQ page, especially pages not covered by the other typed tools. It provides useful context for selection but does not explicitly name the alternatives or state when not to use it, so it falls just shy 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?

No annotations are provided, so the description carries the burden for transparency. It clearly implies a read-only listing operation, but it does not explicitly state that it does not modify data, nor describe output format or any potential side effects. For a zero-parameter listing tool, this is adequate but could be more explicit.

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 zero waste. The core purpose and usage guidance are front-loaded, and each sentence earns its place. It is concise without omitting essential 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 tool with no parameters and no output schema, the description fully explains what it returns (section list with page counts) and when to use it. No further details are missing for an agent to invoke it correctly.

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

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

There are no parameters, so schema coverage is 100% trivially. The description adds no parameter-specific details (there are none), but the baseline for zero parameters is 4 because there is nothing to document.

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 lists ETFIQ publication sections with page counts, and explicitly says 'Start here when the question is not about one fund,' distinguishing it from fund-specific sibling tools. This gives a specific verb ('start here'), resource (ETFIQ sections), and a clear differentiator.

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 an explicit when-to-use condition ('when the question is not about one fund') and implies that fund-specific tools are for single-fund queries, but it does not name specific alternatives like etf_profile or etf_holdings. Still, the guidance 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so well. It reveals that the tool will refuse to answer rather than estimate, and it explains the underlying data source (ETFIQ's comparison page). This is meaningful behavioral context an agent could not infer from the schema alone.

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

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

The definition is compact and front-loaded: the first sentence states the core result, the second gives the use case, and the third defines the refusal boundary. Every sentence earns its place, and there is no redundant or promotional language.

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-string-parameter tool with no output schema, the description covers what the tool does, when to use it, and when it will decline to answer. The remaining gap is parameter format and the exact output representation, but the refusal behavior addresses the most likely source of agent error.

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 has two unnamed string parameters with 0% description coverage, so the description needed to compensate. While 'two funds' and 'the pair' hint that a and b correspond to funds, the description never explains whether these should be tickers, ETFIQ IDs, names, or some other identifier, and it doesn't state that the tool is symmetric in parameter order.

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's function: reporting how much of their weight two funds hold in common, as published on ETFIQ's comparison page. It also gives concrete triggering questions ('whether two ETFs are the same thing, or whether owning both adds anything') that separate this pairwise tool from single-fund siblings like etf_holdings or etf_profile.

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 the tool—for overlap or redundancy questions between two ETFs—and clearly describes a when-not condition: it refuses rather than estimating when the pair is not compared or holdings data is incomplete. It does not name sibling tools as alternatives, but the usage context is strong enough to guide 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?

No annotations are supplied, so the description carries the burden. It implies read-only behavior by describing published data and specifies the content returned, but it does not state side effects, required access, error handling, or output structure.

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

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

Single sentence, front-loaded with the core scope ('Everything ETFIQ publishes about one fund') followed by useful granularity. 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 one-parameter read-only lookup, the description is mostly complete: it tells the agent what content to expect (issuer, desk, figures with source/as-of, verdict). However, with no output schema and no guidance on not-found or malformed ticker behavior, there is a small but real gap.

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 the description never mentions the `ticker` parameter explicitly; 'one fund' only weakly implies that the ticker identifies the fund. No format, examples, or constraints are provided for the 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 names a specific action scope — all ETFIQ-published data for one fund — and enumerates content categories (issuer, desk, figures with source/as-of, verdict). This clearly distinguishes it from multi-fund siblings like etf_rankings or etf_screen.

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 the tool is for single-fund deep-dive lookups ('one fund'), but it never names sibling tools or gives explicit when-to-use vs when-not-to-use guidance. An agent would have to infer that etf_holdings or etf_theme are more targeted 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?

No annotations exist, so the description must carry the disclosure burden. It does reveal useful behavior: a no-argument call returns the list, and each ranking is based on a single stated figure. But it does not state whether the operation is read-only, what a response contains, or how invalid slugs or limits behave.

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 with concrete examples and the default-call behavior included. It is concise and front-loaded with the core resource; the first sentence is slightly awkward ('or one of them'), but there is no padding.

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

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

With no output schema, annotations, or parameter documentation, the description leaves significant gaps: no accepted slug values, no limit semantics, and no indication of the response format. It is enough for a bare no-argument call but not for confident parameterized 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?

Schema coverage is 0%, so the description must explain 'slug' and 'limit'. It gestures at slug selection ('or one of them' / 'stated set') and says no-argument calls succeed, but it never names or describes the 'limit' parameter and provides no slug vocabulary.

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 a specific resource ('ranked lists ETFIQ publishes') and clarifies that each list ranks one published figure with concrete examples. It doesn't explicitly contrast with sibling tools, but the resource is distinct enough that a caller can tell this from 'etf_holdings' or 'etf_screen'.

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 'Call with no argument for the list' gives a clear default invocation, and the examples imply this is for published ranked lists rather than screening or search tools. However, it never states when to choose this over siblings like 'etf_theme' or 'etfiq_list', nor 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?

No annotations are provided, so the description carries the full burden. It discloses ordering ('largest first'), output provenance (source and date of the size figure), fee unit semantics, and the special handling of funds with no published size. Minor gaps remain around how limit interacts with 'every fund' and what desk filtering means.

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 dense, front-loaded sentences: core behavior first, usage trigger second, then two critical data semantics. Every sentence earns its place 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?

Given no output schema and no annotations, the description does substantial work: it covers output composition, ordering, units, and a tricky null-size edge case. The remaining ambiguity around limit and desk keeps it from being fully complete, but an agent can likely invoke it correctly with this information.

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 compensates for some parameters: 'Fees are percentages, not basis points' clarifies max_fee_pct, and the no_size_figure behavior clarifies min_assets_usd. However, desk, issuer, and limit are not addressed in the description, leaving a meaningful portion of the parameter semantics 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 clearly states the tool returns 'every fund matching some filters, largest first' with net assets and source/date, which is a specific screening behavior. It contrasts with 'repeated searches' but doesn't name sibling tools like etf_search, so sibling differentiation is implicit rather than explicit.

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

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

It explicitly tells agents to use this tool for 'find me all X' questions rather than repeated searches, which is a clear usage trigger. It doesn't enumerate when to prefer alternatives like etf_search or etf_holdings, so it stops short of a full when-to-use/when-not-to-use map.

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?

No annotations exist, so the description carries the behavioral burden. It usefully discloses that the tool refuses rather than returning a near match, and that it produces a ticker for downstream use. But it does not explain result shape, pagination, error modes, or side effects beyond refusal.

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 with no filler. The core capability, the handoff to etf_profile, and the strict matching behavior are all front-loaded and each 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 no output schema and two undocumented optional parameters, the description is incomplete. An agent cannot tell what desk controls, how limit affects results, or whether the response is a single ETF or a list. The refusal note and handoff help, but substantive operational gaps remain.

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% for three parameters. The description gives meaning only to query as a ticker, fund name, or name word. desk and limit remain entirely unexplained, so the description fails to compensate for the schema gap.

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

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

States the specific verb and resource: find US listed ETFs by ticker, fund name, or name word. It also positions itself against the sibling etf_profile, making it clear this is the first lookup step rather than a profile/ranking/holdings tool.

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

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

Explicitly says to use this FIRST when the user names a fund loosely and then pass the returned ticker to etf_profile. It provides a clear context trigger and an alternative, though it does not explicitly list when not to use it (e.g., exact ticker lookups).

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 no annotations, the description carries the burden of behavioral disclosure. It transparently describes output composition, ordering, and the complete-set behavior. However, it does not disclose how the optional limit parameter affects results or what happens for unknown themes.

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 and front-loads the core output and ordering. The all-caps 'USE THIS' is slightly noisy but efficiently adds usage routing.

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 list-style tool, it covers scope, ordering, and key output metrics. However, with no output schema and no annotations, the optional limit behavior and theme value semantics remain underspecified, which an agent needs to call it reliably.

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 for both parameters. It implies the meaning of 'theme' through 'in a theme', but the 'limit' parameter is completely unexplained, and no format or accepted values for theme are provided.

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 exactly what the tool returns: every US-listed fund in a theme, sorted largest first, with expense information and S&P 500 overlap. It distinguishes itself by emphasizing 'the whole published set rather than a sample', though it does not name sibling tools explicitly.

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

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

It gives an explicit instruction to use this tool for 'what X ETFs are there' or 'top X ETFs' questions, and clarifies that it returns the complete set rather than a sample. It lacks when-not-to-use guidance or named alternatives, which prevents a perfect score.

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 no annotations available, the description must carry the behavioral burden on its own. It does so by stating the full result set — every published theme and the count of funds in each — which implies a read-only enumeration. It does not specify response ordering or structure, but the no-parameter signature and simple list behavior make that a minor gap.

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, both substantive: the first states the resource and output, the second states when to call it and what to use next. No filler or repeated 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 parameterless tool with no output schema, the description gives everything needed to select and invoke it correctly: what it lists, what counts are included, and how it fits into the workflow with `etf_theme`. An agent can confidently call it without further context.

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

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

The tool has zero parameters, so schema coverage is trivially 100% and there is nothing for the description to add about argument meaning. The baseline for a parameterless tool is 4, and the description does not need to compensate for any schema gap.

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

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

The description clearly identifies the tool as a catalog of every theme ETFIQ publishes, with one concrete output: how many funds each holds. This distinguishes it from the sibling `etf_theme`, which is the follow-up lookup, and from `etf_search` and `etf_rankings`.

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

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

It gives an explicit trigger: 'Call when unsure what a theme is called', and names the next tool to use, `etf_theme`. This is direct when-to-use guidance and a clear pointer to the alternative, leaving no ambiguity about when this tool is appropriate.

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