AlpineDataWorks Intelligence Server

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

The description discloses the index formula, data sources (Alternative.me, CoinGecko, Coinbase, OKX), update frequency (hourly), historical depth (to 2018), and the Gold tier requirement for history, which goes well beyond the readOnlyHint annotation. No contradiction with 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 a single dense sentence packed with valuable info, followed by usage guidance and an update note. It is efficient and front-loaded, though slightly long. No 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 no output schema, the description names the key return fields (composite_score, sentiment_component, volatility_component, liquidity_depth), explains the index construction, and covers the optional parameter behavior and access tier. This is comprehensive for the tool's 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?

The only parameter 'days' is fully described in the schema (100% coverage), so the description need not add much. It does reinforce the hourly/history context but does not add significant new meaning 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?

The description clearly states the tool returns a 0-100 crypto sentiment and volatility regime index, with a specific formula, data sources, and output components. The verb 'Returns' and the resource are explicit, and the description distinguishes it as a sentiment/volatility index tool among many 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?

'Call when the user asks about crypto market sentiment, fear and greed, Bitcoin volatility, risk regimes, or market mood, or when timing portfolio rebalancing, defensive hedging, or crypto entry/exit decisions' provides clear context for when to use. It lacks explicit exclusions or named alternative tools, but the guidance is specific and actionable.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable context: data sources (FRED/BLS/BEA), monthly update cadence, history depth to 1960, and the mention of sub-fields. No contradiction with 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 sentences, front-loaded with the core result, followed by explicit use cases and update frequency. Every sentence earns its place 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?

The description explains the score's composition, data sources, sub-fields, and update frequency, which is sufficient for a simple read-only retrieval tool. The `days` parameter is well-documented in the schema, and with no output schema, the description provides enough context for an agent to 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 schema description covers the single `days` parameter at 100% with details about history length, Gold tier requirement, and fallback behavior. The main description does not discuss parameters, but with full schema coverage this is adequate. Baseline 3.

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 'Returns a 0-100 US macro economic health score' and specifies the composition (Z-scored CPI inflation, unemployment, GDP growth) and sub-fields. This specific verb+resource description distinguishes it from other macro tools and leaves no ambiguity about its function.

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 lists when to call the tool: 'when the user asks about US economic health, recession risk, macro conditions, inflation, jobs, or the business cycle, or when timing portfolio shifts.' It provides clear usage context but does not mention alternatives or when not to use it, 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?

Annotations already establish read-only behavior. The description adds useful context: data sources (DeFiLlama + Etherscan), daily updates, historical depth to 2018, and the TVL/APY divergence logic. It doesn't contradict annotations and provides insight beyond the basic safety profile.

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 concise and well-structured: the core return value and key output fields are front-loaded, followed by explicit usage scenarios and update frequency. No 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 no output schema, the description compensates by listing the key output fields (primary_driver_label, tvl_delta_usd, apy_trend, asset_composition) and contextualizing the score's logic. It gives enough for an agent to select and invoke correctly, though a bit more detail on the history response format would be helpful.

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

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

Schema coverage is 100% with the 'days' parameter fully described including the Gold tier requirement. The description mentions 'history to 2018' which aligns with the parameter but adds no new semantic detail beyond the schema baseline.

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 returns a 0-100 DeFi protocol TVL-driver score, with specific output fields and data sources. It distinguishes itself from opaque sibling tools by focusing on DeFi TVL/APY analysis.

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 explicit when-to-use guidance: 'Call when the user asks why a protocol's TVL, total value locked, liquidity, or yield/APY is changing...'. However, it lacks when-not guidance or named alternatives, so it doesn't fully reach the 5-level.

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 mark this as read-only, so the bar is lower; the description adds meaningful behavioral context beyond that: it discloses the index range (0-100), methodology (branch density and deposit growth scaled by bank failure rate), historical depth (quarterly since 1976), and update frequency. It does not go into depth about failure_risk_indicator semantics, but the added context is substantial.

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 well-structured: the first sentence states what it returns, the second gives usage triggers, and the third notes update frequency. Every sentence earns its place and there is no fluff or repetition of schema fields.

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

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

With no output schema, the description covers the key return fields, data source, index scale, historical availability, and update cadence. The one optional parameter is fully documented in the schema. It lacks detailed definitions of the output fields or an example, but for a read-only index query tool it provides sufficient context for selection and 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 single parameter (days) is fully described in the schema at 100% coverage, including its optional nature, history-series behavior, maximum 1825 days, and Gold tier requirement. The description itself does not mention the parameter, but since the schema carries the full semantic weight, 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 ('Returns a 0-100 US bank stability and branch coverage index') and clearly identifies the resource and scope. It also lists the output fields (stability_index, branch_density_score, failure_risk_indicator) and cites data sources, making it unmistakable what this tool provides and how it differs from generic adw 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?

The description explicitly states when to call the tool: 'Call when the user asks about banking system health, bank failures, branch density, deposit growth, or regional banking access, or when timing credit-risk premiums...' This gives clear context for use, though it does not name alternative tools or provide when-not-to-use exclusions, so it stops short of the highest bar.

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=true, and the description aligns by describing a read operation. It adds valuable context beyond annotations, such as the data being normalized, monthly since 1963, and updated monthly, which helps set expectations about the data's nature and 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?

The description is information-dense but not overly long. It front-loads the core return value and interpretation, then provides usage context and update frequency. The two sentences are somewhat long but each adds necessary detail 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?

The description covers the return fields, interpretation, data sources, update frequency, and usage scenarios. While the optional 'days' parameter is not mentioned in the description, it is fully documented in the schema. The tool is simple with one optional param, and the description is sufficiently complete for an agent to select and 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 description coverage is 100% for the single optional parameter 'days', which thoroughly explains the history feature and Gold tier requirement. The tool description does not add parameter-level details, but the schema already carries the full burden, 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 the tool returns a 0-100 global real estate affordability score with specific components (price-to-income and rent-to-income) and data sources (FRED and World Bank). It uses a specific verb 'Returns' and distinguishes itself from siblings by describing exactly what it measures.

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

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

The description explicitly states when to call the tool: 'Call when the user asks about housing affordability, home prices vs income, rent burden, or housing market valuation, or when timing real estate acquisitions, multifamily underwriting, or rental-demand investment screens.' It does not mention alternatives or when not to use it, but the context is 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=true and openWorldHint=false, so the description does not need to re-state safety. It adds valuable behavioral context: 'weighted 24h avg CO2', data sources 'EIA + Electricity Maps', 'hourly' updates, and 'history since 1973'. It also explains the greenness_flag logic (renewables >50%). This goes beyond the structured 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?

The description is front-loaded with the returned data and key fields, then provides usage guidance and update frequency. It is somewhat dense but every clause contributes useful information. The length is justified given the number of output fields and use cases covered.

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 only one optional parameter and no output schema, the description covers the return fields, data sources, update cadence, and relevant use cases. It does not explain the exact units of avg_co2_intensity or the meaning of grid_load_status, but the description is sufficiently 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% for the single optional 'days' parameter, which has a detailed description in the schema. The tool description itself does not mention the parameter or provide additional meaning, so it does not add beyond the schema. Baseline 3 is appropriate when the schema fully documents the parameter.

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

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

The description clearly states the verb 'Returns' and the resource (a 0-100 renewable-share and grid carbon intensity summary), and lists specific output fields. It is distinctive enough to differentiate from likely sibling tools focused on other data domains.

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 states 'Call when the user asks about carbon intensity, grid emissions, renewable share, clean energy, or electricity greenness, or when timing carbon-aware scheduling of compute, ML training, or batch workloads for Scope 2 reporting.' This provides clear trigger contexts and a concrete use case, effectively guiding when to select this 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 provide readOnlyHint=true, so safety is covered. The description adds update frequency ('Updates: hourly'), data sources (GDELT, RSS, CoinDesk), the weighting formula, and history depth to 2015. It also includes the Gold tier restriction via the parameter description, which adds behavioral context beyond 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 compact, front-loaded with the core purpose and output, followed by usage guidance and update frequency. Every sentence provides value, no redundant text, and it fits in two 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?

For a read-only tool with one optional parameter, the description covers the return fields, sources, update cadence, and usage scenarios. It does not explicitly detail the structure of the 'days' history response, but that is reasonably implied. Given the absence of an output schema, this is 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?

Schema coverage is 100% (only 'days' well-described). The description does not add further parameter semantics beyond what the schema already provides. The baseline of 3 applies since the schema fully documents the parameter and its behavior.

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 a '0-100 global news sentiment and trend velocity index' with specific details on sources, weighting, and history. It lists exact output fields (sentiment_index, news_velocity, tone_score, source_diversity_score), distinguishing it from any sibling tool. The verb 'Returns' is specific and 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?

Explicitly defines when to call: 'Call when the user asks about news sentiment, media tone, news-flow spikes, breaking-news momentum, or headline risk' and even extends to trading applications. It lacks explicit exclusions or named alternative tools, but the context is clear and actionable.

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

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

Annotations already declare readOnlyHint=true, and the description adds that data is daily, reproducible, and uses keyless GitHub REST data, implying no auth. It also discloses the methodology and update frequency. However, it doesn't describe behavior for the 'days' parameter beyond schema, but that's covered there.

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 efficient; however, 'Updates: daily' is redundant with the earlier '(daily...' mention. Otherwise, every sentence serves a purpose.

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

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

The description names all four return fields, explains the scoring formula, and covers the key use cases. With no output schema, this is sufficient to understand the tool's behavior. It could mention the history parameter but the schema covers it, so no 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?

The only parameter 'days' has a full schema description including optionality, range, and the Gold tier limitation. The description itself adds no additional parameter detail, so the baseline of 3 is appropriate given 100% 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 clearly states it returns a 0-100 health score with a specific formula and defines the returned fields. It is specific about the resource (AI/software ecosystem) and distinguishes from generic siblings by naming the unique score and drivers.

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 provides multiple when-to-call scenarios, including organic vs hype, mindshare, and investment timing. It doesn't explicitly say when not to use it, but the positive guidance is strong and 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=true and openWorldHint=false, so safety is handled. The description adds valuable context beyond these annotations: it explains that low scores mean acute stress, describes the normalization methodology, and states the weekly update cadence since 1975. This sets clear expectations and does not contradict 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 clear structure: output and methodology, use cases, and update frequency. The use-case keyword list is long but directly actionable for an AI agent. Every sentence earns its place; 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 simple read-only tool with one optional parameter, the description covers what is returned, when to use it, how the score is computed, and what low/high scores mean. It names the output fields (continuity_score, freight_trend, confidence) even though no output schema exists, adding value. The only minor gap is that it doesn't itself mention the daily history behavior, but the schema fully covers that.

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

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

