macroooracle

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

Annotations are absent, so the description carries full burden for behavioral disclosure. It mentions the data source and indicators but omits key behaviors: whether data is historical or just latest, seasonal adjustment, update frequency, or any call limitations. This lack of detail could lead to incorrect assumptions.

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 at 18 words, front-loading the source 'US employment data direct from Bureau of Labor Statistics.' It efficiently lists key indicators in a comma-separated format. However, it could benefit from slight structuring, such as separate lines or a clearer break between the source and the 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?

Given zero parameters and no output schema, the description partially covers the output by listing indicators. However, it lacks details on data frequency (monthly?, seasonally adjusted?), temporal scope (latest only or historical?), and units. For a complete understanding, an agent would need to infer or test.

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), baseline is 4. The description adds value by listing the specific indicators included, but it does not explicitly state that the tool accepts no parameters (i.e., returns a fixed set). This leaves room for confusion about filtering or customization.

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

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

The description clearly states the tool provides US employment data from BLS and lists specific indicators (unemployment rate, nonfarm payrolls, etc.). It distinguishes from siblings like bls_inflation and bls_series by specifying the data domain. However, it lacks an explicit verb like 'retrieve' or 'fetch,' which slightly reduces clarity.

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 guidance on when to use this tool versus alternatives (e.g., bls_series for custom series or economic_health_v1 for broader context). The description only lists what data it provides, leaving the agent to infer usage from the tool name and sibling list.

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

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

With no annotations, description must disclose behavior. It doesn't mention data frequency, lag, or whether a single value or series. The output is implicit but not detailed.

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?

Single sentence, 18 words, front-loaded with key info. No wasted words. Highly efficient.

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

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

No output schema, so description should explain return structure. It mentions two indices but not their format (number, object) or time scope. Incomplete for full agent understanding.

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

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

No parameters; schema coverage 100%. Description adds meaning by specifying return content (headline and core CPI). Baseline 4 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?

Description clearly states it provides US CPI inflation from BLS, specifying headline and core CPI. This distinguishes it from other inflation tools but could be more explicit about the data format.

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 guidance on when to use this over sibling inflation tools like 'inflation', 'inflation_v2', etc. Lacks any usage context or alternatives.

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

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

No annotations provided, so description must disclose behavioral traits. It only says 'Fetch' (read-only implication) but no details on authentication, rate limits, or error handling for invalid series.

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. First sentence states purpose, second provides examples. Front-loaded 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?

No output schema, so description should explain return format or data structure. It does not mention date ranges, historical depth, or response shape. Incomplete for a data-fetching tool.

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

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

Schema coverage is 100%, baseline 3. Description adds value by listing explicit series names (unemployment_rate, cpi_all, etc.), helping the agent know valid inputs beyond the schema's 'series name or BLS series ID'.

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 'Fetch any BLS data series' with a verb and resource. It lists specific series names, distinguishing from siblings like bls_employment which likely focus on a single series, but does not explicitly differentiate.

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 guidance on when to use this tool versus sibling tools (e.g., bls_employment, bls_inflation). The description implies use for listed series but no exclusions or alternatives are mentioned.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns specific metrics (reason_codes, signal_strength, risk_band) and notes it's 'rebuilt from retired macroracle — NO PESSIMISTIC/OPTIMISTIC labels,' adding useful behavioral context about data sources and output format. However, it doesn't cover aspects like rate limits, error handling, or data freshness, which are gaps for a tool with no 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, efficiently conveying key information in two sentences. Every sentence adds value: the first specifies the index and outputs, the second provides historical context. There's minimal waste, though it could be slightly more structured for clarity.

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 annotations, no output schema, and 0 parameters, the description is moderately complete. It explains what the tool returns and its background, but lacks details on output format (e.g., structure of reason_codes), error cases, or performance characteristics, leaving gaps for an AI agent to use it effectively without additional 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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds context about the tool's output and data source without redundant parameter info, earning a high score for compensating with relevant 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 clearly states the tool returns the Michigan Consumer Sentiment Index with specific outputs (reason_codes, signal_strength, risk_band), distinguishing it from siblings like bls_employment or inflation tools. However, it doesn't specify the exact verb (e.g., 'fetch' or 'retrieve'), leaving some ambiguity about the action.

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 mentioning it's 'as evidence only' and referencing a baseline and long-run average, which suggests context for interpretation. However, it lacks explicit guidance on when to use this tool versus alternatives like economic_health_v1 or recession_risk_v1, leaving the agent to infer based on the data type.

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?

No annotations provided, and the description lacks behavioral details such as data freshness, rate limits, or what 'full' encompasses. Minimal transparency.

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

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

