marketdata-mcp

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

No annotations are supplied, so the description carries the full behavioral burden. The one useful fact it adds is the data provenance ('Envelope labelled TRADINGVIEW'), but it never states that the call is read-only, whether it is rate-limited, or how fresh the data is. For a zero-parameter snapshot tool the risk is low, yet the disclosure remains thin.

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 text is short and front-loads the health summary, which is good. However, the 'Returns:' line is cryptic — 'Envelope labelled TRADINGVIEW' reads as internal implementation detail rather than something an agent can act on.

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

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

An output schema exists, so the description need not explain return values, which lowers the bar. Still, for a composite market-health indicator the description leaves the meaning of 'dominance proxies' and 'trend' undefined, and gives no sense of scope (timeframe, spot vs. futures) that an agent would need to 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-parameter tool applies. The description does not introduce confusing or phantom parameter-like language.

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 the resource (Bitcoin market health) and lists three metric families: trend, dominance proxies, volatility. That is more specific than a tautology, but the verb is implicit and 'dominance proxies' is vague. Nothing distinguishes it from crypto-focused siblings such as crypto_top_movers, crypto_bollinger_scan or crypto_multi_timeframe.

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

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

No when-to-use or when-not-to-use guidance is given. With roughly ten crypto-adjacent siblings in the list, an agent has no stated basis for choosing this tool over crypto_multi_timeframe or crypto_top_movers, and no preconditions or exclusions are mentioned.

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

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

With no annotations, the description carries the full burden and does so well: it explains that the price leg is dual-sourced while analysis and sentiment legs stay single-source and are labelled per field, and that data.news is Marketaux-only and returns empty with an explanation when no token is present. It stops short of covering failure modes per leg, latency, or rate limits.

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

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

The one-line summary is front-loaded and the rest is organized into source/no-key notes plus Args/Returns. Most sentences earn their place, though the Returns block partially restates envelope keys that the output schema already provides.

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?

This is a multi-source composite with no annotations, and the description covers the sourcing, fallback, and degradation behavior an agent would otherwise have to guess at. With an output schema present, the envelope enumeration in Returns is a minor redundancy rather than a gap; only per-parameter value formats remain thin.

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

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

Schema description coverage is 0% and the schema only supplies bare 'string' types with defaults, so the description must compensate. It does add domain meaning (symbol is a ticker, exchange is a TradingView exchange prefix, timeframe is a TradingView interval), but gives no format examples, no allowed timeframe values, and no exchange list, leaving real ambiguity for the agent.

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

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

The opening line names the exact composite ('Technical analysis, news and sentiment in one call, cross-checked on price'), which immediately distinguishes it from the single-leg siblings technical_analysis, stock_news, and market_sentiment. It also specifies the mechanism (TradingView read + Finviz close) so an agent knows what is actually being combined.

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 clear this is the tool to pick when all three views are wanted in one call, and it gives the operational conditions that affect whether to call it (no API key needed; Marketaux used only when MARKETAUX_API_TOKEN is set, otherwise Finviz local scoring). It does not name sibling alternatives explicitly or state when to use the narrower single-purpose tools instead, which keeps it below 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?

With no annotations, the description carries the full behavioral burden. It discloses the data-source restriction, threshold-based qualification, row limiting, and envelope label, but does not explicitly establish read-only behavior or address candidate ordering, data freshness, access requirements, or failure 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 purpose is front-loaded, and the short Args and Returns sections are easy to scan. There is essentially no filler, and the parameter notes add value rather than merely repeating titles and types.

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?

Defaults and parameter notes make a basic invocation straightforward, while the output schema reduces the need for detailed return documentation. However, the scan universe, valid exchange and timeframe examples, result ordering, and operational constraints remain unclear.

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?

Despite 0% schema description coverage, all four parameters receive useful explanations; bbw_threshold in particular gains a clear qualification rule. Accepted TradingView venue and interval formats, along with the units or normalization of band width, remain undocumented.

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 a scan for Bollinger-band squeeze candidates and restricts it to TradingView, distinguishing its signal from siblings such as crypto_volume_breakout. It does not specify the scanned asset universe or explicitly position the tool against related crypto analysis 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?

The TradingView-only constraint and squeeze-candidate purpose imply when the tool is useful. There is no explicit when-not guidance, alternative sibling, or advice on choosing a timeframe or squeeze threshold.

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 full behavioral burden, and it says little beyond 'Returns: Envelope labelled TRADINGVIEW'. It does not disclose that a multi-agent debate is likely slow/expensive, whether it is read-only, or how the two agent perspectives are surfaced, and with no destructiveHint or readOnlyHint the agent must infer safety. The named output envelope is the one genuinely useful disclosure.

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 single sentence followed by terse Args/Returns blocks; nothing is padded. The only waste is restating the title's 'TradingView-only' tag and the near-tautological one-word parameter glosses.

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

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

An output schema exists so return values need not be explained, but for a three-parameter analysis tool with zero schema coverage and no annotations, the definition leaves the agent guessing about valid values and runtime characteristics. It is under-specified relative to the tool's apparent complexity.

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, yet it only restates the parameter names ('symbol: Coin symbol', 'exchange: TradingView venue', 'timeframe: TradingView interval'). It omits accepted timeframe strings, valid venue values, and the schema defaults (exchange=KUCOIN, timeframe=15m), and calling KUCOIN a 'TradingView venue' adds confusion rather than clarity.

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: a bull/bear multi-agent debate over a crypto symbol, plus the 'TradingView-only' scope tag. It is distinguishable from pure price tools like stock_quote or crypto_multi_timeframe, though it never explains how it differs from close siblings such as combined_analysis or market_sentiment.

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

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

