LastLook Data

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

Annotations already declare readOnly/idempotent/non-destructive, so the description wisely spends its words elsewhere: it discloses the x402 price and chains ($0.35 USDC on Base or Solana) and the external data dependency (Optimal Blue locked-rate index) that justifies openWorldHint. It does not say what happens when new_rate is omitted but credit_score/ltv are also absent — a real behavioral gap for a fallback path.

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

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

Two sentences, front-loaded with the decision question and with the output list compressed into one readable clause; the pricing caveat is correctly demoted to its own line. Slightly dense with the comma-separated output enumeration, but nothing is redundant.

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 carries its weight by naming all five return fields and the three verdict values, so the agent knows what it gets back. The remaining gap is the fallback path's dependency on credit_score/ltv and how the verdict thresholds are derived — acceptable omissions for a read-only calculator.

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 each parameter already carries units, ranges and defaults (including the 2%-of-balance closing cost default), so the schema does the heavy lifting. The description adds only two things beyond it: the meaning of omitting new_rate and the interpretation of years_in_home as expected holding period.

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?

Opens with a concrete decision question ("Should this borrower refinance?") and immediately names the required inputs and the full set of computed outputs (payment, savings, break-even, net benefit, verdict). An agent can tell this apart from grade_mortgage_offer or get_bundle_refi_signal because it is a per-borrower scenario calculation, not a market signal or offer score.

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 the framing inputs ("Give the current rate, balance and years remaining") and the one mode switch that matters: omit new_rate to fall back to market rate. No explicit exclusions or sibling alternatives are named, so the agent must infer that bundle_refi_signal is the market-level alternative rather than a per-borrower scenario.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so safety is covered. The description adds material context the annotations do not: a concrete price of $0.75 USDC per call via x402 on Base or Solana, which matters for agent cost decisions, plus the shape of the return payload. It omits freshness/staleness or update cadence of the indicators.

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 short sentences: what it returns, what the key field is for, and what else comes back, with pricing last. No filler and the most decision-relevant 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?

No output schema exists, yet the description enumerates the returned fields (brief, structured series, FX, derived, signals) and the intended use of the primary field. With zero parameters, there is nothing else an agent needs in order to call this 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 takes zero parameters and the description correctly makes no parameter claims, so there is nothing to mis-specify. Baseline 4 applies for a no-arg tool.

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

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

States a specific verb and resource: returns a pre-formatted natural-language paragraph summarizing 15+ named indicator domains (rates, inflation, employment, mortgage, energy, FX). It is clearly distinguishable from the narrower single-series siblings like get_series or get_fx_rate_current, though it never names an alternative explicitly.

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

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

Useful context is implied by 'ready to inject directly into an LLM prompt as economic context', which tells the agent the intended consumption pattern. However, it gives no explicit when-to-use vs. when-to-use-a-sibling guidance (e.g., bundle vs. individual series calls) and no 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?

Beyond the annotations (which already declare readOnly, idempotent, openWorld, non-destructive), the description adds critical behavioral context: the data source (CoinGecko) and the cost/payment mechanism ($0.50 USDC per call via x402 on Base or Solana). This is exactly the kind of operational detail an agent needs before invoking a paid 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 front-loaded with the core return data, then coverage examples, then usage guidance, then source and pricing. Every sentence earns its place, and the structure supports fast scanning.

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 parameters and no output schema, the description carries the full burden of explaining what is returned. It lists the fields and example assets, states the data source, and discloses the payment model, leaving no significant gap for an agent to call 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 tool has zero parameters, so the schema requires no parameter documentation. The description correctly does not invent parameter details; the baseline for 0-param tools is 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 states a specific verb and resource ('Returns the top 20 cryptocurrencies by market cap') and enumerates exactly what data is included (price, 24h change, 7d change, market cap, volume). It distinguishes itself from the sibling get_crypto_price by framing itself as a bundle for broad coverage.

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

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