Single sentence, front-loaded, no wasted words. Efficiently conveys the tool's purpose.

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

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

For a no-parameter tool with no output schema, the description is minimal but adequate for basic understanding. However, it lacks details about output format and scope.

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?

No parameters exist, so schema coverage is 100%. Description adds no parameter info, but baseline for 0 params 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 clearly states the tool provides a dashboard with rates, FX, inflation, economy, and yields. It distinguishes from sibling tools which are individual components.

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 guidance on when to use this aggregated tool versus individual ecb_* tools. Agent gets no context for selection.

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?

No annotations are provided, so the description must disclose behavioral traits. However, it only lists the indicators without mentioning data frequency, update schedule, or any limitations. The user is left uninformed about the nature of the returned data.

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 concise sentence with no wasted words. It could benefit from a clearer structure (e.g., listing items), but it is appropriately short for the simplicity of the tool.

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, no output schema, and no annotations, the description is the sole source of context. It lists three indicators but fails to explain their format (e.g., percentage, ratio) or any time-series details. This is incomplete for a tool returning quantitative data.

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?

No parameters exist (0 params), so the baseline is 4. The description adds meaning by specifying the economic indicators returned, which is not apparent from the empty schema.

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

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

The description clearly states it provides specific Euro Area economic indicators: GDP growth YoY, unemployment rate, and M3 money supply. It distinguishes itself from sibling tools like ecb_series or ecb_inflation by aggregating these three key metrics.

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

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

No guidance on when to use this tool vs alternatives. With many siblings like ecb_dashboard or ecb_series, there is no exclusion criteria or context provided.

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

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

With no annotations, the description must provide behavioral context. It states 'Daily from ECB' implying periodic updates, but does not disclose whether rates are historical or current, time range, or any potential side effects (though read operations are implied). Lacks details on data freshness or guarantees.

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

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

The description is a single, front-loaded sentence with no wasted words. Efficiently conveys the core purpose.

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

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

Given no output schema and no annotations, the description is too sparse. It does not specify the return format (e.g., latest rates or time series), date range, or how to handle multiple currencies. An agent would lack critical context to use the tool effectively.

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

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

There are zero parameters, so the baseline is 4. The description does not need to explain parameters, but it adds no extra meaning beyond the tool name and purpose.

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 explicitly states the tool provides EUR exchange rates against five specific currencies (USD, GBP, JPY, CHF, CNY) from the ECB with daily frequency. This clearly distinguishes it from sibling tools like ecb_rates (interest rates) or ecb_inflation.

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

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

No guidance is given on when to use this tool versus other ECB tools (e.g., ecb_series, ecb_dashboard) or alternatives. Does not mention any prerequisites or limitations.

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?

No annotations are provided, so the description carries full burden. It only lists data content without disclosing behavioral traits such as data frequency, time period, source, or whether results are cached. This is insufficient for a data retrieval 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?

One sentence with no filler. Front-loaded with the key purpose. Every word adds value.

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

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

Given zero parameters and no output schema, the description is minimal but does specify the data scope. However, it lacks details about time range, frequency, or source, which are important for an inflation data tool. Could be more 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?

There are zero parameters, so schema coverage is 100% vacuously. The description adds no parameter info because none exist, which is acceptable. 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 clearly states the tool returns Euro Area HICP inflation data, including headline, core (excl energy+food), and Germany. It specifies the exact resource and scope, differentiating it from other inflation tools like bls_inflation (US) or generic inflation_v2.

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 guidance on when to use this tool versus alternative inflation tools (e.g., bls_inflation for US, inflation_v2 for other measures). No exclusions or context provided.

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

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

With no annotations provided, the description carries the full burden, yet it only mentions that the tool returns 'eligible asset rates and yields' but does not disclose behavioral traits such as data freshness, pagination, or whether it is a read operation. The description is too minimal to fully inform the agent about side effects or output characteristics.

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 extremely concise—a single sentence of 12 words. It is front-loaded with the key domain and regulation references, with no wasted words.

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

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

For a parameterless tool with no output schema, the description is minimally adequate: it identifies the regulatory context and data type. However, it lacks details on what the rates/yields contain (e.g., which assets, currency, update frequency), which a agent might need to decide whether to invoke this tool over 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?

The tool has no parameters, and schema description coverage is 100% (empty). The description adds context by specifying that the no-parameter tool returns ECB data for MiCA compliance, eligible asset rates and yields. This provides meaning beyond the empty schema, aligning with baseline expectations.

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

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

