LastLook Data

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description goes beyond this by disclosing the output format (a natural-language paragraph plus structured series, FX, derived, and signals fields), which informs the agent about the tool's rich return structure. No contradiction with annotations 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 compact—two sentences—with the primary function front-loaded in the first sentence. The second sentence adds the key use case (LLM injection). Every clause earns its place; there is no fluff or repetition of schema/annotation 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?

For a parameterless tool with a rich output schema, the description fully covers what the agent needs to know: what the tool returns (natural-language brief plus structured fields) and why it's useful. The indicator categories are sufficiently enumerated, and the output schema handles the detailed return fields. No important contextual gap remains.

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

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

The tool has zero parameters and the schema is empty (100% coverage), so the description does not need to explain parameter behavior. Per the baseline for 0-parameter tools, a 4 is appropriate since no additional parameter semantics are required.

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 resource ('a pre-formatted natural-language paragraph summarizing 15+ economic indicators'). It distinguishes itself from sibling bundles by naming the indicator categories (rates, inflation, employment, mortgage market, energy, FX) and explicitly framing it as an 'economic context brief' ready for LLM prompts.

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 a clear usage context: the returned brief is 'ready to inject directly into an LLM prompt as economic context.' This tells the agent exactly when this tool is valuable. However, it does not explicitly contrast it with sibling analysis bundles (e.g., get_bundle_macro) or state when NOT to use it, 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, idempotentHint, and non-destructive behavior. The description adds valuable context: the call is a single bundled request, sourced from CoinGecko, and costs $0.50 USDC via x402 on Base, which are important operational details not present in 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 efficient and front-loaded with the primary action. It includes an explicit usage pointer and source/pricing details in a compact form. However, it could be slightly more concise by merging the source and price sentences, but it remains readable.

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

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

Given the output schema exists and annotations cover safety, the description provides all necessary selection context: what data it returns, when to use it, the data source, and cost. The sibling tools are different domains, and the description names the specific alternative (get_crypto_price), making the choice clear.

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

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

The tool has zero parameters, so the schema already fully covers inputs (schema coverage 100%). The description adds meaning by describing what data will be returned (price, 24h/7d change, market cap, volume) and the coin list, which is useful given no parameters.

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

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

The description starts with 'Returns the top 20 cryptocurrencies by market cap in one call' which names a specific verb, resource, and scope. It also lists the exact data fields (price, 24h change, 7d change, market cap, volume) which distinguishes it from sibling tools like get_crypto_price and other bundles.

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 says 'Use this instead of individual get_crypto_price calls when you need broad market coverage.' This provides a clear when-to-use and names the alternative, making it easy for an agent to choose this tool over get_crypto_price.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable context beyond annotations: the data source (FRED) and the specific series (DCOILWTICO, DCOILBRENTEU, etc.), plus the inclusion of a spread and market signal. This enhances understanding of the tool's behavior without contradicting the annotations.

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

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

Two succinct sentences: the first states the action and lists the exact commodities, the second adds the spread, signal, and source. No fluff, important details front-loaded, 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?

For a zero-parameter read-only tool with an output schema present, the description fully covers what the tool does, what it returns (specific series, spread, signal), and the data source. It is complete without needing to explain output schema details, which are already structured.

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

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

The input schema has zero parameters, so the baseline is 4 per the rubric. The description naturally needs no parameter explanations; it correctly focuses on the return payload and source.

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?

Description states it 'Returns current energy commodity prices in one call' and explicitly lists the four included commodities, clearly distinguishing it from sibling bundles like get_bundle_crypto or get_bundle_fx_dashboard. The verb 'Returns' is specific to the resource and the scope is unambiguous.

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

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

The description clearly indicates when to use this tool: when you need current energy/commodity prices in a single call. It doesn't explicitly contrast with alternative bundle tools, but the sibling names (e.g., get_bundle_crypto) and the clear commodity focus imply the appropriate context. No exclusionary guidance is provided, which would warrant 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, idempotentHint, and non-destructive. The description adds useful context beyond annotations: the data source (ECB via Frankfurter), the composition of the response, and the 30-day lookback for the strength index. No contradictions 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 concise, information-dense sentences. The first sentence enumerates the exact delivered content, and the second gives the source. Every sentence earns its place with no 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?