The only parameter 'days' is fully described in the schema (100% coverage), including the Gold tier requirement. The description itself does not discuss the parameter, but the schema carries the full semantic burden. Given the high schema coverage, a 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 opens with a specific verb and resource: it 'Returns a 0-100 global supply chain continuity score' and concretely names the constituent indices (Freightos FBX, Drewry WCI, NY Fed GSCPI) as well as output fields. This clearly distinguishes it from generic adw siblings and communicates its exact function.

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 an explicit 'Call when' list covering user intents (supply chain stress, container shipping costs, ocean freight rates, etc.) and business decisions (timing purchase orders, safety-stock buffers, alternate suppliers). It does not mention exclusions or alternative tools, but the triggers are far more specific than typical descriptions.

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 declare readOnlyHint=true, and the description adds substantial behavioral context: the weighting formula, sources, daily update frequency, and how stale data can pause downstream jobs. It also notes the Gold tier requirement for history via the schema description. No contradiction with 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 well-structured: first sentence defines the output and formula, second sentence provides usage context, and third sentence states update frequency. Every sentence adds value with no redundancy.

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

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

Despite the absence of an output schema, the description lists the concrete output fields (quality_index, freshness_hours, completeness_pct, stability_score) and explains the computation and sources. It also covers update frequency and usage context, making it complete for this tool's 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?

The schema description for the only parameter 'days' is comprehensive (100% coverage), including the optional history behavior and Gold tier constraint. The tool description itself does not add parameter-specific meaning, 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 the tool returns a 0-100 source quality and freshness index with an explicit formula and data sources. It distinguishes this tool from siblings by specifying the exact purpose, output fields, and the computed metric.

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 explicit 'Call when' guidance for user questions about freshness, staleness, completeness, or source reliability, and for downstream pipeline refresh timing. It does not mention alternatives or when-not-to-use, but the context is clear enough.

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 provide readOnlyHint, and the description adds substantial context: data source (FRED), methodology (z-scored, trailing 36 months), interpretation (50=neutral), history since 1992, and update cadence. Exceeds annotation coverage 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?

Two dense but purposeful sentences: the first packs methodology and output fields, the second gives usage triggers and update frequency. No wasted words; front-loaded with the key output.

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?

Without an output schema, the description lists all returned fields. It also covers methodology, data source, update frequency, and usage context. For a single-optional-param indicator tool, this is 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% for the only optional parameter (days), which is well-documented. The description adds no additional parameter semantics, 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?

Clearly states it returns a monthly 0-100 US consumer-credit stress score with specific methodology (z-scored vs trailing 36 months) and output fields. The verb 'Returns' plus the precise resource differentiates it from generic sibling 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?

Provides explicit 'Call when' triggers (consumer credit stress, card delinquencies, etc.) and use cases (underwriting tightening, collections). Missing when-not-to-use or alternative tool mentions, so not 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 readOnlyHint=true, so the description adds extra behavioral context beyond annotations by disclosing 'Updates: daily', the output components (score, trend, confidence, top_drivers), and the data sources (POS volume, discount depth, promo calendars, competitor pricing). No contradiction exists.

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 tightly structured sentences. The first sentence defines the output and calculation inputs; the second provides actionable use cases. It is front-loaded with the core return value and contains no unnecessary 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?

For a tool with no output schema, the description lists the return components and update frequency. It covers purpose, usage, and (with the schema) parameter behavior. Minor omissions like score direction and explicit mention of optional history mode are not critical since the schema covers that.

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 provides 100% coverage for the single optional 'days' parameter, including the Gold tier requirement for history. The description itself adds no parameter-specific meaning, 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 uses a specific verb 'Returns' and identifies a precise resource: '0-100 promo-elasticity gap score by retail category'. It further explains the metric's construction (realized ROI vs elasticity-implied maximum) and data inputs, making the tool's function unambiguous and distinguishing it from other analytics 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 description explicitly lists when to call the tool: 'when the user asks about promotion effectiveness, trade-spend ROI, discount depth, or price elasticity, or when timing trade-budget reallocation and promo-calendar decisions.' This is clear context, but it does not mention alternatives or exclusions, 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 the description adds valuable context beyond that: monthly update cadence, z-scoring vs. 36-month window, the 0-100 scale with 50=neutral, and the list of returned fields. It doesn't explain every field's semantics, but for a read-only indicator the safety profile is handled 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 dense but purposeful, with a clear sequence: what it returns, when to call it, and update frequency. The first sentence is a long parenthetical-heavy construction, but every clause adds substantive information and there is 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?

Given no output schema, the description compensates well by explaining the score's meaning, data source, methodology, and use cases. The returned fields are listed by name, and most are self-explanatory (e.g., core_cpi_yoy_pct, real_wage_gap_pct), though 'trend' is left vague. Overall, an agent has enough context to 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 sole parameter `days` is fully described in the schema, including optionality, range, behavior (daily history vs. snapshot), and the Gold tier requirement. The description itself does not mention this parameter, but because schema coverage is 100%, 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 opens with a strong verb and concrete resource: 'Returns a 0-100 monthly consumer discretionary-squeeze score.' It defines the metric's formula, scale, and neutral point, making it unmistakably distinct from any generic economic or spending tool. The purpose is fully clear.

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?

Explicit call-when guidance is provided: 'Call when the user asks about consumer spending pressure, inflation outpacing wages, real wages, purchasing power, or cost-of-living squeeze, or when timing retail promotions...' This is high-quality context, but it lacks any 'when not to use' or explicit alternative comparisons, 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?

Annotations already declare readOnlyHint=true, and the description adds data-refresh behavior ('daily refresh, history to 1987') and output composition. However, it omits the Gold-tier requirement for history (which appears in the parameter description) and any other limitations or side effects, leaving moderate transparency beyond the annotation.

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 efficient, front-loading the return value and data sources. It slightly repeats 'daily' (once in the parenthetical and again in 'Updates: daily'), but overall it is well-structured and doesn't pad.

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 claims to score by US zip code, yet the input schema has no zip-code parameter and the description doesn't explain how the target zip is supplied. This is a critical ambiguity that could lead an agent to invoke the tool incorrectly. Output fields are mentioned, but the input mechanism is incomplete, making the tool hard to use reliably.

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

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

The sole parameter 'days' has a thorough schema description (returns history series, max 5 years, Gold tier requirement), giving 100% schema coverage. The main description does not discuss parameters, which is acceptable since the schema fully explains it, but it also does not clarify how the required zip code is provided—an important gap.

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

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

The description clearly states the tool returns a 0-100 demographic-affinity score for retail site selection by US zip code, with specific data sources (Census ACS, proprietary weights) and output fields (score, trend, confidence, top_drivers). This distinguishes it from generic demographic tools in the large sibling list, and the title reinforces the site-selection purpose.

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

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

The description explicitly lists call scenarios: 'where to open a store, zip-code site screening, trade-area demographic fit, timing lease commitments, market entry, or new-store openings.' It provides clear context but does not mention when not to use the tool or name alternatives, which would push it to 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 readOnlyHint=true, so the description need not restate safety. It adds useful behavioral context: the index is updated daily, it uses stochastic optimization over specified data feeds, and it returns trend/confidence/top_drivers in addition to the score. This goes beyond the annotation without contradicting it.

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: first states purpose and output, second gives explicit when-to-use, third states update frequency. Every sentence earns its place with no fluff or repetition. Front-loaded with the most important 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?

The tool is moderately complex (stochastic index with multiple inputs and outputs), and the description covers what it returns, when to use it, and its update cadence. Since there is no output schema, the explicit listing of score, trend, confidence, and top_drivers fills that gap. The parameter is simple and well-documented. This is complete for an agent to select and 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?

Schema coverage is 100% for the only parameter 'days', which has a detailed description in the schema including the Gold tier caveat. The tool description does not add semantic detail about the parameter, but per the rubric, a high coverage baseline of 3 applies. No extra credit 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 clearly states the tool returns a 0-100 supply-chain disruption cost index, with specific methodology (stochastic optimization over lead-time volatility, demand variance, holding costs) and output components (score, trend, confidence, top_drivers). This is a specific verb+resource+scope that distinguishes it from the many opaque sibling 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 description explicitly says when to call: 'when the user asks about supply-chain disruption, stockout risk, or freight cost pressure, or when timing a hedge-now versus wait inventory decision.' This gives clear context, though it does not mention alternatives or when-not-to-use, 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?

Annotations indicate read-only (readOnlyHint: true), and the description adds meaningful behavioral context: methodology (NLP over GDELT news sentiment, official trade alerts, entity-specific risk events), historical depth (daily since 1998), update cadence, and the output fields returned. No contradictions with annotations; the read-only claim is consistent with 'Returns.'

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 information-dense sentences plus a three-word update note. The parenthetical methodology adds value without bloat, and the use-case sentence is practical. No filler.

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

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

For a read-only scoring tool with one optional parameter, the description covers output shape, methodology, update cadence, and trigger scenarios. The schema covers the parameter; no output schema exists but output fields are named. Adequate for an agent to select and invoke confidently.

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 optional parameter `days` is fully documented in the input schema (min/max, behavior, and Gold-tier requirement), so schema coverage is 100%. The description adds no additional parameter details, but the baseline of 3 applies because the schema carries the 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 opens with a specific verb ('Returns') and clearly identifies the resource: a 0-100 supply-chain disruption-risk score with concrete output components (score, trend, confidence, top_drivers). It differentiates this tool by domain (supply-chain risk) even though sibling names are opaque.

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 explicit call conditions, enumerating user intents that should trigger this tool: supply-chain risk, supplier/trade-lane disruption, geopolitical logistics exposure, port stability, and timing decisions (diversification, safety stock, pull-forwards). It does not name alternative tools or give when-not guidance, but the call triggers are unusually specific.

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

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

Beyond the readOnlyHint annotation, the description adds behavioral context: 'Updates: daily,' the data sources blended (hospital admission rates, seasonal patterns, BLS employment), and output structure. It does not contradict annotations and provides useful operational details, though it omits any limitation or side-effect information—acceptable given the read-only nature.

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 compact three-sentence paragraph: it front-loads the core output, then provides usage guidance, and finishes with update frequency. No sentence is wasted; technical details like data sources are relevant to understanding the forecast.

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

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

With no output schema, the description sufficiently lists return fields (score, trend, confidence, top_drivers) and explains the forecast nature. It also covers update cadence and intended use cases. The optional parameter is fully documented in the schema, so the description is complete for this tool's 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 coverage is 100% for the single optional 'days' parameter, which is thoroughly described in the input schema (history series, range, Gold tier requirement). The description itself adds no parameter-specific details, 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 the tool 'Returns a 0-100 nursing-staff shortage risk score' with specific output components (score, trend, confidence, top_drivers). The verb 'Returns' and resource 'nursing-staff shortage risk score' make the purpose unambiguous, and the title and content distinguish it from sibling tools focused on other risk domains.

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

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

