macroooracle

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 implies a read-only operation by listing data metrics, but does not specify aspects like data freshness, rate limits, authentication needs, or error handling. This leaves gaps in understanding how the tool behaves beyond its basic purpose.

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 lists key data points without unnecessary words. It is front-loaded with the tool's purpose, though it could be slightly more structured by explicitly stating the action (e.g., 'Retrieve US employment data...').

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

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate for a basic data retrieval tool. However, it lacks details on data format, update frequency, or error cases, which could be helpful for an agent to use it effectively in varied contexts.

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 by listing the types of employment data available, which helps the agent understand what to expect without redundant 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 states the tool's purpose: retrieving US employment data from the Bureau of Labor Statistics, listing specific metrics like unemployment rate and nonfarm payrolls. It distinguishes itself from siblings by focusing on employment data, but could be more specific about the verb (e.g., 'retrieve' or 'fetch') to fully differentiate from tools like 'labor_market'.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention siblings like 'labor_market' or 'bls_series', nor does it specify contexts or exclusions for usage, leaving the agent without clear direction 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?

With no annotations provided, the description carries full burden for behavioral disclosure. It states the data source (BLS) and types (CPI-U, core CPI), but doesn't mention critical behaviors like whether this is a read-only operation, rate limits, authentication needs, data freshness, or error handling. For a data retrieval tool with zero annotation coverage, 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 extremely concise (one sentence) and front-loaded with all essential information: data source (BLS), data type (inflation), and specific metrics (CPI-U index, core CPI). Every word earns its place with zero redundancy or unnecessary elaboration.

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

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

Given the tool's simplicity (0 parameters, no output schema), the description is minimally complete. It tells what data is retrieved but lacks context about data format, update frequency, or comparison to sibling tools. Without annotations or output schema, the agent must guess about behavioral aspects and return values, making this adequate but with clear gaps.

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

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

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the parameter structure (none). The description appropriately doesn't discuss parameters, focusing instead on what data is retrieved. This meets the baseline expectation for a parameterless tool, earning a 4 rather than 5 since it doesn't add any parameter context beyond what's already obvious.

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 what the tool does: retrieves US CPI inflation data from BLS, specifying headline CPI-U index and core CPI. It distinguishes from siblings like 'inflation' and 'ecb_inflation' by specifying the data source (BLS) and scope (US). However, it doesn't explicitly contrast with 'bls_series' which might also provide inflation data, making it slightly less specific than a perfect 5.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose it over 'inflation' (general tool), 'ecb_inflation' (European data), or 'bls_series' (other BLS data). There's no context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the purpose alone.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what data can be fetched but lacks critical behavioral details: it doesn't mention whether this is a read-only operation, what format the data returns, whether there are rate limits, authentication requirements, or temporal constraints (e.g., historical data availability). The description is functional but incomplete for safe agent usage.

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: the first sentence states the core purpose, and the second efficiently lists available series. Every word earns its place with no redundancy or fluff, 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 moderate complexity (fetching economic data), lack of annotations, and no output schema, the description is minimally adequate. It covers what data can be fetched and provides parameter examples, but fails to address behavioral aspects like response format, error conditions, or data recency. For a data-fetching tool with no structured safety hints, this leaves gaps in operational understanding.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds significant value by listing concrete examples of series names ('unemployment_rate', 'cpi_all', etc.) that clarify what the 'series' parameter accepts beyond the generic schema description. This provides practical guidance that compensates for the schema's generality.

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 action ('Fetch') and resource ('BLS data series'), making the purpose immediately understandable. It distinguishes itself from siblings by specifying BLS data rather than ECB, Fed, or World Bank data. However, it doesn't explicitly differentiate from 'bls_employment' or 'bls_inflation' which appear to be more specific BLS tools.

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

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

The description provides implicit usage guidance by listing available series (e.g., 'unemployment_rate', 'cpi_all'), suggesting this tool is for those specific BLS metrics. However, it doesn't explicitly state when to use this versus the 'bls_employment' or 'bls_inflation' sibling tools, nor does it mention any prerequisites or exclusions for usage.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns data 'in one call', hinting at a consolidated response, but lacks details on data freshness, rate limits, authentication needs, error handling, or output format. For a tool with potentially complex data aggregation, 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 extremely concise and front-loaded, using a single sentence that efficiently conveys the core functionality. Every word earns its place: 'Full ECB dashboard' sets scope, 'rates + FX + inflation + economy + yields' specifies content, and 'in one call' implies efficiency. There is no wasted verbiage or redundancy.

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

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