It explicitly says 'Use this instead of individual get_crypto_price calls when you need broad market coverage,' naming the alternative and the condition that selects this tool. No further inference is required to choose between the two.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond annotations: the FRED source, the included WTI-Brent spread and market signal, and the $0.25 USDC x402 payment requirement on Base or Solana.

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 tight sentences with no wasted language. It front-loads the returned commodities and then adds source and payment details efficiently.

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 carries the burden of explaining return values, and it lists all four commodities plus the spread and market signal. It is nearly complete, though it does not define the "market signal" or specify freshness beyond "current."

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. The baseline for a no-parameter tool is 4, and the description does not need to compensate for missing schema 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 states a specific verb and resource: it returns current energy commodity prices, and it names the exact series included (WTI, Brent, gasoline, natural gas). This clearly distinguishes it from sibling bundles such as crypto, FX, and macro.

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

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

The phrase "in one call" implies the bundle is for efficient retrieval of current energy prices, but the description does not explicitly say when to use this versus individual series tools like get_series or get_current_value. Usage is implied rather than fully guided.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the bar is lower; the description adds genuinely non-obvious context: the upstream source (ECB via Frankfurter) and a per-call cost of $0.35 USDC via x402 on Base or Solana. That pricing detail materially affects whether an agent should call it repeatedly.

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

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

Front-loaded with the core value proposition, followed by derived metrics, source, and price. The nine-pair enumeration is long but removes ambiguity about coverage; only minor tightening (e.g. 'all 9 G10 pairs') would shorten it without loss.

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 and no parameters, the description carries the full burden of describing return contents, and it does so concretely: nine named rates, a USD strength index defined as average % change vs the G10 basket over 30 days, and a trend signal. Cost and data source are also disclosed, leaving no practical gap for invoking it.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly avoids inventing parameter semantics and instead spends its words on return contents.

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

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

States a specific verb and resource ('Returns all 9 G10 FX spot rates in one call') and enumerates exactly which pairs are covered, plus two derived metrics. This clearly separates it from single-rate siblings like get_fx_rate_current and series tools like get_fx_rate_series without needing to name them.

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

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

The phrase 'in one call' implies the efficiency rationale for choosing this bundle over individual FX calls, but the description never states when to prefer it versus get_fx_rate_current or get_fx_rate_series, nor any prerequisites. Usage must be inferred from scope.

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

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

Annotations already declare readOnly/idempotent/destructive=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond annotations: a per-call price of $0.50 USDC settled via x402 on Base or Solana, which an agent must know before invoking. It does not state freshness/cadence of the underlying data or what happens on payment failure, keeping it below 5.

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

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

Front-loaded with the return contents, followed by the usage hint and then the payment terms; no filler sentences. The indicator enumeration is long but each item is information the agent needs to judge fit, so it 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 input parameters and no output schema, the description carries the return-value burden and does so by naming every indicator and the cycle-phase signal. The main remaining gap is data recency/as-of semantics and failure/payment-error behavior.

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?

Zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly signals a no-argument call by describing the output rather than implying undocumented inputs.

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

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

States a specific verb+resource ('Returns a macro health snapshot') and enumerates the exact indicators included plus the derived cycle-phase signal, so an agent knows precisely what payload to expect. It does not, however, differentiate itself from siblings that expose overlapping data (get_recession_indicator, get_yield_curve, get_policy_spread, get_bundle_rate_environment), leaving the bundle-vs-single-series choice ambiguous.

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

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

'Use this for macroeconomic context or recession risk assessment' gives a usage context, but no exclusions and no named alternative, even though get_recession_indicator and get_yield_curve expose subsets of the same data. An agent must infer when the $0.50 bundle is preferable to a narrower, presumably cheaper, single-indicator call.

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 read-only, idempotent, non-destructive, open-world behavior, so safety is covered. The description adds genuinely new operational facts: a $0.40 USDC charge per call via x402 on Base or Solana, and that MBS spread and the trend signal are derived rather than raw fields. It omits data freshness/cadence and what happens on payment failure.

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 payload inventory and followed by the price. Each enumerated field earns its place because there is no output schema to carry them. The trailing 'Use this for mortgage market analysis' is largely redundant with the field list.

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 input parameters and no output schema, the description carries the return-value burden and does so by listing every field. Combined with the annotation-covered safety profile and the disclosed price, an agent has nearly everything needed; only freshness/units and the type of the trend signal are missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a parameterless call by describing a fixed snapshot rather than a configurable query.

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?