The description explicitly states when to call: 'Call when the user asks about hospital staffing gaps, nurse shortages, or healthcare labor-market tightness, or when timing travel-nurse contracts, float-pool deployment, or nurse recruiting spend.' This provides clear context, but it does not mention alternatives or when not to use, 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?

The description provides substantial behavioral detail beyond the readOnlyHint: it explains the calculation methodology (WTI log-return stdev 70% + Energy CPI stdev 30%), data source (FRED), update frequency (monthly), output fields, and optional history mode with Gold tier requirement. No contradiction with 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 packs a lot of useful information into a single dense sentence followed by a short 'Updates: monthly.' While not perfectly structured, it contains no fluff and front-loads the core purpose before usage guidance.

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 moderate complexity and lack of an output schema, the description is remarkably complete: it explains the index formula, output fields, usage scenarios, update frequency, and the optional history mode with tier restrictions. An agent can accurately decide when and how to invoke this 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 only parameter, 'days', is fully documented in the schema with details about optional history series, bounds, and Gold tier requirement. The description does not add parameter-specific information beyond what the schema already provides, but since schema coverage is 100%, 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 ('Returns') and identifies a precise resource: a 0-100 energy-cost volatility index with a clear formula and data source. It also lists the output fields, making the tool's purpose unmistakable and distinguishing it from generic sibling 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 description explicitly states when to call the tool ('Call when the user asks about energy price risk, oil/fuel cost swings, or hedging energy exposure...) and gives concrete use cases like timing energy contract locks and WTI futures hedges. It does not mention when not to use it or alternatives, so it falls just 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?

With readOnlyHint=true, the description adds useful context beyond annotations: data source (FRED), update frequency (monthly), and history depth (since 1960). It doesn't contradict annotations and gives the agent a sense of data freshness and 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?

The description is dense but well-structured, packing the formula, output fields, use cases, and update frequency into two sentences. Every word contributes value, making it highly concise.

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 with one optional parameter and no output schema. The description lists all output fields (score, trend, confidence, etc.) and contextualizes the data source and update frequency. It's complete enough for correct invocation, though it could elaborate on what 'aspiration_spread_pct' means, but the formula helps.

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

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

The only parameter 'days' is fully described in the schema (100% coverage), including its optional nature, range, and Gold tier requirement. The main description adds no extra parameter details, 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?

The description clearly identifies the tool as returning a consumer aspiration-premium index with a specific formula and output fields, making its purpose unambiguous. It doesn't explicitly distinguish it from siblings, but the level of detail compensates.

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 explicit scenarios for when to use the tool, such as 'brand pricing power' and 'timing price increases', which is clear context. However, it doesn't mention when not to use it or name alternative tools, 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 readOnlyHint=true, and the description adds meaningful context: the score scale, return fields, and update frequency. It also discloses the Gold tier requirement for history in the schema, but the description itself adds the update cadence and output composition, going beyond 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: the first defines the metric and return fields, the second lists usage triggers and update frequency. Every sentence carries crucial information with no redundancy or filler.

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

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

Given no output schema, the description compensates by listing the returned fields (trend, confidence, alignment_label, signed divergence_z_score) and explaining the score scale. It lacks detailed definitions of 'trend' or 'confidence', but overall it is complete enough for an agent to understand the tool's value and 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 single parameter 'days' is fully described in the schema, including its optional nature, range, and tier prerequisite, so the description does not need to repeat it. The description does not add parameter-level detail, but schema coverage is 100%, 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 the tool returns a 0-100 gas perception-gap score with a specific formula and output fields. The verb 'Returns' plus the resource 'gas perception-gap score' makes the purpose unmistakable and distinguishes it from other tools in the catalog.

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 explicit 'Call when' conditions covering user intents like gas price versus consumer mood and political risk. It lacks exclusions or named alternatives, but the when-to-use guidance is clear and abundant.

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 description discloses data sources, update frequency ('daily'), historical depth ('history to 1966'), and output fields (score, trend, confidence, top_drivers). The readOnlyHint annotation already signals safety, and the description adds context about how data is derived without contradicting the annotation. It does not mention potential limitations or error conditions, but for a read-only tool this is sufficient.

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 output and data sources, followed by explicit use cases. Every sentence carries meaningful information and there is no fluff or repetition of schema fields.

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

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

Given there is no output schema, the description lists the returned fields (score, trend, confidence, top_drivers) and explains the underlying methodology. It covers the main purpose, use cases, and update cadence. The parameter is fully documented in the schema, so the description is 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?

The schema has full 100% documentation for the single 'days' parameter, so the baseline is 3. The description does not elaborate on parameter behavior, but it mentions 'daily, history to 1966' which implicitly aligns with the optional history series. The schema itself already explains the Gold tier requirement and the range (1-1825), so the description adds no extra parameter 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 uses a specific verb 'Returns' and clearly names the resource ('regional sunlight-deficit wellbeing risk score'), including its scale (0-100) and core components (NSRDB solar irradiance, NOAA daylight duration, mental-health utilization). This distinguishes it from generic health risk tools and sibling tools, which are simply numbered without titles.

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

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

The description explicitly states when to use the tool: 'Call when the user asks about seasonal affective risk, winter light deprivation, or regional mental-health demand, or when timing employer wellness campaigns, EAP outreach, or telehealth staffing by region.' It provides clear contexts but does not mention when not to use it or alternatives, so it falls just short of a perfect score.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds behavioral transparency by disclosing that the metric is monthly, percentile-ranked over 36 months, and includes specific output components (gap_type, trend, confidence, top_drivers). It also notes 'Updates: monthly', providing data freshness context beyond 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 two sentences: the first packs the essential return value, methodology, and output fields; the second gives precise usage guidance. There is no filler, and the most important information is front-loaded for quick parsing.

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 that there is no output schema, the description adequately lists the key return fields and the underlying data sources, which is sufficient for an agent to understand what the tool does. It also covers usage scenarios and update frequency. The only minor gap is that it doesn't explain the meaning of trend/confidence, but this is not critical for tool selection.

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

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

The only parameter (days) has a thorough schema description that fully explains its purpose, behavior (historical series vs current snapshot), and the Gold tier requirement. With 100% schema coverage, the description doesn't need to add parameter details; the baseline of 3 applies since the schema carries the explanatory burden.

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

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

The description clearly states the tool's function with a specific verb ('Returns') and a well-defined output: a 0-100 brand sentiment-to-sales-volume gap score with detailed sub-components (gap_type, trend, confidence, top_drivers). It goes beyond generic phrasing by naming the exact data sources (UMich consumer sentiment vs FRED retail sales) and the percentile-ranking methodology, which distinguishes it from 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?

The description provides explicit 'Call when' guidance with four concrete use cases (marketing efficiency, high-engagement low-conversion campaigns, consumer hype vs actual spending, brand buzz outpacing sales, timing shifts in ad spend). While it doesn't explicitly name alternatives or when-not-to-use, the strong context signals make routing 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 state readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds meaningful context beyond that: the score's formula (cost-differential between permanent and contingent staffing), the five data sources (BLS, LinkedIn, Glassdoor, internal HRIS), the output fields (trend, confidence, top_drivers), and the daily update cadence. This enriches the agent's mental model of what the tool does and what 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?

The description is two sentences, front-loaded with the key return value and definition, followed by explicit usage triggers and update frequency. Every sentence serves a purpose, with no filler or repetition of schema details.

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 a read-only indicator with no output schema, and the description sufficiently explains the return value (score, trend, confidence, top_drivers), its meaning, and when to call it. The optional parameter's behavior is fully specified in the schema. There are no hidden prerequisites or side effects left unexplained; the daily update note is a nice completeness touch.

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 optional parameter 'days' has a thorough description in the schema (history series, up to 5 years, Gold tier requirement, fallback to snapshot). Since schema coverage is 100%, the description does not need to compensate, and it does not add any parameter-specific guidance beyond the schema. 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 opens with a specific verb 'Returns' and a precise resource: a 0-100 labor-adjacent capacity score, along with the exact data sources and output components (trend, confidence, top_drivers). This clearly defines what the tool does and differentiates it from the many sibling tools, even though sibling descriptions are absent.

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 explicit call triggers: 'Call when the user asks about contractor availability, hire-vs-contract tradeoffs, or staffing costs, or when timing headcount expansion versus contingent staffing for upcoming quarterly demand.' This gives clear guidance on when to use it, but it does not mention when not to use it or any alternatives (e.g., other adw indices), so it falls short of the top tier that requires when-not/alternatives.

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

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

Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral details: daily updates, data source provenance (NOAA NCEI, USGS, World Bank), and output composition. It does not disclose rate limits or error conditions, but the read-only safety profile is covered by annotations, so a 4 is appropriate.

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 substantive sentence plus a brief usage instruction and update frequency. It front-loads the return value and packs in essential context (data sources, output fields) without waste, though the parenthetical list makes it somewhat dense.

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

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

For a tool with one optional parameter and no output schema, the description is complete: it explains what is returned, when to use it, data sources, update cadence, and the optional history behavior is fully documented in the schema. No critical use-case or output information is missing.

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

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

The only parameter 'days' has 100% schema description coverage, including its optional nature, history mode, and Gold tier requirement. The main description does not mention the parameter, but the schema fully explains it, so the baseline of 3 is appropriate with no added value 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 ('Returns') and a well-defined resource ('0-100 climate-adaptation capex priority score'), plus lists output fields (score, trend, confidence, top_drivers) and data sources. It clearly distinguishes this tool from generic siblings by domain and use case, and the 'Call when' section reinforces purpose.

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

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

Explicit 'Call when' guidance is provided for physical climate risk, facility resilience, flood/heat exposure, adaptation ROI, and capital allocation timing. It lacks explicit statements of when NOT to use or named alternative tools, so it falls just 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 declare readOnlyHint=true, and the description reinforces non-destructive behavior. It adds meaningful context about the data source (monthly FRED series), the exact weighting formula, the high-stress threshold, and the update frequency ('Updates: monthly'), which informs the agent about data recency and interpretation.

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 front-loaded: the first sentence conveys the core value and composition; the second sentence covers usage guidance and update cadence. Every sentence provides distinct value 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?

