market-data

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context about the data content and its role, without contradicting annotations.

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

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

Two dense sentences, front-loaded with purpose ('Crypto market context for a technical read') and followed by precise data points and scoping. No filler or repetition.

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

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

With an empty input schema and an output schema present, the description adequately covers the data categories and usage scope. It provides sufficient context for an agent to select and invoke the tool correctly.

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

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

The input schema has zero parameters, so there is nothing to document. The baseline for no parameters is 4, and the description does not need to add parameter-level 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 clearly states the tool provides crypto market context with a specific list of metrics (dominance, sentiment, funding, open interest, stablecoin supply). It distinguishes itself from siblings by explicitly scoping to crypto assets only, making the purpose 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 explicit when-to-use guidance ('Use ONLY when analysing crypto assets') and notes its role as background context, not a primary signal. It does not name alternative sibling tools, but the boundaries are clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description only needs to add interpretive context. It does so by disclosing the output structure (forward returns, sample size, baseline) and adding a critical caveat about small samples, which goes beyond the structured annotations.

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

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

Three sentences, front-loaded with the main purpose, then examples, then output details and a caveat. Every sentence carries meaningful information without redundancy or fluff.

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 analytics tool with a single parameter, an output schema, and full schema coverage, this description is complete. It explains what the tool does, what it returns, and includes a practical caution, leaving no significant gaps for an AI agent to invoke it correctly.

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

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

The schema already covers 100% of the single parameter (ticker) with a clear description. The tool description references 'a ticker' but does not add further semantic nuance beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool provides 'Historical base rates for the technical events firing on a ticker today' and specifies exactly what it returns: forward returns at multiple horizons, sample size, and an unconditional baseline. This distinguishes it from sibling tools like get_technical_indicators (current values) and get_relative_strength (current performance).

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 usage context by stating it answers 'what usually happened after this' and warns 'small samples warrant caution,' which tells users when to rely on it. However, it does not explicitly name alternatives or state when not to use it, though the differentiation from current-indicator tools is inferable.

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, and destructiveHint=false, covering safety behavior. The description adds context about the payload (price, market state, etc.) but does not disclose edge behaviors such as parameter precedence or not-found handling, which is acceptable given the 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?

Two concise sentences: the first states the tool's purpose and outputs, the second provides parameter instructions. No filler words or redundant information.

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

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

For a simple read-only tool with rich annotations and an output schema, the description is largely complete. However, it creates slight ambiguity by instructing to provide either parameter while the schema marks both as optional (required=0), leaving unclear whether calling with no parameters is valid.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond by explaining that either instrument_id or ticker can be provided, clarifying their mutually exclusive relationship and providing an example format. It does not explain what happens if both are given, slightly reducing completeness.

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 'Get' and identifies the resource as 'financial instrument' while listing the exact data returned (price, price changes, market state, 52-week range, earnings date). This clearly distinguishes it from sibling tools like get_price_history or get_technical_indicators.

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 'current information' implies a snapshot use case, but the description does not explicitly state when to use this tool over alternatives like get_price_history or get_key_levels. No exclusions or alternative tool names are mentioned, leaving the usage context implied rather than explicit.

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, and destructiveHint=false. The description adds behavioral context not covered by annotations: each lens reports 'rising/falling vs its 50-day average plus the 20-day change' and the overall posture is 'risk_on, risk_off or mixed'. This enriches the agent's understanding of output semantics.

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

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

The description is dense but well-structured, using em-dashes to separate the core purpose from specific lens categories and output details. It front-loads the primary purpose and every sentence carries meaningful information without 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?

With an output schema present, the description does not need to explain return format. It thoroughly covers what the tool reads, how each lens reports, the overall posture, and the optional focus parameter. The only completeness issue is the enum mismatch that could cause a failed 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?

The schema provides 100% coverage for the single parameter 'focus' with an enum and description. The description adds the list of allowed values, but it includes 'crypto' which is NOT in the schema enum ('gold', 'bonds', 'tech', 'commodities', 'equity'). This contradiction could mislead an agent into sending an invalid value, reducing trust in the description's parameter 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?