With zero parameters, strong annotations, and an output schema present, the description sufficiently specifies the tool's purpose, contents, and source. It enables an agent to select and invoke the tool without ambiguity.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. Baseline 4 applies as the description correctly doesn't imply any inputs.

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

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

The description clearly states the tool returns all 9 G10 FX spot rates in one call, listing the exact currency pairs and also including a USD strength index and trend signal. This specific verb+resource scope distinguishes it from single-rate sibling tools like get_fx_rate_current.

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

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

The description provides clear context as a comprehensive G10 FX bundle, implying it should be used when an all-in-one dashboard is needed. It doesn't explicitly name alternatives, but the 'bundle' positioning and list of all major pairs communicates the use case adequately.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds that the tool bundles multiple indicators and includes a derived 'cycle phase signal,' which is useful behavioral insight beyond the annotations. It does not mention rate limits or data quirks, but those are less critical for a read-only snapshot.

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

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

Two sentences efficiently convey what the tool returns and when to use it. It front-loads the core purpose and avoids filler; every clause contributes meaningful information.

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

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

With a full output schema available, the description doesn't need to detail return shapes. It provides the essential context: what indicators are included and why to use it (macro context/recession risk). This is complete for a simple, read-only, no-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?

The tool has zero parameters, so no parameter documentation is needed; the schema already covers everything. The description's list of returned data adds context but not parameter semantics, so the baseline 4 for zero param 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') with a clear resource ('macro health snapshot') and enumerates the exact metrics included (GDP, unemployment, CPI, Fed funds rate, yield curve spread, Sahm Rule). This distinguishes it from sibling bundle tools by making its exact scope explicit.

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

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

The description states a clear intended use: 'Use this for macroeconomic context or recession risk assessment.' It does not explicitly mention when not to use it or name alternatives like get_bundle_rate_environment or get_recession_indicator, so it misses the full 'when/when-not/alternatives' bar, but the context is unambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds the bundled field list and the derived 30-day rate trend signal, which is useful output context, but it does not disclose operational details such as data freshness, units, or data source behavior beyond the series codes.

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 exactly two sentences: the first front-loads the action and lists all key data points compactly, and the second gives a single clear use case. No wasted or redundant 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 no-parameter, read-only bundle tool with a rich output schema and strong annotations, the description fully covers what the tool returns and when to use it. Including specific FRED series codes (MSPUS, HOUST) adds precision. With an output schema present, return-value details are not required.

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 is an empty object with 0 parameters, and schema description coverage is 100% vacuously. Per the rubric, 0 params yields a baseline score of 4. The description doesn't need to add parameter information, and it doesn't.

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

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

The description starts with 'Returns a complete mortgage market snapshot' and then enumerates the specific metrics included (30yr/15yr rates, 10Y Treasury, Fed funds, MSPUS, HOUST, MBS spread, trend signal). This clearly defines the tool's purpose and distinguishes it from sibling bundle tools like get_bundle_crypto or get_bundle_energy.

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 ends with 'Use this for mortgage market analysis,' providing a clear context for when to use it. It doesn't explicitly mention alternatives or when not to use it, but the mortgage-specific scope and the list of other bundle tools in the sibling context imply differentiation.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable context beyond annotations by specifying the exact contents, underlying assumptions (20% down, 28% DTI), and pricing via x402. It does not disclose potential data freshness limitations, but for a read-only bundle 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 exceptionally concise: two sentences that deliver the core information (contents and purpose) upfront, followed by practical pricing. Every word adds value, and there is 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 tool has no parameters, a known output schema, and strongly annotated read-only/idempotent behavior, the description fully covers the necessary context. It lists all data elements, states the use case, and notes the payment mechanism, leaving no significant gaps 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?