The only guidance is the parenthetical 'TradingView-only', which hints at a data-source constraint but does not say when to choose this debate over crypto_multi_timeframe, combined_analysis, or bitcoin_market_pulse. No prerequisites, exclusions, or cost/latency caveats for a multi-agent run 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?

With no annotations provided, the description carries the full behavioral burden. It discloses the data source (TradingView) and that the response is a labelled envelope, which is useful context, but it says nothing about permissions, rate limits, latency, or whether the read is purely informational.

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 Args/Returns structure is front-loaded and easy to scan, with no filler sentences. It is arguably too terse for a tool whose key concept (which timeframes are analyzed) is never stated.

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

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

An output schema exists, so return-value explanation is not strictly required, and the description sensibly names the envelope label. However, for a tool whose defining feature is 'multi-timeframe', the description never says which timeframes are covered or what the per-timeframe analysis contains, leaving a material 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 description coverage is 0%, so the description must compensate and it only partially does. It gives concrete symbol examples ('BTC', 'ETH') that the bare string schema lacks and characterizes 'exchange' as a TradingView venue, but it never enumerates valid venues or explains how an invalid/unsupported exchange is handled.

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: a multi-timeframe technical read for a crypto symbol, scoped to TradingView. That distinguishes it from the generic technical_analysis sibling only weakly (the differentiator is the data source, not the analysis semantics), but an agent can still tell what it does.

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

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

There is no explicit when-to-use guidance and no comparison to the obvious alternatives in the sibling list (technical_analysis, crypto_multi_agent, bitcoin_market_pulse). The only routing hint is the parenthetical '(TradingView-only)', which tells the agent the data source but not when to prefer this tool over those siblings.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the return envelope label ('TRADINGVIEW') and enumerates accepted argument values, which helps, but it says nothing about rate limits, whether limit is capped, pagination, or error behavior on an invalid exchange.

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?

It is front-loaded with a one-line purpose followed by a compact Args/Returns block, and every line maps to a real parameter or the response. No filler sentences or restated title material.

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 four-parameter read-only lookup, the description covers all arguments and the response envelope, which is enough to call it correctly; an output schema also exists so return detail is not required. It omits defaults and any limit ceiling, but nothing essential to invoking the tool is missing.

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

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

Schema description coverage is 0% and no enums are declared, so the description is the only source of valid values — and it delivers them for movement, exchange, and timeframe, plus a plain meaning for limit. The exchange list is left open-ended ('…') and no bound on limit is given, keeping it short of a 5.

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

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

The first line states a specific verb and resource ('Top crypto gainers or losers on an exchange') and adds the qualifier 'TradingView-only', which separates it from the futures-oriented sibling futures_top_movers. It does not name that sibling explicitly, so differentiation is implied 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?

There is no explicit when-to-use or when-not-to-use guidance relative to siblings such as futures_top_movers or crypto_volume_breakout. The 'TradingView-only' tag implies this is the TradingView data path for crypto movers, but the agent must infer the rest from the tool name.

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

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

No annotations are provided, so the description carries the full burden. It discloses only that results come back in an envelope labelled TRADINGVIEW and that the source is TradingView; it says nothing about how the thresholds combine (AND vs OR), whether zero results are possible, rate limits, or data freshness.

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 purpose sentence followed by a tidy Args/Returns block; nothing is padded. The one-liners are terse to the point of under-specification rather than verbose.

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

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

An output schema exists, so return values need not be re-explained, but for a 5-parameter screening tool with no annotations and no schema descriptions, the description leaves the two most consequential inputs (exchange and timeframe) essentially undefined. An agent would have to guess valid values.

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% across 5 parameters, so the description must supply the meaning. It gives one-line glosses ('Minimum relative volume', 'Minimum absolute % change') that add a little over the bare titles, but omits default values, accepted exchange names, valid timeframe strings (no enums exist), and what 'relative volume' is measured against.

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: a scanner for volume and price breakouts, and pins the data source as TradingView-only. That distinguishes it reasonably well from siblings like crypto_bollinger_scan and crypto_top_movers, though it never explicitly contrasts itself with them.

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

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

The only usage signal is the '(TradingView-only)' tag, which is a source constraint rather than a when-to-use rule. There is no guidance on when this beats crypto_bollinger_scan, crypto_multi_timeframe, or crypto_top_movers, and no stated preconditions.

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 full burden and discloses almost nothing: 'TradingView-only' flags the upstream source, but there is no word on rate limits, caching, freshness, auth, or expected cost of an overview call. 'Returns: Envelope labelled TRADINGVIEW' is return-shape information that duplicates the existing output schema rather than adding behavioral insight.

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 text is short and front-loads the resource name, which is good. But the second half is a 'Returns' stanza that restates what the output schema already provides, while the parameters that actually need explanation receive zero words — the space is spent in the wrong place.

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

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

An output schema exists, so return values need not be explained, and the tool is read-only in nature with no nested objects. Still, with two undocumented parameters, no usage guidance, and no annotations, an agent is left guessing about the arguments and about when this overview beats the many sibling market tools.

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

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

Schema description coverage is 0% for two parameters, and the description compensates for nothing — it never mentions 'limit' or 'timeframe'. An agent cannot tell whether limit caps rows, symbols, or index entries, or what timeframe values other than the default '1D' are accepted.

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 (Egyptian Exchange overview) and a data source constraint (TradingView-only), so an agent knows roughly what it returns. However there is no verb describing the operation and no differentiation from plausible siblings such as market_snapshot, market_indices, or market_sentiment, so selection relies on the name alone.

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

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