A specific verb ('Returns') plus an enumerated resource: 30yr/15yr rates, 10Y Treasury, Fed funds, MSPUS, HOUST, MBS spread, and a 30-day trend signal. The field-level inventory makes it distinguishable from generic siblings like get_series or get_yield_curve. It stops short of 5 because near-identical bundles (get_bundle_rate_environment, get_bundle_refi_signal) are never named as different.

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

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

'Use this for mortgage market analysis' gives a usage context but no when-not-to-use condition and no named alternative. With roughly a dozen sibling bundle and single-indicator tools, an agent must infer which of get_bundle_rate_environment, get_bundle_refi_signal, or get_bundle_macro to pick instead.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered; the description adds the genuinely non-obvious operational fact that each call costs $0.60 USDC via x402 on Base or Solana. That payment/auth detail is exactly the kind of context annotations cannot express, though rate limits, timeout or failure behavior are not mentioned.

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 return payload and the question it answers, with the price disclosure isolated at the end. The long enumeration of metrics is justified rather than padding, since no output schema exists to carry that information elsewhere.

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 and no parameters, the description carries the full burden of telling the agent what comes back, and it does so metric by metric, including the analytics assumptions (20% down, 28% DTI). The one gap is data recency — median sale price series like MSPUS are lagged, and calling this to answer 'today' without a freshness note could mislead.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly presents this as a parameterless pull, matching the empty input schema.

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

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

States a specific verb and a precisely enumerated resource: 'Returns a home purchase market bundle' followed by the exact six metrics it contains (30yr rate, MSPUS, monthly P&I, qualifying income, affordability signal, housing starts). The contents also differentiate it from siblings like get_bundle_mortgage_pulse and get_bundle_refi_signal, which are narrower rate-only 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?

Frames the decision it supports — 'can my client afford a home today?' — which tells the agent the buyer-affordability scenario that selects this bundle. There are no explicit exclusions or comparisons against the other bundle siblings (mortgage_pulse, refi_signal, rate_environment), so the agent must infer which bundle wins in overlapping 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 read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuinely non-obvious context: the call costs $0.35 USDC via x402 on Base or Solana, which materially affects an agent's decision to use a bundle rather than cheap single calls. It omits data freshness/latency, which keeps it from a 5.

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

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

Two sentences, both earning their place: the first front-loads contents and the routing rule, the second front-loads the cost constraint. The dense ticker list is functional precision rather than padding.

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

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

With no output schema, the description carries the burden of explaining the return value, and it does so by naming every field and computed spread. It stops short of describing the response envelope (units, timestamps, nesting), leaving a modest gap for a data-returning 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 takes zero parameters, so the baseline is 4; there is nothing for the schema to document and nothing the description needs to disambiguate. The enumeration of returned fields implicitly confirms no filtering arguments 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?

Names a specific verb+resource and then enumerates exactly which series (FEDFUNDS, SOFR, DGS2/5/10/30) and derived values (2s10s, 3m10y, EFFR vs IORB spread, curve shape signal) come back. This clearly distinguishes it from siblings like get_yield_curve, get_policy_spread, and get_series, which return only pieces of the same picture.

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

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

"Use this instead of multiple individual calls when you need the full rate picture" gives an explicit selection rule against the alternative pattern. It falls short of a 5 because the alternative is described generically ("multiple individual calls") rather than naming the concrete siblings it replaces, and no when-not condition (e.g. single-series needs) is stated.

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

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

The annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the description does not need to repeat safety hints. It adds useful context by disclosing the $0.60 USDC per-call cost via x402 on Base or Solana and by explaining the practical meaning of the breakeven threshold field. It still omits freshness, source latency, and rate-limit details.

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 front-loads the returned bundle contents and uses compact sentences with no wasted preamble. The pricing note is appended cleanly and every sentence contributes useful 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?