Given the tool's complexity (aggregating multiple data types) and lack of annotations and output schema, the description is incomplete. It doesn't explain the return structure, data sources, update frequency, or potential limitations. For a dashboard tool with rich sibling alternatives, more context is needed to guide effective use.

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

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

The tool has zero parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for any parameter gaps, and it appropriately avoids unnecessary parameter details. A baseline of 4 is given since no parameter information is required, and the description doesn't mislead about inputs.

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

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

The description clearly states the tool's purpose: retrieving a comprehensive ECB dashboard with specific data categories (rates, FX, inflation, economy, yields). It uses the verb 'Full' to indicate completeness and lists the included data types, making the function explicit. However, it doesn't explicitly differentiate from sibling tools like 'macro_dashboard' or 'ecb_rates', which might offer overlapping or subset functionality.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions 'in one call', implying efficiency, but doesn't specify scenarios where this is preferable over individual tools like 'ecb_rates' or 'ecb_inflation'. There are no exclusions, prerequisites, or comparisons to sibling tools, leaving usage context unclear.

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 of behavioral disclosure. It only lists the data points returned, without mentioning how the data is sourced (e.g., ECB API), update frequency, potential rate limits, authentication needs, or error handling. For a tool with zero annotation coverage, 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 extremely concise and front-loaded, consisting of a single sentence that directly states the tool's purpose and the specific economic indicators provided. Every word earns its place, with no redundant or vague language. It efficiently communicates the core functionality without unnecessary elaboration.

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 complexity (economic data retrieval) and lack of annotations and output schema, the description is incomplete. It lists data points but doesn't explain the return format (e.g., structured JSON, time series), data recency, units, or potential limitations. For a tool with no structured fields to rely on, more context is needed to be fully 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?

The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids discussing any. Baseline 4 is correct for a tool with no parameters, as there's nothing to compensate for.

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

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