The description clearly states it is an 'Intermarket compass — a first-pass read of the market environment through price-ratio lenses' and enumerates specific ratio categories (asset-class rotation, risk appetite, defensive flows, dollar). This distinguishes it from sibling tools like get_macro_context and get_market_breadth by focusing on cross-asset price relationships.

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 'first-pass read' provides clear context for when to use it—as an initial market environment scan. It doesn't explicitly name alternative tools or state when not to use it, but the usage context is unambiguous and sufficient for an agent to decide.

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, and destructiveHint=false, so the safety profile is covered. The description adds behavioral depth by explaining how support/resistance are computed ('clustered swing highs/lows with touch counts') and what the output includes ('nearest levels above and below with distance %'). This goes beyond the annotations and clarifies the tool's analytical 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 compact and information-dense. Every phrase adds value: it lists the types of levels, explains the touch count concept, mentions the output format (nearest levels with distance %), and gives a usage recommendation. There is no fluff or repetition.

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

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

For a single-parameter, read-only tool, the description is complete. It specifies all key outputs, the input, and the intended use. An output schema exists, but the description already conveys the return substance. No important gaps are apparent.

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 input schema has only one parameter 'ticker' with a clear description ('Ticker symbol, e.g. 'SPY''), and schema coverage is 100%. The description does not add additional semantics about the parameter, but the schema already handles it. Per the baseline rule for high schema coverage, a score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Compute key price levels for a ticker' and enumerates specific outputs (support/resistance zones, round numbers, moving averages, 52-week high/low). This distinguishes it from sibling market context tools by focusing on concrete price levels for trade planning.

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

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

The description provides clear usage context: 'Use these for concrete trigger/target/invalidation levels.' This implies when to apply the tool (for trade execution planning) but does not explicitly mention when not to use it or name alternative sibling tools. Since siblings are present, more explicit exclusion would be ideal, but the context is strong.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description's job is lighter. It adds useful context about the specific data included (e.g., 2Y/10Y/30Y Treasury rates, HYG/LQD, TLT/SPY) and mentions the data source ('our price data'). However, it does not disclose behavioral traits such as data freshness, update frequency, or any limitations, which would have increased transparency.

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 remarkably concise, consisting of two sentences. It front-loads the key purpose ('Get macro market context') and then efficiently lists the specific data categories. Every word adds value, with no fluff or repetition of schema information.

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

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

For a zero-parameter tool with an existing output schema, the description is sufficiently complete. It enumerates all major data categories and even includes the inter-market ratios, which adds depth. It does not need to explain return values because an output schema exists. The only minor gap is lack of mention about time periods or data granularity, but this is not critical for a read-only macro context 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?

The tool has no parameters, so there are no parameter semantics to explain. The baseline for zero parameters is 4, and the description does not need to compensate for any schema gaps. It adequately summarizes the data content, which is sufficient.

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

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

The description clearly states the tool's purpose with a specific verb ('Get') and a well-defined resource ('macro market context'). It enumerates concrete data types (sector P/E ratios, sector performance, US Treasury rates, CPI inflation, inter-market ratios), which distinguishes it from siblings like get_crypto_context or get_intermarket by its focus on macro indicators.

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 usage for macro context needs, but it does not explicitly state when to use this tool versus alternatives. The mention of inter-market ratios could create ambiguity with the sibling tool get_intermarket, yet no comparisons or exclusion criteria are provided. The guidelines are implied rather than explicit.

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 indicate read-only, idempotent, and non-destructive behavior. The description adds useful context about the data content (percentage above MAs, RSI, trend, 52-week range) and its interpretation as a breadth gauge, going beyond the safety profile provided by annotations.

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

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

The description is two sentences, front-loaded with the tool's focus and key metrics, and contains no redundant information. Every clause adds value.

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

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

Given the tool's simplicity (no parameters, output schema present), the description is complete. It explains what the tool measures, what components are included, and the purpose of the data, making it self-sufficient for selection and basic understanding.

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

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

The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline score of 4 is appropriate because there is no parameter complexity to document.

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

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

The description clearly states that the tool provides S&P 500 market breadth, specifically the percentage of members above 50-day and 200-day moving averages, along with RSI, trend, and 52-week range. This is a specific verb+resource combination that distinguishes it from sibling tools like get_sentiment_data or get_relative_strength.

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

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

