market-data

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the data is supplementary, not a primary signal, and is only meaningful for crypto assets. It does not discuss freshness, caching, or data sourcing, keeping it short of 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?

Content is front-loaded in a single dense sentence with two short supporting sentences. The parenthetical glosses on funding rate and SSR add interpretive value, though the metric list is packed tightly enough that a reader must parse it carefully.

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

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

With zero parameters, an output schema present, and rich annotations, the description's remaining job is to state scope and what is returned, which it does fully. An agent has everything needed to decide whether to call it and how to weight 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 no parameter semantics to describe and the baseline of 4 applies. The description does not attempt to document any inputs, which is correct 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 description names a specific resource (crypto market context) and enumerates exactly what it returns: BTC/ETH dominance, total/alt market cap, Fear & Greed, perp funding rate and open interest, and Stablecoin Supply Ratio. It also scopes itself to crypto assets, which implicitly separates it from siblings like get_macro_context and get_sentiment_data.

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

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

It gives explicit when-to-use guidance ('Use ONLY when analysing crypto assets (BTC, ETH, crypto ETFs)') and a clear caveat that it is background context rather than a primary signal. It does not name the alternative tools (e.g. get_macro_context, get_sentiment_data) an agent should prefer for non-crypto or sentiment-first analysis, so routing is only partly resolved.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: the statistics are drawn from the US universe, each event comes with a sample size, and small samples are flagged as caution-worthy.

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

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

Three dense sentences, front-loaded with the primary purpose and followed by what is returned per event and the small-sample caveat. Nearly every clause earns its place, though the parenthetical example list could be trimmed.

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

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

An output schema exists, and the description still usefully previews the return shape (forward returns at 1w/1m/3m/6m/1y, sample size, unconditional baseline), which helps the agent judge relevance. It is complete enough for a single-parameter read-only 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?

Only one parameter (ticker) and schema description coverage is 100%, so the schema fully documents it. The description adds the implicit scoping of 'on a ticker today' but no format or syntax detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource: historical base rates for technical events firing today, with concrete examples of the event types (RSI below 30, golden/death cross, 52-week high/low). This clearly separates it from siblings like get_technical_indicators, which report current indicator state rather than historical forward-return statistics.

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

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

Provides clear usage context via the quoted question it answers, 'what usually happened after this', which tells the agent the intended analytical framing. It does not, however, state when not to use it or point to an alternative sibling for current indicator values or raw price history.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds real context beyond that: which asset classes are supported, that crypto requires the -USD pair form, and that fields like market cap/sector/earnings are conditional ('where they apply'). No auth or rate-limit detail, but that is minor given annotation coverage.

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

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

Four sentences, front-loaded with the return payload and then the coverage boundaries. Dense and mostly earning its place, though the parenthetical enumeration of session states is slightly list-heavy.

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 exists so return values need not be explained. The description covers supported asset classes, exclusion list, pair format, and example inputs — everything needed to invoke correctly, with only the instrument_id alternative left implicit.

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

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

Schema description coverage is 100%, so the baseline is 3. The description usefully adds crypto pair syntax ('BTC-USD') and multiple ticker examples beyond the schema's single 'AAPL' example, but it only discusses the ticker parameter and never mentions the alternative instrument_id UUID path.

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 ('Current snapshot of one instrument') and enumerates the exact fields returned (price, session state, 52-week range, market cap, sector, earnings date). This clearly separates it from siblings like get_price_history and get_technical_indicators, which cover different concerns.

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

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

Explicitly bounds coverage: US-listed stocks, ETFs, major crypto (-USD pairs); excludes forex, futures, options, non-US listings. The 'current snapshot' framing implies when to choose it over historical tools, but no alternative sibling is named outright, so it falls short of a 5.

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

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

Annotations already declare a safe, idempotent, closed-world read, so the burden is light. The description still adds real value beyond them: each lens reports rising/falling vs its 50-day average plus 20-day change, and the tool emits a single posture of risk_on/risk_off/mixed, which tells the agent what kind of judgement to expect.

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 tool's purpose and role, then the lens taxonomy, then the optional focus parameter. It is dense with domain jargon but every clause carries information; a slight trim of the lens enumeration would tighten it.

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-required-param, single-enum, read-only analysis tool with an output schema, the description covers what is computed, how each lens is expressed, the posture enum, and the effect of focus. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100% with a single enum-backed parameter, so the baseline is 3. The description restates the same idea ('adds lenses specific to that asset class') without adding syntax, defaults, or per-value distinctions 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 analytical verb ('first-pass read of the market environment') and resource (price-ratio lenses across asset-class rotation, risk appetite, defensive flows, the dollar), with concrete sub-scopes. No sibling in the list (breadth, macro context, relative strength) overlaps this intermarket-ratio scope, so an agent can route to it unambiguously.

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?