Because there is no output schema, the description appropriately enumerates the key return fields and defines the refi_breakeven_threshold. It is nearly complete for invocation, but it does not mention data freshness/source, output structure, or update cadence for an openWorld paid data bundle.

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 empty input schema has 100% description coverage, and no parameter semantics need to be explained in the 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 states a specific verb and resource: 'Returns a refinance signal bundle' and enumerates the contents, including 30yr/15yr rates, 52-week range, MBS spread, trends, and breakeven threshold. It is clear what the tool does, but it does not explicitly distinguish the bundle from siblings such as calc_refinance, get_bundle_mortgage_pulse, or get_bundle_rate_environment.

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

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

The description implies usage by saying the refi_breakeven_threshold field answers whether a borrower benefits from refinancing today. However, it gives no explicit when-to-use guidance, exclusions, or comparison against calc_refinance or the mortgage/rate bundle siblings.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds material context annotations cannot express: a paid call ($0.15 USDC via x402 on Base or Solana) and the upstream source (CoinGecko) — the payment requirement is the critical behavioral fact here.

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

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

Two tight sentences plus a one-line price notice, with the core capability front-loaded before the cost caveat. No filler and nothing redundant with the schema.

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 2-param, fully-enumerated, no-output-schema tool this is nearly complete: what it returns, when to use it, and the payment gate are all stated. It only omits the shape of the returned series (e.g., list of date/close pairs), which matters somewhat since there is no 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% and both params carry enums, so the schema already defines valid values. The description adds only 'any supported cryptocurrency' and the 30/90/365 windows, both of which restate the schema; baseline 3 applies.

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

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

States a specific verb and resource ('Returns historical daily closing prices'), plus scope (30/90/365 days) and data source (CoinGecko). It implicitly contrasts with the sibling get_crypto_price (current price) via 'historical', but never names an alternative explicitly.

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

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

Gives concrete use cases ('trend analysis, drawdown calculation, or training data'), which tells the agent when this tool is appropriate. It stops short of exclusions or naming which sibling to use instead (e.g., get_crypto_price for a spot quote).

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

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

Annotations already declare readOnly, idempotent and openWorld, so safety is covered. The description adds genuinely new behavioral context the annotations cannot convey: the call is paid ($0.02 USDC per call via x402 on Base or Solana) and the upstream source is CoinGecko. It stops short of disclosing rate limits, freshness/latency, or failure behavior for unsupported symbols.

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 return payload before source and payment details. Slightly wasteful because the 20-symbol list restates the schema enum verbatim, but the overall length is proportionate and no sentence is filler.

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

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

There is no output schema, but the description compensates by enumerating the returned fields (price, 24h change, market cap, volume) and disclosing the payment model, which is essential before invoking a paid endpoint. Remaining gaps are minor: unsupported-symbol behavior and data freshness are unstated.

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

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

Schema description coverage is 100% and the single 'coin' parameter is a fully enumerated string, so the schema carries the parameter semantics. The description's list of supported symbols duplicates the enum value-for-value rather than adding format or edge-case meaning, so baseline 3 applies.

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

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

States a specific verb ('Returns') plus the exact resource: current USD price, 24h % change, market cap and 24h volume for supported cryptocurrencies. It also names the data source (CoinGecko) and lists the supported symbol universe, so the agent knows precisely what data points come back and which coins qualify. The word 'current' implicitly separates it from the sibling get_crypto_history.

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

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

The description implies the usage context ('current' price) which implicitly contrasts with get_crypto_history, but it never states when to prefer this tool versus its siblings or when not to use it. There are no exclusions or prerequisites beyond the implicit supported-symbol constraint, which the schema already enforces.

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 open-world behavior. The description adds cost and payment details ($0.01 USDC via x402 on Base or Solana), which an agent needs before invoking. It does not describe the return shape, such as whether the observation date or units are included.

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

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

The text is short and front-loaded with purpose, and every sentence earns its place: purpose, cost comparison, when to use, alternative, and price.

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?