The tool has zero parameters, so the baseline is 4. The description correctly focuses on what the bundle contains rather than parameter explanations, which are unnecessary. There is no additional parameter semantics needed beyond the schema, which already has 100% 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 uses a specific verb 'Returns' and clearly identifies the resource as a 'home purchase market bundle' with a detailed list of components (30yr mortgage rate, median home price, P&I payment, income required, affordability signal, housing starts). It also states the direct use case ('can my client afford a home today?'), distinguishing it from other bundle tools focused on different markets.

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

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

The description provides clear contextual guidance with the statement 'Directly answers "can my client afford a home today?"' implying when to use this tool. However, it does not explicitly name sibling alternatives or state when not to use it, so it falls short of a 5 but is still well above average.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds behavioral context by revealing computed outputs (e.g., curves, signals) beyond raw data, indicating that the tool performs calculations and returns a synthesized snapshot. While it doesn't clarify rate limits or output format, the description supplements annotations with valuable behavioral nuance.

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 compactly lists the full inventory of returns, the second offers tactical guidance. Every word earns its place, and the key 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 presence of a rich output schema (acknowledged in signals) and comprehensive annotations, the description is fully adequate for an agent to select this tool. It explains the tool's scope, contents, and use case, making it a complete reference for decision-making.

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

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

With zero parameters and 100% schema coverage (trivially empty), the baseline is 4 per the rubric. The description adds no parameter semantics because there are none to explain; it appropriately focuses on the tool's broad return scope.

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 complete rate environment snapshot' and explicitly enumerates all included series and computed metrics (FEDFUNDS, SOFR, DGS2, DGS5, DGS10, DGS30, yield curve spreads, Fed policy spread, curve shape signal). This distinguishes it clearly from sibling tools like get_treasury_yield_current or get_policy_spread by establishing the full-picture 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 explicitly states when to use the tool: 'as the full rate picture' and recommends it instead of multiple individual calls. This provides clear contextual guidance, though it does not name specific sibling tools as alternatives or state exclusion criteria (e.g., when only a single series is needed).

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description doesn't repeat those. It adds the pricing detail ($0.60 USDC via x402 on Base) and clarifies the meaning of the breakeven field, which is beyond the annotations and useful for an agent considering invocation.

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 result, lists contents efficiently, explains one key field, and provides pricing. 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?

An output schema exists, so return values are already structured. The description adds field meaning and pricing, making it complete for a no-parameter tool with a good annotation set.

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

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

The tool accepts zero parameters, so the description carries no parameter burden. Baseline of 4 applies; the description doesn't need to explain inputs.

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

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

The description clearly states it returns a refinance signal bundle and enumerates its components (mortgage rates, 52-week range, MBS spread, trends, breakeven threshold). While it doesn't explicitly contrast with sibling bundles, the name and listing of specific refi data make the purpose unambiguous.

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

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

The description implies use for refinancing decisions, especially by explaining that the breakeven threshold directly answers what rate a borrower needs to benefit. It doesn't provide exclusions or alternatives, 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?

The description discloses the data source (CoinGecko), the exact time windows (30/90/365), and the cost ($0.15 USDC via x402), all of which go beyond the readOnlyHint, openWorldHint, and idempotentHint annotations. 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 concise, front-loaded sentences: the first states the core function, the second gives use cases, and the third provides source and pricing. 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 tool is simple (2 params, enums, output schema exists) and annotations cover safety. The description adds essential missing context: source, cost, and use cases. It fully equips 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?

Schema description coverage is 100% with enums and descriptions for both coin and days. The description mentions the days windows but does not add extra semantics beyond what the schema already provides. Baseline of 3 is appropriate when the schema does 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 the tool returns historical daily closing prices for supported cryptocurrencies over 30, 90, or 365 days. The verb 'Returns' plus the resource 'historical daily closing prices' makes the purpose unambiguous and distinguishes it from siblings like get_crypto_price.

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 'Use for trend analysis, drawdown calculation, or training data,' which provides clear when-to-use guidance. It does not name alternative tools or state when not to use it, but the use cases are sufficient for an agent to select it appropriately.

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 carry the read-only, idempotent, non-destructive hints. The description adds valuable context beyond that: the data source (CoinGecko) and the monetization/pricing model ($0.02 USDC via x402 on Base). This gives the agent useful operational knowledge not present in 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 compact and front-loaded with the core purpose. The supported coin list is necessary for the agent to know valid inputs, and the source and pricing info are each one short clause. Every sentence earns its place 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?