The description provides clear context on when to use the tool—when assessing the breadth of an advance or decline. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous enough for an agent to select it over other market analysis 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?

Annotations already convey read-only, idempotent, non-destructive behavior. The description adds context about the tool's output content — setup instructions and delivery channels (email/Telegram) — providing value beyond the annotations without contradiction.

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

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

The description is two sentences, front-loaded with the core purpose and followed by usage guidance. Every sentence adds distinct value with no redundancy or fluff.

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

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

For a simple one-parameter tool with rich annotations and an output schema, the description fully covers the necessary context: what the tool returns, when to invoke it, and what it includes. No further detail is needed.

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 input schema fully describes the single optional 'intent' parameter with an enum and clear description, giving 100% schema coverage. The tool description does not elaborate on the parameter, but the schema already provides sufficient meaning, so baseline 3 applies.

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

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

The description clearly states the tool returns available options for ongoing monitoring with concrete examples (price alerts, idea tracking, watchlist monitoring, scheduled digests) and setup instructions. It distinguishes itself from sibling market-data tools by focusing on monitoring/notifications rather than data retrieval.

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 explicit usage guidance: 'Call only when the user asks for ongoing monitoring or notifications' and 'never needed to answer a question.' This clearly delineates when and when-not to use the tool, making it easy for an agent to follow.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds context about daily OHLCV granularity and default/max for period_days, which is useful beyond annotations. No contradiction.

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

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

Two sentences, front-loaded with the core purpose, and every word contributes. No fluff or redundant explanation.

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

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

Given the straightforward nature of the tool, the presence of an output schema, and complete parameter descriptions, the description is sufficiently complete for an agent to invoke it correctly. It might clarify the precedence between bars and period_days, but that is minor.

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 baseline is 3. The description repeats period_days default and max from the schema but adds no new meaning for bars, from_date, or to_date. It does not compensate beyond schema.

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

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

The description clearly states 'Get daily OHLCV price history for a ticker' with specific content (open/high/low/close/volume), and this distinguishes it from sibling tools like technical indicators or sentiment data. Verb and resource are 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?

The description gives clear context that this tool is for daily price history and provides a usage hint for the period_days parameter. However, it does not explicitly mention when to avoid this tool or name alternatives, stopping 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 the tool as read-only, idempotent, and non-destructive, so the description only needs to add context. It lists the computed outputs (SMA, RSI, trend direction), making the tool's behavior transparent without contradicting the annotations.

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

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

The description is three sentences with no wasted words. It front-loads the purpose, then lists outputs, then gives usage examples – each sentence 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?

This is a simple read-only tool with a full output schema and safe annotations. The description covers purpose, output metrics, and usage examples, leaving no obvious gaps. Return values are already documented by the output schema, so no extra explanation is needed.

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?

All parameters are fully described in the schema (100% coverage), so the description adds limited value. It provides example ticker pairs (e.g., GDX/GLD) that clarify numerator/denominator roles, but doesn't add meaning beyond schema descriptions for period_days.

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 'Calculate relative strength ratio between two tickers (A/B)' – a specific verb and resource. It also lists the exact outputs (current ratio, SMA(50)/SMA(200), RSI, trend direction), which clearly distinguishes it from sibling tools like get_intermarket or get_technical_indicators.

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 states 'Used for inter-market analysis' and provides concrete examples (GDX/GLD, HYG/LQD, XLK/SPY), giving an agent clear context for when to apply it. It doesn't explicitly contrast with alternatives like get_intermarket, but the examples effectively communicate the typical use 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context beyond listing the data points; it does not mention rate limits, freshness of data, or response format, meaning it adds marginal value over annotations alone.

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

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

The description is two sentences and every sentence earns its place: the first identifies the data, the second gives an application hint. 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?

This is a simple read-only tool with one optional parameter, full schema coverage, and an output schema present. The description and annotations together are complete for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% as the single 'type' parameter is fully described with an enum and default. The description lists the content but does not add syntax or selection guidance beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states a specific verb ('Get') and a specific resource ('market sentiment indicators'), enumerating the exact data included (CBOE Put/Call ratios, AAII survey, VIX). While it doesn't explicitly contrast with sibling tools, the listed indicators make the tool's scope distinct from other market 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?