The description clearly states what the tool does: provides Euro Area economic indicators (GDP growth YoY, unemployment rate, M3 money supply). It specifies the resource (Euro Area economy) and the data points returned, though it doesn't explicitly state the verb (e.g., 'retrieve' or 'fetch'). It distinguishes from siblings like ecb_inflation or ecb_rates by focusing on broader economic metrics rather than specific 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like ecb_dashboard or macro_dashboard that might offer similar or overlapping data, nor does it specify use cases or exclusions. The user must infer usage from the data points listed.

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 of behavioral disclosure. It states the data source (ECB) and update frequency (daily), but lacks critical details such as whether this is a read-only operation, potential rate limits, authentication requirements, error handling, or the format of returned data. For a tool with zero annotation coverage, 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 extremely concise and front-loaded, consisting of a single, information-dense sentence: 'EUR exchange rates vs USD, GBP, JPY, CHF, CNY. Daily from ECB.' Every word earns its place by specifying currencies, data source, and frequency without any redundancy or fluff.

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

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

Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimally adequate. It covers the core purpose and data characteristics but lacks completeness in behavioral aspects (e.g., no info on output format, errors, or operational constraints). For a data-fetching tool with no structured support, it should provide more context on what to expect from the tool's execution.

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, and the schema description coverage is 100% (since there are no parameters to describe). The description does not need to compensate for any parameter gaps, and it appropriately does not discuss parameters. Baseline score of 4 is applied as per rules for 0 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 what the tool does: provides EUR exchange rates against specific currencies (USD, GBP, JPY, CHF, CNY) from the ECB on a daily basis. It uses specific verbs ('exchange rates') and resources (ECB data), but does not explicitly differentiate from sibling tools like 'ecb_rates' or 'ecb_series', which might offer similar or overlapping data.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions the data source (ECB) and frequency (daily), but does not indicate when to choose it over sibling tools like 'ecb_rates' or 'ecb_series', nor does it specify any prerequisites, exclusions, or contextual triggers for usage.

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 mentions the data types (headline, core, Germany) but doesn't cover critical aspects like data freshness, source reliability, rate limits, error handling, or output format. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding its 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 extremely concise and front-loaded, using a single phrase that efficiently conveys the core purpose without any wasted words. Every term ('Euro Area HICP inflation', 'headline', 'core', 'Germany') earns its place by adding specific information about the data retrieved.

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 (data retrieval with no output schema) and lack of annotations, the description is incomplete. It specifies the data types but omits essential context such as output format, temporal coverage, update frequency, or how to interpret the results. Without annotations or output schema, more detail is needed for effective use.

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

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

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description adds value by specifying the data scope (Euro Area HICP inflation, headline vs. core, Germany focus), which provides semantic context beyond the empty schema. This compensates appropriately for the lack of 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 what the tool does: retrieve Euro Area HICP inflation data, specifying headline and core measures, with a focus on Germany. It uses specific terms ('Euro Area HICP inflation') and distinguishes the resource (inflation data), though it doesn't explicitly differentiate from sibling tools like 'inflation' or 'ecb_series' in usage context.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'inflation' (general) or 'ecb_series' (broader ECB data), nor does it specify prerequisites or exclusions. Usage is implied by the data focus but not explicitly stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the data domain (ECB, MiCA compliance, asset rates/yields) but doesn't describe operational traits such as whether this is a read-only query, potential rate limits, authentication needs, or what the output format might be. For a tool with zero annotation coverage, 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 extremely concise—a single sentence that efficiently conveys the tool's purpose and scope without any redundant or unnecessary information. It is front-loaded with the key information (ECB data for MiCA compliance) and uses every word effectively.

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 complexity implied by the MiCA compliance context and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., data format, time series, specific metrics) or any behavioral aspects. For a tool with no structured support, more detail is needed to adequately 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 tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description adds context about the data's purpose (MiCA compliance) and content (eligible asset rates and yields), which provides semantic value beyond the empty schema. This justifies a score above 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: providing ECB data for MiCA stablecoin reserve compliance, specifically mentioning eligible asset rates and yields. It identifies the resource (ECB data) and the use case (MiCA compliance), though it doesn't specify a precise verb like 'retrieve' or 'fetch' and doesn't explicitly differentiate from siblings like 'ecb_rates' or 'ecb_yields'.

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 compliance scenarios (Art. 24/25/53), but provides no explicit guidance on when to use this tool versus alternatives like 'ecb_rates' or 'ecb_yields'. It lacks any mention of prerequisites, exclusions, or comparative context with sibling tools, leaving the agent to infer usage based on the MiCA reference alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it indicates this is a data retrieval tool (implied by listing rate types), it doesn't specify whether this is real-time or historical data, update frequency, data source, or any limitations. For a financial data tool with zero annotation coverage, this is insufficient 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 extremely concise - a single sentence that efficiently lists all the rate types provided. Every word earns its place with no wasted text, and the information is front-loaded with the tool's purpose immediately clear.

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 data retrieval tool with no output schema, the description provides the essential information about what data is returned. However, it lacks important context about data freshness, format, or limitations that would be helpful for an AI agent. The absence of annotations means the description should do more to compensate.

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 is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on what data the tool provides, which adds value 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 states what data the tool provides ('ECB interest rates') and lists specific rate types (Main Refinancing, Deposit Facility, etc.), giving a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling ECB tools like 'ecb_yields' or 'ecb_series' that might also provide interest rate data.

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

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

The description provides no guidance on when to use this tool versus alternatives. With multiple ECB-related sibling tools available (ecb_dashboard, ecb_economy, ecb_inflation, ecb_yields, etc.), there's no indication of when this specific interest rate tool is appropriate versus other ECB data sources.

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 of behavioral disclosure. It mentions '20 series available', which adds some context about data scope, but fails to describe critical behaviors such as whether this is a read-only operation, potential rate limits, authentication needs, error handling, or the format of returned data. For a data-fetching tool with zero annotation coverage, this is a significant 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, efficient sentence that front-loads the core action ('Fetch any specific ECB data series by ID') and follows with useful context ('20 series available...'). It avoids unnecessary words, but could be slightly more structured by separating the list into bullet points or clarifying the relationship between series IDs and categories.

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 annotations and no output schema, the description is incomplete for a data-fetching tool. It covers the purpose and hints at data scope, but misses key contextual elements like return format, error cases, or behavioral traits. With 1 parameter and high schema coverage, it's minimally adequate but lacks depth for effective agent use.

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

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

The input schema has 100% description coverage, with the parameter 'series_id' documented in the schema as including examples like 'REFI_RATE'. The description adds value by listing categories (rates, FX, etc.) that help interpret these IDs, but doesn't provide additional syntax or format details beyond what the schema offers. With high schema coverage, a baseline score of 3 is appropriate.

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

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