There is no when-to-use guidance, no stated preconditions, and no mention of alternatives. The parenthetical 'TradingView-only' hints at a data-source constraint but never says which tool to pick when TradingView data is insufficient or when the user wants a different market region.

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 behavioral burden. It usefully discloses the data source is TradingView-only and that results come wrapped in a TRADINGVIEW-labelled envelope, but it says nothing about ordering direction (descending by rank?), pagination, or what happens when limit exceeds available contracts. For a read-only overview the risk is low, so this is adequate rather than rich.

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

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

Front-loaded with the one-line purpose, then Args and Returns sections in a compact block; nothing is padded. Minor overlap with the title'sthe 'TradingView-only' phrasing appears twice, but that redundancy reinforces an important constraint rather than wasting space.

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

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

An output schema exists, so the return values need not be spelled out, and the description still flags the wrapper key usefully. Missing pieces are routing guidance relative to sibling tools and any note on defaults or pagination limits, which leaves the agent to guess at scope when the futures list is large.

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 no enums are declared in the schema, so the explicit enumeration of category values (all, equity_index, energy, metals, agriculture, rates, forex, crypto_futures) and exchanges values (us, global) adds substantial meaning that is available nowhere else. The limit parameter only gets 'Rows to return', which essentially repeats the schema title and omits the default of 30.

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 resource and ordering: futures contracts ranked by volume, with a source qualifier (TradingView-only). This is enough to separate it from futures_top_movers and futures_watchlist, though it never explicitly names those siblings to sharpen the distinction.

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

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

The description gives no when-to-use guidance and no exclusions or alternatives, even though several siblings (futures_top_movers, futures_watchlist, market_indices) overlap in domain. The agent must infer that this is the 'broad futures list' tool from the name alone.

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

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

With no annotations supplied, the description does carry some of the burden: it discloses the data source ('TradingView-only') and that results come back in an envelope labelled TRADINGVIEW. It does not say how the ranking/sort is performed, whether results are live vs delayed, or any rate-limit/permission considerations, which are the remaining gaps on a zero-annotation tool.

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

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

The definition is short and front-loaded, with the purpose in the first line and Args/Returns clearly partitioned. It is appropriately sized for a three-parameter list tool, though the Returns line is a minor redundancy given an output schema exists.

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 most important facts (what it returns, valid values for the two enum-like params) are present, and an output schema exists so return structure need not be explained. What's missing is behavioral context the agent would need to choose this over futures_market_overview or futures_watchlist, plus the effect of defaults when movement/exchanges are omitted.

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

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

Schema description coverage is 0% and the schema declares no enums, so the description is the only source of parameter meaning. It usefully supplies the accepted values for movement ('gainers' or 'losers') and exchanges ('us' or 'global'), plus the meaning of limit; only limit's note ('Rows to return') is essentially a restatement of the parameter name.

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 concrete verb+resource: futures gainers/losers ranked by percent change, and the '(TradingView-only)' qualifier distinguishes it from a generic screener. It doesn't name a specific sibling (e.g., crypto_top_movers or futures_market_overview) to sharpen the boundary, so a 4 rather than 5.

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

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

There is no when-to-use or when-not-to-use guidance; the agent must infer from the title that this is a ranked futu res list and that futures_market_overview or futures_watchlist are alternatives. Naming one alternative and the condition that selects it would be needed for a higher 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, the description carries the full behavioral burden, yet it discloses nothing about data freshness, refresh cadence, entitlement/authentication requirements implied by 'TradingView-only', or failure behavior. The single behavioral fact given - that results arrive in a 'TRADINGVIEW'-labelled envelope, which is already covered by the output schema - is low-value on its own.

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 lines, front-loaded with the resource name, with no filler prose. The 'Returns:' line is largely redundant given that an output schema exists, which keeps it from a top score.

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?

A zero-argument tool with a rich output schema needs little description, so the terse form is not fatal. Still, an agent cannot tell what 'levels' contains, how fresh the watchlist is, or why the TradingView source matters, which is the minimum context this tool should supply.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description does not need to compensate for any schema gap here.

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 phrase 'Curated futures watchlist with levels' identifies the resource and hints at content ('levels'), but uses no verb and gives no scope detail, so the agent must infer that it is a zero-argument fetch. It does not contrast itself with close siblings such as futures_market_overview or futures_top_movers, leaving the agent to guess how the watchlist differs from those overviews.

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?

'(TradingView-only)' is the only conditional signal, and it functions as a data-source label rather than a when-to-use rule. Nothing says when to pick this over futures_top_movers or futures_market_overview, nor whether a symbol argument exists elsewhere for narrower 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 behavioral burden and does well: it discloses dual sourcing from Finviz and TradingView/Yahoo, explains ticker normalization to canonical names, and notes that each result carries its own data_provider. It does not mention latency, caching, rate limits, or failure behavior, but the core data provenance and comparison behavior are 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 front-loaded with the purpose, then the covered indices, then the normalization behavior, then the return shape. Every sentence adds useful information and there is no redundant 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?

The tool is simple, parameterless, and has an output schema, so the description is nearly complete: it covers scope, sources, canonical keys, and returned fields. It could add update frequency or freshness expectations, but no critical invocation detail 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 has zero input parameters, so the baseline is 4. There are no parameter semantics to explain beyond the absence of arguments.

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 resource and payload: dual-sourced level and day change for major US indices, explicitly listing S&P 500, Dow, Nasdaq Composite, Russell 2000, and VIX. It is clear what the tool returns, though it does not explicitly differentiate itself from siblings such as market_snapshot or futures_market_overview.

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 listed US indices and day-change scope, which tells an agent this is for broad US index levels rather than individual stocks or futures. However, there is no explicit when-to-use guidance, no prerequisites, and no named alternative for overlapping snapshot or sentiment tools.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses backend selection, that local scoring is deterministic/offline/free, that the payload self-reports its backend via `provider`/`scoring`, and that it never fabricates a score when there is no material. It stops short of stating failure behaviour (unknown symbol, empty feed) or latency/cost of the Marketaux path.

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

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