The description clearly identifies the tool's domain as ECB data for MiCA stablecoin reserve compliance, referencing specific articles. It spells out the resource: eligible asset rates and yields. However, it uses a noun phrase rather than a verb, and among siblings like ecb_yields and ecb_rates, the differentiation is implied by regulation context rather than 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 implies usage for MiCA stablecoin reserve compliance, but it does not explicitly state when to use this tool versus sibling tools like ecb_yields or ecb_rates. No exclusions or alternatives are given.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, or whether data is current or historical. The agent lacks critical context for safe 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?

A single, front-loaded sentence efficiently lists the rates without redundancy. Every word 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 no parameters and no output schema, the description lists the rates but lacks explanations about output format, time range, or frequency. It is partially complete but could be enriched with result expectations.

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, the description adds value by enumerating the specific interest rates included, helping the agent understand the data content beyond the empty schema.

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

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

The description clearly specifies the resource as ECB interest rates and lists specific rates (Main Refinancing, Deposit Facility, etc.), distinguishing it from sibling tools like ecb_dashboard or ecb_fx.

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 guidance on when to use this tool versus alternatives (e.g., ecb_dashboard, ecb_economy). The description does not mention when not to use or provide context about use cases.

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

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

The description indicates a read operation ('Fetch') and mentions 20 series, but no annotations are provided. It lacks details on rate limits, authentication, error behavior, or the fact that the enum only covers 6 of the 20 series. This leaves gaps in understanding the tool's behavior.

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

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

The description is a single sentence, directly stating the action and available data. It is front-loaded with the verb and resource. However, it could be more informative by including usage context or a hint about the enum limitation.

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 fetch tool with one parameter, the description is mostly adequate but has clear gaps: it claims 20 series but only lists 6 in the schema, and it does not describe the output format or any filtering options. Without an output schema, more context would be helpful.

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

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

Schema description coverage is 100% as the series_id parameter includes a description listing enum values. The tool description adds that 20 series are available, but since the enum only shows 6, the added value is marginal. Baseline 3 is appropriate.

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

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

The description uses a specific verb 'Fetch' and identifies the resource as 'ECB data series'. It lists categories of series available. However, it does not explicitly distinguish this tool from sibling tools like ecb_rates or ecb_fx, which also fetch ECB data, and the enum in the schema lists only 6 series, not the claimed 20, creating slight 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?

No guidance is provided on when to use this tool versus alternatives such as ecb_rates, ecb_fx, or ecb_yields. There is no mention of prerequisites, use cases, or 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?

With no annotations and minimal description, the agent cannot infer critical behaviors such as data frequency, historical coverage, whether the output is a single value or time series, or any latency/rate limits. The description fails to compensate for missing 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, relevant sentence with no wasted words. It is appropriately brief for a parameterless tool, though it could include more context without becoming verbose.

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 lack of output schema and annotations, the description is too minimal. It does not explain what the tool returns (e.g., a numeric value, a time series), which is essential for an agent to use the output 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?

There are zero parameters, so the description need not add parameter-level detail. According to criteria, baseline is 4 when no parameters exist.

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

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

The description clearly identifies the resource as 'Euro Area 10Y AAA government bond yield benchmark', which distinguishes it from sibling tools like ecb_rates or yield_curve. However, it lacks an active verb (e.g., 'retrieves' or 'provides'), making it slightly less 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?

No guidance is provided on when to use this tool versus alternatives (e.g., yield_curve for multiple maturities, ecb_rates for policy rates). The description does not include any context about typical use cases or exclusions.

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

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

With no annotations, the description covers key behavioral aspects: it is a read-only evidence tool, returns specific fields (reason_codes, signal_strength, risk_band), requires payment via premium header, and mentions free units for new wallets. It could explicitly state it has no side effects, but the context 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 front-loaded with the premium notice and provides essential information in a compact format. Each sentence contributes meaning, though the call URL could be moved to usage instructions for tighter focus.

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 and no nested objects, the description adequately explains what the tool returns and its purpose. It mentions the composite nature and missing regime labels. It is sufficient for an agent to understand scope, though frequency or time range is omitted.

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 coverage is 100%, so the description cannot add parameter-level details. Baseline 4 is appropriate as no further meaning is needed.

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

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

The description clearly states the tool provides a composite US economic health index using GDP, unemployment, inflation, and consumer confidence. It differentiates from sibling tools by noting 'NO regime labels' and positioning itself as evidence-only, but does not explicitly compare to other composite tools like macro_coherence_v1.

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

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