It is mostly complete for a simple one-parameter read tool with rich annotations. The lack of an output schema leaves the return format (value, date, units) undocumented. Routing among many overlapping siblings is only partly addressed.

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 the enum plus its description already explain series_id well. The description's examples (CPI, unemployment, mortgage rate) add a little mapping help but little 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?

It names a specific action and resource: the single most recent value for a supported FRED series. It separates itself from get_series by contrasting latest-only with historical observations.

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 says when to use the tool (latest reading, with examples) and when to use get_series instead (historical data). It gives no guidance against close siblings such as get_treasury_yield_current, get_value_by_date or the bundle tools, which overlap heavily with this one.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds materially useful context the annotations cannot carry: the paid x402 model at $0.02 per call and the accepted payment rails (Base or Solana). It does not state whether results include prior actuals or revisions.

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?

One sentence establishes the capability with examples, a second gives the usage cue, and a third carries pricing. Front-loaded and free of padding, though the price line reads as a bolted-on operational note rather than an integrated part of the definition.

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

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

For a one-parameter, read-only tool with an enum-constrained input and annotations covering safety, this is nearly sufficient: an agent knows what it gets, when to reach for it, and what it costs. The only gap is that the return shape (a list of release dates, presumably with source/date fields) is only loosely implied since no output schema exists.

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 the single `days` parameter is a constrained enum (30/60/90) with its own description, so the schema does the heavy lifting. The description adds nothing about the lookahead window, which is fine given the baseline but leaves no extra value.

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

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

States a specific verb and resource — 'Returns upcoming FRED economic data release dates' — and enumerates concrete examples (CPI, jobs report, GDP, Treasury rates). This implicitly separates it from the historical-data siblings like get_series or get_value_by_date, though no sibling is named.

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 clause 'Use this to find out when the next major economic data will be published' gives a clear forward-looking usage context, which is enough to distinguish it from historical lookups. It stops short of naming alternatives or stating when not to use it.

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 readOnly/idempotent/openWorld, and the description usefully adds data coverage (annual 10-K plus quarterly 10-Q, most recent periods), the upstream source, and — critically — the per-call price of $0.75 USDC via x402 with payment networks. It does not disclose how many periods are returned or what happens for an invalid/unknown ticker.

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

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

Front-loaded with purpose, metrics, and coverage before pricing. Slightly wasteful: two separate long lists of example tickers (AAPL/MSFT/TSLA/AMZN/NVDA/GOOGL/META/JPM/BAC, then AAPL/MSFT/NVDA) repeat information already in the schema.

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 the necessary work by naming the returned fields and the period types. Gaps remain on units/currency, number of periods returned, and ordering, but an agent can 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%, so the baseline is 3; the description earns extra by scoping the parameter to US-exchange-listed tickers and confirming the ASX-style free-text form. The example tickers largely duplicate the schema's own example, so the added value is modest.

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

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

States a specific verb+resource ('Returns financial fundamentals ... from SEC EDGAR XBRL filings') and enumerates the exact metrics and filing types returned. No sibling tool covers company-level fundamentals, so it is unambiguously distinguishable.

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 domain constraint ('any ticker listed on a US exchange') implicitly excludes foreign/private companies, but there is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives. The agent must infer that this is the only fundamentals source among mostly macro/market-data siblings.

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

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

Annotations already cover read-only, idempotent, non-destructive, and open-world behavior, so the lower bar applies; the description nonetheless adds real context the annotations don't: the European Central Bank as the upstream source and a $0.01 USDC per-call payment via x402 (Base or Solana). That cost/payment requirement is operationally important and not inferable from 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?

Three short sentences, front-loaded with purpose, then source, then format, then price. The date-format sentence duplicates the schema's own pattern, which is a minor redundancy, but nothing is padded.

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

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

For a two-parameter read-only lookup with no output schema, the description states what is returned (a single rate) and where it came from, which is sufficient. It omits edge cases such as non-publishing days or missing-date behavior, and return value shape is only implicit.

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

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

Schema coverage is 100% and the enum of nine G10 pairs plus the date pattern are fully documented in the schema. The description restates the YYYY-MM-DD format but adds no syntax or semantic detail beyond it, so the baseline 3 applies.

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

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