Front-loaded one-line summary followed by Args and Returns sections; every sentence adds information, including the backend-precedence rule and the no-fabrication guarantee. There is no filler or 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?

An output schema exists, yet the description still helpfully sketches the envelope (TRADINGVIEW label, sentiment_score, label, bullish/bearish/neutral counts, strongest headlines). Combined with the backend disclosure, an agent has enough to call it correctly; only the sibling-routing and error cases remain uncovered.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: `symbol` is a ticker, `limit` is the number of headlines analysed, and `category` is explicitly flagged as applying only to the Marketaux path — a non-obvious constraint the schema does not convey. It could still note the valid category values, since no enum is declared.

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 — news-based sentiment for a symbol — and names the concrete mechanism (Marketaux entity sentiment vs local VADER scoring of Finviz headlines). It does not, however, distinguish itself from the sibling `stock_news` tool, leaving the agent to infer that this one returns a score and that one returns articles.

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 a clear selection rule for the internal backends: Marketaux is preferred when MARKETAUX_API_TOKEN is set, otherwise local scoring is used, and it notes no API key is required. What is missing is external routing guidance versus alternatives such as `stock_news` or `stock_why_moving`, which would let an agent pick among siblings confidently.

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 full behavioral burden and usefully discloses the single-source TradingView constraint plus the output envelope labeled `TRADINGVIEW`. It does not discuss freshness, delay, or rate limits, but it provides the key source-reliability caveat for a read-only snapshot.

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 purpose, and moves cleanly through source limitation, alternative tool, and return grouping. Every sentence adds value without 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?

Given zero parameters, an existing output schema, and no annotations, the description provides enough context to call the tool correctly: asset coverage, source limitation, alternative for verified indices, and return envelope labeling.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain. The baseline score of 4 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 resource and scope: a global snapshot covering FX, crypto, index, and ETF data, sourced exclusively from TradingView. It also distinguishes the tool from `market_indices`, so an agent can identify its role 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 names `market_indices` as the alternative for a cross-verified index read and explains why: Finviz covers only four US indices, making the broad snapshot single-source. That gives a clear condition for choosing the sibling tool over this one.

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 supplied, the description carries the full burden and does disclose a genuinely important behavioral trait: the output is single-source and labelled TRADINGVIEW because it cannot be cross-verified. That pre-empts over-trust in results. It still omits compute cost, latency, and whether the backtest is deterministic or subject to lookahead/parameter-fitting caveats.

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

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

Front-loads the one-line purpose before the caveat, then uses compact Args/Returns sections that are easy to scan. The structure is efficient; the only redundancy is restating the TRADINGVIEW label twice (in the caveat and in Returns).

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

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

An output schema exists, so the brief Returns note is sufficient and the description rightly spends its budget on parameters and the single-source caveat. What is missing relative to a 7-parameter analytics tool is routing guidance to stock_backtest_compare and any hint about runtime cost when equity curve and trade log are enabled.

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%, yet the description documents all seven parameters, including the nine valid strategy values, period formats like 6mo/1y/2y/5y, and interval options 1d/1h -- meaning the schema alone would not. The remaining weakness is thin treatment of initial_capital (no currency or unit) and the two include_* flags, whose output-cost implications are unstated.

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: 'Backtest a strategy on a symbol', plus a clear scoping qualifier (TradingView-only, single-source). It does not name the obvious sibling stock_backtest_compare, so the agent must infer which backtest tool to pick, but the purpose itself is unambiguous.

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

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

It gives a useful constraint -- Finviz has no OHLCV history, so results cannot be cross-verified -- which tells the agent why this tool is the only option for backtesting. However, it never says when to use this versus stock_backtest_compare or technical_analysis, and offers no prerequisites or exclusions for strategy 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?

With no annotations, the description must carry behavioral weight, and it partially does: it discloses the TradingView data source and that results come back in a TRADINGVIEW-labelled envelope. It does not say whether the call is read-only versus state-changing, whether it is expensive/long-running (it runs a backtest across all strategies), or whether it needs credentials. The output schema covers the return shape, so the return sentence is bonus rather than load-bearing.

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?

Compact and front-loaded: the purpose sits in the first sentence, followed by a short Args block and a Returns line. Nothing is padded or redundant enough to distract. The Args list is thin rather than bloated, so brevity here is not the problem.

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

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

An output schema exists, so the description need not explain the return payload, and the essentials (one symbol, a period, starting cash) are present. However, for a comparison tool it never says how many strategies are evaluated, what the leaderboard is ranked on, or how costly the call is. Adequate to invoke, but thin for interpreting or planning around the result.

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

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

Schema description coverage is 0%, so the description must compensate and largely does not: "symbol: Ticker", "period: Lookback period", and "initial_capital: Starting cash" merely restate the parameter titles. Critical format details are absent — whether period takes "1y"/"6mo" style strings, what ticker convention/exchange applies, and what currency initial_capital is in. Only "Ticker" adds anything beyond the schema.

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

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

States a specific verb and resource: "Compare every strategy on one symbol", which clearly separates it from the sibling stock_backtest (single strategy on a symbol). The parenthetical "TradingView-only" further pins the scope. It stops just short of 5 because "every strategy" is never enumerated, leaving the scope of the comparison fuzzy.

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

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

Usage is only implied by the word "Compare" and the tool name; there is no explicit statement of when to pick this over stock_backtest or combined_analysis. No prerequisites, exclusions, or alternative routing are given. An agent can infer the intent but must guess at the boundary with its nearest 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?