The description clearly states the verb ('Fetch') and resource ('ECB data series by ID'), making the purpose understandable. It distinguishes from some siblings like 'ecb_dashboard' or 'ecb_economy' by focusing on series IDs, but doesn't explicitly differentiate from 'ecb_series' (if that's a sibling) or other ECB tools that might also fetch series data, keeping it from 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 implies usage by listing available series types (rates, FX, inflation, economy, yields), which suggests when to use it for those data categories. However, it lacks explicit guidance on when to choose this tool over siblings like 'ecb_rates' or 'ecb_inflation', and doesn't mention when not to use it or prerequisites, leaving room for ambiguity.

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 only states what data is provided, without mentioning how it behaves—e.g., whether it fetches real-time or historical data, requires authentication, has rate limits, or handles errors. This is a significant gap for a tool with zero annotation coverage.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core information, making it easy for an agent to parse quickly. Every word earns its place by specifying the metric and its attributes.

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

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what data is provided but lacks details on behavior, output format, or usage context. For a data-fetching tool, this leaves gaps in understanding how to interpret or rely on 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 0 parameters, and the input schema has 100% description coverage (though empty). The description does not need to add parameter semantics, as there are none to explain. A baseline score of 4 is appropriate for a parameterless tool, as it avoids confusion about inputs.

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

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

The description clearly states what the tool does: it provides a specific financial metric ('Euro Area 10Y AAA government bond yield benchmark'). It identifies the resource (government bond yield) and scope (Euro Area, 10-year, AAA-rated), but does not explicitly distinguish it from sibling tools like 'ecb_rates' or 'yield_curve', which might offer related data. This makes it clear but not fully differentiated from alternatives.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools such as 'ecb_rates' or 'yield_curve', nor does it specify contexts or exclusions for its use. This lack of comparative information leaves the agent without clear usage direction.

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 describes the output format (reason_codes + signal_strength + risk_band) and clarifies it doesn't provide regime labels. However, it doesn't mention important behavioral aspects like whether this is a real-time or historical calculation, data sources, update frequency, or potential limitations. The description adds some value but leaves significant 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 efficiently structured in two sentences that each earn their place: the first states the purpose and output format, the second provides important context about what it doesn't include and its origin. It's appropriately sized for a no-parameter tool, though it could be slightly more front-loaded by leading with the core functionality.

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

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

Given the tool has no parameters, no annotations, and no output schema, the description provides adequate basic information about what the tool returns. However, for a tool that presumably performs economic analysis, it lacks details about calculation methodology, data recency, confidence intervals, or error handling. The description is complete enough to understand the tool's purpose but leaves important contextual gaps.

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

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

The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on what the tool provides. No additional parameter information is needed or provided.

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

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

The description clearly states the tool returns a US economic health composite based on GDP, unemployment, inflation, and consumer confidence, with specific output fields (reason_codes, signal_strength, risk_band). It distinguishes itself from siblings by specifying it's a composite metric rather than individual indicators like bls_employment or inflation. However, it doesn't explicitly name a verb like 'retrieve' or 'calculate', keeping it at 4 instead of 5.

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

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

The description provides clear context for when to use this tool: when needing a composite economic health assessment rather than individual indicators. It explicitly states 'NO regime labels' to clarify what it doesn't provide, and mentions it's 'rebuilt from retired macroracle' for historical context. However, it doesn't explicitly name alternative tools or provide when-not-to-use exclusions, preventing a score of 5.

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

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

With no annotations, the description carries full burden but only lists topics without disclosing behavioral traits like data freshness, rate limits, authentication needs, or output format. It doesn't mention if it's read-only, real-time, or historical, which is a significant gap for a tool with zero annotation coverage.

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

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

The description is a single, efficient phrase listing key topics without waste. However, it could be more front-loaded with a clearer action verb to improve structure, but it's appropriately sized for its content.

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

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

Given the complexity of financial data and lack of annotations or output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., raw data, summaries, or forecasts), making it inadequate for an agent to understand the tool's full context and usage.

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 coverage, so no parameter documentation is needed. The description doesn't add param info, but this is acceptable given the lack of inputs, aligning with the baseline for zero 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 states the tool provides Federal Reserve interest rates, FOMC meeting calendar, and policy outlook, which gives a general purpose but lacks a specific verb (e.g., 'fetch' or 'retrieve') and doesn't clearly distinguish it from sibling tools like 'ecb_rates' or 'yield_curve'. It's vague about whether it returns data, forecasts, or historical information.

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' for European rates or 'yield_curve' for broader yield data. The description implies a context of U.S. monetary policy but doesn't specify exclusions or prerequisites, leaving the agent to infer usage.

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 provided, so the description carries full burden for behavioral disclosure. It lists data types but doesn't describe how the tool behaves: whether it returns current/latest data, historical time series, source/accuracy of data, update frequency, or any limitations. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding its 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?