The combination of an output schema (not shown but present) and the annotations already covers return structure and safety. The description fills in the supported universe, data source, and cost model. It could hint at whether prices are live or delayed, but for a simple lookup tool this is adequately 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 schema already fully describes the parameter: the enum lists every supported coin, and the schema-level description gives examples. The main description repeats the supported list verbatim, adding no extra meaning. According to the baseline rule 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 opens with a specific verb ('Returns') and clearly names the resource ('current USD price') along with the exact data fields (price, 24h % change, market cap, 24h volume). The word 'current' distinguishes it from get_crypto_history, and the supported coin list further disambiguates the 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 establishes clear context (current price for a fixed set of supported cryptocurrencies) and implicitly signals this is for current data, not historical. It does not explicitly name alternatives or exclusions such as 'use get_crypto_history for historical data,' 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, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable behavioral context beyond annotations: it returns only the most recent value (not a time series) and is cheaper than get_series ($0.01 vs $0.05). This provides practical operational detail without contradicting annotations.

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

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

The description is concise and front-loaded. The first sentence states the core function, and the remaining sentences provide cost, usage context, and alternative tool guidance. Every sentence earns its place with no fluff 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?

Given the tool's simplicity (one parameter, output schema present) and strong annotations, the description fully covers the needed context: what it returns, when to use it, when not to, and the cost trade-off. The alternative tool is named, and the output schema obviates the need to describe return structure.

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

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

Schema description coverage is 100%: the series_id parameter has a description and an enum list of valid FRED series IDs. The description does not add further semantic details about the parameter, only mentions 'any supported FRED series,' which is already implied by the schema. Since the schema carries the burden, 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 function with a specific verb+resource: 'Returns only the single most recent value for any supported FRED series.' It explicitly distinguishes from siblings by mentioning 'single most recent value' and naming the alternative get_series for historical data.

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

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

The description provides explicit usage guidance: 'Use this when you need just the latest reading — e.g. current CPI, unemployment rate, mortgage rate' and 'Use get_series instead when you need historical observations.' It also includes the cost advantage, making the when-to-use decision even clearer.

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, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the FRED source and example indicators, but no deeper behavioral traits such as coverage limitations or response details. With annotations handling the core safety, this is adequate but not rich.

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

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

Two concise sentences, front-loaded with the main action, and no filler. Every word contributes meaning.

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 well-documented parameter, an output schema, and comprehensive annotations, the description fully covers what the tool does and when to use it. No critical 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 coverage is 100% for the single 'days' parameter, with an enum and description. The tool description does not add any meaning beyond the schema, 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 states a specific verb ('Returns') and resource ('upcoming FRED economic data release dates'), with concrete examples (CPI, jobs report, GDP, Treasury rates). It clearly distinguishes itself from sibling tools focused on current values or series data.

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

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

It provides an explicit use case: 'Use this to find out when the next major economic data will be published.' However, it 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond these annotations, including that it covers annual (10-K) and quarterly (10-Q) data, the source is SEC EDGAR, and it is priced at $0.75 USDC via x402 on Base. 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 slightly longer than minimal but every sentence earns its place: it provides the main purpose, the specific metrics, the data frequency, the scope with examples, the source, and the pricing. It is front-loaded with the primary function and maintains a logical flow.

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 is simple (single parameter) and an output schema exists (so return structure is defined), the description covers all essential aspects: purpose, scope, data types, frequency, source, and cost. It 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 already describes the ticker parameter with examples at 100% coverage, giving a baseline of 3. The description adds meaning by clarifying that the ticker must be listed on a US exchange and by expanding the example list, which helps the agent understand the accepted input scope beyond the schema's brief 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 the tool 'Returns financial fundamentals for any US public company from SEC EDGAR XBRL filings' and lists the specific metrics (revenue, net income, etc.), distinguishing it from sibling tools that focus on macro, crypto, or FX bundles. The verb 'Returns' is specific and the resource is well-defined.

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

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