The description explains the returned fields (score, trend, load_level, composite_z_score, driver YoY rates), the composite methodology, the threshold interpretation, and the appropriate usage contexts. The optional history parameter is fully specified in the schema, so the description's omission is acceptable. Without an output schema, the description still gives the agent enough knowledge to invoke and interpret the 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 coverage is 100% with the single optional `days` parameter fully described in the schema. The tool description does not mention the parameter or add semantics beyond the schema, so it meets the baseline of 3.

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 ('Returns') and a measurable resource ('0-100 digital infrastructure load index'), specifies its composition (electricity generation 60% + data-processing PPI 40% YoY z-scores), lists the output fields, and includes a threshold (>70=high stress). This clearly distinguishes it from other adw tools as a specialized infrastructure load indicator.

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 lists trigger scenarios: 'data center demand, cloud capacity strain, compute cost pressure, or infrastructure buildout' and decision contexts: 'timing capacity expansion, reserved-instance purchases, or auto-scaling budgets'. It does not mention when not to use the tool or name alternatives, but provides strong situational guidance.

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

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

Beyond annotations (readOnlyHint=true), the description discloses data sources (NLP over gazettes, agency publications), weighting methodology, refresh cadence ('Daily refresh', 'Updates: daily'), depth of history (to 1997), and return fields. This adds substantial behavioral context with no contradiction to 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 compact and front-loaded: the first sentence states exactly what the tool returns and how, the second gives usage guidance, and the third covers freshness. No redundant or filler content.

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

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

Given the simple schema (one optional parameter) and read-only annotations, the description provides sufficient detail for an agent to invoke the tool correctly and interpret the result (score, trend, confidence, top_drivers). The lack of output schema is mitigated by listing expected fields.

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 optional 'days' parameter, including behavior and tier requirement, with 100% coverage. The description adds no additional parameter information, so the baseline score 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?

The description clearly states the tool returns a 0-100 regulatory compliance risk score with specific output fields, methodology, and use cases. It does not explicitly differentiate from sibling tools, but the title and description make its domain unmistakable.

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

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

Provides explicit guidance on when to call, listing trigger phrases like 'regulatory exposure' and decision contexts like 'market entry' and 'vendor onboarding'. Does not mention alternatives or when not to use, but offers clear context.

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, so the description doesn't need to state it's a read operation. It adds valuable behavioral context: 'Daily refresh; history to 1996' and 'Updates: daily' plus the output components (trend, confidence, top_drivers). No contradiction with annotations, and it provides additional context beyond the 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?

The description is three sentences that front-load the core return value, then give usage triggers and data freshness. Every sentence adds essential information with 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 no output schema, the description does mention the key return components (score, trend, confidence, top_drivers) and data sources, which is sufficient for basic invocation. It could be more explicit about how the tool identifies the relevant supply chain (there are no required parameters), but for selection among many siblings the triggers are clear enough.

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% for the single optional 'days' parameter, whose description explains the history series, limits, and Gold tier requirement. The tool description does not add parameter-level semantics beyond what the schema already provides, so 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?

The description opens with 'Returns a 0-100 supply-chain diversification score' and clearly enumerates the score's components (HHI across supplier spend, sourcing regions, transport modes) and data sources (ImportGenius, Panjiva, etc.). This specific verb+resource+scope distinguishes it from the many similarly named sibling 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?

Explicit usage triggers are provided: 'Call when the user asks about supplier concentration, single-source risk, regional exposure, or transport-mode dependence' and it lists decision contexts like dual-sourcing and nearshoring. However, it does not mention when not to use it or any alternative tools, just missing the exclusion/alternative component.

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 mark the tool as readOnlyHint=true, so the description need not repeat safety. It adds valuable behavioral context by disclosing the data source (TSA checkpoint passenger volumes), weekly update cadence, and the formula (30-day throughput vs 7-year history plus momentum). It also lists the returned fields, which is helpful given no output schema exists.

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: the first leads with the primary output and its composition, the second provides explicit usage triggers and update frequency. Every word earns its place, with no tautology or filler, making it highly scannable and informative.

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

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

For a tool with one optional param and no output schema, the description covers the main behavior, use cases, data source, update cadence, and all output field names. It does not define each field's exact meaning, but the field names are largely self-explanatory and the schema covers parameter behavior, leaving only minor gaps.

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% for the sole parameter `days`, including its optionality, purpose, range, and tier requirement. The description adds no additional parameter detail, so the baseline 3 is appropriate given the schema fully handles parameter 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 states a specific verb ('Returns a 0-100 US tourism-demand pulse') and resource/scope (US TSA checkpoint volumes), and enumerates the exact output fields (score, trend, confidence, etc.). This provides a clear, distinct purpose that differentiates it from the many sibling adw tools, even without naming 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?

Explicitly lists when to call the tool: when the user asks about US travel demand, air passenger traffic, airport throughput, tourism recovery, hospitality occupancy, or dynamic pricing/discount decisions. It lacks a when-not-to-use clause or direct comparison to alternatives, so it falls short of a 5, but the stated triggers offer strong guidance.

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

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

Annotations already declare readOnlyHint=true, and the description adds valuable context beyond that: monthly update frequency, the calculation formula, and the specific output fields (trend, wages_yoy_pct, core_cpi_yoy_pct, wages_z/cpi_z). It does not mention error handling or rate limits, but for a read-only data retrieval tool, this is adequate 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 dense but not bloated—two sentences pack the essential methodological, output, and usage details. It front-loads the primary return value ('0-100 wage-price spiral risk score') before diving into components and when to use it. Some might find it slightly long, but 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 no output schema, the description compensates by listing the key return fields and explaining the risk score's meaning. It covers the tool's purpose, methodology, update frequency, and use cases. The only minor gap is a lack of explicit explanation for the 'trend' field, but this does not undermine overall completeness for a read-only indicator 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 input schema has 100% description coverage for the only parameter ('days'), providing a complete explanation of its optional use, maximum value, and Gold tier requirement. The description does not add parameter-specific information, which is acceptable since the schema already carries the full semantic load. 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?

The description begins with a specific verb ('Returns') and a precise resource ('0-100 wage-price spiral risk score'), then details the exact methodology (YoY avg hourly earnings + YoY core CPI, equal-weight z-scores vs 36-month window). It clearly distinguishes this tool from generic economic metrics by naming the output components and threshold (>50 = rising risk), making it easy to identify from the many sibling 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 description explicitly states when to call the tool: 'Call when the user asks about wage-price spirals, wage growth vs inflation, sticky core inflation, or labor-cost pass-through, or when timing rate-hike exposure, bond duration shifts, or nominal-vs-TIPS allocation.' This is strong positive guidance, but it does not mention any when-not-to-use cases or alternative tools, so it falls slightly 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?

Beyond the readOnlyHint annotation, the description discloses the calculation method (weighted z-scores of truck freight PPI YoY and diesel 4-week change), the 36-month window, data source (FRED), frequency (monthly since 2007), and update cadence. It also transparently notes that the optional history feature requires Gold tier and otherwise returns the current snapshot. This is rich behavioral context with no contradictions.

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 efficient sentences. The first sentence fronts the return value and composition, the second gives concrete use-case triggers and update cadence. Every clause carries information; no 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?

Given there is no output schema, the description usefully enumerates the return fields (score, trend, confidence, top_drivers, component z-scores). It also explains the index's construction, data source, and update frequency. It does not define interpretation benchmarks for the 0-100 scale, but for a data-index tool this is sufficient. A 4 reflects strong coverage without overreaching.

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

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

The only parameter, `days`, is already fully described in the schema (optional, range 1-1825, returns a historical series, requires Gold tier). The description adds no additional parameter-level nuance, so with 100% schema coverage 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 opens with a specific verb ('Returns') and a clear resource: a 0-100 US freight and logistics cost pressure index. It names the exact outputs (score, trend, confidence, top_drivers, component z-scores) and the underlying methodology, making it unmistakably distinct from any sibling tool.

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

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

The description explicitly lists when to call the tool: 'when the user asks about freight rates, trucking costs, diesel prices, shipping cost inflation, or supply-chain margin pressure, or when timing carrier contract renegotiations, fuel surcharge requests, or margin-risk alerts.' This is strong when-to-use guidance, though it stops short of naming alternatives or exclusions, so it earns a 4 rather than 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 indicate readOnlyHint=true and openWorldHint=false. The description adds useful behavioral context: monthly updates, the 36-month z-score window, and the data sources. It does not contradict annotations and provides meaningful methodology details beyond the safety profile.

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 well-structured sentences: the first defines the index and outputs, the second provides use cases and update frequency. Every sentence is informative with no 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?

The description lists all return fields and covers use cases, update frequency, and methodology, which is sufficient given no output schema. It does not explain the confidence metric or top drivers in detail, but the essential information for invoking the tool is present.

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 schema fully explains the single 'days' parameter, including the optional history behavior and Gold tier requirement. The main description adds no extra parameter information, 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?

The description clearly states the tool returns a 0-100 healthcare cost inflation index with a precise definition (monthly FRED medical CPI vs core CPI spread, z-scored over 36 months) and enumerates the output fields. It is specific and distinguishes this tool from siblings by focusing on healthcare inflation.

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 lists when to call the tool, including specific query topics and business scenarios like employer health-plan renewals and healthcare budgeting. However, it does not mention when not to use it or alternative tools, so it lacks 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=true. The description adds rich behavioral context: the score is a composite z-score, updated weekly, includes trend/percentile/confidence/methodology_version, and has a 51-year history. This goes beyond the annotations by disclosing the nature and cadence of the data, though it doesn't mention rate limits/auth (not indicated as relevant). No contradiction with 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: first states what it returns, second gives usage triggers, third states update frequency. Every sentence earns its place with no redundancy or fluff, and the most important information 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 tool's simplicity (no required params, read-only, no output schema), the description fully outlines the return payload (score, trend, percentile, confidence, methodology_version) and the optional history behavior (via schema). It is complete for an agent to select and invoke the tool correctly even without an output schema.

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

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

The only parameter 'days' is fully described in the input schema (100% coverage), including its optional history behavior and Gold tier requirement. The description itself does not add any parameter-specific meaning, so 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 a specific verb ('Returns') and resource ('0-100 energy-transition demand score'), defining its composition (weekly composite z-score of EIA renewable-generation share) and history (51-year since 1975). It distinguishes itself from sibling tools by naming precise topics like renewable share growth and clean-energy allocation shifts.

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 explicit when-to-use scenarios: 'Call when the user asks about renewable share growth, clean energy adoption, solar/wind expansion, or decarbonization momentum, or when timing renewable-tilt ETF rebalances...'. However, it lacks when-not-to-use guidance or explicit alternatives, so it doesn't fully meet the 5-point criterion of exclusions/alternatives.

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

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

Annotations only say readOnlyHint=true and openWorldHint=false. The description adds substantial context: the exact weighted formula, the data source (FRED monthly since 1983), update frequency, output field list, and the Gold tier requirement for historical data. This goes well beyond 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 dense but every sentence carries value: formula, outputs, use cases, update frequency. It is front-loaded with the core functionality. Slightly long but not wasteful.

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

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