It provides a clear use case ('useful for contrarian signals at extremes') but gives no explicit guidance on when not to use it or how to choose between the 'type' parameter values. It does not mention alternatives, which is acceptable for a simple tool but not fully explicit.

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 and idempotentHint, and the description adds useful behavioral context by clarifying that it returns short synthesized passages with relevance scores rather than raw data. This goes beyond the schema and annotations without contradicting them.

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 main purpose. Every clause earns its place—the em-dash notes clarify the nature of the content, and the second sentence discloses the return format. No fluff.

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

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

For a simple, read-only retrieval tool with an output schema and full parameter docs, the description adequately covers purpose, return shape, and applicability. There is no missing behavioral or contextual information needed for correct invocation.

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

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

The input schema has 100% description coverage for both parameters (query and top_k), including an example in the schema. The description's mention of 'what you want the methodology on' adds no new meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Look up') and names the resource ('MarketCrew's distilled technical-analysis methodology') with qualifiers that distinguish it from sibling data tools like get_technical_indicators or get_key_levels. It clearly communicates this is methodology/notes, not raw data.

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

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

The phrase 'to ground an answer in a consistent framework' gives a clear situational context for when to use this tool. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a full 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 readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds useful context by enumerating exactly which indicators are computed and noting they are based on daily price history, which clarifies scope without contradiction.

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

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

The description is a single well-structured sentence that front-loads the action and resource, then lists indicators in a compact, readable list. No filler words; every item adds value.

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

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

Given the output schema exists (so return format is covered), one parameter, and annotations covering safety/idempotency, the description fully addresses the tool's scope and inputs. No significant gaps remain.

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

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

The single parameter (ticker) is fully described in the schema with an example, and the description adds nothing beyond the schema. With 100% schema coverage, the baseline of 3 is appropriate; the description does not need to elaborate further.

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 ('Calculate') and explicitly names the resource ('technical indicators for a ticker'). It lists concrete indicators (SMA, RSI, MACD, etc.), which clearly distinguishes it from sibling tools like get_price_history or get_relative_strength.

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 the tool is used when you need these specific technical indicators, and the detailed indicator list makes the use case clear. However, it does not explicitly state when NOT to use it or name alternative tools for overlapping analyses, so it stops 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?

The annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond those hints: it guarantees a mandatory source_url and explicitly states that the full third-party article text is never returned, which is important for agents to understand output limitations.

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

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

The description is two sentences, both dense with useful information: the first defines the return contract, the second explains the use case. No wasted words, and the key behavioral constraint (never full third-party text) is front-loaded.

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

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

Given the presence of a full output schema, rich annotations (read-only, idempotent, non-destructive), and complete parameter documentation, the description covers all needed context for an agent to invoke the tool correctly. It also explains the output's nature and the intended grounding use case, making it sufficiently 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?

The input schema has 100% coverage with all three parameters described, so the baseline is 3. The description adds minimal parameter-level detail beyond the schema; it mentions 'recent' news and 'ticker' implicitly, but does not enrich the meanings of limit or days_back beyond what is already in 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?

The description clearly states the tool returns the latest news for a ticker, listing the specific content (headline, short summary, mandatory source_url), which precisely defines its function. It distinguishes itself from sibling tools by focusing on per-ticker news rather than broader search or market context.

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

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

The description explicitly recommends using it 'to ground a market read in recent, attributable news,' providing a clear use case. It does not explicitly mention when to prefer alternatives like public_search_news, but the ticker-specific scope makes the intended context clear.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds valuable context about the return format (summary and mandatory source_url) and explicitly excludes full article text, which is beyond what annotations provide.

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, well-structured sentence that is front-loaded with the core purpose and then delivers key constraints. No word 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?

Combined with a rich input schema and the presence of an output schema, the description sufficiently explains the tool's behavior and constraints. It doesn't need to reiterate parameter details or return structure.

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 does not add parameter-level detail beyond the schema, but it does clarify a behavioral nuance (no full text) that indirectly relates to query expectations.

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 ('search') with a clear resource ('news') and scope ('across tracked instruments'), and distinguishes itself from siblings by emphasizing 'semantic' search and the output constraints (summary and source_url, never full text).

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 the tool is for semantic news searching but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives such as public_instrument_news for instrument-specific news.

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