'First-pass read' implies a screening use case, which is useful implied guidance. However, it never says when NOT to use it or which sibling (e.g. get_macro_context, get_market_breadth, get_relative_strength) to prefer under which conditions, so the agent must infer the boundary.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: how zones are derived (clustered swing highs/lows), what touch counts mean, and that results include nearest levels above/below with a distance metric.

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 action and the output inventory, followed by a short usage sentence. Dense but every clause carries information; no filler sentences, though the parenthetical touch-count explanation makes the first sentence long.

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 detail is not required, and the description adequately covers what is computed and why. Minor gaps remain around data freshness or behavior for non-equity tickers, but nothing essential for correct invocation is missing.

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

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

With a single parameter and 100% schema description coverage, the schema already documents 'ticker' including an example. The description adds no additional semantics about the ticker argument, so the baseline of 3 applies.

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

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

States a specific verb ('compute') and resource ('key price levels for a ticker'), then enumerates exactly what is produced: support/resistance zones with touch counts, round numbers, 50/200-day MAs, and 52-week high/low. That enumeration functionally distinguishes it from siblings like get_technical_indicators or get_price_history without needing to name 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?

Gives a clear use case — 'Use these for concrete trigger/target/invalidation levels' — which tells the agent the intended decision context. It does not, however, state when to prefer this over get_technical_indicators or get_price_history, so no explicit exclusions or alternatives are offered.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld behavior, so the safety profile is covered. The description adds a small amount of provenance by noting the ratios come 'from our price data,' but says nothing about data freshness, update cadence, or reliability of the macro figures.

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

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

Two sentences, front-loaded with the primary content list and no filler. Every clause enumerates a distinct dataset the caller receives.

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 described, and the enumerated contents give a solid preview of scope. The only real gap is failing to clarify its boundary against get_intermarket, which shares stated functionality.

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 are no argument semantics to explain and the schema is trivially complete; baseline 4 applies. The description correctly adds no parameter detail because none is needed.

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

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

The description uses a specific verb+resource (get macro market context) and enumerates concrete contents: sector P/E ratios, sector performance, Treasury rates, CPI, and inter-market ratios. It does not explicitly differentiate itself from the sibling get_intermarket, which appears to overlap on the HYG/LQD and TLT/SPY ratios mentioned here.

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 tool, when not to, or which alternative to pick. The omission is notable because the sibling get_intermarket also covers inter-market ratios, so an agent has no basis for choosing between them.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the burden is lower. The description adds useful content about what data is returned (RSI, trend, 52-week range per series), which is context beyond the annotations. However, it doesn't add behavioral details like data freshness or scope 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?

Two tightly written sentences: the first names the resource and lists exactly what is measured; the second supplies the interpretation. Every clause earns its place with no filler.

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

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

An output schema exists, so the description needn't detail return values, and with no parameters there's little else to specify. It covers what the tool is and why it matters. A minor gap is the absence of any usage routing relative to the many sibling context 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?

The tool takes zero parameters, so there is nothing to document. Baseline is 4 for a parameterless tool, and the description appropriately focuses on the return content rather than nonexistent inputs.

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

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

States a specific resource (S&P 500 market breadth) with exactly what it measures (percentage of members above 50/200-day MAs) and the derived metrics per series. This is clearly distinguishable from siblings like get_technical_indicators (per-instrument) and get_macro_context (macro data).

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

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

The description implies what the tool is used for (gauging how broad an advance/decline is) but provides no explicit when-to-use guidance or alternatives. No sibling tools are named to route the agent elsewhere.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=true), and the description usefully adds what the tool actually surfaces — setup instructions and delivery channels (email/Telegram). It stops short of describing response shape or whether options are static vs account-dependent, which would have pushed it higher.

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

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

Two sentences, no filler, and the routing constraint is placed at the end where it functions as a gate. Every clause earns its place.

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

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