With no annotations supplied, the description carries the full behavioral burden. It does usefully disclose that the result is a file saved to disk with a path and dimensions and that the envelope is labelled FINVIZ, plus the provider limitation. It does not cover auth/API-key requirements, failure behavior, or cost/rate limits, which matters for a provider-restricted rendering call.

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

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

Front-loaded with the core purpose, then organized into compact Args/Returns blocks with zero filler. The TradingView explanation is relevant context rather than padding. Slight redundancy between the opening line and the Returns line, but 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?

For a straightforward render-and-save tool whose return shape is already covered by an output schema, the definition supplies what an agent needs to call it correctly, including the param code legends. Remaining gaps (provider/auth prerequisites, error cases) are modest given the tool's simplicity.

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 none of the string params carry enums, so the description does the heavy lifting: it maps period to d/w/m, chart_type to c/l/h, and scale to l/log, which is essential information the schema omits entirely. It documents all six parameters, though it gives no guidance on sensible width/height ranges.

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: 'Rendered PNG candlestick chart for a ticker', which is unambiguous. It also implicitly distinguishes itself from text-based charting siblings by explaining that TradingView's provider computes charts as text analysis rather than images, making this PNG path Finviz-only. A slightly more explicit naming of the sibling (e.g. technical_analysis) would push this to 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?

Usage context is implied rather than stated: the agent can infer 'use this when you need an actual image, not a text-based chart', and the 'Finviz-only' framing hints at a provider prerequisite. However, there is no explicit when-to-use/when-not phrasing, no named alternative, and no statement of what happens if the Finviz provider is unavailable.

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 full disclosure burden. It usefully explains the return envelope and the meaning of `model_available`, including that it reflects whether Finviz flagged the company as dilution-prone, but it omits failure modes, rate limits, or data freshness expectations.

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 and front-loads the tool's purpose, then separates arguments and returns into clearly labelled sections. The 'Args: symbol: Ticker' line is slightly redundant but does not materially waste space.

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 one required parameter and an existing output schema, the description covers enough to invoke the tool. However, it does not explain what the model examines beyond the field list or clarify the 'Finviz-only' limitation's impact on coverage, leaving a gap for an agent interpreting results.

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 is only one parameter, and the description identifies it as the ticker symbol, adding modest clarity beyond the schema's bare 'Symbol' title. With schema coverage at 0%, that brief explanation is sufficient for a single well-understood input.

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 analytical resource: a dilution-risk model built from share count, float, and cash runway, restricted to Finviz data. It is clear what the tool produces, though it does not explicitly distinguish itself from siblings such as stock_ownership or stock_screener.

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

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

The only usage context is the parenthetical 'Finviz-only,' which signals the data source but not when an agent should choose this tool over alternatives. There are no exclusions, prerequisites, or sibling comparisons 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?

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: the data is dual-sourced, Finviz supplies detailed tables while TradingView confirms the timestamp, and the two dates are reconciled and reported. It omits failure behavior when one source is unavailable, and any rate-limit or caching traits.

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

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

Front-loaded with the purpose in the first line, then source roles, then args/returns. The docstring-style 'Args:'/'Returns:' blocks partly duplicate structured fields, but the prose is tight with no wasted sentences.

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

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

An output schema exists, so describing return fields is optional (and here partly redundant), and with one simple parameter the definition covers what the agent needs to call it correctly. What's missing is edge-case behavior such as tickers with no scheduled earnings.

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

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

Schema description coverage is 0% for the single required parameter, so the description must compensate; it only states 'symbol: Ticker', which clarifies the value is a ticker rather than an internal ID but gives no format examples, exchange prefix, or case rules.

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 resource and scope: earnings calendar plus earnings history for a single ticker, with named upstream sources (Finviz tables, TradingView scanner). It is unambiguous enough to separate from stock_quote or stock_news, though it never explicitly names a sibling it is not.

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

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

Usage is only implied by the content ('earnings calendar and history'): an agent can infer this is the tool for earnings dates and reported quarters, but there is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives such as stock_news for earnings coverage.

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 full burden and does real work: it discloses two independent providers (Finviz after-hours print vs. TradingView derived from 1-minute Yahoo candles) and that the after-hours price and change are compared, warning the agent that sources may disagree. It omits freshness/delay characteristics and failure behavior when no extended-hours print exists, which keeps it below 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 one-sentence purpose, then provenance, then Args/Returns. The docstring-style 'Args:' and 'Returns:' blocks partially restate the structured schema and output schema, which is mild waste, but the sizing is appropriate for the tool's complexity.

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 is simple (one parameter, output schema present), and the description covers purpose, data provenance, and the comparison behavior — enough to invoke it correctly. Gaps remain around data freshness and what is returned when no pre/post-market print exists, which matter for a dual-sourced price tool.

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

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

Schema description coverage is 0% for the single required parameter, so the description must compensate; it does so only minimally by labeling it 'Ticker' and implying a US listing via the opening sentence. It adds no format, exchange, or symbol-resolution guidance beyond the bare schema.

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

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

States a specific resource and scope: 'Dual-sourced pre-/post-market price for a US stock,' which is clearly distinguishable from regular-quote siblings like stock_quote or stock_prices. It never names those siblings explicitly, so an agent must infer the boundary rather than being told it.

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

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

Usage is only implied by the resource name ('extended hours' → use when you need pre/post-market prints). There is no explicit 'use this instead of stock_quote when…' routing, no mention of when the data is unavailable (e.g. outside trading windows), and no stated prerequisites.

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 usefully discloses single-source provenance, the lack of cross-verification, FINVIZ response labeling and notice, and pagination through has_more. It does not explicitly state read-only behavior or operational limits, although the filing-history wording strongly implies a non-mutating retrieval.

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 source limitation are front-loaded, followed by compact Args and Returns sections. The labeling sentence reinforces the provenance caveat, and there is no substantial filler or unnecessary elaboration.

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 straightforward four-parameter filing-history lookup, the description covers scope, provenance, verification limitations, filtering, pagination, and the response envelope. Defaults remain available in the input schema, while the output schema can supply detailed return fields, leaving no material invocation 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?

