cryptoetf

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds real behavioral context: the return is a time series of net USD millions per day, positive means inflow, negative outflow, and the window is fixed at 30 days.

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 tightly packed sentences, front-loaded with the core purpose and sign convention, closing with the sibling disambiguation. 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 no output schema, the description supplies the missing return-shape information (daily net USD millions, sign convention) and the fixed time window, leaving nothing essential unstated.

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

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

Schema coverage is 100% with a fully enumerated asset list, so the schema carries the parameter documentation. The description only reinforces 'single crypto asset' without adding format, default, or casing nuance beyond what the enum already 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?

States a specific verb+resource ('Get daily net ETF flow history for a single crypto asset'), a fixed scope (last 30 days), and explicitly distinguishes itself from the sibling get_fund_flows by noting this returns asset-level totals rather than per-fund breakdown.

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

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

Names the alternative (get_fund_flows) and the condition that selects it — per-fund detail. That is clear routing, but there is no explicit when-not guidance or mention of other siblings like get_flows_summary.

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

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

Beyond the readOnlyHint annotation, the description discloses the supported windows, the null-ratio behavior during ETF net outflows, the consecutive-week metric, and the exact methodology for converting USD net flows to BTC and counting mined BTC. These details are important for interpreting the result 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 dense but well front-loaded: it starts with the core comparison, then lists windows and metrics, then defines methodology. Every sentence contributes useful meaning, though the final methodology sentence is lengthy.

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

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

There is no output schema, so the description carries the burden of explaining return values. It does so thoroughly: available windows, each window's ETF net BTC, mined BTC and ratio, plus consecutive-week demand-above-supply counts and the last 12 weeks.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly focuses on the fixed analytical outputs rather than on nonexistent inputs.

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: net creations of US spot Bitcoin ETFs in BTC against newly mined bitcoin. This is clearly distinct from siblings like get_etf_holdings and get_fund_flows, which cover holdings and fund flows rather than ETF-vs-miner supply comparison.

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 makes the intended use clear by specifying the exact comparison and time windows, but it does not explicitly say when to prefer this tool over alternatives such as get_weekly_analytics or get_flows_summary. Usage is strongly implied rather than explicitly guided.

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, openWorldHint=false), and the description adds meaningful behavioral context: the weighting scheme, the 50/69/31 reference points, and the fear/greed zone mapping. It does not discuss caching, freshness, or latency, so it falls short of a full 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 definition before the methodology and zones, and every sentence carries information an agent needs to interpret the score. It is still dense at roughly 100 words for a zero-parameter tool, so it is slightly heavier than strictly necessary.

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 fully explain return values, and it does: scale anchoring, component breakdown with weights, and zone thresholds. Nothing an agent needs to call and interpret this tool is missing.

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

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

There are zero parameters, so the schema imposes no semantic burden and the baseline is 4. The description cannot add parameter meaning and does not attempt to.

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 ('Returns the composite CEFI'), defines the exact scope (US spot crypto ETFs, all 16 tracked assets) and the 0–100 scale, so an agent can tell it apart from the flow-oriented siblings 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?

No explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. Usage is only implied by the domain ('sentiment index' vs the raw-flow siblings), so the agent must infer the routing decision.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description doesn't need to argue safety. It adds real value beyond them: the methodology (daily creations/redemptions valued at volume-weighted price) and the exclusion of converted trusts (GBTC, ETHE), which materially affects interpretation of 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?

Three front-loaded sentences with no filler; the metric list and the methodology note each carry information an agent needs. Slightly dense, but nothing reads as 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 a single optional parameter and no output schema, the description usefully enumerates the returned fields and explains the calculation basis. A minor gap is the absence of units/currency for money invested and unrealised P&L, which would help an agent report results 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?

With 100% schema coverage and an enum of all supported assets, the schema already fully documents the parameter. The description adds only the mild clarification that omitting it returns all 16 assets, which is a small increment over 'Optional asset filter'.

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 precise verb and resource ('estimated average entry price per coin of US spot crypto ETF holders') and enumerates the returned metrics (net-flow coins, money invested, entry price, latest price, unrealised P&L, day streak). That clearly separates it from siblings like get_etf_holdings or get_fund_flows, which cover different 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?

'for one asset or all 16' implies how to scope the call, but there is no explicit when-to-use guidance and no named alternative such as get_etf_holdings for pure holdings data. The usage context is inferable but not 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 readOnlyHint=true and openWorldHint=false, so safety and scope are covered. The description goes beyond that by disclosing the returned fields and, importantly, the meaning of coinsBasis (reported by issuer vs estimated from net assets/coin price) and the presence of 7-/30-day changes and 30 days of daily history — meaningful disclosure for an agent interpreting 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?

Front-loaded with the core output and scope, then the per-fund breakdown and history. Two dense sentences with no filler, though the second sentence packs several schema-adjacent terms (coinsBasis, supplyPct) that make it heavier than necessary for a single-parameter tool.

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

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