With an output schema present, the description need not explain return values, and the annotations carry the safety semantics. What remains — scope, option types, when to invoke — is fully covered for a zero-required-parameter lookup 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 100% and the single enum parameter is fully documented in the schema, so the baseline is 3. The description echoes four of the enum values but omits 'memory', adding no syntax or mapping detail beyond what the schema carries.

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

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

States a specific verb and resource ('Returns available options for ongoing monitoring') and enumerates the concrete option types (price alerts, idea tracking, watchlist monitoring, scheduled digests) plus channels. This lets an agent distinguish it from the informational siblings like get_market_breadth or get_price_history without opening any schema.

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

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

Gives an explicit when ('Call only when the user asks for ongoing monitoring or notifications') and an explicit when-not ('never needed to answer a question'), which is unusually strong routing guidance. The exclusion is the key discriminator against every sibling tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds default/max limits on the history window but says nothing about throttling, data availability, or gaps in the series. With annotations carrying the safety burden, this is adequate but 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?

Two tight sentences, front-loaded with the resource and scope, with the acronym expanded inline. Nothing is wasted.

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

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

Return values are covered by the output schema and safety by annotations, so the description need not repeat those. However, four overlapping window parameters (bars, from_date, to_date, period_days) coexist with no explanation of which takes precedence, leaving a real ambiguity the description could have resolved.

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

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

Schema description coverage is 100%, so the schema already documents ticker, bars, dates, and period_days. The description only restates period_days' default and max ('default 365, max 3650'), duplicating the schema, and never clarifies precedence between period_days, bars, and the from/to date pair.

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

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

States a specific verb and resource ('Get daily OHLCV price history for a ticker') and spells out the OHLCV components, which cleanly separates it from siblings like get_technical_indicators or get_instrument_info. It does not name an alternative explicitly, but the resource 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?

The description gives no when-to-use context and does not route the agent to or away from any sibling. The only guidance is a default/max on period_days, which is a parameter detail rather than a usage condition.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is fully covered. The description adds value beyond that by disclosing what the analysis computes (distance from 50/200-day averages, RSI, trend, recent values, one-line verdict), though much of this overlaps with the existing 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?

A single dense sentence, front-loaded with the core purpose and followed by the computed outputs. Every clause carries meaning, though the output enumeration makes it longer than strictly necessary 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?

With an output schema present, return values need not be spelled out, and annotations carry the safety profile, so the description is largely complete for a 3-parameter read-only analytics tool. It lacks any explicit guidance on period_days selection tradeoffs, a minor 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 100%, so the schema already documents ticker_a as numerator, ticker_b as denominator, and period_days defaults/limits. The description reinforces the A/B orientation with example ratios, but adds no syntax or format details beyond the schema—baseline 3 applies.

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

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

States a specific verb+resource (relative strength of one ticker against another as a price ratio A/B) and names concrete example pairs (GDX/GLD, HYG/LQD). This clearly distinguishes it from generic siblings like get_technical_indicators or get_price_history without needing to open either 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?

Usage is implied by the example pairs (e.g. GDX/GLD for gold miners vs gold, XLK/SPY for sector vs benchmark), which hints at when the tool is appropriate. However, there is no explicit when-to-use vs alternatives statement and no exclusions relative to get_technical_indicators or get_intermarket.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: the data source (Cboe daily statistics), the exact datasets returned, and the conditional contrarian flag — information an agent cannot get from annotations.

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

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

A single dense sentence that front-loads the source and resource before listing the contents. Every clause carries information, though the length edges toward a run-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?

With an output schema present, return values need not be explained, and annotations cover the safety profile. The description supplies the data provenance and contents, leaving little an agent needs before calling it.

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

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

Schema description coverage is 100% and the single enum parameter is fully documented in the schema, so the baseline is 3. The description adds no parameter-level detail, but the schema already handles the 'all' vs 'put_call' semantics.

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

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

The description names a specific resource — Cboe daily options statistics — and enumerates exactly what it returns (put/call ratios for all products, equities, indices, SPX and VIX, plus underlying volumes). This is far more specific than a tautology, though it never explicitly distinguishes itself from siblings like get_macro_context or get_market_breadth.

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 statement or named alternative, but the mention of a 'contrarian flag when the equity put/call ratio sits at an extreme' implies the tool's role as a sentiment/crowding gauge. Usage is inferable from the data described rather than stated.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real value by disclosing that the corpus is an internally authored, curated framework rather than retrieved web content, and that returns are 'short passages ... with relevance scores'.

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

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