The description implies usage for evidence gathering ('as evidence only') and mentions the premium paywall. It lacks explicit guidance on when not to use (e.g., if regime labels are needed) and does not suggest alternative tools, though sibling tools exist for specific components or regimes.

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?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It merely lists content areas without describing side effects, data freshness, authorization needs, or any other behavioral traits.

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 with 8 words, highly concise and front-loaded. Every word adds value in describing the tool's domain.

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

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

For a zero-parameter tool with no output schema, the description gives a reasonable overview of topics. However, it lacks specifics like whether the data is current or historical, and could be more precise (e.g., 'latest interest rates').

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

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

There are zero parameters, and schema coverage is effectively 100%. The baseline for 0 parameters is 4 per guidelines. The description adds no parameter info, which is acceptable since none exist.

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

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

The description specifies the tool covers Federal Reserve interest rates, FOMC meeting calendar, and policy outlook. This clearly states the resources involved, but does not differentiate from sibling tools like fed_rates_v2 or fed_rates_v3, which limits the 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?

No guidance on when to use this tool versus alternatives. The description only lists topics, without any context on prerequisites, exclusions, or preferred use cases.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool provides 'pre-reasoned data' with an 'interpretation layer,' which adds behavioral context beyond a simple data fetch. However, it lacks details on rate limits, error handling, or data freshness, leaving gaps for a tool with complex outputs.

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 key information in a single, dense sentence. Every phrase adds value, such as specifying the version ('v2'), target users ('autonomous agents'), and output details, with zero wasted words.

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

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

Given the tool's complexity (providing interpreted economic data) and lack of annotations or output schema, the description does well by detailing the output components. However, it could improve by mentioning data sources, update frequency, or confidence intervals to fully guide an agent.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by explaining the output includes an 'interpretation layer' with specific metrics, compensating for the lack of an output schema.

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

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

The description clearly states the tool provides 'Fed Funds Rate WITH interpretation layer' and lists specific outputs like 'signal (hawkish/dovish), regime, percentile_2y/10y, momentum, volatility, confidence, actionable_prompt.' It distinguishes from sibling 'fed_rates' by specifying it's 'v2' with 'pre-reasoned data' for 'autonomous agents.'

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 it's 'Built for autonomous agents that need pre-reasoned data,' providing clear context for when to use this tool. However, it does not specify when not to use it or name alternatives among siblings like 'fed_rates' or other economic tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds context about what the tool does (returns Fed Funds Rate evidence with specific output fields) and what it doesn't do (no recommendations, sizing, or venue picks), but it doesn't cover other behavioral aspects like rate limits, error handling, or data freshness. This is adequate but has gaps.

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 highly concise and front-loaded, with every sentence adding value: it specifies the data source, output fields, exclusions, and product positioning. There is zero waste, making it efficient and easy to parse.

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

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

Given the tool has no input parameters (complexity low) and no output schema, the description does a decent job by explaining the output fields and limitations. However, it could provide more context on data sources, update frequency, or error cases to be fully complete, especially with no annotations to supplement.

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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter information, and it doesn't contradict the schema. A baseline of 4 is appropriate as it compensates by focusing on output semantics instead.

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 Fed Funds Rate data with specific output fields (signal_strength, risk_band, etc.), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'fed_rates' or 'fed_rates_v2', which appear to be related rate tools, so it misses full sibling differentiation.

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

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

The description provides clear context on when to use this tool by stating it's for 'evidence only' and specifying exclusions (NO personalised recommendations, NO sizing, NO venue picks). However, it doesn't explicitly name alternatives or compare with sibling tools like 'fed_rates' or 'fed_rates_v2', so it lacks explicit alternative guidance.

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

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

No annotations are present, and the description does not disclose any behavioral traits such as whether the tool is read-only, requires authentication, or has rate limits. For a data retrieval tool, this lack of transparency is a gap.

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 concise sentence that front-loads the key purpose and includes essential detail (quarterly/yearly, real GDP, consumer spending, recession risk) with no wasted words.

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

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

For a simple data retrieval tool with no parameters and no output schema, the description sufficiently covers the types of data the agent can expect (GDP growth, real GDP, consumer spending, recession risk), making it contextually 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 tool has zero parameters, so the description cannot add parameter-level meaning. With schema coverage at 100%, baseline is 4, and the description adequately indicates the data scope without needing 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 clearly specifies the tool provides US GDP growth data, including quarterly and yearly, real GDP, consumer spending, and recession risk. It distinguishes from sibling tools focused on inflation, employment, and other economic indicators.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The name and description imply it is for GDP-related queries, but alternatives among many siblings are not mentioned.

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?