For a tool with no output schema, the description enumerates all output fields (trend, confidence, top_drivers, etc.), describes the data source and update cadence, and gives the Gold tier caveat for history. It feels complete for the tool's 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 coverage is 100% for the sole 'days' parameter, and its schema description is already detailed. The tool description does not add extra parameter semantics, but the baseline of 3 applies because the schema carries the burden.

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 starts with a specific verb ('Returns') and resource ('0-100 auto affordability score'), and even explains the underlying formula. This unambiguously distinguishes the tool from the many sibling adw 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?

Explicitly states when to call: 'Call when the user asks about car affordability, new vehicle prices, auto loan rates, or consumer auto financing costs, or when timing auto lending credit tightening...' This is strong use-case guidance.

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

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

Annotations include readOnlyHint=true, and the description adds meaningful behavioral context beyond that: the composite methodology, the 36-month rolling window, monthly update cadence, and the gold-tier requirement for history via the schema. It does not go into pagination or exact value formats, but with annotations covering safety, this is above average.

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 dense sentence followed by a terse 'Updates: monthly.' It packs in formula, fields, use cases, and cadence without fluff. The structure is slightly front-loaded with the result and methodology before use cases, which is effective.

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?

Even without an output schema, the description lists the key return fields (trend, confidence, pressure_level, top_drivers, component fields) and the underlying methodology. It also captures the optional history behavior through the schema description. This is nearly complete for an agent to use 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 description coverage is 100%, and the only parameter 'days' is fully described in the schema. The description does not mention the parameter, but the schema already carries the meaning, so 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?

The description opens with a specific verb and resource: 'Returns a 0-100 food-price pressure score' and enumerates the exact components (FRED Food CPI + Farm Products PPI YoY, weighted z-scores) and output fields. This clearly distinguishes the tool from the many adw.* 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?

The description gives explicit when-to-use scenarios: 'food inflation, grocery or agricultural commodity prices, farm-cost pass-through, or consumer food-price pressure' and even strategic uses like timing forward contracts. It does not name alternatives or exclusions, but the context is clear enough for an agent to select this 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=true, and the description adds useful context about the methodology (z-scored vs 36-month window), the meaning of 50, and the update frequency. It does not explicitly mention the Gold tier requirement for history, which is in the schema, but overall it provides meaningful behavioral detail beyond 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 long, front-loaded with the core purpose and output details, followed by use cases and update frequency. Every sentence adds value with no redundancy.

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

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

The description lists all output fields and explains the score interpretation. While it does not describe the Gold tier requirement for history (the schema does), it is otherwise complete for a read-only tool with a single optional parameter and clear update cadence.

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 'days' parameter is fully described in the schema. The main description does not add any additional semantic meaning for the parameter beyond what's in the schema, 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 returns a 0-100 US labor-market tightness score with a specific formula and lists the exact output fields. It also names concrete use cases, effectively distinguishing it from sibling tools even without explicit alternatives.

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

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

The description provides an explicit list of when to call the tool (e.g., labor market tightness, worker shortages, wage pressure, salary-band reviews). However, it does not state when not to use it or mention any alternatives, so it falls 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 openWorldHint=false, but the description goes far beyond by detailing data sources (FRED), calculation method (equal-weight z-scores vs trailing 130-observation window), scale anchor (50=neutral), historical coverage (monthly since 1953), and update cadence. This provides essential behavioral context not available from 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 compact and well-structured: first sentence states the return value and methodology, second gives usage scenarios, third states update frequency. Every sentence earns its place with no filler or redundant restatement 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?

For a tool with no output schema, listing all returned fields, methodology, and typical use cases is strong. The only minor gap is a slight ambiguity between the description's 'monthly since 1953' / 'Updates: monthly' and the schema's 'daily HISTORY series' for the `days` parameter, which could confuse an agent about data granularity in history mode.

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

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

The only parameter `days` is fully documented in the schema with 100% coverage, including its behavior and Gold tier requirement. The description itself adds no parameter-level detail beyond the schema, so a baseline 3 is appropriate per the rubric.

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 ('Returns') and identifies the resource as a corporate credit-spread stress index with clear methodology (Baa spread and high-yield OAS, z-scores, 0-100 scale, 50=neutral). It lists concrete output fields, making the tool's purpose unambiguous and distinct from generic market 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?

Explicit call triggers are provided: 'Call when the user asks about credit spreads, corporate default risk, high-yield stress, or bond market risk' plus specific hedging/de-risking timings. However, it does not mention when not to use this tool or name alternative sibling tools, so it lacks full exclusion/alternative guidance.

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

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

Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context: the calculation methodology (FRED M2 YoY growth, M2 velocity z-scores, 36-month trailing window), monthly update cadence, and historical coverage since 1962. It also notes the Gold tier requirement for the history parameter via schema, but the description itself mentions the data source and composite structure.

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

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

The description is compact (two sentences plus an update note) while packing essential details: output fields, methodology, data source, usage triggers, and update frequency. No filler or redundant phrasing.

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?

Since there is no output schema, the description compensates by listing all return fields (score, trend, monetary_impulse_label, m2_yoy_pct, etc.) and explaining the data source and scope. It fully equips an agent to decide when to invoke this tool, though it could add interpretation of the 0-100 score, which is not necessary for selection.

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% for the single optional 'days' parameter, which already explains the history behavior and Gold tier requirement. The description adds no additional parameter semantics beyond what the schema provides, so 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?

The description states a specific verb ('Returns') and a well-defined resource: a 0-100 money-supply momentum index composed of FRED M2 YoY growth and M2 velocity z-scores. It enumerates the exact output fields (score, trend, etc.), making the tool's purpose unambiguous and distinct from generic 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?

Explicitly specifies when to call: 'when the user asks about M2 money supply growth, liquidity, money velocity, or monetary tightening/easing regimes, or when timing duration positioning...' This provides clear usage context, though it lacks exclusions or named alternative 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?

The annotations only indicate read-only and open-world hints. The description goes well beyond this by disclosing the exact FRED series used, the calculation window, update frequency ('quarterly'), and a Gold tier requirement for the history parameter. No side effects are hidden, and the read-only nature is consistent with annotations. This is comprehensive behavioral 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 two sentences, front-loads the core return value and methodology, and packs the use cases into the second sentence. Every clause adds value; there is no fluff or repetition. It is appropriately sized 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?

Despite having no output schema, the description explicitly lists all returned fields (score, trend, confidence, top_drivers, productivity_yoy_pct, ulc_yoy_pct, z-scores). It also covers access restrictions, update cadence, and intended use cases. For a read-only data retrieval tool with one optional parameter, this is 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 description coverage is 100% for the single optional 'days' parameter, and the schema already explains its behavior (returns daily history, requires Gold tier, otherwise snapshot). The tool description does not add any parameter semantics 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 states exactly what the tool returns: a 0-100 US productivity-vs-labor-cost index with specific data sources, calculation method, and output fields. It clearly distinguishes itself from the many sibling tools by the precise index definition and the listed use cases, making it easy to recognize when this tool is needed.

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 explicit triggering conditions: 'Call when the user asks about labor productivity, unit labor costs, wage or cost squeeze, or margin pressure, or when timing earnings-growth and margin assumptions in sector models.' This is clear usage guidance, though it does not mention alternatives or when not to use it, so it doesn't earn 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 description discloses the score range, methodology, data sources, monthly cadence, and output fields. It adds useful behavioral context beyond the readOnlyHint annotation, such as the fact that updates are monthly and the score is based on equal-weight z-scores. It does not describe potential edge cases or response formatting, but the annotation already covers safety.

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 efficient: the first sentence packs the score scale, methodology, data sources, output fields, and temporal scope; the second sentence gives targeted use cases and update frequency. No filler or repetition of schema details.

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

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

There is no output schema, but the description compensates by enumerating the returned fields (trend, confidence, health_label, top_drivers, rate/delinquency percentages) and defining the score's meaning. It also explains when to use the tool and how often data updates, making the tool self-sufficient for an agent.

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 schema already fully documents the optional days parameter, including the history behavior and Gold tier requirement. The description adds monthly frequency context but does not meaningfully extend the parameter semantics beyond what the schema provides. 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?

The description opens with a specific action and object: 'Returns a 0-100 mortgage-market stress score' with an explicit formula, time range, and update frequency. It also lists the exact output fields, making the tool's purpose unmistakable even among opaque sibling names.

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

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

The description explicitly states when to call the tool: when the user asks about mortgage market health, mortgage rates, delinquency trends, or housing credit stress, and for timing LTV/underwriting decisions. It provides clear use-case triggers but does not describe when not to use it or name alternative 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?

The description adds transparency about data source (FRED delinquency rate), blending methodology (70/30 level-plus-momentum z-score), frequency (quarterly since 1992), and output fields. The readOnlyHint annotation already indicates safety, and the description does not contradict it.

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 output, then usage context. Every sentence serves a purpose; no filler.

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

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

For a no-output-schema tool, the description enumerates the key returned components (stress_label, trend, confidence, top_drivers, delinquency rate, z-scores), states update frequency, and provides explicit use cases. This is complete for an agent to select and invoke the 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 covers the single `days` parameter 100% with a clear description. The description does not mention this parameter, but the schema is sufficient, 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 states a specific verb+resource: 'Returns a 0-100 commercial real estate lending stress score' with methodology and output fields. It clearly distinguishes from siblings by specifying CRE stress context in the usage sentence.

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?

Explicit when-to-use guidance is provided: 'Call when the user asks about CRE stress, commercial real estate delinquencies, bank credit quality, or property lending risk, or when timing CRE loan-concentration reviews, credit-committee escalations, or exposure decisions.' However, no when-not-to-use or alternative tool names are given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds context about the data source, calculation method (z-scoring over trailing 36 months), and update frequency ('Updates: monthly'). No contradictions with annotations, and no missing destructive behavior since it is 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 a single, information-dense sentence followed by a usage sentence. It front-loads the main output (the 0-100 score) and follows with formula, output fields, and usage triggers. Every clause adds value, with no filler or repetition of schema info.

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 that there is no output schema, the description adequately enumerates all return fields (trend, confidence, gap_label, breakeven_inflation_pct, core_cpi_yoy_pct, divergence_pct, divergence_z) and explains the score's interpretation. The optional 'days' parameter is fully documented in the schema, and the update frequency is stated. This is complete for an agent to select and invoke 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 one parameter with a full description ('Optional: return a daily HISTORY series... History requires Gold tier'). Schema coverage is 100%, so the description does not need to add parameter details. The description does not mention the 'days' parameter, but the schema fully handles it, so a 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 returns a 0-100 inflation-expectations gap score with a specific formula (T10YIE minus core CPI YoY, z-scored), and lists the output fields. It distinguishes itself by specifying the exact data sources (FRED) and the output items, making it unambiguous versus sibling 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?