The description is extremely concise and front-loaded: a single sentence fragment that efficiently lists all key data elements without any wasted words. Every component (quarterly/yearly, real GDP, consumer spending, recession risk) directly contributes to understanding the tool's output.

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

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

Given the tool's complexity (simple data retrieval with no parameters) and lack of annotations/output schema, the description provides basic completeness by listing data types. However, it doesn't address behavioral aspects like data recency, format, or limitations that would be important for proper use. The absence of output schema means the description should ideally provide more detail about return values.

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

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

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description appropriately doesn't discuss parameters, focusing instead on what data is returned. This meets the baseline expectation for parameterless tools.

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 what the tool provides: US GDP growth data including quarterly/yearly metrics, real GDP, consumer spending, and recession risk. It specifies the resource (US GDP) and the types of data returned, though it doesn't explicitly distinguish from siblings like 'wb_gdp' or 'macro_dashboard' which might offer overlapping economic data.

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

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

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'wb_gdp' (likely global GDP data), 'macro_dashboard' (broader economic indicators), and 'inflation' (related economic metric), there's no indication of when this specific US GDP tool is preferred or what its scope limitations are.

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 for behavioral disclosure. 'Server status, API connectivity' suggests a read-only diagnostic operation, but it doesn't specify what exactly is checked, what the response format might be, whether authentication is required, or any rate limits. The description provides minimal behavioral context beyond the basic purpose.

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 at just three words: 'Server status, API connectivity.' Every word earns its place by conveying essential information about what the tool checks. There's no redundancy or unnecessary elaboration, making it efficiently front-loaded with 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?

For a simple diagnostic tool with no parameters and no output schema, the description provides adequate but minimal context. It states what the tool does but doesn't explain what constitutes 'status' or 'connectivity,' what format the response takes, or what values indicate healthy versus problematic states. Given the tool's simplicity, the description is complete enough but could be more informative.

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 100% schema description coverage. The description doesn't need to explain any parameters, and the empty input schema is self-explanatory. A baseline of 4 is appropriate for a parameterless tool where the schema fully documents the input requirements.

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 'Server status, API connectivity' clearly states the tool's purpose: checking server and API operational status. It uses specific terms like 'status' and 'connectivity' that indicate a diagnostic/health monitoring function. However, it doesn't explicitly distinguish this from sibling tools, which all appear to be data retrieval tools for economic indicators rather than system monitoring tools.

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

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

The description implies usage context through the terms 'Server status, API connectivity' - suggesting this should be used to verify system/API availability before attempting data operations. However, it doesn't explicitly state when to use this tool versus alternatives or provide any exclusion criteria. The implied usage is reasonable but not explicitly articulated.

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

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

The description provides no behavioral information beyond the data types. With no annotations, it fails to disclose whether this is a read-only operation, if it requires authentication, rate limits, or how data is sourced/updated. It does not add context beyond the basic data listing, leaving the agent with no operational guidance.

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 lists all key data points without redundancy. It is front-loaded with the main purpose and provides specific examples, making it easy to scan and understand quickly. 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 the complexity of economic data retrieval and lack of annotations or output schema, the description is incomplete. It lists data types but does not explain format, frequency, source, or how to interpret results. For a tool with no structured behavioral hints, more context is needed to guide effective use.

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

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

The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the data returned. This meets the baseline of 4 for zero-parameter tools.

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 what the tool provides: US housing market data including housing starts, permits, median prices, 30Y mortgage rates, and home sales. It specifies the resource (housing market data) and scope (US), though it lacks a specific verb like 'retrieve' or 'get'. It distinguishes itself from siblings by focusing on housing data rather than employment, inflation, or 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?

The description provides no guidance on when to use this tool versus alternatives. It lists the data types but does not mention context, prerequisites, or comparisons to sibling tools like 'macro_dashboard' or 'ecb_economy' that might overlap. There is no explicit when/when-not usage advice.

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 of behavioral disclosure. It mentions what data is provided but doesn't describe how the tool behaves: Is it a read-only query? Does it fetch real-time or historical data? Are there rate limits or authentication requirements? What format does it return? For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding its 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?