Despite 0% schema description coverage, the Args section documents all four parameters. It adds 1-based pagination, the 1-100 page-size range, optional form filtering, and a concrete comma-separated forms example, supplying the details needed for correct invocation.

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?

Clearly identifies the resource (SEC filing history), scope (one ticker), and source (Finviz-only, single-source). Its subject matter distinguishes it from quote, news, and earnings siblings, but it does not explicitly route away from any named 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 source restriction and explanation that TradingView cannot cross-verify filings provide concrete context for choosing the tool and interpreting its results. There is no explicit when-not guidance or named alternative for other company-data needs, so selection guidance is not exhaustive.

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 does useful work by naming Finviz and TradingView as sources, explaining that Finviz headlines carry price reactions, and noting that headline titles are matched to report overlap. It still omits operational behavior such as provider failure handling, rate limits, or whether the call is always read-only.

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 core purpose, then cleanly separates source behavior, arguments, and return structure. Every section adds useful information without 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?

For a three-parameter read-oriented market data tool with an output schema, the definition covers the important source behavior, parameter meanings, and shape of the returned data. It is not fully complete on failure modes or rate-limit behavior, but no major decision-critical context is missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: limit is defined as maximum headlines per provider, include_reactions is tied specifically to requesting Finviz reaction columns, and symbol is identified as the ticker. The only minor gap is that it does not further explain the effect of include_reactions=false on the returned fields.

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 starts with a specific verb and resource: dual-sourced headlines for one ticker. It identifies the two providers and the overlap concept, making the tool clearly distinct from quote, price, screener, and analysis siblings.

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

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

Usage is only implied by the purpose: fetch news headlines for a ticker. There is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternative such as stock_why_moving for causal analysis.

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 full burden and does reasonably well: it discloses that two providers are queried, that contracts are matched by strike and volume/OI compared, and that a null expiry falls back to each provider's nearest expiry. It does not cover failure/partial-failure behavior when one source is unavailable, or any rate/latency expectations for the dual fetch.

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 summary sentence followed by tidy Args/Returns blocks; each line carries information. The Returns section partially duplicates what an output schema already provides, which is mild redundancy but not noise.

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

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

For a two-parameter read tool with an output schema, the description covers what to pass, what happens on null expiry, and how the two sources are reconciled. The remaining gap is operational edge cases (one provider failing, empty overlap) rather than core call correctness.

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

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