The description provides clear context for when to use the tool: for any US public company ticker, with examples like AAPL, MSFT, TSLA. However, it does not explicitly mention when not to use it or recommend alternative tools among the siblings, 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds only the ECB source and date format requirement, which are useful but not rich behavioral disclosures. It does not contradict any 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 short, focused sentences. The first states the core function; the second gives the date format. 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?

The tool is simple, annotations cover safety, an output schema exists, and parameters are fully described. The description supplies purpose, source, and format, which is complete for this context.

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 detailed descriptions for both 'date' and 'pair', including a pattern and enum. The description reinforces the date format but adds no meaningful parameter semantics beyond what the schema already provides, so baseline 3 applies.

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

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

The description clearly states the tool 'Returns the exchange rate for a G10 currency pair on a specific date,' using a specific verb and resource. It distinguishes from sibling tools like get_fx_rate_current and get_fx_rate_series by emphasizing the specific date, and adds the data source (ECB).

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 specifies the date-specific use case and instructs 'Use YYYY-MM-DD format,' which is direct guidance. It does not name alternative tools like get_fx_rate_current or get_fx_rate_series, but the qualifier 'on a specific date' clearly implies the intended 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source (European Central Bank) and explicitly lists supported pairs, but does not disclose update frequency, any latency, or whether the rate is a mid-price or bid/ask. This adds some context but not substantial 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 a single sentence followed by a compact list of supported pairs. It is front-loaded with the primary action and resource, contains no filler, and every sentence earns its place. The structure is highly scannable and 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?

Given the tool has a single parameter, an output schema (true), and strong annotations, the description covers the essential what (current rate), source, and supported inputs. It does not mention how to retrieve historical or series data, but that is addressed via sibling tool names. For a simple read tool, the description is sufficiently complete for correct use.

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

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

The input schema has 100% coverage for the 'pair' parameter, including an enum and a description with examples. The description repeats the enum values and the phrase 'G10 currency pair', which is already in the schema. It adds no additional meaning about parameter semantics or formatting beyond what the schema provides, so baseline 3 applies.

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

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

The description clearly states the tool returns the current exchange rate for a G10 currency pair, with a specific verb ('Returns') and resource ('current exchange rate'). It distinguishes from sibling tools by emphasizing 'current', contrasting with get_fx_rate_by_date and get_fx_rate_series. The supported pairs are explicitly listed, leaving no ambiguity.

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

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

The description clearly implies this tool is for current rates, which contrasts with historical or series tools available as siblings. However, it does not explicitly name alternatives or state 'when not to use' this tool. The context signals include sibling names, so the agent can infer, but the description itself lacks direct exclusionary 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by revealing the data source ('Source: European Central Bank'), which is not present in annotations or schema. This provides context on data origin and reliability. It does not contradict annotations. However, it does not describe return structure or rate-limiting behavior, but given the output schema exists, that is acceptable.

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 exactly two sentences: one for core functionality and one for data source. Every sentence adds distinct value with zero filler or redundancy. It is highly efficient and front-loaded, making it easy for an agent to parse quickly.

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 tool with only two enum parameters, rich annotations (read-only, idempotent), and an output schema, the description is fairly complete. It states what is returned (historical daily rates), the scope (G10 pairs), and the source (ECB). However, it does not explicitly mention that it returns a time series, nor does it provide any usage context like typical applications. Given the low complexity, a score of 4 is appropriate; it is not fully maximized.

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 of both parameters, including enums (currency pairs and time windows) and per-parameter descriptions (e.g., days: '30 ($0.05)'). The tool description adds no additional parameter-level meaning beyond what the schema already contains. Baseline 3 is appropriate because the schema does the heavy lifting; the description adds no extra 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 resource ('historical daily exchange rates for a G10 currency pair'), which clearly states the tool's function. It is distinguishable from siblings like 'get_fx_rate_current' (current rates) and 'get_fx_rate_by_date' (single-date rates) due to 'historical daily' implying a time series, though it does not explicitly name alternatives. The title 'Get G10 FX Rate History' reinforces the purpose. A score of 4 reflects clear purpose without explicit sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or when to prefer other FX tools such as 'get_fx_rate_current' or 'get_fx_rate_by_date'. There is also no mention of use cases or limitations. This is a clear gap in usage 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 cover read-only, idempotent, and non-destructive behavior. The description adds value by noting the interpretation component, the normal operating band, and the FRED source, offering useful context about data provenance and analytical content 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 concise sentences that front-load the core function, then add interpretation context and source. Every sentence earns its place with no 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?