No annotations provided, and the description gives no behavioral details beyond the basic purpose. No indication of side effects or restrictions.

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 very short and to the point, but could be more informative without losing conciseness.

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

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

Despite simplicity, the description lacks output format, what exactly is checked, and any error handling details. Incomplete for a health check 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?

No parameters exist, so the description adds no param info. Baseline for zero parameters 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 clearly states this tool checks server status and API connectivity. It is distinct from sibling economic data 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?

No guidance on when to use this tool versus alternatives. With many siblings, usage context would be helpful but is absent.

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

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

With no annotations provided, the description must disclose behavioral traits like data freshness, source, or rate limits. It only lists indicators, omitting any such details, leaving the agent uninformed about operational behavior.

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

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

The description is a single concise sentence listing five key indicators, with no unnecessary words. It is front-loaded with the core topic 'US housing market', making it highly 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?

For a parameterless tool without an output schema, the description adequately names the data points. However, it lacks details on format, time period, or data source, which could be important for agent understanding. It is minimally complete but not richly specified.

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

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

The tool has zero parameters and the schema coverage is 100% (empty schema). The description adds value by enumerating the specific data fields (housing starts, permits, etc.), which compensates for the lack of parameters and clarifies what the tool returns.

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 explicitly lists specific housing market indicators (starts, permits, median prices, mortgage rates, home sales) and states 'US housing market', clearly distinguishing this tool from sibling tools like bls_employment or inflation. The verb 'get' or 'retrieve' is implied by the data listing.

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 such as other economic indicators. There is no mention of prerequisites, exclusions, or comparative advice to aid agent decision-making.

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

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

With no annotations, the description must disclose behavioral traits. It only lists data types and lacks information on read-only nature, data source, update frequency, or any limitations, which are important for a data retrieval 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 a single concise sentence that efficiently conveys the tool's content with no redundant words 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?

Given no parameters or output schema, the description is minimally adequate. However, it lacks context on default time periods, data source, or whether it returns the latest values or historical data, which would improve completeness.

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 no parameters, and schema coverage is 100%. The description adds no parameter semantics, but baseline for zero parameters is 4, as per guidelines.

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

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

The description clearly states the tool provides US inflation data including CPI, PCE, and core inflation, with YoY and MoM metrics. It distinguishes from ECB inflation tools but does not differentiate from sibling tools like 'inflation_v2' or 'bls_inflation'.

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

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

No usage guidelines are provided. The description does not clarify when to use this tool over alternatives such as 'inflation_v2', 'inflation_v3', or 'bls_inflation', all of which are present as sibling tools.

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

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions an 'interpretation layer' but doesn't explain how regime classifications are determined, what 'ranked actions array' contains, or any operational constraints like rate limits, data freshness, or authentication requirements. The description is too vague about actual behavior.

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

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

The description is reasonably concise but poorly structured. It front-loads version information ('[AGENT-NATIVE v2]') rather than the core purpose. The second sentence adds value but could be integrated more smoothly. While not verbose, the structure doesn't optimally guide understanding.

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

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

For a tool with no annotations, no output schema, and complex interpretation features, the description is inadequate. It doesn't explain what the output looks like, how the interpretation is generated, what time periods are covered, or provide any examples. The agent would struggle to understand what exactly this tool returns and how to use the results.

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 with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't waste space discussing parameters that don't exist, though it could mention that this is a parameterless tool that returns current/latest inflation data.

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

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

The description clearly states the tool provides CPI YoY data with an interpretation layer including regime classification, trend analysis, percentile, and ranked actions. It distinguishes from siblings like 'bls_inflation' and 'inflation' by specifying the 'v2' version with interpretation features. However, it doesn't explicitly mention what 'CPI YoY' stands for (Consumer Price Index Year-over-Year), which could be slightly 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?

The description mentions it's 'Built for autonomous agents' but provides no guidance on when to use this tool versus alternatives like 'bls_inflation', 'ecb_inflation', or 'inflation'. There's no indication of data source, currency, region, or specific use cases that would help an agent choose between these sibling tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by specifying what the tool returns (evidence components) and what it doesn't do (no recommendations/sizing/picks). However, it lacks information about rate limits, error conditions, data freshness, or any authentication requirements that might be relevant for an evidence 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 extremely concise and front-loaded with all essential information in a single, dense sentence. Every element serves a purpose: specifying the evidence type, output components, usage limitations, and product positioning. There is zero wasted verbiage or redundant information.

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

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