Schema coverage is 0%, so the description must compensate, and it does: symbol is identified as the underlying ticker and expiry is given an explicit ``YYYY-MM-DD`` format plus the semantics of null (each provider's nearest expiry). Only minor gaps remain, such as expiry validation or timezone conventions.

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 resource (options chain) scoped to a single expiry, and the opening line also discloses the dual-source mechanism (Finviz plus a TradingView/Yahoo endpoint). No sibling tool covers options chains, so an agent can place it unambiguously among the listed market-data 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?

Usage is only implied: the line about comparing volume/open-interest 'so an agent can see whether the two sources agree on open positioning' hints at the cross-source validation use case. There is no explicit when-to-use, when-not-to-use, or reference to alternatives (e.g. stock_quote or technical_analysis) for simpler needs.

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 full burden. It does add one genuinely useful behavioral trait — results degrade gracefully, returning only 'whichever Finviz could serve' — which matters for downstream parsing. However, it says nothing about rate limits, data delay/freshness, or required plan access, and the envelope/block structure it describes is largely already covered by the output schema.

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

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

Front-loaded with the one-line purpose and the differentiator, followed by a conventional Args/Returns block. Every line is scannable and there is no filler, though the Returns paragraph restates output-schema content and 'Ticker.' is a wasted line.

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

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

For a two-parameter read-only data fetch with an output schema available, this covers purpose, both parameters and the partial-availability caveat, which is enough to invoke it correctly. The remaining gap is minor: no example symbol format or bounds/sane values for 'limit'.

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 partially does: 'limit' is clarified as max rows PER TABLE, which is non-obvious given three stacked tables. But 'symbol: Ticker.' is pure tautology, adding no format, case, or exchange-suffix guidance.

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

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

Names a specific verb set and three concrete resources (Form-4 insider transactions with monthly aggregates, institutional positions, FINRA short-interest history), and explicitly contrasts with siblings via '(Finviz-only)' / 'no other provider here offers'. An agent can tell this apart from stock_filings or stock_quote without opening the schema.

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

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

The 'Finviz-only' framing plus 'no other provider here offers' gives clear positive selection context: use this when you need insider, institutional or short-interest data because no sibling covers it. It stops short of explicit exclusions or the opposite direction (e.g. use stock_filings for raw filings instead), so it is clear guidance but not a full when/when-not 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 are supplied, so the description carries the full behavioral burden. It does disclose the data source (Finviz-only, single-source) and the response envelope label ('FINVIZ' with 'peers'), which is useful, but says nothing about failure modes for invalid tickers, rate limits, peer ordering, or how a partial list is handled.

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

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

The purpose is front-loaded in one line followed by a compact Args/Returns block, so there is no filler prose. The docstring scaffolding is slightly verbose for a two-parameter tool but remains scannable.

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?

Output schema existence reduces the need to document return values, and for a simple two-parameter read tool the definition is minimally adequate. However, with zero annotation coverage and no parameter documentation, an agent still lacks enough to invoke it confidently in ambiguous cases (peer ordering, limit semantics, source-only caveats).

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 both parameters and largely does not. 'symbol: Ticker' and 'limit: Maximum peers' merely restate the parameter names, omitting the default of 12, ticker format expectations, and what happens when limit exceeds the available peer set.

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 resource ('Finviz peer group for a ticker') and a concrete verb-equivalent (fetch peers), which is distinguishable from siblings like stock_ownership or stock_quote. It does not explicitly name which sibling to use instead, so it falls 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?

There is no guidance on when to use this instead of related tools such as stock_ownership or market_snapshot. The parenthetical 'Finviz-only, single-source' hints at a data-source constraint but names no alternative tool when a non-Finviz or multi-source view is wanted.

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 full burden and does disclose a genuinely non-obvious trait: each ticker is checked against two independent providers and the per-row data_provider records confirmation status. It does not cover failure modes such as invalid or delisted tickers, partial failures, or rate limits.

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 behavior, then Args and Returns sections; every sentence carries information. The Returns section partially duplicates the existing output schema, which is the only wasted space.

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 batch read tool with an output schema present, the description supplies what the schema cannot: the dual-source verification model and the meaning of data_provider. Only error/edge-case behavior is left unaddressed.

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 single parameter has only a title, so the description must compensate; it does so with an explicit format example ('AAPL,MSFT,NVDA') and the statement that the value is comma-separated. That resolves the main ambiguity of how to pass multiple symbols.

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 concrete verb and resource: 'Dual-sourced prices for several tickers at once,' plus the mechanism (TradingView scanner and Finviz screener). This clearly separates it from a single-symbol lookup like stock_quote, though it never names that sibling explicitly.

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

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

The phrase 'several tickers at once' implies batch usage, but there is no explicit when-to-use / when-not-to-use guidance and no routing to stock_quote (single symbol) or stock_screener (filtering). An agent must infer the choice from the name alone.

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

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

With no annotations, the description carries the full burden and does most of it well: it discloses parallel dual-provider fetching, that fields are compared and merged, that each item is provenance-labelled, and the exact data_provider envelope states (BOTH/TRADINGVIEW/FINVIZ/NONE) including the degradation case where data is not cross-verified. It omits cost/latency implications of hitting two providers and what an error response looks like beyond NONE.

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 one-line purpose, then structured prose, then Args/Returns blocks that are easy to scan. Slightly verbose — the provider-parenthetical and the 84-field mention are dense — but every sentence adds information rather than restating the 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 single-ticker aggregation tool with one parameter, the definition covers what is fetched, how sources are reconciled, and how to interpret the provider envelope. Since an output schema exists, the Returns section is bonus context rather than a necessity. The main remaining gap is the absence of guidance on when a caller should prefer a sibling tool instead.

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 the single symbol parameter, so the description must compensate — and it does, supplying format examples (AAPL, BRK.B, BRK-B) and noting the ticker can be written for either source, which resolves the real ambiguity of dot-vs-dash class shares. It does not state validation rules or case sensitivity.

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

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

The opening line states a specific verb and resource ("Dual-sourced quote and fundamentals for one US ticker") and the body enumerates exactly which fields are fetched and merged. It is clearly distinguishable from bulk/screening siblings, but it never names an alternative tool, so the differentiation is inferential 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?

Usage is implied: one ticker, quote plus fundamentals, dual-source comparison. There is no explicit when-to-use versus siblings like stock_prices, market_snapshot, technical_analysis, or stock_peers — even though the description mentions peers and RSI as data it carries, which are their own dedicated tools. No exclusions or prerequisites are 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?

With no annotations, the description carries the full burden and does well: it discloses that ranking happens server-side, that the two providers are cross-checked on change percentage, and that Finviz caps at 200 rows. It omits failure behavior when one provider errors, rate limits, and whether the call is read-only (implied, but not stated).

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 purpose sentence followed by prose that explains the two providers, then compact Args/Returns blocks. The Returns block partially restates the output schema, which is mild redundancy against an existing output_schema, but the overall density is high and no sentence is 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 four-parameter, dual-provider tool with an output schema, the description covers inputs, provider semantics, and the comparison logic. The remaining gap is operational edge cases: what happens when one provider returns nothing or fails, and how rows are matched by ticker beyond change percentage.

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

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

Schema coverage is 0%, so the description must compensate and does: country is tied to TradingView markets with examples, sort_by has its enum values listed, limit is given a per-provider cap, and finviz_filters gets concrete example expressions. An agent could populate every parameter from the description 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?

Opening sentence states a specific verb and resource: 'Run the US stock screener on both providers and cross-check the rows.' It immediately conveys the distinctive dual-provider design. It does not explicitly address the closest sibling, stock_screener_filters, so an agent must infer the division of labor.

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 explains the division of the two providers: TradingView ranks server-side via sort_by, Finviz narrows via its own filter language. That is actionable usage context. It stops short of explicit when-not-to-use guidance or naming stock_screener_filters as the place to discover filter syntax.

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 full disclosure burden. Calling it a 'catalogue' implies a read-only reference fetch, and the envelope label FINVIZ is disclosed, but nothing is said about caching, auth, or rate limits. An output schema exists, so return-value detail is not required here.

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 lines with the resource stated first and the return shape second, so it is well front-loaded. The '(Finviz-only)' qualifier duplicates the title's 'Finviz-only' prefix, which is minor waste.

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 an output schema, the description covers what is returned but not how the tool fits the workflow. The key missing context is that this is the discovery step feeding stock_screener's filter arguments.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter meaning 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 states a specific resource: the full screener filter catalogue, scoped to Finviz. It tells the agent this is metadata about available filters rather than screening results. It does not explicitly position itself against the sibling stock_screener, which is the tool an agent would most likely confuse it with.

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?

'Finviz-only' hints at data-source scope but there is no when-to-use guidance, no mention of pairing with stock_screener to discover valid filter names, and no exclusions. The agent is left to infer the workflow role from the name alone.

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

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

No annotations are supplied, so the description carries the burden. It usefully discloses the data source (Finviz only) and the returned fields, but says nothing about coverage limits, behavior when Finviz has no explainer, or freshness of the catalyst 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 core purpose is front-loaded in one clear sentence, and the Args/Returns block is short. The docstring-style formatting is slightly mechanical but nothing is padded.

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

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

An output schema exists, so the Returns summary is a bonus rather than a necessity. For a single-parameter read tool this is close to adequate, but the absence of any guidance on alternatives or empty-result behavior leaves a 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 description coverage is 0% and the description only says 'symbol: Ticker.', which essentially restates the schema title. No format guidance (exchange suffix, case, ambiguity between tickers) is added, so it fails to compensate for the coverage 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 a specific verb and resource: it retrieves Finviz's own explanation for why a ticker moved. The '(Finviz-only)' qualifier signals the data source and implicitly distinguishes it from broader news/analysis siblings, though it never names an 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?

There is no explicit when-to-use or when-not-to-use guidance. An agent must infer that this is for 'why did this stock move' questions and that stock_news or combined_analysis might be better for general coverage; nothing in the text says so.

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 supplied, the description discloses live upstream probing, cached verdict reuse, forced re-probing, and warning propagation to other tools. It also defines the provider states and degradation fields, though it does not mention operational implications of forced refresh such as additional latency or upstream load.

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, followed by caching behavior and compact, scannable Args and Returns sections. The refresh semantics are repeated, and the Returns discussion is not strictly necessary given the output schema, making the description slightly more verbose than required.

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 health probe with an output schema, the description supplies the invocation behavior, cache model, downstream consumers, and status vocabulary needed to call it correctly. Not naming the two providers is a small contextual omission, but it does not prevent correct selection or 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?

Although schema description coverage is 0%, the description fully compensates for the sole parameter: ``refresh=True`` forces fresh probes, while the default path reuses the cached verdict for the configured TTL. The inline explanation and Args entry make the boolean's operational effect unambiguous.

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

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

The opening line uses specific verbs, “Probe” and “report,” and identifies the resource as both provider upstreams and their API schema drift. Explaining that every other tool consumes this monitor's cached verdict clearly distinguishes it from the market-data and analysis siblings.

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

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

It explicitly says to use ``refresh=True`` for an immediate re-probe and explains that other invocations reuse the cache for ``TAPEBASIS_HEALTH_TTL`` seconds. It also describes how siblings consume the verdict, but does not give a broader decision rule for when to run this monitor directly versus relying on their warnings.

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 load, and it discloses the key traits: no upstream requests (so it is free/offline and safe to call liberally), plus the vocabulary of the returned source labels. It stops short of covering auth requirements or whether the map is static or changes at runtime.

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, front-loaded with what it returns followed by the agent-facing use case. Every clause earns its place, including the no-upstream-requests caveat.

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?

This is a zero-parameter read-only tool with an output schema, so the return shape is already covered by structured data. Purpose, use case, source-label semantics, and cost profile are all present; nothing needed for correct invocation is missing.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The empty schema is self-explanatory and the description does not waste words restating it.

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 ('List every tool, which providers back it, and how it is cross-checked') and implicitly separates itself from every sibling, all of which fetch market data rather than metadata. An agent can tell this is the registry/introspection tool 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 names a concrete use case: an agent that needs to know whether a capability is dual-sourced (BOTH), single-sourced (TRADINGVIEW/FINVIZ), or single-provider analysis. That is clear when-to-use guidance, but there are no explicit exclusions or named alternatives for the opposite case.

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 full burden, and it does disclose the dual-source design (TradingView computes, Finviz independently cross-checks) plus the response envelope shape. It does not disclose what happens when Finviz is unavailable or the ticker is missing from the given exchange, nor latency, rate limits, or whether the two sources can disagree silently. Useful context, but incomplete for an unannotated tool.

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

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

The lead sentence states the tool's identity, then Args and Returns sections structure the rest cleanly. Every line carries information and the parameter list is front-loadable. Minor redundancy between the opening sentence and the TradingView/Finviz paragraph prevents a 5.

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

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

An output schema exists, so return values need not be explained, yet the description still orients the agent to data.analysis and data.cross_check, which is genuinely helpful. All three parameters are covered, but the absence of annotations means degradation behavior and the meaning of a failed cross-check are left 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 0% and the schema has no enums, so the description does real work: it defines symbol as a ticker, exchange as the TradingView prefix with concrete examples (NASDAQ, NYSE, BIST), and timeframe with the exact allowed values (5m, 15m, 1h, 4h, 1D, 1W, 1M). Only the defaults and any validation rules are left implicit, keeping it just under a 5.

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

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

The description names a specific capability: a TradingView-computed indicator stack (RSI, MACD, EMAs, Bollinger, ATR, ADX, structure, trade setup) for a symbol, cross-checked against a Finviz snapshot of price, RSI(14), ATR(14) and 52-week range. That is far more concrete than the tool name alone and implicitly separates it from price-oriented siblings like stock_chart or stock_quote. It stops short of explicitly naming a sibling it replaces, so it is not 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?

There is no statement of when to use this versus stock_chart, combined_analysis, stock_screener or any other sibling, and no prerequisites or exclusions. The only usage signal is implicit: the returned fields suggest it is for indicator readings. An agent must infer the routing decision entirely from the data-source description.

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