For a one-parameter, read-only tool with no output schema, the description fully carries the return-value burden: totals, per-fund coins, share metrics, basis provenance, and the change/history windows. An agent can decide to call it and interpret the response correctly from this text alone.

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

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

Schema coverage is 100% and the single parameter is an enum of 16 tickers with its own description, so the schema does the heavy lifting. The description adds only the marginal note that omitting the filter returns all 16, which is the baseline-3 level of added 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?

States a specific verb and resource — the coins held in trust by US spot crypto ETFs — and defines the scope (one asset or all 16) plus the derived metric supplyPct. It is clearly a holdings-snapshot tool, implicitly distinct from flow-oriented siblings like get_fund_flows, but it never names an alternative to sharpen the boundary.

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 'one asset or all 16' phrasing implies the optional-filter usage (omit asset for the full ETF universe), which is useful. However, there is no explicit when-to-use/when-not guidance and no mention of the neighboring tools (get_fund_flows, get_funds) an agent would weigh this against.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds substantial behavioral context beyond them: publication lag, referenceDate/referenceIsToday semantics, Monday behavior, totalUsdM aggregation rules, and null netFlowUsdM handling with lastReportedDate. These details materially affect interpretation of 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 front-loaded and dense with useful information, with no filler. However, it is a long single paragraph and could be more scannable if the data-lag and field semantics were structured separately from the asset list.

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

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

With no output schema, the description carries the burden of explaining return semantics, and it does so thoroughly: referenceDate, referenceIsToday, totalUsdM, netFlowUsdM nullability, lastReportedDate, and the distinction from per-fund data. An agent has enough context to call and interpret this 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?

There are zero input parameters, so the baseline is 4. The description does not need to explain input parameters, and it instead spends space on output-field semantics, which is appropriate for this tool.

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

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

The description states a specific verb and resource: get latest-day net ETF inflow/outflow in USD millions for every tracked crypto asset. It enumerates the covered assets and explicitly distinguishes this asset-level total view from get_fund_flows (per-fund breakdown) and get_funds (net assets), so an agent can identify it 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 clearly explains when to use this tool and routes to alternatives: per-fund breakdown is get_fund_flows and net assets is get_funds. It also gives important timing context, including that data is one business day in arrears and Monday data is Friday's, which directly affects when an agent should call it and how to interpret results.

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 operationally critical behavior: the fixed 30-day window, publication one business day in arrears, the sign convention (positive = inflow), and the distinction between null (not yet reported) and 0 (no creations/redemptions). This is exactly the context 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?

Four dense sentences, front-loaded with purpose and scope before the field-level detail. Every sentence earns its place: the null/0 semantics and reporting lag are non-obvious facts an agent would otherwise get wrong.

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 carries the return-shape burden and does so: it enumerates ticker, issuer, net USD millions, and totalUsdM, and explains the null case. Nothing an agent needs to call or interpret this tool is missing.

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

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

Schema description coverage is 100% and the enum of 16 assets is fully documented in the schema, so the description is not required to carry parameter meaning. It adds only 'one crypto asset' and fund-ticker examples, which is baseline-level 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?

States a specific verb (get), resource (daily net flows of every spot ETF), and scope (one crypto asset, fund by fund, last 30 days). The phrase 'fund by fund' implicitly separates it from asset-level siblings like get_asset_flows and summary-level get_flows_summary, so an agent can distinguish it without opening a schema.

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

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

The 30-day window and single-asset scope imply when the tool applies, but the description never names an alternative or states an exclusion (e.g., 'for aggregate totals use get_flows_summary'). Usage must be inferred from the sibling list rather than from explicit routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real behavioral context on data quality — that netAssetsBasis can be published, repriced, or estimated, that coinsHeld is null for some issuers, and that delistedAt marks closed funds. This is exactly the kind of caveat an agent cannot get from the annotations or 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?

The purpose is front-loaded in the first clause, and each clause carries information about a returned field. However, it is delivered as one extremely long run-on sentence with parenthetical definitions chained together, which hurts scanability when a short field list would have been clearer.

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

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

There is no output schema, so the description must carry the return-value burden and it does: it names every field, explains the netAssetsBasis taxonomy, flags nullability of coinsHeld, and covers fee, staking, and delisting fields. For a 16-row directory with no pagination concerns, nothing an agent needs to interpret results 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 single `asset` parameter has 100% schema coverage including an enum, so the schema does the documentation work and the baseline is 3. The description only adds that omitting it returns all 16 assets, which is a modest clarification rather than new 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?

States a specific verb and resource ('Get the US spot crypto ETFs that have started trading') with an explicit scope ('one asset or all 16') and enumerates the returned fields, so the agent knows exactly what comes back. It does not name any sibling (e.g. get_fund_flows or get_etf_holdings) to differentiate itself, 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?