The description is a single, efficient sentence that lists the key data points without unnecessary words. It's appropriately sized for a simple data tool. However, it could be slightly more front-loaded by specifying the action (e.g., 'Retrieve US inflation data...') to improve clarity immediately.

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 apparent simplicity (0 parameters, no output schema), the description is incomplete. It lacks behavioral context (how it operates, return format) and doesn't differentiate from siblings, which is crucial in this server with multiple inflation-related tools. Without annotations or output schema, the description should do more to explain what the tool actually does beyond listing data types.

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, and schema description coverage is 100% (empty schema is fully described). The description doesn't need to explain parameters, and it appropriately doesn't mention any. Baseline for 0 parameters is 4, as there's nothing to compensate for and no misleading information.

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

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

The description states the tool provides 'US inflation data' and lists specific metrics (CPI, PCE, core inflation) with timeframes (year-over-year, month-over-month), which gives a general purpose. However, it's somewhat vague about what action the tool performs (retrieve? calculate? display?) and doesn't clearly distinguish from sibling tools like 'bls_inflation' or 'ecb_inflation' that might provide similar data for different regions/sources.

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. With multiple inflation-related siblings (bls_inflation, ecb_inflation), there's no indication of what makes this tool unique or when it should be preferred over others. No context, exclusions, or prerequisites 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 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?

No annotations are provided, so the description carries full burden for behavioral disclosure. The description only lists data types returned but doesn't disclose any behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, data freshness, or what format the data comes in. For a data retrieval tool with zero annotation coverage, this is a significant 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 extremely concise - a single sentence fragment that efficiently lists all the data points provided. Every word earns its place by specifying the exact labor market indicators available. There's no wasted text or unnecessary elaboration.

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

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

Given that this is a data retrieval tool with no annotations and no output schema, the description is incomplete. It lists what data types are available but doesn't explain the return format, whether data is historical or current, how values are structured, or any limitations. For a tool that presumably returns complex economic data, more context about the output 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?

The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to explain parameters since there are none, and it appropriately focuses on what data the tool provides rather than 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 states what the tool does: provides US labor market data including unemployment rate, nonfarm payrolls, wages, jobless claims, and labor participation. It specifies the resource (US labor market) and the data types returned, though it doesn't explicitly mention a verb like 'retrieve' or 'get'. It distinguishes from siblings like bls_employment or inflation by focusing specifically on US labor market indicators.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to siblings like bls_employment (which might provide more detailed Bureau of Labor Statistics data) or macro_dashboard (which might offer broader economic indicators). There's no context about 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 provided, the description carries the full burden of behavioral disclosure. It does well by specifying what the tool returns ('reason-code index, distributions of signal_strength/risk_band/staleness_tier, cross-tool concentration') and what it doesn't include ('No directional labels, no alignment score, no venue hints'). However, it doesn't mention potential limitations like rate limits, data freshness, or error conditions.

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 efficient and front-loaded. Every sentence earns its place: the first establishes the aggregation purpose, the second specifies outputs and exclusions, and the third provides usage guidance. There's zero wasted text, and the information is structured logically from purpose to implementation details.

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

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

Given the tool has no parameters, no annotations, and no output schema, the description does an excellent job explaining what the tool does, what it returns, and when to use it. However, without an output schema, the description could benefit from more detail about the return format structure. The mention of specific return elements is helpful but not exhaustive.

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 4. The description adds value by explaining the aggregation behavior and what data sources are combined, which provides important context beyond the empty parameter schema. However, it doesn't mention any optional parameters or configuration options that might 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 states the tool's purpose: 'Neutral aggregation of fed_rates_v3 + inflation_v3 + yield_curve_v3 in one call.' It specifies the exact resources being aggregated and distinguishes itself from its sibling tools by explaining it replaces three separate calls (fed_rates_v3, inflation_v3, yield_curve_v3) with one aggregated call.

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

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

The description provides explicit usage guidance: 'One call replaces three for macro-aware agents.' It clearly indicates when to use this tool (for macro-aware agents needing aggregated data) versus when to use alternatives (the three individual tools it aggregates). The phrase 'No directional labels, no alignment score, no venue hints' also provides helpful exclusion criteria.

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 of behavioral disclosure. It states the tool provides 'all key indicators at once,' which implies a read-only operation, but doesn't clarify aspects like data freshness, source, rate limits, authentication needs, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence that front-loads the key information: it's a full US economic dashboard with all key indicators. Every word earns its place by specifying the scope and included indicators, with no wasted text or redundancy.

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

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