This is a simple zero-parameter tool with rich annotations and an output schema. The description covers purpose, interpretation behavior, and source, which is sufficient 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 tool has zero parameters and schema coverage is trivially 100%. With no parameters to document, the baseline score of 4 applies, and the description appropriately needs no parameter details.

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 the specific verb 'Returns' and identifies the exact resource: the spread between EFFR and IORB. It also mentions the interpretive output and source, clearly distinguishing it from sibling data-retrieval 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 clear context on what the tool measures and its policy-stance interpretation, which implies when it should be used. It does not explicitly name alternatives or exclusions, but no sibling tool directly overlaps with this specific spread calculation.

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 the tool as read-only and idempotent. The description adds valuable behavioral context: it defines the indicator as 'the rise in unemployment from its recent low,' specifies the 0.50 recession threshold, and cites the FRED SAHMREALTIME source. 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 short sentences, each delivering specific content: what the tool returns, how to interpret the value, and the data source. There is no filler or redundancy.

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

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

For a zero-parameter read-only tool with an output schema, the description is sufficient. It states the output, the interpretation threshold, and the source, with no missing prerequisites or edge cases.

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

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

The tool has zero parameters, and the schema confirms this with an empty properties object. The description does not need to explain input semantics, and it adds no param-specific information because none exists. Baseline 4 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 resource: 'Returns the real-time Sahm Rule recession indicator.' It also clearly states the interpretation threshold and source, which distinguishes it from sibling getters like get_series or get_current_value.

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

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

The description provides clear context for when to use this tool—to obtain the Sahm Rule indicator and check the recession threshold. It does not explicitly name alternatives or exclusions, but the tool's narrow scope makes its intended use obvious.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds a valuable behavioral detail: 'The most recent observation in the returned array is the current value,' which clarifies output ordering and how to extract the latest data point. No contradictions 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 and front-loaded, with a clear first sentence followed by a bulleted list of five specific, actionable examples. The final note about the most recent observation is a critical piece of usage information. No fluff or redundant content; every line 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 tool's moderate complexity, rich annotations, complete parameter schema, and presence of an output schema, the description covers the core purpose, provides common use cases, and clarifies output interpretation. It could be slightly more explicit about how it relates to sibling tools, but overall it is sufficiently 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% with both parameters fully described, including enums and guidance like 'Use 30 for current/recent values.' The description's examples reinforce common series_id/day combinations but do not add substantial semantics beyond what the schema already provides, 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 recent observations for any supported FRED data series, listing a wide range of economic indicators. This distinguishes it from sibling tools like get_current_value or get_value_by_date that focus on single values or specific dates, though it does not explicitly name these 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 clear context for when to use the tool ('Use this to get current and historical values') and includes five concrete common use cases with exact series_id and days parameters. It does not explicitly mention when not to use it or name alternative tools, but the examples give strong practical 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, idempotentHint, and destructiveHint false, so the description need not repeat safety. It adds the business-days-only constraint, which is useful. Does not explain behavior for non-business days, but that is a minor gap given annotations cover 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?

Two sentences, no wasted words. States purpose, constraint, and format efficiently. Front-loaded with the core action and object.

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?