States a specific verb and resource ('Returns the exchange rate for a G10 currency pair on a specific date') and names the data source (ECB). The 'on a specific date' phrasing implicitly separates it from get_fx_rate_current and get_fx_rate_series, but no sibling is named explicitly.

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

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

The only guidance is 'Use YYYY-MM-DD format,' which is a formatting rule, not a usage rule. Nothing tells the agent when to pick this over get_fx_rate_current, get_fx_rate_series, or the get_bundle_fx_dashboard bundle.

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 safety (readOnly, idempotent, non-destructive), and the description adds genuinely new context: the ECB data source and, importantly, a $0.01 USDC per-call cost via x402 on Base or Solana. It stops short of stating data refresh cadence or staleness, which would matter for a 'current' rate.

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 tight sentences, front-loaded with purpose and then source and price. The enumerated pair list slightly duplicates the schema enum, a minor 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 tells the agent it receives an exchange rate, plus source and cost, which is enough to call correctly. Return format and update frequency are the only omissions.

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 pair argument is a fully enumerated type, so the schema already carries the burden. The description's list of supported pairs merely restates the enum rather than adding format or semantics.

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

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

The description names a specific verb and resource ('Returns the current exchange rate for a G10 currency pair') and the word 'current' implicitly separates it from historical siblings like get_fx_rate_by_date and get_fx_rate_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 scope is implied by 'current' exchange rate, but the description never states when to pick this over get_fx_rate_by_date or get_fx_rate_series, and gives no exclusions or preconditions.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, so safety is covered. The description adds genuinely non-inferable context: the data source (ECB) and, importantly, that each call costs $0.05 USDC via x402 on Base or Solana — a payment/auth requirement the agent must know before calling.

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 short sentences, front-loaded with the purpose, then source, then cost. No filler, nothing wasted.

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

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

For a read-only, two-enum-param tool, the essential calling information is present and the pricing/source context is useful. But with no output schema, the description says nothing about the return shape (array of date/rate points, row count implied by 'days'), and it omits any routing guidance against the other FX siblings.

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

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

Schema description coverage is 100% with enumerated values for both 'pair' and 'days', so the schema fully documents the inputs. The description adds only the 'daily' granularity hint, which is marginal; baseline 3 applies 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?

States a specific verb ('Returns'), resource ('historical daily exchange rates') and scope ('G10 currency pair'), which distinguishes it reasonably from get_fx_rate_current. However, it never explicitly contrasts with the close sibling get_fx_rate_by_date, leaving the series-vs-single-date boundary implicit.

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

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

No when-to-use guidance at all: nothing says to prefer this over get_fx_rate_by_date or get_fx_rate_current, nor when the 30/90/365 windows are appropriate. The agent must infer usage purely from the tool name.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: the data source (FRED) and the cost model ($0.02 USDC per call via x402 on Base or Solana), which an agent needs before invoking. It does not specify the response shape (scalar vs. object with interpretation text).

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

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

Two tight sentences plus a price line, front-loaded with what is returned and followed by the interpretive baseline, source, and cost. Every sentence carries distinct information 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?

With no output schema, the description carries the burden of describing the return, and it does so at a high level (spread plus policy-stance interpretation). Combined with source and per-call pricing, an agent has enough to decide and call, though the exact return structure is left unspecified.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly spends its words on output meaning and pricing instead of restating a nonexistent input 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 names a precise verb and resource — the spread between EFFR and IORB — and even defines both acronyms, so an agent can tell it apart from siblings like get_yield_curve, get_series, or get_recession_indicator without opening a schema. It stops short of explicitly contrasting itself with any sibling, which keeps it out of the top band.

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

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