Given the tool's complexity (providing multiple economic indicators) and lack of annotations and output schema, the description is minimally adequate. It covers the purpose and scope but doesn't address behavioral aspects like data format, update frequency, or limitations. For a tool with no structured output documentation, more detail on what to expect 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 tool has 0 parameters, and schema description coverage is 100%, meaning there are no parameters to document. The description doesn't need to add parameter semantics beyond what the schema provides. A baseline of 4 is appropriate as it efficiently handles the lack of parameters without unnecessary detail.

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 what the tool does: provides a comprehensive US economic dashboard with all key indicators at once. It specifies the resource (US economic data) and scope (all key indicators including Fed, inflation, yields, labor, GDP, housing). However, it doesn't explicitly distinguish from sibling tools like ecb_dashboard or other economic data tools, keeping it from 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 implies usage context by listing the indicators included (Fed, inflation, yields, labor, GDP, housing), suggesting this tool is for getting a broad economic overview. However, it doesn't provide explicit guidance on when to use this versus alternatives like bls_employment for specific labor data or fed_rates for just Fed rates, nor does it mention any exclusions or prerequisites.

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 behavior: it computes a composite index from specific financial indicators and returns structured outputs. It also clarifies a key behavioral trait—the absence of a categorical stress_level output—which is valuable context not covered by annotations. However, it lacks details on potential limitations, data freshness, or error handling.

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

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

The description is highly concise and well-structured in a single sentence. It front-loads key information (purpose and outputs) and efficiently includes essential context (evidence version, indicator list, and distinction from the retired tool). Every element adds value without redundancy.

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

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

Given the tool's complexity (computing a composite index) and lack of output schema, the description is moderately complete. It explains what the tool does and what it returns, but does not detail the output structure (e.g., formats of reason_codes or risk_band) or potential edge cases. With no annotations and no output schema, more behavioral or output context would enhance 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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's function and outputs. This aligns with the baseline expectation for tools with no parameters, as it avoids unnecessary repetition.

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: to compute a US financial stress composite using specific indicators (VIX, HY spread, TED spread, STLFSI) and return structured outputs (reason_codes, signal_strength, risk_band). It explicitly distinguishes itself from a retired predecessor by noting the absence of a categorical stress_level output, making its function specific and distinct from sibling tools.

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

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

The description implies usage for financial stress analysis in the US context, but does not provide explicit guidance on when to use this tool versus alternatives like 'recession_risk_v1' or 'economic_health_v1'. It mentions being 'rebuilt from retired macroracle', which hints at a replacement role, but lacks clear when-to-use or when-not-to-use directives.

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 key behavioral traits: it's a read-only operation (implied by 'returns'), provides specific output fields, and explicitly states limitations ('evidence-only form,' no probability or classification). It also mentions version history ('rebuilt from retired macroracle'), adding useful context about its evolution and reliability.

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 well-structured in two sentences. The first sentence front-loads the core purpose and output fields, while the second clarifies limitations and version context. Every phrase adds value with zero waste, 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 (economic indicator analysis), no annotations, no output schema, and 0 parameters, the description does a good job of completeness. It covers purpose, output fields, limitations, and version history. However, it lacks details on data sources, update frequency, or error handling, which could be relevant for an agent's decision-making in this domain.

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, detailing the return fields (reason_codes, signal_strength, risk_band) and their meaning in context. This adds significant value beyond the empty schema, though it doesn't fully explain the structure or possible values of these fields.

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: providing US recession indicators as evidence with specific output fields (reason_codes, signal_strength, risk_band). It distinguishes itself by explicitly stating what it does NOT provide (probability or classification labels), though it doesn't explicitly differentiate from specific sibling tools beyond the general domain.

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

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

The description implies usage context through phrases like 'evidence only' and 'NO recession probability as label,' suggesting this tool is for raw indicator data rather than interpreted classifications. However, it doesn't explicitly state when to use this versus alternatives like 'economic_health_v1' or 'macro_dashboard,' nor does it provide clear exclusions or prerequisites.

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 of behavioral disclosure. It states the tool retrieves economic profiles but does not cover critical aspects like data freshness, rate limits, authentication needs, error handling, or response format. For a data-fetching tool with zero annotation coverage, this is a significant 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, efficient sentence that front-loads key information: source (World Bank), resource (country economic profile), and metrics (GDP, inflation, trade balance, population). It is appropriately sized 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 (fetching economic data), lack of annotations, and no output schema, the description is incomplete. It does not explain the return values, data structure, or potential limitations (e.g., time periods, availability), leaving significant gaps for an AI agent 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?