Explicit usage guidance is provided: 'Call when the user asks about market inflation expectations vs realized CPI, breakevens, TIPS, or Fed credibility, or when timing TIPS-vs-nominal Treasury rebalancing or inflation-hedge positioning.' This also implies when not to use it and differentiates it from alternatives.

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

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

The description adds behavioral context beyond the readOnlyHint annotation by explaining the signal's interpretation (50=neutral, >50=more inverted), computation (z-scored vs trailing window), output components, and update frequency ('Updates: monthly'). It also notes the Gold tier requirement for history, though that is also in the schema. This is valuable but not exhaustive.

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

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

The description is three sentences, front-loaded with the core output and meaning, followed by precise usage guidance and update frequency. Every sentence adds value without redundancy, making it highly efficient for an AI agent to parse.

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

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

The description covers the tool's purpose, output components, scale interpretation, usage triggers, and update cadence. While there is no output schema, the description lists the returned fields (trend, confidence, inversion_depth_label, raw spreads, composite_z). Minor gaps include exact definitions of trend/confidence and the history behavior, but the schema covers the parameter, and the description is adequate for most agent interactions.

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 'days' is fully described in the input schema (coverage 100%), including its optional nature, range, and the Gold tier requirement. The main description does not mention 'days' at all, so it provides no additional semantic meaning beyond the schema. Thus 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 the tool's specific function: 'Returns a 0-100 yield-curve inversion signal' with detailed methodology and output fields. This distinguishes it from generic siblings by focusing on the unique yield-curve inversion signal, making it easy to identify when this tool is relevant.

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 explicit use cases: 'Call when the user asks about yield-curve inversion, 10y-2y or 10y-3m Treasury spreads, curve flattening/steepening, or recession risk, or when timing credit de-risking, duration, or cash-allocation decisions.' It does not mention when not to use or name alternatives, which prevents a 5, but the guidance is specific and helpful.

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 indicate read-only safety. The description adds meaningful context beyond that: the composite z methodology (level 60%, momentum 40%), monthly update frequency, and 16.5-year history. It does not contradict annotations and provides enough behavioral detail for an agent.

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 every clause earns its place: what it returns, methodology, interpretation, when to call, and update frequency. It is organized in a single coherent sentence followed by targeted usage guidance, with no 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?

For a moderately complex tool without an output schema, the description covers the core purpose, methodology, output components, interpretation, and use cases. It does not explicitly describe the optional history mode in prose, but the schema covers that, and the description provides enough for correct selection and 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 fully documents the only parameter 'days' with its type, range, and behavior (returns history series, requires Gold tier). The description itself does not mention this parameter, so it adds no extra semantic value beyond the schema's already-complete 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 clearly states it returns a 0-100 US dollar strength score with specific components (trend, confidence, top drivers, etc.), distinguishing it from other tools. It names the precise economic measure (FRED broad trade-weighted index) and the output semantics (50=neutral, higher=stronger).

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 lists when to call it: user asks about dollar strength/weakness, USD/FX/currency moves, or FX hedging/pricing decisions. It does not mention when not to use it or name alternative tools, but the clear use-case list provides strong guidance.

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

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

Annotations already declare readOnlyHint=true, and the description adds useful context: data source (FRED PSAVERT), update frequency (monthly), and that it returns trend, confidence, saving_rate_pct, 3-month change, and top drivers. It does not contradict annotations. Some behavioral details (like the Gold tier requirement for history) are left to the schema, but the description still adds meaningful context.

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

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

Three sentences with no filler. The first sentence packs the core functionality and methodology, the second gives explicit use cases, and the third states update frequency. Every sentence earns its place, and the description is well 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?

The description covers what the tool does, its methodology, output fields, update frequency, and use cases. It does not mention the optional history feature (days parameter), but that is fully specified in the schema. Given the tool's simplicity and the schema's completeness, the description is fairly complete, though it could have briefly noted the history option.

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

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

The only parameter (days) is fully documented in the schema with a clear description, giving 100% schema coverage. Per the rubric, the baseline is 3 because the description does not need to repeat parameter details. The description adds no extra parameter semantics, but the schema does the job.

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 a 0-100 US consumer savings-rate stress index, with specific methodology (FRED PSAVERT, inverted, z-scored vs trailing 36-month window) and a threshold interpretation (>50 = below-average saving). This is a specific verb+resource that distinguishes it from any generic sibling 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?

Explicit when-to-use guidance is provided: 'Call when the user asks about consumer savings drawdown, household financial cushion, spending sustainability, or recession stress, or when timing consumer-credit underwriting, lending limits, or debt-to-income cutoffs.' However, it does not mention alternatives or when not to use this tool, 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 readOnlyHint=true, and the description adds behavioral context beyond that: the score's computation (composite z-score of EIA weekly stocks), the meaning of 100 as tightest on record, weekly refresh cadence, and the presence of an IOM field. This enriches the safety signal with data provenance and 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 two sentences with clear front-loading: the first defines the output and data attributes, the second lists exact usage triggers. Every clause adds value, with no repetition of schema or annotation details.

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 indicator tool with one optional param and no output schema, the description explains the score's scale, data source, refresh frequency, historical coverage, and when to call it. The 'IOM field' is mentioned but not explained, a minor gap in an otherwise complete description.

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 for the only parameter 'days' is 100%, with detailed description of its optional nature, range, and Gold tier requirement. The tool description adds no extra parameter guidance, 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?

The description opens with a specific verb and resource: 'Returns a 0-100 US petroleum inventory tightness score' and elaborates with the composite z-score, EIA data source, weekly refresh, and historical depth, clearly defining the tool's output and distinguishing it from 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?

Provides explicit invocation criteria, listing exact user queries like 'crude oil inventories' and 'EIA stock draws or builds' as well as trading contexts. However, it does not mention when not to use it or point to alternative tools, so it lacks 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 mark it read-only; the description adds meaningful behavioral detail: the data source (TSA checkpoint volumes), the calculation baseline (30-day vs 365-day mean), weekly update cadence, and the response components. No contradiction with 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 core return value, followed by concrete use cases and update frequency. Parenthetical details add precision without wordiness, and every 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?

Even without an output schema, the description enumerates all major response components (score, trend, confidence, top_drivers, recovery_ratio, means, daily count) and specifies the optional history behavior via the schema. This is complete enough for correct selection and 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 single optional `days` parameter is fully described in the schema, including range, optionality, and Gold tier requirement, so the description does not need to add more. The tool description provides no additional parameter-level meaning 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?

The description opens with a precise verb and resource: 'Returns a 0-100 US air-travel recovery index...' and names the source, calculation method, and returned fields. It is specific enough to distinguish this tool from the many siblings even without individual sibling descriptions.

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 lists triggering user requests ('air travel demand, TSA throughput, passenger volumes, airport traffic, or travel recovery') and a business context ('timing dynamic pricing and promotions'). It does not mention alternatives or exclusions, but the positive use-case guidance is concrete and actionable.

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

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

Annotations already mark readOnlyHint=true, and the description adds meaningful behavioral context: 30-day change calculation, percentile ranking against 8.5 years of history, low/high interpretation, hourly update cadence, and the exact fields returned. This goes beyond annotations and explains the data's nature and frequency.

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 dense but well-organized paragraph that front-loads the core return value, then details methodology, output fields, use cases, and update frequency. Every clause adds value without redundancy, and the 'Updates: hourly' at the end is a crisp external context signal.

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 tool with one optional parameter, no output schema, and clear annotations, the description covers the return format, interpretation, use cases, update frequency, and limitation history. Together with the schema's days parameter explanation, the agent has all necessary context 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%, with the days parameter fully described in the schema (optional history series, Gold tier requirement). The description adds no additional parameter semantics; it mentions the current snapshot but doesn't discuss the days parameter. Baseline 3 applies because the schema carries the parameter documentation burden.

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 'Returns a 0-100 stablecoin-flow momentum score', clearly specifying the verb and resource. It defines the score's construction (30-day change, percentile-ranked) and lists output fields (trend, confidence, top_drivers, supply, 30d change %), making the tool unambiguous and distinct from 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?

The description explicitly states when to call: 'Call when the user asks about stablecoin inflows/outflows, crypto liquidity, dry powder, or risk-on/risk-off rotation, or when timing DeFi/yield-farming exposure or crypto drawdown risk.' This provides clear contextual triggers for the agent, though it does not name a specific alternative 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=true, and the description adds meaningful behavioral details: hourly refresh, historical percentile basis (8.7 years), and the Gold tier requirement for history in the parameter description. This surpasses minimal annotation coverage and helps the agent understand data freshness and access constraints.

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 first sentence is dense but information-rich, and the usage guidance is explicit. 'Updates: hourly' is a minor standalone clause, but overall the description is well-organized and wastes no words. It could be slightly more compact but remains 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?

No output schema exists, and the description compensates by listing all key output fields (trend, confidence, top drivers, chains-above-floor count, 30-day mean/change, percentile rank). It also provides data source, methodology, refresh cadence, and use cases, making it fairly complete for a read-only metric 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 covers 100% of the single optional parameter, explaining its behavior (history series) and the Gold tier requirement. The description itself doesn't add parameter-level details, so the baseline of 3 is appropriate given 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 specifies a precise metric ('0-100 DeFi liquidity breadth score'), defines its derivation ('count of top-20 chains with TVL above $100M, DeFiLlama data'), and lists output components, making the tool's function unmistakably clear. It goes beyond a vague verb+resource statement.

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 enumerates triggering user intents ('DeFi health', 'cross-chain TVL distribution', 'multichain liquidity concentration') and a strategic context ('timing cross-chain LP deployment'). It does not name alternative tools or exclusions, so it falls short of the full 5 but provides clear usage context.

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, so no safety concern is needed. The description adds useful context: data source (GitHub Search API), normalization ceiling, update frequency (hourly), and history depth (since 2016). It doesn't mention rate limits or authentication, but these are not critical for a read-only metric 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 description is two sentences (plus an update note) that front-load the output and then provide usage context. Every sentence contributes value, with no redundancy.

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

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

Given no output schema, the description lists all output fields (trend, confidence, top_drivers, per_language breakdown, total_new_repos_30d) and explains the data source and update cadence. It could mention the days parameter's effect more explicitly in the description itself, but the schema already handles that.

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 covers 100% of parameter documentation, including the days parameter's behavior and Gold tier requirement. The description mentions history since 2016 but adds no additional semantics beyond the schema's already complete parameter description.

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 returns a 0-100 developer momentum score for four specific languages, with the metric definition (30-day new-repo creation via GitHub Search API), normalization, and output fields. It is specific and distinguishes from siblings by focusing on language ecosystem momentum.

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 states when to call: 'when the user asks about programming language popularity, adoption trends, developer ecosystem growth, or open-source activity, or when timing devtools GTM, developer-marketing spend, or language-community sponsorships.' This gives clear invocation context, though it doesn't name specific alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds behavioral context by describing the output components (percentile rank, trend, confidence, source_lineage, methodology_version), the data source (EIA), update frequency ('Updates: weekly'), and the historical depth ('history since 1975'). This goes beyond the annotations and is consistent with 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?