For a parameterless evidence tool with no annotations and no output schema, the description provides adequate coverage of what the tool does and doesn't do. However, it doesn't describe the format or structure of the returned evidence components (signal_strength, risk_band, etc.), which would be helpful given the lack of output schema. The description is complete enough for basic understanding but leaves some implementation details 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 has 0 parameters with 100% schema description coverage, so the baseline would be 3. However, the description adds value by explicitly stating this is a parameterless tool that returns CPI YoY evidence, which helps the agent understand this is a fixed-query evidence retrieval tool rather than a configurable one. This semantic clarification elevates the score above baseline.

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

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

The description clearly states the tool returns CPI YoY evidence with specific output components (signal_strength, risk_band, reason_codes, action categories). It distinguishes itself from siblings by specifying 'NO personalised recommendations, NO sizing, NO venue picks' and positioning as 'evidence_infrastructure'. However, it doesn't explicitly name the verb (e.g., 'retrieve' or 'calculate') and the resource is implied rather than explicitly 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?

The description provides clear context on when to use this tool: for CPI YoY evidence with specific output types. It explicitly excludes usage for personalized recommendations, sizing, and venue picks, which helps differentiate it from potential alternatives. However, it doesn't name specific sibling tools as alternatives or provide explicit 'when-not-to-use' scenarios beyond the listed 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?

With no annotations, the description must disclose behavioral traits. It only lists data points without explaining source, update frequency, or whether data is historical or real-time. This is insufficient for an agent to understand side effects or limitations.

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

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

The description is a single sentence, very concise and to the point. However, it lacks structure or brevity that could be improved with a minimal usage hint.

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 parameters and no output schema, the description leaves out important details like data frequency, time range, or source. It is incomplete for an agent to understand what the tool returns and how to interpret the results.

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 no parameters, so the description does not need to add parameter info. Listing the output indicators provides useful context for what the tool returns, which compensates for the missing output schema.

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

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

The description clearly states the tool provides US labor market data, listing specific indicators like unemployment rate, nonfarm payrolls, wages, jobless claims, and labor participation. It distinguishes itself from sibling tools by naming these exact metrics, but could be more explicit about the source or format.

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 guidance is provided on when to use this tool versus siblings like bls_employment or economic_health_v1. The description does not mention scenarios, prerequisites, or alternatives.

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

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

With no annotations, the description fully covers behavioral traits: it's a premium tool requiring payment via x402, details the call method with X-PAYMENT header, mentions free units for new wallets, and briefly describes outputs. Lacks info on error handling or rate limits.

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 extremely concise, front-loaded with key info (premium label, aggregator purpose), covers return data, exclusions, and call instructions in three lines with no redundancy.

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

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

Given the tool has zero parameters and no output schema, the description is largely complete: it explains the aggregator function, outputs, and payment process. Could add details on distribution format but otherwise sufficient.

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

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

There are no parameters (0 params, schema coverage 100%), so the description need not add param details. Baseline of 4 applies. The description adds value by explaining the return type.

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

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

The description clearly states it is an aggregator of three specific tools (fed_rates_v3, inflation_v3, yield_curve_v3) and lists the precise outputs: reason-code index, distributions, cross-tool concentration. It distinguishes itself from directional tools by explicitly stating what it does not provide.

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 indicates when to use (for macro-aware agents needing neutral aggregation) and what it does NOT do (no directional labels, alignment score, venue hints), helping with alternative selection. However, explicit alternatives among siblings are not named.

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

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

No annotations are provided, so the description carries full burden. It discloses the premium payment requirement and call method but does not mention whether the tool is read-only, rate limits, or output behavior. Given that it's a dashboard, it's likely read-only but not stated.

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, efficient sentence that conveys the tool's purpose and payment requirement without unnecessary detail. It is well-structured with clear call instructions.

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 should explain return values. It only says 'all key indicators at once' but lacks specifics on format or structure. However, for a dashboard tool, this may be sufficient for an agent to infer the output. It covers the payment flow well.

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 schema coverage is 100% trivially. The description does not need to add parameter info, and it correctly omits it. Baseline 4 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 provides a full US economic dashboard with all key indicators at once, listing specific categories like Fed, inflation, yields, etc. This distinguishes it from sibling tools that focus on individual indicators.

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

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

The description implies this tool is for a broad overview due to the phrase 'all key indicators at once', but does not explicitly state when to use it over the individual sibling tools or when not to use it. No alternatives are mentioned.

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

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

With no annotations provided, the description carries full burden. It discloses that the tool is premium (payment required), rebuilt from a retired source, and explicitly states what the output does NOT contain (stress_level categorical), which prevents false expectations. It lists the return fields. 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 a single dense paragraph with no wasted words. Emojis and formatting (🔒, →) front-load the critical premium information. Every sentence provides distinct, useful information: payment requirement, what it is, what it returns, what it lacks, how to call it.

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

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