'for one asset or all 16' makes the optional-filter usage clear, and 'Net assets are a current snapshot, not a history' tells the agent when this tool is the wrong choice (i.e. for time-series questions). No alternative tool is named explicitly, so there is clear context but no stated 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 establish that this is a safe read-only operation, and the description adds valuable methodological transparency beyond that: it is an estimate based on published fees, applies temporary waivers, and excludes staking rewards. It does not discuss freshness, update cadence, or limits, so it is strong but not exhaustive.

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

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

The description is front-loaded with the tool's purpose and then efficiently covers output shape and caveats. It is dense, especially the long enumeration of per-fund fields, but every sentence contributes useful information.

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

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

With no output schema, the description carries the burden of explaining what is returned, and it does so by naming the per-fund and aggregate fields and the estimation caveats. Combined with the fully documented asset parameter, it is complete enough to invoke correctly, though it could say more about time coverage and data freshness.

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 single optional asset parameter is fully documented in the schema. The description does not add any parameter-specific semantics; it only describes the computed output, 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 and resource: estimated sponsor fee revenue of US spot crypto ETFs. It is clearly distinct from sibling tools like get_etf_holdings and get_fund_flows, and the calculation basis (net assets times prospectus sponsor fee) further sharpens the purpose.

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 the tool is useful by specifying the exact metric computed, but it does not explicitly say when to use it versus alternatives or when not to use it. No sibling tools are named or ruled out, leaving routing to the agent's inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond them: data provenance ('sourced from major exchanges'), freshness ('refreshed frequently'), and fixed coverage of 16 named assets. The cadence is vague, but this is useful disclosure for a price-freshness-sensitive 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?

Two sentences, front-loaded with what is returned before provenance. The long asset enumeration is dense but genuinely informative for coverage checking, and no sentence is wasted.

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 (USD spot price plus 24-hour percentage change). It also covers coverage, source, and refresh cadence. Minor residual gaps: no output shape/ordering detail and no mention of stale-data or error behavior.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies a parameterless, whole-market snapshot ('for all 16 tracked crypto assets'), but adds no parameter detail because none exists.

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'), resource ('current spot prices'), scope ('all 16 tracked crypto assets'), units (USD) and an additional returned field (24-hour percentage change). It enumerates the tracked assets, which makes it easy to distinguish from siblings like get_asset_flows or get_cefi_index.

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

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

Usage is implied by the snapshot nature of the call — an agent can infer this is the tool for current price quotes — but there is no explicit when-to-use, no alternatives named, and no exclusions relative to the four sibling analytics/flow tools. Minimum viable guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds valuable provenance (SEC filings) and a data-quality caveat ('coinsPerShare' shown only where the series is clean), which goes beyond structured fields. It stops short of describing rate limits or failure modes, keeping it at a 4.

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 status enumeration is front-loaded, but the second sentence is a dense run-on that packs many metrics into one clause. It is informative but could be structured with clearer separation, slightly hurting readability.

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 carries the burden of explaining return values, and it does so thoroughly: statuses, yield disclosure, payout behavior, and per-asset aggregates. It is nearly complete for a one-parameter read tool, though a note on response shape or empty-result behavior would make it fully self-contained.

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 single enum parameter is fully documented in the schema. The description adds only a slight hint that results can be broken down per asset, but does not clarify filter syntax or defaults beyond the schema. 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?

The description states a specific verb and resource (get staking status of US spot crypto ETFs from SEC filings) and enumerates the exact status values, which distinguishes it from sibling tools like get_etf_holdings or get_fund_flows. An agent can identify the tool's purpose 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?

Usage is implied by the domain (staking status of crypto ETFs), but the description never states when to choose this over sibling tools or when the data is not applicable. No explicit alternatives or exclusions are given.

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

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

Annotations already cover safety (readOnlyHint=true, openWorldHint=false), so the bar is lower, and the description still adds real behavioral detail: the exact aggregate fields returned, that weekends are excluded from the trading-day count, and that the daily series is omitted. It does not discuss caching or freshness of the 7-day window, which is 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?

Three tight sentences, front-loaded with purpose, then return fields, then the exclusion rule and the summary framing. Every sentence carries information an agent would otherwise have to guess.

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

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

With no output schema, the description fully compensates by enumerating the returned metrics (net flow, trading days, average flow per day, positive/negative day counts) and the weekend-exclusion rule. Nothing needed to call this zero-arg 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?

The tool takes zero parameters, which is the baseline-4 case. The description correctly implies a fixed default of all tracked assets over a fixed 7-day window, matching the empty schema with no 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?

States a specific verb and resource with scope: 'Get 7-day aggregated ETF flow analytics for all tracked assets.' The phrase 'all tracked assets' plus 'compact momentum summary without the full daily series' hints at how it differs from per-asset siblings, but no sibling is named explicitly, so differentiation is inferential rather than stated.

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?

'A compact momentum summary without the full daily series' implies when to prefer this over a daily-series call, which is useful contextual guidance. However, it never names an alternative (e.g., get_asset_flows or get_flows_summary) or states when NOT to use it, so the agent must infer routing.

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