The description is two sentences long: the first conveys the metric's definition and output fields, the second provides usage guidance and update frequency. Every clause is informational, with no filler or repetition. It is dense but readable, earning a top score for conciseness.

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

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

With no output schema, the description compensates by listing the return fields (score, percentile rank, trend, confidence, source_lineage, methodology_version) and data source. It also includes usage triggers and update frequency. While it doesn't detail the format of every field or the 'days' parameter behavior, that parameter is fully covered by the schema, so the description is sufficiently complete for its 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?

The schema fully documents the only parameter ('days') with a description covering optionality, range, and tier requirements (100% coverage). The description does not add any parameter-specific information, so it doesn't improve on the schema. Baseline 3 is appropriate since schema handles parameter semantics completely.

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: 'Returns a 0-100 renewable-capacity growth momentum score' with specific components like percentile rank, trend, confidence, and methodology. The verb 'Returns' and resource 'renewable-capacity growth' are explicit, and the detailed output list distinguishes it from sibling tools that likely cover other metrics.

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 explicit trigger scenarios: 'Call when the user asks about renewable capacity growth, clean-energy buildout, solar/wind expansion, or energy transition pace, or when timing renewable infrastructure investment screening...' This is clear context for when to use the tool. However, it lacks explicit when-not-to-use guidance or references to alternative sibling tools, so it doesn't fully meet the top criterion.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=false. The description adds useful behavioral context beyond that: the update frequency ('Updates: monthly') and the methodology (z-score vs 1980-present NOAA NCEI history), which helps set expectations. No contradiction with 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 appropriately sized and front-loaded. The first sentence states exactly what is returned, the second enumerates use cases, and the third gives update frequency. Every sentence earns its place with 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?

Given no output schema, the description fully inventories the return fields (trend, confidence, top_drivers, cost z-score, percentile rank, latest vs trailing-10yr mean) and explains the data source and update cycle. It is complete for a read-only, optional-parameter 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 coverage is 100% for the single optional 'days' parameter, with a thorough schema description covering the history series and Gold tier requirement. The tool description does not add any parameter information, 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?

The description clearly states the tool returns a specific 0-100 US climate-disaster cost-trend score and enumerates the output fields (trend, confidence, top_drivers, cost z-score, percentile rank, latest vs trailing-10yr mean). This makes its purpose unambiguous and distinct from 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?

The description provides explicit call conditions: 'Call when the user asks about climate disaster costs, extreme-weather losses, hurricane/wildfire/flood damage, or catastrophe costs vs historical norms...' and lists timing use-cases. However, it does not specify when NOT to use or mention alternative tools, so it lacks the full 'when-not/alternatives' element.

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 provide readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds value beyond annotations by disclosing the update frequency ('Updates: daily'), the underlying methodology (60-day rolling z-score, CUSUM, Shannon entropy), and the data history (9+ years). It does not contradict annotations, and no major behavioral traits are obscured.

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 information-dense but compact. It front-loads the score definition and output fields, then gives usage triggers, and finally the update cadence. Every sentence contributes 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?

The tool has no output schema, but the description lists all return fields (trend, confidence, top_drivers, ewc_raw, cusum_statistic) and the score range (0-100). It also explains the methodology and when to use it. However, it does not interpret the score direction (e.g., higher = higher risk), which is a minor gap given the lack of an output schema.

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

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

Schema description coverage is 100% for the only parameter 'days', which already includes a detailed description including the Gold tier requirement and fallback behavior. The tool description itself does not add any additional parameter semantics. Per the baseline for high schema coverage, a 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 returns a 0-100 volatility regime-shift early-warning score for US equities, with specific methodology (SPY log-returns, rolling z-score, CUSUM, Shannon entropy). It lists all output fields (trend, confidence, top_drivers, ewc_raw, cusum_statistic), making its purpose unmistakable. Even among many sibling tools, the specific asset class (US equities) and output distinguish 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?

The description explicitly says 'Call when the user asks about market volatility, regime change, S&P 500 instability, turbulence, or vol spikes, or when timing position sizing, hedge adjustments, or options/straddle exposure ahead of market instability.' This gives clear when-to-use triggers. However, it does not mention alternatives or exclusions, so it does not fully differentiate against sibling tools that might also handle volatility signals.

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 description adds meaningful behavioral context beyond the readOnlyHint annotation by detailing the formula (20-day tail-exceedance rate vs 252-day baseline, sigmoid-scaled), the 0-100 score range, the output fields, and the daily refresh. It does not contradict annotations and provides a richer picture of what the tool returns and how it behaves.

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 a dense, informative first sentence that explains exactly what the tool returns. However, 'Updates: daily.' at the end redundantly repeats 'refreshed daily' from the first sentence, so not every sentence earns its place, preventing 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?

Without an output schema, the description is responsible for explaining return values. It lists the output fields (score, trend, confidence, top_drivers, tail_prob_shift, tail_prob_recent, tail_prob_baseline) but does not explain what 'trend', 'confidence', or 'top_drivers' represent. The optional history behavior is only in the schema, not in the description, leaving some gaps for a moderately complex 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 schema provides 100% coverage of the only parameter ('days'), including its optional nature, range, and Gold tier requirement. The main description does not add parameter semantics, so the baseline score of 3 is appropriate—the schema is doing the heavy lifting.

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 and resource: 'Returns a 0-100 fat-tail risk escalation score for US equities' with calculation details, making its purpose unambiguous. However, it does not explicitly distinguish itself from sibling tools by naming alternatives or contrasting with other risk metrics, 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?

The description provides an explicit 'call when' list covering tail risk, fat tails, crash probability, extreme moves, volatility regime shifts, drawdown risk, and timing de-risking/hedging. This gives clear context for use, but it lacks explicit when-not-to-use scenarios or alternative tool suggestions, so it earns a 4 rather than 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 readOnlyHint=true annotation, the description need not state read-only behavior. It adds valuable context: update frequency ('Updates: daily'), the percentile-ranking methodology, and the output field names. This goes beyond the annotation by explaining what the returned score represents and when it is current.

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: the first packs the core functionality and output fields, the second provides usage guidance. No wasted words, and the essential information is front-loaded. This is an example of efficient, well-structured description.

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 there is no output schema, the description compensates by enumerating output fields (trend, confidence, top_drivers, realized_vol_20d_ann, vol_slope_10d) and detailing the score's construction. It also covers update frequency and use cases. It doesn't define each field's semantics, but for a read-only data tool with a single optional parameter, this is sufficient.

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

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

Schema coverage is 100%, so the single 'days' parameter is already fully described in the input schema. The tool description does not add parameter-level detail, which matches the baseline of 3 as the schema carries the burden.

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 a daily 0-100 volatility regime-shift score with specific calculation methodology (10-day OLS slope of SPY 20-day realized volatility, percentile-ranked against 252-day history). It lists the output fields, making the resource and intended data highly specific and distinct from generic sibling 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?

Explicitly provides when-to-use conditions: 'Call when the user asks about volatility regimes, vol expansion or compression, whether market volatility is rising or falling, or SPY realized vol trend, or when timing entries, exits, hedges, or long/short-gamma options positioning.' However, it does not mention alternatives or exclusions, so it falls 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 declare readOnlyHint=true, and the description aligns, describing a read-only calculation. It adds behavioral context beyond annotations: data source (SPY via Stooq), update frequency (daily), score range, and output fields, which set expectations for what the tool returns. No contradiction detected.

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 concise sentences: what it returns, when to use, and update frequency. It is front-loaded with the main output and every sentence provides value without 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?

With no output schema, the description enumerates the return fields, which is crucial. It also provides methodology and use cases. The only minor omission is not explicitly stating it is a market-wide indicator (SPY proxy), but the description implies this via 'for US equities' and SPY. 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 only parameter (days) is fully documented in the schema with a description, constraints, and tier requirement. Schema description coverage is 100%, so the tool description does not need to add parameter details. 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 it returns a 0-100 volatility-range expansion score for US equities, with specific methodology (ATR-14 vs ATR-252, percentile-ranked over 10 years) and a list of output fields. This is a specific verb+resource+scope that distinguishes it from generic market 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?

Explicitly states 'Call when the user asks about volatility expansion, widening trading ranges, ATR, or breakout setups' and also lists use cases like timing momentum entries and breakout alerts. This gives the agent clear, actionable triggers for invocation.

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 mark the tool as read-only; the description adds valuable context about data source (Stooq OHLCV, daily since 2016), update frequency ('Updates: daily'), and expected output fields, going beyond the annotation baseline.

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 composed of two substantive sentences plus a brief update note. It is front-loaded with the core result, then use cases, and ends with cadence—every sentence earns its place with no redundancy.

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

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

For a read-only tool with a single optional parameter and no output schema, the description covers the return fields, data source, update cadence, and use cases. The schema handles parameter semantics and tier limitation, making the overall context 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 only parameter 'days' is fully documented in the input schema with a rich description covering history behavior and Gold tier requirement. The main description does not add parameter details, but since schema coverage is 100%, 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?

The description clearly states a specific verb ('Returns') and resource ('a 0-100 volatility-regime score for SPY') with a detailed methodological definition. It also lists output fields, distinguishing this from sibling tools as a volatility/tail-risk indicator.

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 explicit use cases ('Call when the user asks about volatility regimes, tail risk, market turbulence, vol spikes, or S&P 500 risk') and even tactical applications ('timing protective hedges, put spreads'). However, it does not name specific sibling alternatives or provide a when-not-to-use statement.

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 mark readOnlyHint=true, and the description confirms a read-only 'Returns' operation without contradiction. The description adds valuable behavioral context beyond annotations: daily update frequency, the list of output components (trend, confidence, top_drivers, etc.), and the meaning of the score. It does not disclose any unusual caveats, but for a read-only indicator this is sufficient.

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 information-dense yet concise: it packs the metric definition, interpretation, output fields, use cases, and update frequency into two sentences plus a short update note. Every clause serves a purpose, with 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?

There is no output schema, so the description compensates by naming the key output fields (trend, confidence, top_drivers, tmd_raw, upper/lower tail means) and explaining the score's interpretation. It also covers update frequency and use cases. Minor gap: the optional 'days' parameter and Gold tier behavior are only in the schema, not the main description, but the schema adequately handles that.

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% for the single optional 'days' parameter, and the schema description thoroughly explains its purpose, constraints, and tier requirement. The main description does not mention the parameter at all, so it adds no additional semantic value beyond the schema. Baseline 3 applies.

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

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