For a zero-parameter tool with no output schema, the description adequately covers all necessary aspects: the tool's purpose, return values (reason_codes, signal_strength, risk_band), usage instructions (payment, header), and a behavioral note (no stress_level). The agent has enough to invoke it correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description adds value by explaining what the tool returns and its usage constraints, but since there are no parameters to describe, it doesn't need to add parameter-level detail. Schema coverage is 100% (empty).

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

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

The description clearly states it is a US financial stress composite using specific indices (VIX, HY spread, TED spread, STLFSI) and lists exact return fields (reason_codes, signal_strength, risk_band). It also differentiates from the retired macroracle by noting it lacks stress_level categorical. Among sibling tools like recession_risk_v1 or macro_coherence_v1, this is distinct.

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 indicates it's a premium tool requiring payment and specifies the call mechanism with X-PAYMENT header, which aids the agent in deciding if it can be used. However, it does not provide explicit when-to-use or when-not-to-use guidance compared to other tools, nor does it cite alternatives. The 'as evidence only' phrase gives some usage context.

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

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

With no annotations provided, the description fully discloses that the tool is evidence-only, rebuilt from a retired version, and requires payment. It mentions the absence of a probability label and classification. No contradictions with annotations exist, as none are present.

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 somewhat lengthy due to payment and version details, but it is well-structured with key information front-loaded. It uses bullet points effectively, though some redundancy could be trimmed.

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

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

Given zero parameters and no output schema, the description covers the essential outputs (reason_codes, signal_strength, risk_band) and call requirements. It provides sufficient context for an agent to select and invoke this tool.

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

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

The input schema has zero parameters, so the description does not need to add parameter details. The baseline is 4, and the description appropriately focuses on other aspects.

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

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

The description clearly states that the tool returns US recession indicators as evidence, listing specific outputs (reason_codes, signal_strength, risk_band) and distinguishing itself from a prior version. It also includes payment requirements, making the purpose unambiguous.

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

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

The description explains that the tool returns evidence only (not probability or classification) and provides calling instructions (X-PAYMENT header, free units for new wallets). However, it does not explicitly differentiate from sibling macro tools; the user must infer when to use this versus other recession-related tools.

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

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

No annotations are provided, so the description bears the burden. It mentions the data fields returned but says nothing about read-only nature, rate limits, or update frequency. Adequate for a simple retrieval tool but could add more behavioral context like 'returns latest available data'.

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?

Single sentence with no wasted words. Key information (source, contents) 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?

For a simple single-parameter tool with no output schema, the description provides the core purpose and indicators. Could be slightly improved by specifying temporal scope (e.g., 'latest available annual data') but otherwise complete.

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

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

Schema description coverage is 100% since the only parameter has a clear description of ISO-3 codes and examples. The description adds no additional meaning beyond the schema, so 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 provides a World Bank country economic profile including GDP, inflation, trade balance, and population. It distinguishes itself from sibling tools like wb_gdp (likely just GDP) by indicating a broader profile.

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 guidance on when to use this tool versus alternatives like wb_gdp or macro_dashboard. Usage is implied as retrieving a country's economic profile, but no when-not-to-use or alternative tool 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?

No annotations provided, so description must carry the burden. It does not disclose any behavioral traits like data freshness, ranking criteria (e.g., number of economies), or potential limitations. Only implies a read-only operation.

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?

Single sentence, front-loaded with key information, no extraneous words. Highly 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 no output schema and zero parameters, the description is too brief. It does not specify what 'top' means (count), GDP type (nominal/PPP), time period, or data source specifics. This leaves the agent guessing about the 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?

With zero parameters, the schema is complete. The description does not add semantic meaning about implicit behavior (e.g., 'top' is ambiguous). Baseline 3 is appropriate as there is no conflict or additional clarity needed 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 specifies the resource (World Bank top global economies by GDP) and includes growth rates, making the purpose clear. It implies a listing tool, distinct from siblings like gdp_growth which likely focuses on a single country.

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 guidance on when to use this tool versus siblings such as gdp_growth or macro_dashboard. The description only states what it does, leaving the decision to the agent without 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?

No annotations are provided, so the description carries full burden. It states it provides data but does not disclose if it is read-only, destructive, or what the output format includes. The behavioral traits beyond the name are unclear, limiting transparency.

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

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

The description is a single 15-word sentence that efficiently communicates the source and purpose. It is front-loaded and contains no unnecessary information, earning a high score.

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

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