The phrase 'with an interpretation of Fed policy stance' implies the use case (assessing policy posture) and the note that 'EFFR below IORB is the normal operating band' hints at how to read the result. But there is no explicit when-to-use, when-not-to-use, or named alternative such as get_series or get_yield_curve, so usage must be inferred.

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 readOnly/idempotent/non-destructive, so the bar is lower; the description adds genuinely useful context beyond them — the interpretation threshold, the underlying definition, the data source, and notably a per-call cost of $0.02 USDC via x402 on Base or Solana, which is a real behavioral constraint an agent must know before calling.

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 short sentences, front-loaded with the return value and threshold before the source and price. Dense and largely waste-free, though the pricing line is compressed into a sentence that could be more cleanly separated.

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 the necessary work of explaining what the returned value means and how to read it. It stops short of saying whether the response includes a date/series metadata or just a scalar, a minor gap for a 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 takes zero parameters, so there is nothing for the description to disambiguate; the 4 baseline applies. No parameter guidance is needed or expected.

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

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

States a specific verb+resource (returns the real-time Sahm Rule recession indicator) and immediately defines what the indicator measures and its FRED source, so it is clearly distinguishable from the surrounding macro/pricing siblings such as get_bundle_macro 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 threshold rule ('a value >= 0.50 signals a recession is likely underway') implies the use case, but the description never says when to pick this over siblings like get_bundle_macro or get_series, nor does it state any prerequisite or exclusion. Usage is inferable rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so safety needs no restatement. The description adds genuinely non-obvious context beyond that: per-call pricing tiers tied to the days window and payment rails (x402 on Base/Solana), plus a hint about the returned array's ordering.

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

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

Front-loaded with the core behavior, then a scannable example block, then the pricing note. The bullet list is long but every bullet is a distinct series mapping; the pricing sentence is necessary because cost varies by parameter.

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 must carry return-value burden; it only partially does ("most recent observation in the returned array is the current value"). It omits that values are percentage points for rate series but index levels for CPIAUCSL/GDP, and says nothing about how many observations the window yields or error behavior for stale series.

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 enums, so the baseline is 3; the description earns above baseline by translating opaque series IDs into real-world meaning (MORTGAGE30US = 30-yr mortgage rate, CPIAUCSL = inflation) and by restating that days=30 maps to the cheapest current-value tier.

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

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

States a specific verb and resource ("Returns recent observations for any supported FRED data series") and lists concrete domains (mortgage rates, Treasury yields, CPI, SOFR, GDP). It is distinguishable from bundle/aggregate siblings, but it never names overlapping siblings like get_current_value or get_value_by_date, so the boundary is left implicit.

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

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

Gives five concrete use cases with exact series_id and days values, which is unusually actionable when-to-use guidance. It offers no when-not-to-use guidance or explicit routing to the simpler sibling tools (get_current_value, get_value_by_date) that appear to overlap.

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, open-world and non-destructive, so the bar is low. The description still adds two traits not in the annotations: business-day-only data availability and a $0.01 USDC per-call x402 payment requirement, the latter being operationally critical before invoking.

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 short sentences, front-loaded with what is returned, then the constraint, then the cost. Nothing is wasted and the payment caveat is not buried.

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 should say more about the response: units (percentage points vs basis points), and especially what happens when a weekend/holiday date is supplied. Safety and cost are covered, but the failure mode for non-business days is left ambiguous.

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 the single `date` parameter is already documented with format and an example in the schema. The description restates the YYYY-MM-DD format and adds the business-day restriction on valid values, but adds no new semantics beyond that.

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

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

States a specific verb and resource with scope qualifiers ('30-year US Treasury yield', 'for a specific date'), which implicitly separates it from get_treasury_yield_current and get_yield_curve. It never names a sibling explicitly, so the differentiation is inferred rather than stated.

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

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

'Business days only' and 'Use YYYY-MM-DD format' are real usage constraints, but there is no guidance on when to pick this over get_treasury_yield_current or get_yield_curve. The agent must infer the historical-single-date use case from the name alone.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds the upstream source (FRED) and a cost note, but does not say what 'most recent' means in practice (latest business day, publication lag, caching/refresh cadence) or the units of the returned value.

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

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

The core is two tight, front-loaded sentences, but 'Free — no payment required.' appears twice verbatim, which is pure waste in a definition this short. Removing the duplicate would leave a well-structured definition.

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, single-value lookup with no output schema, the description covers the series, source, and cost. The only real gap is the return shape (bare number vs. object with date) and units, which an agent must otherwise infer.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the series identifier DGS30 usefully pins down what fixed input the tool substitutes for.

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

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