The description clearly states the tool returns a daily 0-100 return-asymmetry score for US equities, specifies the exact computation (SPY 60-day returns, 90th-percentile upper-tail mean minus 10th-percentile lower-tail mean), and explains interpretation (50=symmetric, >50=upside skew). This provides a specific verb and resource, effectively distinguishing it from generic sibling 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?

Explicitly provides concrete when-to-use guidance: 'Call when the user asks about return skewness, tail risk asymmetry, fat tails, or non-linear return dynamics, or when timing factor rotations...' This is clear context, though it does not mention when-not-to-use or alternative tools by 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?

Annotations declare readOnlyHint=true, and the description adds valuable context: it discloses the update frequency ('Updates: weekly'), the score scale and interpretation, and indirectly mentions the Gold tier requirement via the schema. It does not describe return format or rate limits, but for a read-only tool this is adequate.

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 with no waste. It front-loads the core mechanism (score range, interpretation), then lists outputs and usage triggers. Every 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?

Given the simple read-only nature, the tool is well covered. The description lists output fields and usage context, while the schema covers the optional parameter and tier requirement. It lacks an output schema, but the description names the fields explicitly, making it complete enough for an agent.

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% for the single optional 'days' parameter, and the schema itself provides detailed semantics (returns history series up to 5 years, requires Gold tier). The description adds no parameter-specific meaning beyond the schema, so the 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?

The description clearly states the tool returns a 0-100 Bitcoin whale-flow pressure score, with detailed interpretation (above 65 accumulation, below 40 distribution) and a list of output fields. This specific verb+resource+scope fully distinguishes it from sibling 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?

Explicit usage guidance is provided: 'Call when the user asks about BTC whales, large holders, smart money, on-chain flows, or whether whales are buying or selling, or when timing BTC allocation shifts, crypto rebalancing, or funding-rate position adjustments.' This gives clear triggers and context for selecting this 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?

Beyond the readOnlyHint annotation, the description adds the score's composition, update frequency, history length, and the IOM fields (top_drivers, source_lineage). This gives the agent important behavioral context about data provenance and output structure.

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

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

The description is two information-dense sentences plus a short update note. Every phrase contributes: the core function, the composite details, the usage contexts, and the update cadence. No 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 no output schema, the description adequately conveys the return value (score range, IOM fields) and parameter behavior via the schema. It leaves the acronym 'IOM' unexplained, which may be unclear to an agent, but overall the tool is well-specified.

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% for the single 'days' parameter, which is fully explained in the schema including the Gold tier requirement. The tool description does not add parameter-specific meaning, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Returns') and resource ('0-100 metals-complex stress score') with a precise definition (weekly composite z-score of gold volatility, momentum, and gold/silver ratio) and history span. This clearly distinguishes it as a precious-metals stress indicator among the many numeric sibling 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?

Provides explicit when-to-use guidance for gold/silver queries and hedge-sizing decisions with numerical thresholds. It does not name alternative tools or give when-not-to-use constraints, but the context is clear and actionable.

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

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

Beyond the read-only annotation, the description adds meaningful context: the index is a daily z-score composite of transaction count, transfer volume, and fees; 50 denotes normal; history extends to the 2009 genesis block; and updates are daily. This helps the agent interpret the score and understand its computational basis.

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 long and front-loaded with the core return value. It then gives use-case guidance and update frequency without any filler. Every sentence contributes directly to tool understanding.

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

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

For a tool with one optional parameter and no output schema, the description is thorough: it lists all returned fields, explains the index scale and composition, and provides concrete usage scenarios. The schema covers the parameter, and annotations confirm safety, making the definition complete for an agent to select and invoke 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 main description does not mention the optional 'days' parameter, but the schema provides 100% coverage, including its effect (history series vs. snapshot) and the Gold tier requirement. The description adds no extra parameter meaning, 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?

The description clearly states the tool returns a 0-100 Bitcoin network-activity index with specific output fields (score, trend, top_drivers, confidence, methodology_version). The verb 'returns' and the precise resource define its purpose unambiguously, distinguishing it from sibling 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 description provides explicit 'Call when' scenarios covering user questions about surging/quiet activity, fee pressure, congestion, and timing decisions. It lacks explicit when-not-to-use or named alternatives, but the guidance is concrete and actionable within the context of a large sibling set.

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 declare readOnlyHint=true, and the description adds valuable context beyond that: the output format (IOM with source_lineage and methodology_version), weekly update frequency, history since 2003, and the composite z-score basis. It does not discuss rate limits or error handling, but the read-only nature is already covered.

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 concise and front-loaded with the main output. The only redundancy is the final 'Updates: weekly' which repeats the weekly frequency already stated in the first sentence, causing 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 simple read-only tool with one optional parameter and no output schema, the description covers the score range, data source, calculation method, update cadence, return format, and audit trail fields. The schema handles the parameter details, making the overall definition 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 only parameter 'days' is fully described in the schema, including the Gold-tier requirement and fallback to snapshot. The description does not mention any parameter specifics, so with 100% schema coverage, 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 the tool returns a 0-100 US live air-traffic density score, explains the composite z-score methodology, specifies the output as an IOM with source_lineage and methodology_version, and lists concrete use cases. It distinguishes this tool from generic data tools by its focused aviation demand scope.

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 explicit trigger phrases ('air traffic volume', 'flight activity', 'airspace congestion', etc.) and a specific use case for airline-sector equity models. It lacks explicit exclusions or alternative tool names, but the context is clear enough for an agent to decide when to invoke.

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 indicate readOnlyHint=true and openWorldHint=false. The description adds substantial behavioral context: weekly update cadence, methodology (composite z-score of advisory levels and bulletin severity), and output components (score, trend, confidence, auditable source lineage). This goes beyond the 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, front-loading the main purpose, then use cases and update frequency. Every clause adds value; 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?

The description explains the return components (score, trend, confidence, lineage), the index scale (0-100), update frequency, and history to 1973. Given no output schema, this adequately covers what the agent needs to select and invoke the 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 schema fully documents the single optional 'days' parameter with range, meaning, and Gold tier restriction. The description does not add parameter-specific information, but baseline 3 applies given 100% 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 clearly states it returns a 0-100 travel-demand and safety-openness index based on State Department advisory levels, with score, trend, confidence, and auditable source lineage. The verb 'Returns' and specific resource make the purpose specific and distinguishable from the opaque sibling IDs.

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 lists when to call this tool (questions about global travel demand, tourism outlook, travel safety, advisory risk, and hospitality pricing/booking decisions). It lacks explicit when-not or alternative tool references, but provides strong contextual use cases.

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, so no extra safety disclosure is needed. The description adds valuable context beyond annotations: the index is an annual series since 1958, updates annually, and returns vintage dates and methodology_version. This tells the agent about data freshness and versioning, which is useful for invoking the tool correctly. No contradiction with 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 plus a short update note. It front-loads the core return value, then gives usage scenarios and update frequency. Every sentence earns its place with no redundant or vague 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 (no required parameters, one optional parameter with schema coverage). The description covers the return values (index, vintage dates, methodology_version) and usage context. It does not explicitly mention the `days` parameter's history behavior, but that is fully covered in the schema. With no output schema, the return components are still described, making this sufficiently complete for selection and 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 only parameter `days` is fully described in the schema (coverage 100%), including its optional nature, meaning (daily history series vs current snapshot), and the Gold tier requirement. The main description does not add any additional parameter semantics, but the schema already carries the full burden, 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 opens with a specific verb ('Returns') and clearly defines the resource: a 0-100 US Community Health Index based on CDC PLACES chronic-disease composite z-score. It lists the exact output elements (index values, vintage dates, methodology_version) and is distinct from sibling tools like health_risk or obesity_risk by focusing on a composite community health index.

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

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

The description explicitly states when to call the tool ('Call when the user asks about population health, chronic disease burden, community wellness, or how healthy the US is, or when timing payer market entry, actuarial risk loading, or underwriting decisions'). This provides clear context but does not mention when not to use it or name alternative tools, so it lacks explicit 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?

Despite readOnlyHint=true, the description adds valuable behavioral context: it explains that the 'source_lineage' fields exist to 'separate real signal from small-area estimation noise' and notes 'Updates: annually.' These details go beyond the annotations and inform the user about data quality and 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?

The description is two sentences, front-loaded with the core return value and composition. It then provides usage triggers and update frequency with no wasted words. Every 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?

With no output schema, the description names the return fields (value, confidence, source_lineage) and explains the score's derivation and purpose. It covers the main aspects needed to invoke the tool, but does not detail the exact types or structure of those fields, and the 'days' parameter is only documented in the schema.

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

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

The description does not mention the 'days' parameter, but the input schema already provides a thorough description (returning a daily history series, up to 5 years, Gold tier requirement). With 100% schema coverage, the baseline is 3, and the description adds no additional parameter meaning.

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

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

The description clearly states it 'Returns a 0-100 US behavioral-health stress score' with details on composition (CDC PLACES mental-distress and depression prevalence) and scope (US, history to 1951). It is specific about the resource and what it provides, making it distinguishable even though sibling tools are not explicitly compared.

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

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

The description explicitly states when to call: 'Call when the user asks about mental-health strain, depression rates, psychological distress, or EAP demand...' This provides clear context for use. However, it does not mention when not to use or name alternative tools, so it falls short of the 5-level.

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 mark the tool as read-only. The description adds useful behavioral context: data source, time range, weekly update cadence, return components, and the meaning of high/low scores. It does not mention pagination, rate limits, or history-tier requirements, but those are less critical for a read-only data query.

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 information-dense without fluff: each clause adds value—methodology, interpretation, return fields, use cases, update frequency. It is well-structured and easy to scan, with the most essential information 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 tool's low complexity (one optional parameter), the description is complete: it explains what is returned, what the index means, when to use it, and how often it updates. Since there is no output schema, the explicit listing of return components (score, trend, top_drivers, methodology_version) is sufficient.

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 covers the only parameter (days) fully, including its optional nature, purpose, range, and tier restriction. The description does not add parameter-level details, but because schema coverage is 100%, 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 opens with a specific verb and resource ('Returns a 0-100 weekly Drug-Safety Index'), clearly identifies the data source (openFDA adverse-event reports), and explains the scoring direction. It also enumerates the return components, making the tool's purpose unmistakable and distinct from generic safety or adverse-event 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 description explicitly states when to call the tool: 'Call when the user asks about drug adverse events, FAERS surges, medication side effects, drug safety trends, or pharmacovigilance, or when timing safety escalations, recall monitoring, or pharma risk reviews.' It lacks explicit when-not-to-use or named alternatives, but provides strong contextual guidance.

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