Simple tool with one param, full schema coverage, and output schema present. Description covers the essential constraint (business days) and format. Output schema handles return value details, so no additional need.

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

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

Schema coverage is 100% and description reiterates the date format already present in the schema pattern. No additional semantic meaning 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?

Description uses specific verb 'Returns' with explicit resource '30-year US Treasury yield' and scope 'for a specific date'. Clearly distinguishes from siblings like get_treasury_yield_current (current) and get_yield_curve (curve).

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?

States 'Business days only' and date format, giving clear usage constraints. Does not explicitly name alternatives or when not to use, but the tool name and context make the specific-date use case obvious. Lacks explicit exclusions but provides adequate 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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the FRED source and 'no payment required' context, but does not disclose response format, pagination, or rate limits. It does not contradict annotations, but adds minimal behavioral depth beyond them.

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

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

Two sentences, with the first front-loading the core function and the second providing usage guidance. No wasted words, ideal length for the tool's simplicity.

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

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

With zero parameters, an output schema, and strong annotations, the description fully covers the necessary context: what is returned, from where, and how it differs from related tools. Nothing essential is missing.

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

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

The tool has zero parameters and the schema has 100% coverage (vacuously). Baseline for 0 params is 4. The description correctly does not attempt to explain parameters since there are none.

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'), resource ('most recent 30-year US Treasury constant maturity yield'), and data source ('FRED'), even specifying the series code (DGS30). It distinguishes from siblings by explicitly directing users with different needs to get_current_value or get_series.

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 'For other series use get_current_value or get_series', providing direct guidance on when to use this tool versus alternatives. It also notes 'Free — no payment required', a practical contextual guideline.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the meaningful behavioral constraint that the tool works only for business days, which is not present in the annotations. It does not explain what happens for non-business days (e.g., whether it returns null or errors), but this extra context goes beyond structured metadata.

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 concise sentences with no redundant words. The main output is front-loaded, followed by key constraints. Every word earns its place, and the structure is ideal 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 the tool's simple interface, a rich output schema, and strong annotations, the description is nearly complete. It covers what the tool does, the date format, and the business-day limitation. The only missing piece is explicit guidance on fallback behavior for non-business days, but that is a minor gap given the output schema likely covers error handling or null values.

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

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

The schema already documents both parameters thoroughly (series_id enum with descriptions, date pattern with example), so the baseline is 3. The description adds semantic value by emphasizing 'Business days only' and reiterating the YYYY-MM-DD format, which reinforces date handling expectations. This extra contextual guidance warrants a 4.

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 identifies the resource ('the value of any supported FRED series for a specific date'). This distinguishes it from sibling tools like get_current_value (which lacks date specification) and get_treasury_yield_by_date (which is narrower in 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 clearly conveys when to use this tool: when you need a historical value for a supported FRED series on a specific date. It adds the constraint 'Business days only' and a date format reminder, but it does not explicitly mention alternatives or exclusions, such as pointing to get_current_value for live data. This is clear context without explicit alternative references.

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, idempotentHint, and destructiveHint=false, so safety is covered. The description adds useful context about the specific spreads and inversion signal meaning, plus the source (FRED), but does not disclose additional behavioral details such as data latency or error handling.

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

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

Two concise sentences, front-loaded with the main function. The first sentence states exactly what is returned; the second adds interpretive context. Every word 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 no-parameter tool with an output schema and comprehensive annotations, the description provides complete context: what spreads are returned, the inversion signal's meaning, and data source. Nothing essential 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 input schema is empty (0 parameters), and baseline for 0 params is 4. The description does not need to explain nonexistent parameters, and the schema already provides full 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 uses a specific verb and resource: 'Returns 2s10s (2-year vs 10-year) and 3m10y (3-month vs 10-year) Treasury yield curve spreads with inversion signal.' This clearly states what the tool does and distinguishes it from sibling tools that return yields or bundles.

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

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

The description clearly implies usage when yield curve spreads and inversion signals are needed, noting their historical recession link. However, it does not explicitly name alternatives or state 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.