The description does not mention the 'country_code' parameter or its semantics. However, the input schema has 100% description coverage, clearly documenting the parameter as an ISO-3 country code with examples. With high schema coverage, the baseline score is 3, as the description adds no value 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's purpose: retrieving World Bank country economic profiles with specific metrics (GDP, inflation, trade balance, population). It uses a specific verb ('profile') and resource ('World Bank country'), but does not explicitly differentiate from sibling tools like 'wb_gdp' or 'wb_rwa_context', which appear related to World Bank data.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools (e.g., 'wb_gdp' for GDP-specific data or 'inflation' for broader inflation data) or specify contexts where this tool is preferred, leaving usage decisions ambiguous.

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 mentions data source (World Bank) and content (GDP with growth rates), but lacks behavioral details such as rate limits, authentication needs, data freshness, or what happens on invocation. This is inadequate for a tool with zero annotation coverage.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it 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 no annotations, no output schema, and 0 parameters, the description is incomplete. It covers the basic purpose but lacks crucial context like return format, data scope (e.g., time period, number of economies), or behavioral traits, leaving significant gaps for 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?

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the inputs. The description adds no parameter information, but with no parameters, a baseline of 4 is appropriate as there's nothing to compensate for.

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

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

The description clearly states the tool retrieves World Bank data about top global economies by GDP with growth rates, providing a specific verb ('Top') and resource ('World Bank: Top global economies by GDP with growth rates'). However, it doesn't explicitly differentiate from sibling tools like 'wb_country' or 'gdp_growth', which may offer overlapping or related functionality.

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. With siblings like 'wb_country' and 'gdp_growth' available, there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions what data is provided (economic risk score and key indicators), it doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, data freshness, or error handling. For a tool accessing external data with no annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a simple lookup tool and front-loads the key information about what the tool provides. There's no wasted verbiage, though it could potentially benefit from slightly more structure if it included usage guidance.

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

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

For a single-parameter tool with good schema coverage but no annotations or output schema, the description provides adequate basic information about what the tool does. However, it doesn't address important contextual elements like what format the risk indicators come in, whether this is real-time or historical data, or how to interpret the results. The absence of an output schema means the description should ideally provide more guidance about the return values.

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

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

The input schema has 100% description coverage, with the single parameter 'country_code' clearly documented as an ISO-3 code. The description doesn't add any parameter-specific information beyond what the schema provides, such as examples of valid codes or how missing parameters might be handled. Given the high schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool provides 'economic risk score and key indicators for country risk assessment' from the World Bank RWA context, specifying both the resource (World Bank RWA data) and the action (providing risk context). However, it doesn't explicitly differentiate from sibling tools like 'wb_country' or 'wb_gdp', which also provide World Bank data for countries, leaving some ambiguity about when to use this specific tool versus those alternatives.

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

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

The description offers no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'wb_country' or 'wb_gdp', nor does it specify scenarios where this risk context tool is preferred over other economic indicators. Without such context, an AI agent might struggle to choose appropriately among the many data sources available.

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 of behavioral disclosure. It lists what data is returned but doesn't describe how the tool behaves: e.g., whether it fetches real-time or historical data, requires authentication, has rate limits, or what format the output takes. For a data-fetching tool with zero annotation coverage, this leaves significant gaps in understanding its 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?

The description is a single, efficient sentence that lists all key data points without unnecessary words. It's front-loaded with the main purpose ('US Treasury yield curve') and then details the specific components. Every part of the sentence provides essential information, making it highly concise and well-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 has no parameters, no annotations, and no output schema, the description does a minimal job by stating what data is returned. However, it lacks details on data sources, update frequency, or output format, which are important for a financial data tool. It's adequate for basic understanding but incomplete for full contextual use.

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

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

The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't discuss parameters, focusing instead on the data returned. This meets expectations for a parameterless tool, though it doesn't add value beyond the schema (which is fine here).

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 with specific maturities (1M-30Y), the 10Y-2Y spread, inversion signals, and recession probability. It uses specific terms like 'US Treasury yield curve' and lists the exact data points returned, making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'ecb_yields' or 'fed_rates', 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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'fed_rates' or 'ecb_yields', nor does it specify use cases (e.g., for US-specific economic analysis vs. other regions). The user must infer usage from the tool name and description alone, with no explicit when/when-not instructions.

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.