Despite the tool's simplicity, the description lacks details on return format, specific indicators, or whether data is current/historical. With no output schema, more context is needed for the agent to understand the tool's output fully.

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 the parameter 'country_code' described as ISO-3. The tool description adds no extra meaning beyond the schema, listing only 'economic risk score and key indicators' without linking to the parameter. 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 provides World Bank RWA risk context with economic risk score and key indicators for country risk assessment. It specifies the resource and implied retrieval action. It distinguishes from sibling tools like wb_country and wb_gdp by focusing on risk context, though it lacks an explicit verb.

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 offers no guidance on when to use this tool versus alternatives such as wb_country or macro_dashboard. There are no explicit when-to-use or when-not-to-use instructions, leaving the agent without context for tool selection.

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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It does not mention frequency of updates, data source, response format, or how recession probability is computed. The description lists content but lacks behavioral context.

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

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

The description is a single sentence that efficiently lists the key data points. No wasted words, and it is front-loaded with the main subject.

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 should hint at the return structure. It mentions components but does not describe format or organization. For a simple data retrieval tool, this is adequate but not comprehensive.

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

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

The tool has no parameters, and the schema description coverage is 100% (naturally). The description does not need to add parameter information, so this is appropriate.

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

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

The description clearly states the tool provides US Treasury yield curve data, including specific maturities, spread, inversion signals, and recession probability. However, it does not differentiate itself from sibling tools like yield_curve_v2 or yield_curve_v3.

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 guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or comparisons with sibling tools such as yield_curve_v2 or other economic data tools.

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

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

No annotations are provided, so the description carries the full burden. It discloses behavioral traits like output interpretation (curve_state, recession_imminent detection, ranked actions), but lacks details on rate limits, error handling, data sources, update frequency, or computational requirements. For a tool with complex output implications, this is a significant gap in transparency.

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

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

The description is a single run-on sentence that packs multiple concepts (spread calculation, interpretation layer, curve states, days inverted, recession detection, actions). While information-dense, it lacks structural clarity and could benefit from bullet points or separation for better readability. It's concise but not optimally structured.

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 complexity (economic analysis with interpretation) and lack of annotations/output schema, the description provides a good overview of output features but misses contextual details like data recency, accuracy, or integration with sibling tools. It's adequate for basic understanding but incomplete for robust agent decision-making in a macroeconomic 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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on output semantics, explaining the interpretation layer without redundant parameter info. This meets the baseline for tools with 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 clearly states the tool calculates the Treasury 10Y-2Y spread with an interpretation layer, including curve state classification, days inverted tracking, recession detection, and action recommendations. It specifies the verb ('yield curve spread calculation') and resource ('Treasury 10Y-2Y'), though it doesn't explicitly differentiate from its sibling 'yield_curve' beyond the 'v2' versioning hint.

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 guidance is provided on when to use this tool versus alternatives like 'yield_curve' or other economic indicators (e.g., 'fed_rates', 'inflation'). The description implies usage for recession analysis but doesn't specify contexts, prerequisites, or exclusions, leaving the agent to infer based on the tool name and output features.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavioral traits: it returns structured evidence data (signal_strength, risk_band, etc.) and has clear limitations (no personalized elements). However, it doesn't mention potential constraints like rate limits, authentication needs, or data freshness, which are important for a financial data 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 extremely concise and well-structured: it starts with the core function, lists outputs, specifies exclusions, and ends with product positioning. Every sentence earns its place with no wasted words, 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?

Given the tool's complexity (financial evidence with structured outputs) and lack of both annotations and output schema, the description is moderately complete. It covers purpose, outputs, and limitations well, but doesn't explain the meaning of outputs like 'signal_strength' or 'risk_band', nor does it provide examples or error handling information that would be helpful for an agent.

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

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

The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description adds value by explaining what the tool provides (Treasury spread evidence) and its limitations, which helps the agent understand the tool's semantics despite no parameters. This exceeds the baseline of 3 for high schema coverage.

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

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

The description clearly states the tool's purpose: it provides Treasury 10Y-2Y spread as evidence with specific outputs (signal_strength, risk_band, reason_codes, action categories). It distinguishes itself from siblings by specifying 'evidence only' and excluding personalized recommendations, sizing, and venue picks. However, it doesn't explicitly name the sibling tools it differs from, which prevents a perfect 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?

The description provides clear context on when to use this tool: for evidence infrastructure with Treasury spread data, and explicitly states exclusions (no recommendations, sizing, or venue picks). It implies alternatives by mentioning what it doesn't do, but doesn't name specific sibling tools for comparison, which keeps it from a top score.

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