States a specific verb, resource, and scope: the most recent 30-year constant maturity yield (DGS30) sourced from FRED. The series ID makes it unambiguously distinguishable from siblings like get_yield_curve and get_treasury_yield_by_date.

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 routes the agent to get_current_value or get_series when a different series is wanted, which is the main ambiguity here. It does not, however, address when to prefer this over get_treasury_yield_by_date (historical dates) or get_yield_curve (term structure), so the routing is only partially complete.

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, open-world, and non-destructive. The description adds valuable operational context beyond annotations: business-days-only behavior and the $0.01 USDC payment requirement via x402.

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

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

Four short sentences front-load the purpose, then add only necessary constraints: business days, date format, and cost. There is no wasted language.

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 two-parameter read tool with full schema coverage and annotations, the description is mostly complete. The main remaining gap is that it does not explain the return format or behavior for non-business days or unavailable dates.

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 documents both parameters, including the date format and the full series_id enum. The description restates the date format but adds no additional parameter semantics 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 states a specific verb and resource: returns the value of a supported FRED series for a specific date. It is clear what the tool does, though it does not explicitly distinguish itself from siblings such as 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?

It provides implied usage guidance by saying the tool is for a specific date and that only business days are supported. However, it does not state when to use this instead of get_current_value, get_series, or other date-specific siblings.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the upstream source (FRED) and an explicit cost of $0.03 USDC per call via x402 on Base or Solana — pricing is the kind of detail annotations never carry. It does not state whether calls are cached or what happens on upstream failure, keeping it below 5.

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

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

Three short sentences: what it returns, why it matters, where it comes from, then the price line. Front-loaded with the payload and every sentence carries information an agent would otherwise have to guess.

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 must carry the return contract and it largely does by naming both spreads and the inversion signal. The one gap is units/format — whether spreads come back in basis points or percent — which an agent needs to render or threshold the values 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 takes zero parameters, so the baseline is 4 and there is nothing the description could add or omit on this dimension.

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

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

States a specific verb and resource ('Returns 2s10s and 3m10y Treasury yield curve spreads') plus the derived artifact ('inversion signal'). This is precise enough to separate it from siblings like get_treasury_yield_current (single-tenor yields) and get_recession_indicator without opening any schema.

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

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

No explicit when-to-use or when-not statement, and no sibling is named as an alternative for related needs. Usage is only implied by the interpretive note that inversion precedes recessions, which tells an agent why it might want the data but not when to pick this over get_treasury_yield_by_date.

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 readOnly/idempotent/non-destructive/openWorld, and the description adds genuinely new behavioral context: the data source is a live index of actually locked rates (so results move with market), the returned figures (spread in bps, monthly and total cost, plain-language verdict with next step), and the metered cost of $0.50 USDC per call via x402 on Base or Solana. It stops short of noting failure modes or index availability.

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

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

The core sentence front-loads the question, the method and the returned outputs, and the payment terms are isolated on their own line. Slightly dense (one long sentence packing method, outputs and verdict) but nothing is wasted.

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

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

For a 9-parameter read-only analytic with a fully described schema and no output schema, the description covers input meaning, return contents, benchmark source and per-call cost. An agent has everything needed to decide 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?

Schema coverage is 100%, so a baseline of 3 applies, but the description adds real meaning by explaining that product, term, credit score and LTV are matching keys against the index and that years_in_home defines the comparison horizon — information the per-field schema descriptions do not convey.

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

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

States a specific verb (grades) and a specific resource (a written mortgage offer with rate, points, lender fees) plus the A–D output and the benchmark it uses (live Optimal Blue locked-rate index). This clearly separates it from calc_refinance and the mortgage_pulse bundle reads.

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 framing question 'Is this mortgage offer good?' implies the use case (evaluating an offer a borrower already has in hand), but there is no explicit when-to-use versus calc_refinance or get_bundle_mortgage_pulse, and no stated prerequisites or exclusions.

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