Two sentences, front-loaded with what the tool is, followed by what it returns. No filler or repetition of the title.

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

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

With an output schema present, return values need not be explained, and the description covers purpose, usage context, and return shape adequately. Only the absence of explicit when-not guidance keeps it from a 5.

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

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

Schema description coverage is 100%, so both 'query' and 'top_k' are already documented in the schema; the baseline of 3 applies. The description adds no syntax, example, or default guidance beyond what the schema provides.

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

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

States a specific verb ('look up') and a precisely scoped resource: MarketCrew's distilled, synthesized TA methodology notes, explicitly contrasted with raw data by the phrase 'our own synthesized notes.' An agent can distinguish this from get_technical_indicators or public_search_news without opening a schema.

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

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

It gives an implied use case ('to ground an answer in a consistent framework') but never states when to prefer this over siblings such as get_technical_indicators or when it is inappropriate. Usage is inferable but not explicit, and no alternative is named.

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

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds that indicators are computed from daily price history, which is useful context about data granularity, but does not disclose rate limits, auth requirements, or error behavior.

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

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

The description is a single front-loaded sentence that immediately states the action and resource before listing the computed indicators. Every item in the list contributes to scope, and there is no filler or redundancy.

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

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

For a read-only calculation tool with one required parameter, full schema coverage, rich annotations, and an output schema, the description is nearly complete. It fully enumerates what is computed and the data source, though it omits usage context that would help in a suite with many related market-context siblings.

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

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

There is only one parameter, ticker, and schema description coverage is 100% with the example 'SPY'. The description says 'for a ticker' but adds no syntax or format detail beyond what the schema already provides, matching the baseline for high schema coverage.

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

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

The description states a specific verb (Calculate) and resource (technical indicators for a ticker) and lists the exact indicators computed, making the tool's scope unambiguous. It does not explicitly name or differentiate itself from sibling tools such as get_price_history or get_ta_methodology, which keeps it from a 5.

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

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

The description gives no guidance about when to use this tool versus alternatives like get_price_history, get_key_levels, or get_ta_methodology. Usage is only implied by the tool's name and purpose, with no stated context or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld=false, so safety is covered. The description adds genuinely useful behavioral context beyond that: output is headline + summary only, source_url is mandatory, and it explicitly never returns full third-party text — a licensing/content constraint an agent should know. It says nothing about rate limits or freshness/latency, keeping it from a 5.

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

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

A single tightly packed sentence plus a short usage clause, with the resource and returned fields front-loaded and zero wasted words.

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

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

With an output schema present, return-value explanation is not needed, and the content constraints (summary-only, mandatory source) cover the key disclosure. What remains unstated is the alternative route (public_search_news) and any rate/pagination behavior, so it is strong but not fully complete.

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

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

Schema coverage is 100% (ticker, limit, days_back all documented with defaults and maxima), so the schema carries the parameter burden. The description adds no syntax, default, or range detail beyond it; baseline 3 is appropriate.

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

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

Names a specific resource and scope ('Latest news for a ticker') plus the returned shape (headline, short summary, source_url). It implicitly separates itself from the generic public_search_news sibling by being ticker-scoped, but never says so outright, so it stops short of full sibling differentiation.

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

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

'Use to ground a market read in recent, attributable news' gives a concrete when-to-use scenario. It offers no exclusions or alternative routing (e.g., when to prefer public_search_news over this tool), which caps it at 4.

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

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

Annotations already cover read-only/idempotent/non-destructive, so the description adds real value by disclosing the output contract: matching items with a short summary and a mandatory source_url, never full article text. That is a meaningful behavioral constraint beyond structured fields.

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

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

A single sentence that front-loads the core action and compresses scope, output shape, and a key limitation with no filler.

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

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

All parameters are documented in schema and an output schema exists, so the description only needed to frame intent and output character, which it does. The only gap is not positioning against the overlapping sibling public_instrument_news.

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

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

Schema description coverage is 100%, so all four parameters are already fully documented with defaults and ranges. The description adds only the concept of semantic search and one-angle framing, which is already implied by the query parameter text.

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 ('Semantic news search across tracked instruments') and previews the return shape. It doesn't explicitly distinguish itself from the sibling public_instrument_news, so it stops short of a 5.

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

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

Usage is implied by the 'semantic search' framing and the schema's 'ONE semantic angle' hint, but there is no statement of when to use this versus public_instrument_news or any other sibling, and no exclusions or prerequisites.

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