AlpineDataWorks Intelligence Server

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

The description adds no behavioral information beyond what the annotations already provide (readOnlyHint=true). It does not describe output format, pagination, or any side effects, which would be helpful for a tool returning sentiment data.

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

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

The description is a single sentence, making it concise but lacking structure. It is front-loaded with a question but does not provide meaningful information beyond the title.

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

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

Given that there is no output schema, the description should explain the return value or format. It fails to do so, leaving the agent uninformed about what response to expect. The optional parameter 'days' is not mentioned in the description, and default behavior is unclear.

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

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

Schema coverage is 100% for the single parameter 'days', which includes a detailed description in the input schema. The tool description does not add any additional parameter guidance, but the schema already handles it adequately, so the baseline score of 3 is appropriate.

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

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

The description is a question rather than a clear statement of what the tool does. It lacks a specific verb and resource, and while the title provides context, the description itself is vague about what 'regime' means or what exactly is returned.

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

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

No guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent without direction for tool selection.

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

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

Annotations provide readOnlyHint=true, so there is no contradiction. However, the description adds no behavioral insight beyond the question; it does not state that the tool is read-only, what the output format is, or any other runtime behavior. Given annotations cover read-only, a 2 is appropriate.

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

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

The description is very concise (one line) but at the cost of substance. It is a question rather than a structured statement. While brevity is good, it omits essential information about the tool's output and 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 only one optional parameter and no output schema, the description should state what the tool returns (e.g., a numeric score, a report, or dashboard). It does not, making it inadequate for an AI agent to understand the tool's output and how to use it correctly.

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

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

Schema description coverage is 100%; the schema already explains the 'days' parameter in detail, including its optional nature, the history feature, and the Gold tier requirement. The description adds no additional meaning, so baseline 3 is correct.

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 is a question ('How healthy is the US macro economy right now?') rather than a clear declarative statement. It implies the tool returns a health score but does not explicitly state what it does or what it returns. It does not distinguish itself from sibling ADW tools, many of which also provide economic indicators.

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

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

No guidance on when to use this tool versus alternatives. The description does not mention the optional 'days' parameter for historical data, nor the Gold tier requirement. There is no context on prerequisites or suitable use cases.

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

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

Annotations indicate readOnlyHint: true, which is consistent with the tool's read nature. However, the description adds no behavioral context beyond the schema—it does not explain what the tool returns (e.g., TVL values, yield data) or any side effects. The parameter description in the schema covers some details, but the tool description itself is lacking.

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?

Extremely concise (one sentence), but the question format is not a proper description. It sacrifices clarity for brevity and does not effectively communicate the tool's purpose.

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

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

The tool has a simple interface (one optional parameter, no output schema), but the description fails to specify what data is returned or how it helps explain TVL changes. It is incomplete and relies heavily on the title and schema for context.

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

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

Schema coverage is 100%, with a detailed parameter description for 'days' including constraints and tier requirements. The tool description adds no parameter information, so baseline of 3 applies.

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

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

The description is a question ('Why is TVL in this DeFi protocol changing?') rather than a clear statement of what the tool does. It hints at TVL analysis but lacks a verb-resource structure. The title provides more context but the description alone is vague.

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

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

No explicit guidance on when to use this tool versus alternatives. The parameter description mentions a Gold tier requirement for history, but there is no comparison to sibling tools or conditions for use.

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

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

Annotations already declare readOnlyHint=true, but the description adds no behavioral context beyond that. It does not explain what the tool returns or any side effects, relying solely on the structured 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 extremely brief but fails to convey necessary information. It is under-specified rather than concise, as it does not state the tool's purpose or 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?

With no output schema, the description should explain the return value, but it does not. The parameter schema is detailed, but the overall tool function remains unclear, leaving the agent without sufficient context to invoke the tool correctly.

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

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

The input schema covers the single parameter 'days' with a clear description, providing 100% coverage. The tool description itself adds no additional meaning beyond what the schema already provides, meeting the baseline for high 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 is a vague question ('What is the stability & coverage of US banking?') rather than a clear statement of the tool's function. It does not use a specific verb+resource structure and offers no differentiation from the many sibling tools.

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

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

No guidance is provided on when to use this tool versus alternatives. The description lacks any context or exclusion criteria that would help an agent choose it appropriately.

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

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

Annotations indicate readOnlyHint=true, and the description adds that the 'days' parameter for history requires Gold tier access, which is useful behavioral context. However, it does not describe the output format or the calculation, so transparency is adequate but not comprehensive.

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

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

The description is a single sentence, very concise. No wasted words, but it is a question rather than a statement, which slightly reduces clarity. Still efficient.

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

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

Given the tool has no output schema, the description should explain what the tool returns or the nature of the score. It only poses a question, leaving the return value ambiguous. The schema covers the parameter, but the overall purpose is under-specified.

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

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

Schema coverage is 100% and the parameter's own description (in the schema) already explains the days parameter. The tool description does not add new meaning beyond that, so baseline score of 3 applies.

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

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

The description is a question ('How affordable is real estate vs income?') which implies the tool computes an affordability score, but it does not explicitly state the action or output. The title helps clarify, but the description is vague.

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

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

No guidance on when to use this tool versus the many sibling tools. No when-to-use or when-not-to-use information is provided, leaving the agent without context for selection.

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

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

Annotations indicate a safe read-only operation, but the description omits essential behavior: the optional 'days' parameter for historical data and the tier restriction (Gold required for history). This is a significant gap for an agent.

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

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

The description is extremely brief (a phrase) but under-specified, not concise in a helpful way. It lacks a clear sentence structure and does not earn its place.

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

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

With no output schema, the description should explain what the tool returns. It does not. It also fails to mention the optional historical data feature, making it incomplete for an agent.

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

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

Schema coverage is 100% with a description for the 'days' parameter. The tool description adds no additional parameter information, so it meets the baseline but provides no extra value.

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

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

The description is a vague question ('Current carbon intensity & renewable share?') rather than a clear statement of what the tool does. It fails to use a specific verb or resource name, and does not differentiate it from the many sibling tools.

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

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

No guidance is provided on when to use this tool versus alternatives. The description gives 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?

Annotations already declare readOnlyHint=true, but the description adds no behavioral context such as output format, authentication needs, or what happens without parameters. With annotations present, the description should complement them but fails to do so.

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 brief but omits critical details. It reads as a query rather than a declarative explanation, sacrificing clarity for brevity. It is under-specified rather than appropriately concise.

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

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

Without an output schema, the description should explain the return value but does not. It also fails to clarify the default behavior (current snapshot) or any tier dependency mentioned in the schema parameter. The tool is incomplete in aiding correct invocation.

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

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

The only parameter 'days' is fully described in the input schema with its constraints and behavior (history vs snapshot, tier requirement). The description does not mention parameters, but with 100% schema coverage, the baseline is met without adding extra meaning beyond the schema.

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

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

The description is a vague question 'Current global news sentiment & velocity?' It does not state a specific action or resource, making it unclear what the tool returns. It fails to distinguish from many sibling tools with similar naming.

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. The description offers no context about scenarios or prerequisites, leaving the agent without 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?

The readOnlyHint annotation indicates safe read, but the description adds no behavioral context. It does not explain what data is returned, how the 'health driver' is measured, or any limitations.

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

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

While extremely short, the description lacks substance. It does not convey meaningful information, making it insufficient for an agent to understand the tool.

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

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

The tool has no output schema, so the description must explain the output. It fails to do so, and given the large number of sibling tools, the description is too incomplete to guide proper selection.

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

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

The input schema has 100% coverage for the 'days' parameter, describing its purpose clearly. The description adds no extra value, but the schema is self-sufficient.

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

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

Description is vague and phrased as a question, not stating a specific action or resource. It does not clarify what the tool computes or returns, and with many sibling tools, it fails to distinguish itself.

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

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

No guidance on when to use this tool versus the many siblings. The description provides no context about the problem it solves or when it's appropriate.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, indicating a safe, read-only operation. The description adds no further behavioral context such as data freshness, aggregation method, or geographic scope.

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), but the content is insufficiently informative. While brevity is maintained, the description fails to front-load a clear action verb or resource.

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

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

Despite the tool's simplicity (one optional param, no output schema), the description is incomplete. It does not specify the nature of the output (e.g., a numeric score, a category) or any interpretation guidelines, leaving the agent uncertain about what to expect.

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

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

Schema coverage is 100% because the single optional parameter 'days' is fully described in the input schema. The description does not add any additional meaning, but the baseline of 3 applies since the schema already handles parameter semantics.

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

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

The description is a vague rhetorical question ('How stressed are global supply chains?') rather than a clear statement of what the tool does. It does not specify that it returns a continuity score or index, nor does it distinguish the tool from its many siblings.

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

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

No usage guidance is provided. There is no mention of when to use this tool, what scenarios it addresses, or how it compares to alternative tools (e.g., other ADW indices).

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

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

Annotations already indicate readOnlyHint=true, so the tool is safe to use without side effects. The description adds the concept of freshness and completeness but does not elaborate on behavior such as data source identification or potential errors. With annotations covering safety, a score of 3 is appropriate.

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

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

The description is extremely concise, consisting of a single short question. It is front-loaded and quickly communicates the tool's value. However, it might benefit from slightly more context without losing conciseness.

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

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

The description is minimal and does not explain the output format, how to interpret the index, or what data sources are covered. There is no output schema to compensate, leaving the agent without sufficient context for evaluating the response.

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

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

Schema coverage is 100%, and the parameter 'days' is fully described in the schema with constraints and conditional behavior (Gold tier required for history). The tool description adds no extra param information, so the baseline of 3 is correct.

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 title and description clearly indicate the tool provides a quality/freshness index for a public data source. The question 'How fresh & complete is this source?' conveys the purpose, but it lacks differentiation from siblings, which may have similar purposes.

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 does not specify prerequisites or contextual triggers. The parameter description in the schema mentions Gold tier for history, but that is not part of the main description.

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

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

Annotations indicate read-only behavior. The description adds that the 'days' parameter provides historical data (requires Gold tier) but does not disclose the return format or other traits beyond schema.

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

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

The description is a single concise sentence. It is adequately sized but could benefit from structured details without being verbose.

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

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

No output schema is provided, and the description does not explain the return format (e.g., index value, categories). This leaves the agent with incomplete understanding of the tool's output.

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

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

Schema coverage is 100%; the schema already explains the optional 'days' parameter. The description does not add additional meaning beyond what the schema provides.

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

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

The description clearly states the tool provides a measure of US economic exposure to billion-dollar weather/climate disasters, aligning with the title 'US Natural-Hazard Risk Index'. However, with no sibling tool descriptions provided, it is unclear if it distinguishes adequately from other 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 does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for current snapshot or historical data, but lacks when-not-to-use context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, indicating a safe read-only operation. The description adds useful context: it returns either a current snapshot or a history series (depending on the 'days' parameter), and the history feature requires Gold tier. This goes beyond the annotations to set expectations about data retrieval and access tiers.

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

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

The description is a single sentence, front-loading the key concept. It is concise and efficiently communicates the tool's focus. However, the question format may be slightly less direct than a declarative statement, which could be improved for agent interpretation.

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

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

The tool has no output schema, so the description should ideally explain what the output contains. It only describes the input 'days' parameter and the general purpose. While the tool is simple (one optional parameter), the lack of any mention of the return value format or structure leaves the agent somewhat uncertain about what to expect.

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

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

Schema description coverage is 100% because the 'days' parameter is fully described in the schema (purpose, range, tier requirement). The tool description itself does not add any additional parameter details, so it does not improve upon the schema. Baseline score of 3 is appropriate given full 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 title 'Consumer-Credit Stress Index' and description 'How stressed is US consumer credit right now — rising delinquencies or credit binging?' clearly indicate the tool provides an index measuring consumer credit stress. However, the description is phrased as a question rather than a declarative statement, and it lacks a clear verb like 'get' or 'retrieve', which slightly reduces clarity.

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

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

No explicit guidance is provided on when to use this tool versus its many siblings. The only usage hint is in the parameter schema, which mentions a Gold tier requirement for history. The tool does not state when it is appropriate to use or suggest alternatives, making it hard for an agent to choose correctly.

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

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

Annotations already declare readOnlyHint=true, so the description correctly does not need to restate safety. However, the description adds valuable context: the optional 'days' parameter returns a historical series if Gold tier is available, otherwise returns a snapshot. This goes beyond annotations and schema details. No contradictions.

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

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded with the core action and immediately useful for an agent.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description provides sufficient context about what the tool does. It could be improved by briefly hinting at the output format (e.g., a list or report), but it is still adequate for an agent to understand and invoke the tool correctly.

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

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

Schema description coverage is 100%, with the 'days' parameter fully described in the schema. The tool description does not add any additional meaning or usage guidance for this parameter beyond what the schema already provides. Per guidelines, baseline is 3 when schema covers parameters sufficiently.

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 identifies underperforming promotional investments and helps reallocate trade spend toward high-elasticity categories, with a specific verb (identify, reallocate) and resource (promotional investments, categories). The title 'Promo-Elasticity Gap' further differentiates it from sibling tools in the adw.adw_* suite, which likely cover other analytical topics.

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

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

The description implies the tool is used for analyzing promotional effectiveness and elasticity, but it does not explicitly state when to use this tool versus alternatives among the many sibling tools. No 'when not to use' or alternative tool names are provided, which is a gap for an agent to correctly select it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds no behavioral context beyond the abstract purpose—no mention of data sources, update frequency, access tiers, or side effects. Since the bar is lowered by annotations, the description provides minimal extra value.

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

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

The description is a single sentence, efficient and front-loaded. However, it could be slightly longer to include essential details without becoming verbose. No wasted words.

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

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

For a simple read-only tool with one optional parameter, the description is adequately complete in conveying the high-level purpose. However, it lacks any indication of the output format or structure, which could hinder an agent in interpreting the result. The annotations and schema partially compensate, but a user would benefit from knowing what the tool returns.

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

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

Schema coverage is 100% for the single parameter 'days', and the schema description is thorough (explains optional, history vs snapshot, Gold tier requirement). The tool description itself does not mention the parameter, so it adds no value beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's domain (quantifying financial pressure on discretionary spending) and its intended use for retailers (timing promotions, optimizing assortment). However, the verb 'enables' is somewhat indirect; it doesn't explicitly state what the tool returns (e.g., an index, score, or data series). It distinguishes purpose from siblings but lacks sharp 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?

No guidance is provided on when to use this tool versus the many siblings. There is no mention of prerequisites, context, or exclusion criteria. The agent is left to infer usage solely from the vague outcome-oriented description.

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

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

Annotations declare readOnlyHint=true, and description aligns with read-only identification. No additional behavioral traits are disclosed (e.g., output format, data source). With annotations present, the description adds minimal 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?

Single sentence, extremely concise, no redundant information. Front-loaded with 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?

Tool has one optional parameter, annotations, and no output schema. Description is adequate for purpose but lacks return format information. Could be more complete given simplicity.

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

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

Schema coverage is 100% and the schema description for the sole parameter 'days' is clear. The tool description does not add meaning beyond the schema, so 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 it identifies high-potential zip codes for retail site selection using local demographics. It uses specific verbs and resources, but does not differentiate from many sibling tools with similar demographic focus.

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

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

No guidance on when to use this tool versus alternatives. The description implies site selection use, but no explicit context or exclusion criteria given the large sibling set.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=false. Description adds the core behavior of comparing strategies and notes the optional history parameter. No contradictions, but could mention the read-only nature explicitly.

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

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

Single sentence, front-loaded with action and resource, no filler. Every word is meaningful.

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?

Purpose and parameter are clear, but the return format (e.g., numeric cost, decision string) is not described. With no output schema, the description should cover the output structure.

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

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

Schema coverage is 100% with a well-described 'days' parameter. The description adds no extra semantic detail beyond the schema, meeting the baseline for high coverage.

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

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

The description uses a specific verb 'Quantify' and clearly identifies the resource as 'financial impact of supply-chain disruptions', with a clear decision outcome between two strategies. It is distinct from sibling tools, though sibling descriptions are unknown.

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

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

No guidance on when to use this tool vs alternatives. No prerequisites, scenarios, or exclusions provided. Given many siblings, explicit usage context is missing.

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

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

Annotations already declare readOnlyHint=true, so the tool is clearly a read operation. The description adds behavioral context about identifying geopolitical/operational disruptions but does not disclose any additional traits like data format or limitations beyond what annotations provide.

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

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

The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and target user. It is concise but could be slightly more structured with separate user and action elements.

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

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

The tool is simple with one optional parameter, and the description provides sufficient context for its use case. However, without an output schema, the description could hint at the type of data returned (e.g., list of disruptions). It is adequate but not fully complete.

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

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

Schema description coverage is 100% for the single parameter 'days'. The description does not add any additional meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: enabling logistics managers to proactively diversify suppliers by identifying disruptions. It uses a specific verb ('identify') and resource ('disruptions'), and distinguishes from many sibling tools by focusing on supply-chain early warning.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or the specific contexts in which it should be preferred over 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?

Annotations declare readOnlyHint=true, so the tool is safe. The description adds that with the 'days' parameter it returns a daily history series (Gold tier required) vs. a current snapshot, which is useful behavioral context. It does not contradict annotations, though the action-oriented phrasing is slightly misaligned.

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

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

The description is a single sentence that conveys purpose and outcome. It is reasonably concise but could be shorter and more direct. The structure front-loads the tool's value but lacks technical specificity.

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

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

Despite annotations and schema covering the parameter, the description fails to explain the output format or content (e.g., what data is returned). As a read tool with no output schema, this omission is significant. The tool's place among many siblings is also not clarified.

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

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

Schema description coverage is 100% and the parameter description in the schema is detailed (history vs. snapshot, tier requirement). The main description adds no additional parameter info. Baseline 3 is appropriate.

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

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

The description states the tool helps administrators recruit and deploy nursing staff to prevent shortages, implying it provides staffing data or predictions. However, it is vague on what exactly the tool returns (e.g., a report, metrics) and does not distinguish from many sibling tools. The verb 'enable' is indirect and the description reads more like a business outcome than a tool function.

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

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

The description broadly suggests use for proactive staffing, but provides no explicit guidance on when to use this tool vs. alternatives. No conditions, prerequisites, or exclusions are mentioned. Without differentiation from siblings, an agent cannot reliably choose this tool over others.

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

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

Annotations already declare readOnlyHint=true, so the description does not need to reiterate. The description's purpose statement adds context about the tool's analytical nature, and the parameter schema explains the historical data restriction. No contradictions with annotations.

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

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

The description is a single sentence that is clear and front-loaded with the tool's purpose. No unnecessary words.

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

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

Given the tool has only one optional parameter and no output schema, the description is fairly complete. It explains the high-level use case, and the parameter schema covers the main behavior. Could be slightly more detailed about the output format.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add additional parameter semantics beyond what the schema provides; it focuses on the tool's overall purpose.

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

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

The description clearly states the tool's purpose: enables corporate buyers to quantify price risk and justify locking in long-term energy contracts. It uses a specific verb (quantify, justify) and resource (energy-cost volatility), distinguishing it from sibling tools that cover other domains like health or air quality.

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 energy contract decisions but provides no explicit when-to-use or when-not-to-use guidance compared to alternatives. The parameter description adds a constraint (Gold tier for history), but overall guidance is minimal.

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 readOnlyHint annotation already marks it as safe. The description adds context about distinguishing pricing power types, but does not disclose limitations, data sources, or any side effects. Annotations cover safety, but behavioral details are sparse.

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

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

The description is a single sentence with no wasted words. However, it uses jargon that may reduce clarity for some agents.

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

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

The description does not explain the return format or output structure. Without an output schema, the agent lacks information on what to expect from invoking this tool.

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

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

Schema coverage is 100% with a detailed parameter description for 'days'. The tool description adds no further parameter information, so baseline score of 3 is appropriate.

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

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

The description uses specific terms (emotional aspiration, functional utility, pricing fragility) to convey a distinct purpose: analyzing pricing power sources. However, it does not explicitly state that the tool returns an index or score, which would clarify its output.

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 its many siblings or alternatives. The description lacks context on prerequisites or typical scenarios.

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

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

Annotations already declare readOnlyHint=true, so the description doesn't need to reiterate read-only behavior. However, it does not add any behavioral context beyond the title, such as what data is returned (e.g., list, amounts) or how to interpret the 'signal'. Since annotations cover the safety profile, the description adds minimal extra 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, efficient sentence that immediately conveys the core purpose. It is front-loaded and contains no wasted words.

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

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

Given the tool has one optional parameter and no output schema, the description is fairly complete for a simple signal tool. However, it does not explain the output format (e.g., what fields or data points are returned), which could be useful for an agent. This leaves some gaps in 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?

Schema coverage is 100% with a single parameter 'days' already well-described in the schema. The tool description itself does not add any parameter semantics beyond what the schema provides. Baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: enabling investors and contractors to identify municipalities with upcoming infrastructure spending before public tender announcements. The verb 'identify' and the resource 'municipalities with upcoming spending' are specific and distinguish this tool from other adw tools that likely provide different 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 implies the tool should be used for early signals before public tender announcements, but it does not explicitly state when to use versus alternatives or when not to use. Among many sibling tools, no direct comparison is made, so guidance is limited but not absent.

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

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

The description adds context about the tool's output (flagging scenarios) but does not disclose behavioral traits beyond what annotations already provide (readOnlyHint). No mention of data sources, latency, or other constraints.

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

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

The description is a single 12-word sentence with no wasted words. It is front-loaded with the core action and 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 simple input (one optional parameter) and read-only annotations, the description adequately explains the tool's purpose. However, it does not describe the output format or provide examples, which would be helpful.

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

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

Schema coverage is 100% (the single 'days' parameter is described in the schema). The tool description does not add meaning beyond the schema description, so a baseline of 3 is appropriate.

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

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

The description clearly states the tool quantifies divergence between gasoline price moves and consumer sentiment, with a specific verb ('Quantifies') and resource ('divergence'). The title and description uniquely identify this tool among many siblings.

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

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

The description mentions the purpose (flag political risk and demand-destruction), but does not provide explicit guidance on when to use this tool versus alternatives, nor does it list 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?

Annotations declare readOnlyHint=true, which is consistent. The description adds behavioral context by explaining that the optional 'days' parameter returns a daily history series (requires Gold tier) or the current snapshot. This goes beyond the annotations, though it does not detail output format or other side effects.

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

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

The description is a single, concise sentence of 18 words that front-loads the core purpose. Every word adds value with no redundancy.

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

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

For a tool with one optional parameter and no output schema, the description adequately states the purpose and context. However, it omits the parameter's existence, which is covered in the schema, and does not describe what the output contains (e.g., data fields). The lack of output schema increases the burden, but the tool is simple enough that this is acceptable.

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

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

Schema coverage is 100% with a clear description of the 'days' parameter. The tool-level description adds no additional meaning to the parameter beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool enables employers and insurers to deploy mental health interventions and telehealth resources to employees in regions with seasonal light deprivation. It uses a specific verb ('Enables') and resource ('deploy mental health interventions'), and the context is well-defined, distinguishing it from sibling tools with cryptic names.

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

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

The description provides context (seasonal light deprivation) but no explicit guidance on when to use this tool versus alternatives. It lacks usage boundaries or exclusions, leaving the agent to infer applicability.

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

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

Annotations already indicate readOnlyHint=true, so the description's implication of read-only analysis is consistent. However, it adds minimal behavioral context beyond what annotations provide, such as no details on return format or side effects.

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

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

The description is a single concise sentence that front-loads the action and purpose with no redundant information. Every word serves a purpose.

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

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

With no output schema, the description should clarify what the tool returns, but it only says 'identify inefficiencies' without specifying output structure, metrics, or format. The title's 'Volume Gap' is also unexplained, leaving significant 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 input schema fully describes the single optional 'days' parameter with 100% coverage, so the description does not need to add parameter details. It adds no additional semantic 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 identifies marketing inefficiencies by isolating high-engagement, low-conversion campaigns, which is a specific verb+resource combination. However, it does not distinguish from sibling tools, preventing a top score.

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

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

No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or exclusions mentioned. The description only states the tool's purpose without contextual 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?

Annotations declare readOnlyHint=true, but the description adds no behavioral details beyond the parameter's effect (history vs snapshot). It does not describe the output format, data structure, or any side effects, even though it is inherently read-only.

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

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

The description is a single, concise sentence. However, it could be more directly actionable by starting with a verb like 'Retrieve' or 'Analyze' instead of 'Enables enterprises to make'.

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

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

The tool has no output schema, so the description should compensate by explaining what the tool returns. It only says it enables decisions but does not describe the output format, metrics, or how the data supports the decision. This is a notable omission.

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 already has 100% coverage with a clear description for the 'days' parameter. The tool description does not add any additional parameter information, so it meets the baseline but provides no extra value.

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

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

The description clearly identifies the domain (labor-adjacent capacity) and the decision-making context (headcount vs contractors for quarterly demand). However, the verb is indirect ('enables' instead of a direct action like 'retrieve capacity data'), and it does not explicitly differentiate from sibling tools.

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

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

The description provides a usage context ('for upcoming quarterly demand') but no explicit guidance on when not to use the tool or how it compares to alternatives. With many sibling tools, this is a significant gap.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds no further behavioral details, but does not contradict 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?

Single, front-loaded sentence with no extraneous information.

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

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

With one optional parameter for history, the description does not explain this capability or the tool's output. Incomplete for practical 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?

Schema coverage is 100% for the single parameter 'days'. The description adds no meaning beyond the schema's own description.

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

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

The description clearly states the tool's purpose: enabling organizations to prioritize and allocate capital for climate resilience based on physical risk exposure. However, it does not differentiate from the many sibling tools.

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

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

No guidance on when to use this tool versus alternatives. No prerequisites or context provided.

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

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

Annotations already indicate readOnlyHint=true, so the tool is read-only. The description adds valuable context about requiring Gold tier for historical data and using real archived data, exceeding what annotations provide.

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 with no waste, front-loading the core purpose. Every word earns its place.

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

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

The description explains the tool's purpose and tier requirement, but lacks details about the output format. Given the low complexity and good schema coverage, it is mostly complete.

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

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

Schema description coverage is 100%, and the schema already explains the 'days' parameter well. The tool description does not add any additional parameter meaning beyond what is in the schema, so baseline score applies.

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

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

The description clearly states the tool enables IT leaders to forecast infrastructure capacity needs and prevent outages, indicating a specific verb and resource. However, it does not differentiate from the many sibling tools with similar numerical names, preventing a top score.

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

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

No guidance is provided on when to use this tool versus alternatives. The description and schema do not compare to siblings or specify contexts where this tool is preferred.

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

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

Annotations already declare readOnlyHint=true, indicating safe read operation. The description adds no behavioral traits beyond this; it mentions 'mitigate' which could imply mutation, but the annotations override. No contradiction.

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

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

The description is a single concise sentence that conveys the core purpose without extraneous details. It is well-structured and front-loaded.

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

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

Given no output schema, the description does not explain return values. The tool is simple (one optional parameter, read-only), but more information about the output format or example 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?

Input schema covers the only parameter (days) with a detailed description. The tool description does not add extra meaning beyond what the schema provides, so baseline score of 3 applies.

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

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

The description clearly states it enables identification and mitigation of regulatory exposure across multiple jurisdictions, which is specific. However, with many sibling tools (adw_001 to adw_*), it does not differentiate itself from other risk-related tools.

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

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

No guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or contexts where this tool is preferred.

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

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

Annotations already declare readOnlyHint=true, so the tool is a safe read operation. The description adds that it quantifies and identifies over-reliance, which is consistent. However, it does not disclose behavioral details such as whether results are aggregated, whether it returns a snapshot or history (the schema covers history), or any rate limits. The description adds some context but does not go beyond what annotations provide for safety.

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

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

The description is a single, well-structured sentence that immediately conveys the tool's purpose. It is front-loaded with the target user ('logistics buyers') and action ('quantify and mitigate concentration risk'). No unnecessary words; every phrase earns its place.

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

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

Given the tool has one optional parameter, no output schema, and annotations indicating a read-only operation, the description provides the core purpose but lacks details about output format, how results are presented, or how to interpret the concentration risk metrics. Without output schema, the description could better inform agents about what to expect, but the simplicity of the tool makes this acceptable but not exemplary.

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

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

Schema description coverage is 100% for the single 'days' parameter, which already explains its purpose and constraints. The description does not add any additional meaning or usage tips beyond the schema. With full schema coverage, 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?

Description clearly states the tool's purpose: enabling logistics buyers to quantify and mitigate concentration risk by identifying over-reliance on specific suppliers, regions, or transport modes. The verb 'enable' is weaker than 'quantify' or 'identify', but overall it's specific to supply chain risk analysis. However, it does not differentiate from numerous sibling tools beyond its title, which limits clarity in a large toolset.

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

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

No guidance on when to use this tool versus alternatives. The description implies use for supply chain diversification analysis, but it does not specify prerequisites, exclusions, or mention similar tools. With many sibling tools, explicit usage context would be valuable.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, indicating safe, deterministic reads. The main description adds 'current level and momentum', and the parameter description discloses that passing days returns a historical series (with Gold tier requirement). This adds useful behavioral context beyond annotations, though the main description is a question.

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 main description is a single short sentence (a question). It is concise but not optimally structured as a declarative statement. The parameter description is in the schema. Overall, no wasted text, but the format is suboptimal for agent 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?

The description covers the primary purpose (US tourism demand level and momentum) and the optional history feature via the parameter. However, it lacks details on the output format, data sources, or how to interpret 'momentum'. With no output schema and many sibling tools, more context would help complete the picture.

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

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

Schema description coverage is 100%; the 'days' parameter is fully described in the input schema (optional, range, history vs snapshot, tier requirement). The main tool description adds no additional parameter information. Baseline 3 is appropriate since schema already covers semantics.

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

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

The description is phrased as a question ('What is the current level and momentum...') rather than a clear verb+resource statement. It does not explicitly say it retrieves or returns data. The title 'Tourism-Demand Pulse' hints at its function, but the description fails to provide a definitive action. With many sibling tools, no differentiation is provided.

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

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

No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, typical use cases, or scenarios where another tool would be better. The only contextual hint is the 'days' parameter description, which explains optional history retrieval, but no overall usage strategy.

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

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

Annotations already declare readOnlyHint=true, so the description's value is moderate. It discloses that the tool returns a snapshot or history based on the 'days' parameter and that Gold tier is required for history, but it omits details about output format or data content.

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

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

The description is very short (one sentence), which is concise, but the question format is unconventional and may not be immediately clear as a tool description. It could be more effectively structured as a statement.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description covers the basic purpose and parameter behavior. However, it lacks any information about the return value structure, which would be beneficial for an agent to interpret results.

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

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

The input schema has 100% description coverage, so the baseline is 3. The tool description adds no additional semantics beyond what the schema already provides for the 'days' parameter, such as its optional nature and tier requirement.

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 is phrased as a question rather than a clear statement of the tool's action, making the purpose somewhat vague. The title 'Wage-Price Spiral Risk' helps, but the description does not explicitly state that the tool returns a risk metric or index.

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

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

No guidance is provided on when to use this tool versus sibling tools. The description does not mention alternatives or specific use cases beyond the parameter note about Gold tier for history.

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

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

The description adds value beyond the readOnlyHint annotation by clarifying that the tool can return either a current snapshot or a historical series (via the 'days' parameter), and that the history feature requires Gold tier. This discloses behavioral traits not covered by annotations.

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

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

The main description is extremely short (a single question) but inadequate. The schema description carries the informational load. While conciseness is valued, under-specification harms 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?

The tool has only one optional parameter and no output schema. The description explains the snapshot vs history behavior, but does not specify what the output looks like (e.g., format, units, interpretation). For a cost index, this leaves some ambiguity.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds significant meaning to the 'days' parameter by explaining its effect (returns history vs snapshot) and the Gold tier requirement, which goes beyond the schema's description.

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

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

The description is a question rather than an explicit statement of the tool's function. It implies the tool provides information about freight and diesel cost pressure, but lacks a clear verb and resource combination. The title 'Freight & Logistics Cost Index' adds context, but does not fully compensate for the vague phrasing.

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, and no mention of when not to use it. The context signals include a long list of sibling tools, but no differentiation is offered.

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

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

Annotations already declare readOnlyHint=true, so the agent knows it is a safe read. However, the description adds no behavioral context beyond this, such as what data is returned or any constraints.

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

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

The description is a single sentence, which is concise but not structured as a clear definition. It is more a prompt than a informative description.

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

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

For a simple tool with one optional parameter and no output schema, the description should explicitly state what the tool returns. It does not, leaving the agent to infer from the question.

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

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

Schema coverage is 100% and the schema describes the optional 'days' parameter well. The description does not mention the parameter or add any additional meaning, meeting the baseline for high 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 is phrased as a question, which implies the tool provides an answer comparing healthcare inflation to core inflation. It is not a tautology and gives a vague idea of purpose, but lacks an explicit verb such as 'returns' or 'computes'.

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. There is no mention of context, exclusions, or sibling tools, leaving the agent without decision support.

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

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

Annotations already declare readOnlyHint=true, so the tool is a safe read operation. The description adds no behavioral context beyond the parameter description for 'days'. It does not disclose what happens with or without the parameter, or any side effects, but no contradictions exist.

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

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

The description is very short (one sentence question), which is concise but at the expense of completeness. It is front-loaded but lacks explicit statements about what the tool returns. The brevity may hinder agent 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?

The tool has no output schema, so the description should explain the return value. It does not; it only poses a question. The agent cannot infer whether the output is a single number, a time series, or a report. The parameter description in the schema covers input but not output.

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

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

Schema description coverage is 100%, so the parameter 'days' is fully documented in the schema. The tool description does not add any additional meaning or context about the parameter beyond what is already in 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 asks 'How fast is renewable share growing?' which implies the tool provides data on the growth rate of renewable energy share. It is specific about the resource (renewable share) and action (growing), but does not explicitly state what it returns (e.g., a metric or time series). The title 'Energy-Transition Demand' adds context, but the description does not differentiate 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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention any conditions, prerequisites, or exclusions. The list of sibling tools is large, but no differentiation is given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. Description adds no new behavioral details beyond the implied read operation. No contradiction with annotations.

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

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

Single-sentence description is concise, but its interrogative form is unconventional. Could be more direct as a statement. No wasted words, but the structure is average.

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

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

No output schema exists, yet the description does not explain what the tool returns (e.g., a numerical index, range, or comparison). Lacks details on interpretation or scope, making it incomplete for a tool that likely outputs a metric.

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?

Input schema covers 100% of parameters, with a clear description for the 'days' parameter. The tool description does not add any extra meaning about parameter usage, so baseline 3 is appropriate.

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

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

Description is a question asking about affordability relative to history, implying the tool returns an index. However, it lacks a clear declarative statement of what the tool does (e.g., 'Retrieves the auto-market affordability index'). Does not distinguish 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?

No guidance on when to use this tool versus the many siblings. No mention of prerequisites or scenarios. The description only asks a question, leaving the agent without context for selection.

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

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

Annotations already declare readOnlyHint=true, so the description does not need to restate that. However, the description adds no additional behavioral context such as what the output format is (e.g., a single numeric value, a percentage), or how the index is calculated. With annotations covering the safety profile, the description is adequate but not enriched.

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

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

The description is a single concise sentence, a question that conveys the core purpose. There is no fluff or repetition. Every word earns its place.

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

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

Without an output schema, the description should clarify what the tool returns (e.g., a numeric index value, scale, or units). The question format leaves ambiguity about the exact return value. For a tool with low complexity and one optional parameter, this is acceptable but not fully complete.

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

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

The input schema has 100% description coverage for the single 'days' parameter, including details about history retrieval and tier requirements. The description does not mention the parameter, so it adds no extra meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description is a question that implies the tool returns a measure of upward price pressure from the food supply chain. The title 'Food-Price Pressure Index' reinforces this. However, it does not explicitly state that the tool returns a current index value or differentiate it from sibling tools like adw.adw_001 or adw.adw_002, which likely cover other indices.

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. There is no mention of scenarios where this index is appropriate or when to use other tools. The description does not exclude any contexts nor compare to siblings.

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

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

Annotations already mark the tool as read-only (readOnlyHint=true). The description adds no behavioral details beyond the question, such as data source, update frequency, or limitations.

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

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

The description is very short but uses an interrogative form, which is unconventional for a tool description. It is concise but not optimally 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?

For a simple read-only tool with one optional parameter, the description fails to state what the tool returns (e.g., a numeric index value) or how the index is computed. Output schema is missing, but even without it, the description should provide basic 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 schema provides full coverage for the single 'days' parameter. The description does not mention parameters, so it adds no extra meaning. Baseline of 3 is appropriate.

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

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

The title clearly indicates the metric, and the description is a natural language question that implies the tool provides the tightness index. However, it does not explicitly state an action (e.g., 'returns the index') and remains 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?

No guidance on when to use this tool versus the many sibling economic indicators. There is no mention of alternatives or context for selection.

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

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

The description adds no behavioral information beyond the readOnlyHint annotation. It does not disclose what the index represents, its range, time period, or any side effects. The schema provides some parameter details, but the description fails to enhance 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 sentence, which is concise, but it is not informative. It sacrifices substance for brevity, and the use of a question is unconventional. It is front-loaded but under-specified.

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 a single optional parameter and no output schema, the description should at least explain the index's meaning, typical values, and usage scenario. The current description is too vague to be considered complete for an agent to correctly select and invoke this tool.

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

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

The schema already documents the single 'days' parameter completely (100% coverage). The description does not add any new meaning or context beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description is phrased as a question ('Are corporate credit spreads signaling elevated default risk right now?'), which does not clearly state the tool's function. It implies an index, but lacks a specific verb and resource. Among many sibling tools with similar numeric index names, this provides no 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?

No guidance is provided on when to use this tool versus alternatives, nor any context on prerequisites or exclusions. The description gives no indication of typical use cases or comparisons with other 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?

Annotations already indicate readOnlyHint=true (safe read). The description adds behavioral context about the 'days' parameter switching to history mode and requiring Gold tier, which is useful. However, it does not describe the output format or other traits.

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

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

The description is a single sentence, but it is phrased as a question, which is less direct than a typical imperative description. It is concise but could be more effective as a statement.

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

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

Without an output schema, the description should explain what the tool returns (e.g., the index value, growth rate, or velocity signal). It only covers the 'days' parameter behavior and fails to describe the output, making it incomplete for an agent to understand the tool's 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 schema already covers the 'days' parameter (100% coverage). The description adds significant value by explaining that providing 'days' returns a historical series (up to 5 years) instead of a snapshot, and notes the Gold tier requirement. This helps the agent understand the parameter's effect.

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 is phrased as a question rather than a clear statement of what the tool does. It implies the tool computes an index related to M2 money supply and velocity, but does not explicitly state the action (e.g., 'returns the Money-Supply Momentum Index'). The name and title help, but the purpose is not directly 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?

No guidance is provided on when to use this tool versus the many sibling tools. There is no mention of specific use cases, prerequisites, or when not to use it.

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

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

The description adds no behavioral information beyond the existing readOnlyHint annotation. It does not disclose what the output contains, how the index is calculated, data sources, or any side effects. Since annotations already declare it's read-only, the description should provide additional context but fails to.

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 vague sentence that does not efficiently convey purpose. It is not front-loaded with actionable information and reads as a marketing question rather than a tool definition.

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

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

The tool has no output schema, so the description must explain what the tool returns (e.g., a time series, a single index value). It does not. The parameter documentation is complete, but without any output context, the description is wholly insufficient for an agent to understand the tool's behavior.

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

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

Schema description coverage is 100% for the single optional parameter 'days', which is well-documented in the schema (max 1825 days, tier requirement). The tool description does not add any parameter information, but given high schema coverage, a baseline of 3 is appropriate.

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

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

The description is a question ('Is nonfarm business productivity outpacing unit labor cost growth...?') rather than a clear statement of the tool's function. It only hints at comparing two metrics but does not specify what the tool returns (e.g., a ratio, an index, or a comparison). The title 'Productivity Trend Index' adds minimal clarity.

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

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

No guidance is provided on when to use this tool versus the many siblings (100+ tools). There are no context cues, alternatives, or exclusions. The description does not help an agent decide when this tool is appropriate.

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

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

Annotations already declare readOnlyHint=true. The description adds that the index combines rate levels and delinquency trends, and the schema reveals tier-dependent behavior for the days parameter. This adds moderate context beyond annotations.

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

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

The description is a single, efficient sentence that conveys the purpose without unnecessary words. It is front-loaded and earns its place.

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

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

For a simple read-only tool with one parameter and no output schema, the description combined with the schema provides adequate context. It could be improved by explicitly stating the return type (e.g., an index value or history), but overall it is mostly complete.

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

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

Schema description coverage is 100% for the one parameter (days). The tool description does not add further parameter information, so baseline 3 is appropriate.

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

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

The description clearly states that the tool measures stress in the residential mortgage market by combining rate levels and delinquency trends. It uses a specific verb and resource, but does not differentiate from the many sibling tools with similar naming (e.g., adw.adw_001, etc.).

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. The schema mentions a Gold tier requirement for history data, but no explicit comparison to sibling tools or conditions for use.

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

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

Annotations already declare readOnlyHint=true. Description adds context about comparing to historical norms and the parameter's effect (history series vs snapshot) and Gold tier requirement. No contradictions.

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

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

Single sentence, extremely concise. Could be improved by adding a brief statement of what it returns, but no wasted words.

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

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

For a simple read-only tool with one optional parameter, the description adequately conveys purpose. Missing output schema is compensated by the implicit numerical result. Adequate given the low complexity.

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

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

Schema description coverage is 100% for the single parameter. The tool description adds no additional meaning beyond what the schema already provides for 'days'.

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

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

The description uses a question format to indicate the tool provides a commercial real estate stress index relative to historical norms. It is clear about the resource and action but lacks an imperative verb and does not differentiate from many sibling tools with numeric names.

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

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

No guidance on when to use this tool versus alternatives. The only usage hint is in the parameter description about history requiring Gold tier, but no context on choosing this tool over siblings.

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

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

Annotations already indicate readOnlyHint=true. The description adds that the tool compares market expectations with realized CPI, but does not disclose additional behaviors like data frequency, update lag, or output format. It does not contradict annotations.

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

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

The description is a single, concise sentence. It is front-loaded and contains no extraneous 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?

No output schema exists, so the description should hint at return values. It only asks a question without specifying output type (e.g., numeric index, units). The parameter description mentions history vs snapshot, but overall the tool's context is incomplete for an economic indicator.

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

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

The single parameter 'days' is fully described in the input schema (100% coverage). The tool description adds no further parameter details, so the baseline score of 3 is appropriate.

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

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

The description asks whether market inflation expectations are above or below realized core CPI, clearly indicating the tool computes a gap index. However, it lacks an explicit verb like 'Get' or 'Retrieve.' It distinguishes from sibling tools by focusing on a specific economic indicator.

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

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

No guidance on when to use this tool versus other adw indices. The sibling list contains many similar economic indicators, but the description does not specify prerequisites or context for selection.

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

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

Annotations (readOnlyHint: true) already disclose read-only nature. The description adds minimal behavioral context, mostly repeating the title's implication. No contradiction, but could detail output structure.

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

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

Extremely concise: a single question that accurately captures the tool's function. No wasted words, front-loaded with the core inquiry.

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

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

Despite high schema coverage and annotations, the description lacks any specification of the return value (e.g., numeric metric, graph, severity level). This is a significant gap for a tool with no output schema.

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

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

Schema coverage is 100%, detailing the 'days' parameter fully. The description adds no additional parameter meaning beyond the schema, so baseline score applies.

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

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

The title and description clearly indicate the tool measures the depth and trend of yield-curve inversion. 'How deep...and is it deepening?' is a specific verb phrase that uniquely identifies the tool's purpose among siblings.

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

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

The description implies usage for querying current inversion state, but no explicit guidance on when to use alternatives or when not to use this tool. Lacks distinction from other adw 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?

Annotations already indicate readOnlyHint=true, so description adds no behavioral context (e.g., what is returned, access restrictions beyond Gold tier mentioned only in parameter schema).

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?

Very short (one line), but structured as a question rather than a clear statement of action. While concise, the format may confuse agents expecting an imperative description.

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

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

No output schema exists, and the description does not explain what the tool returns (e.g., bullish/bearish signal, numeric index). Incomplete for a tool that likely outputs a simple value.

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

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

Schema description coverage is 100% for the single optional 'days' parameter, which is well-documented. Tool description does not add parameter information, so baseline 3.

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

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

Description is a question that implies the tool assesses dollar strength against historical range, but lacks a clear verb stating what it does (returns, computes, indicates). It is not a tautology but is vague.

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

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

No guidance on when to use this tool versus alternatives, nor when not to use it. Sibling tools are listed but not distinguished.

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

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

Annotations already indicate readOnlyHint=true, so the description does not add any behavioral context beyond that. It does not describe the output type (snapshot vs history) or any other behavioral traits.

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

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

While the description is short, it is under-informative. A single rhetorical question does not effectively convey the tool's purpose or usage. Conciseness should not come at the expense of 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?

With no output schema, the description should explain what the tool returns. It fails to do so, leaving the agent to guess the output format (e.g., a number, index value, series). The parameter is well-documented in the schema, but the tool's overall purpose is incomplete.

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

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

Schema coverage is 100%, so the input schema already fully describes the only parameter (days). The description adds no additional meaning beyond what is in 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 is a vague question ('Are US consumers running down savings at an alarming rate?') that does not clearly state what the tool does, what it returns, or how it differs from sibling tools. It lacks a specific verb and resource.

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 the many sibling tools. There is no mention of context, prerequisites, or alternatives.

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

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

Annotations already declare readOnlyHint=true, so the description adds no behavioral context. The description does not disclose the nature of the output (e.g., numeric value vs. categorical), units, or any side effects. It adds minimal value beyond annotations.

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

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

The description is extremely concise (one sentence), but lacks structure and essential information. It is not verbose, but the conciseness comes at the cost of completeness. It is functional but not 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 absence of an output schema, the description should explain what the return value represents (e.g., a percentage, index, or historical series). It does not. The tool is simple, but the description leaves ambiguity about the output format and comparison to similar tools.

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

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

Schema description coverage is 100%, with the 'days' parameter well-described. The tool description itself does not explain or expand on this parameter, but the schema already carries the burden. Baseline 3 is appropriate.

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

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

The description is a question ('How tight are US petroleum stocks?') which implies the tool returns a tightness metric, but lacks an explicit verb+resource statement. The title clarifies it's about 'Energy-Inventory Tightness', but it does not distinguish from numerous sibling tools with similar naming patterns.

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 vs. alternatives. There is no mention of prerequisites (e.g., Gold tier for history), nor any when-to-use or when-not-to-use context. The schema's 'days' parameter description hints at conditions, but the main description is silent.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds little extra; it implies a query returning a recovery percentage but does not specify data frequency, aggregation, or other behavioral traits.

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

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

The description is a single concise sentence, front-loading the core purpose. It earns its place but could briefly mention the optional parameter.

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

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

No output schema exists, yet the description does not explain the return format (e.g., a single number, a daily series). The parameter 'days' is only in schema, not mentioned in description, leaving gaps for a tool with no other documentation.

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

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

Schema coverage is 100% for the single parameter 'days', which is well-documented in the schema. The description does not repeat this parameter, so no added meaning beyond schema. Baseline 3 is appropriate.

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

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

The description clearly asks about the recovery of US air travel vs prior-year baseline, indicating the tool computes a recovery index. It is specific to US air travel, but does not differentiate from sibling tools with similar names (e.g., other indices in the adw family).

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

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

No guidance on when to use this tool versus alternatives (e.g., other travel indices or metrics). No exclusions or conditions provided beyond an implicit query context.

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

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

Annotations already declare readOnlyHint=true, indicating no side effects. However, the description adds no further behavioral context—it does not explain what 'flow' means (e.g., net inflow/outflow metric, time aggregation), what data sources are used, or whether the return is a Boolean, numeric, or string. With annotations covering safety, the description contributes minimal behavioral insight.

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 line, which is concise, but it is too sparse to be effective. It omits critical information such as what the tool returns and how to interpret results. Conciseness should not come at the expense of completeness; here it under-specifies.

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

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

Given the tool's simplicity (one optional parameter, no output schema, read-only), the description is inadequate. It fails to describe the expected output (e.g., a signal value, direction string, or time series) and does not help the agent understand how to use the returned data. The schema provides the parameter, but the description leaves the agent guessing about the tool's core functionality.

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

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

Schema coverage is 100%, and the only parameter 'days' is well-documented in the input schema (purpose, range, tier restriction). The description adds no additional parameter meaning, so baseline 3 is appropriate.

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

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

The description 'Is stablecoin capital flowing into or out of crypto?' is phrased as a question, implying the tool returns an indicator of flow direction. It gives a general sense of the metric (stablecoin flow momentum) but lacks a verb like 'retrieve' or 'compute', and does not specify the output format (e.g., a sign, a value, a string). Compared to siblings, the purpose is somewhat discernible but not precisely 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?

No guidance is provided on when to use this tool versus its many siblings. There is no mention of prerequisites, alternatives, or typical use cases. The schema mentions that history requires Gold tier, but the description does not clarify this usage constraint.

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

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

Annotations already indicate readOnlyHint=true, so the description does not need to repeat that. The description adds that the tool measures liquidity distribution across chains, which is useful but lacks detail on computation or data sources. It does not contradict annotations.

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

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

The description is a single short sentence, which is concise but may be too vague. It is front-loaded as a question but could be more informative without adding length.

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

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

With no output schema, the description should indicate the type of output (e.g., a number, array, etc.) but does not. It only says 'how broadly distributed', leaving the output format unclear. The tool has few parameters, but more context would help for usability among many siblings.

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

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

The single parameter 'days' is fully documented in the schema (100% coverage) with clear explanation of history vs snapshot and Gold tier requirement. The description does not add further parameter information, so baseline 3 is appropriate.

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

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

The description is a question that hints at measuring liquidity distribution across chains, but it lacks an explicit verb or declaration of what the tool returns. The title 'DeFi-Activity Breadth' provides some context, but the purpose is not clearly stated as a specific metric or function.

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

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

The description offers no guidance on when to use this tool or how it compares to siblings. The 'days' parameter description implies that history requires Gold tier and otherwise returns a snapshot, but there is no explicit advice on choosing this tool over alternatives.

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

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

Annotations already declare readOnlyHint=true, so the description adds no new behavioral insights. It does not mention authentication, rate limits, side effects, or what happens if the Gold tier requirement (mentioned only in the parameter schema) is not met. That requirement belongs in the description for 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 sentence, but its brevity sacrifices clarity. It omits important information such as output format, what 'momentum' means, and the Gold tier dependency. True conciseness would preserve necessary detail.

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

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

The tool has no output schema, so the description must explain the return value, but it does not. The parameter is optional, yet the description fails to clarify default behavior. The sibling list is large, and this description is insufficient to distinguish the tool or understand its complete functionality.

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

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

Schema documentation covers 100% of the parameter 'days' with clear constraints and usage. The description does not add extra meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description is phrased as a question ('How strong is developer momentum...') rather than stating an action. It vaguely indicates the tool assesses momentum for specific languages but does not specify what the tool returns (e.g., a metric, trend, or list). This lack of a clear verb and resource makes it hard for an agent to understand what the tool actually does.

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 any condition, prerequisite, or context for invocation. Given the large sibling list, this omission impedes correct tool selection.

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

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

Annotations already declare readOnlyHint=true, but the description adds no behavioral context (e.g., what data source, update frequency, or limitations). It contributes nothing beyond the structured fields.

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

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

The description is a single sentence, which is concise, but it is phrased as a question rather than a clear declarative statement. It is minimally 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?

With no output schema, the description should explain what the tool returns (units, geography, format). It does not, leaving the agent uncertain about the result. The description is incomplete for a tool with one optional parameter.

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

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

Schema coverage is 100%, so the parameter description already explains the 'days' parameter. The description adds marginal value by mentioning the Gold tier requirement, but baseline 3 is appropriate.

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

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

The title and description vaguely suggest querying renewable capacity growth, but the description is a question, not a clear verb+resource statement. It lacks specificity about what metric is returned or how it differs 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?

No guidance is provided on when to use this tool versus alternatives, nor any context about prerequisites or exclusions. The description does not help an agent decide when to invoke this tool.

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

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

Annotations declare readOnlyHint=true, but the description adds no behavioral insights. It fails to disclose what the tool returns (e.g., snapshot or history) or its reliance on Gold tier, which is only mentioned in the parameter schema. The description alone is insufficient.

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 (one sentence) but at the expense of clarity. It does not effectively convey the tool's purpose, making it under-informative despite its brevity.

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

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

Without an output schema, the description should clarify what the tool returns, but it does not. It only poses a question, leaving the agent unable to anticipate the tool's response or integrate it into a workflow.

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

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

Schema description coverage is 100%, so the baseline is 3. The tool description adds no parameter information beyond the schema, so it neither improves nor degrades parameter understanding.

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 is a vague question ('Are US climate-disaster costs trending above historical norms?') rather than a clear statement of what the tool does. It does not specify the action (e.g., 'returns trend data') or the resource, leaving ambiguity about the tool's output.

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 context, prerequisites, or exclusions, leaving the agent without decision-making support.

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

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

Annotations already declare readOnlyHint=true, so the description is not required to state that. It adds the behavioral context that the tool 'anticipates' shifts, but does not disclose output format, limitations, or other traits. Adequate but not rich.

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

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

Single sentence, 25 words, front-loaded with verb 'Enables'. Clear and efficient, though jargon 'volatility regime shifts' may obscure meaning slightly.

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

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

No output schema exists, yet the description does not explain what the tool returns or how to interpret results. The optional historical 'days' parameter is documented in schema but absent from description, leaving a significant gap for a complex tool.

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

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

Schema coverage is 100% for the single parameter 'days', with its own description. The tool description adds no additional meaning to the parameter, so baseline of 3 is appropriate.

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

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

The description uses a specific verb 'anticipate' and resource 'volatility regime shifts', clearly indicating the tool's purpose for traders. However, it does not differentiate from the many sibling tools, preventing 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?

No guidance on when to use this tool versus alternatives. The description implies use for volatility anticipation but lacks explicit when-to or when-not-to 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?

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds context about fat-tail risk detection but does not elaborate on behavioral traits like output format or limitations beyond what annotations provide.

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

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

The description is a single, concise sentence (19 words) that front-loads the purpose. Every word earns its place; no redundancy or filler.

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

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

For a read-only tool with one optional parameter and no output schema, the description adequately conveys the core purpose but omits what the output is (e.g., a signal or metric). The days parameter is only explained in the schema, not the description.

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

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

Schema description coverage is 100% for the single optional parameter 'days', so the baseline is 3. The tool description does not add extra meaning about this parameter; the schema already documents it thoroughly.

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 detects early-stage increases in fat-tail risk to prevent drawdowns, using specific verb+resource. However, it does not differentiate from sibling tools, which all have similar naming.

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 during market stress events but provides no explicit when-to-use or when-not-to-use guidance, nor alternatives among siblings.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds no additional behavioral context beyond the stated purpose, but does not contradict 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?

Single sentence with no redundancy. Every word adds value, front-loading the 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?

Despite simple schema and annotations, the description lacks completeness for a complex domain like cyclical volatility. No output format or interpretation hints are provided.

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

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

Schema coverage is 100% with a detailed description for the only parameter. The tool description does not add extra parameter semantics, so baseline 3 is appropriate.

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

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

The description states a specific verb ('Identify') and resource ('cyclical volatility regime shifts') with a clear benefit. However, the title 'Phase-Slope' is not explained, and the exact output is vague.

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

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

No guidance on when to use this tool versus siblings or alternatives. Does not provide when-not-to-use conditions 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?

Annotations already declare readOnlyHint=true, so the description carries less burden. It adds minimal behavioral context, only mentioning 'expanding volatility ranges' without explaining what that means operationally or any side effects. Does not contradict annotations.

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

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

The description is a single sentence, no unnecessary words. It is front-loaded with purpose. However, it could be more concise by stating the output format.

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

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

Without an output schema, the description should clarify what the tool returns (e.g., a list of assets, a ratio value). It only describes a high-level use case, leaving the agent unsure about the tool's functional boundaries. Incomplete for a 1-parameter tool with no output schema.

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

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

Schema coverage is 100% with one optional parameter 'days' fully described. The description does not add any additional meaning about parameters beyond the schema. Baseline 3 is appropriate as the schema carries the burden.

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

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

The description mentions 'identify assets with expanding volatility ranges' but does not specify what the tool actually computes or returns. It is somewhat vague, lacking a clear verb-resource pair. Not a tautology, but not specific enough to differentiate from many sibling 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?

It states 'to anticipate breakout opportunities and optimize entry timing,' which implies when to use. However, no guidance on when not to use or how it differs from other ADW tools. No alternatives mentioned, leaving the agent without clear selection 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?

The annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds context about the tool's analytical purpose and mentions 'statistically validated predictive power' but does not explain the output format, what the LTVR value represents, or any limitations. It provides some additional context beyond annotations but not substantial behavioral detail.

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

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

The description is a single, concise sentence that front-loads the core purpose. It is not overly long, but could be more structured with a clearer separation of what the tool does and its output. Still, it is efficient and to the point.

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

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

Given the lack of an output schema and the complexity of the tool (volatility regime detection), the description should explain what the tool returns (e.g., a ratio value, signal, or historical series). Without this, the agent cannot fully anticipate the tool's behavior. The mention of 'statistically validated' is vague and does not compensate for missing output details.

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

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

Schema coverage is 100%, with the 'days' parameter fully described in the schema. The description does not mention the parameter at all, so it adds no value beyond the schema. Baseline 3 is appropriate given the 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: identifying accelerating volatility regimes for traders to time entries or hedge. It uses specific financial terminology and mentions statistically validated predictive power, giving a clear sense of the tool's function. However, it does not differentiate from sibling tools, so it loses the 5 mark.

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 volatility regime detection in trading contexts but provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent has no information on when not to use it or how it compares to other 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?

Annotations already declare readOnlyHint=true, so the description's addition of purpose is helpful but does not disclose other behavioral traits like data source, performance, or limitations. Adequate but not rich.

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

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

The description is a single sentence that is concise and front-loaded with the action verb 'Capture'. However, it could be slightly more structured with explicit value proposition, but overall efficient.

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

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

Given the tool has only one optional parameter and no output schema, the description lacks completeness about return values, typical usage context, or examples. The parameter is explained in schema but the description does not integrate that context.

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

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

Schema coverage is 100% for the single 'days' parameter, which is well-documented in the schema. The description does not add any extra meaning about parameters, so baseline score of 3 applies.

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

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

The description clearly states the tool calculates Tail Mean Difference to capture non-linear return dynamics and identify asymmetric distributions. It implies differentiation from linear factor tools, but does not explicitly name alternative tools among the many siblings, so slightly less than perfect.

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

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

No explicit guidance on when to use this tool versus alternatives. The description mentions 'linear factors miss' but does not specify when-not-to-use or provide comparisons with 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?

Annotations indicate readOnlyHint=true, so the agent knows it is a safe read operation. However, the description adds no additional behavioral context beyond what annotations provide. It does not disclose output format, data freshness, or any side effects. With annotations covering the safety profile, the description contributes minimal value.

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

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

The description is a single sentence, making it concise. However, it is too brief and lacks structure such as clear action, input, and output. While front-loaded with a question, it does not earn its place as a helpful description because it omits essential details.

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

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

The tool has one optional parameter and no output schema. The description does not explain what the tool returns (e.g., a number, percentage, chart). Given the simplicity, the description is incomplete and leaves the agent guessing about the response format and interpretation.

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

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

Schema coverage is 100% for the single optional 'days' parameter, and its description in the schema already explains its purpose and constraints. The tool description does not add any further meaning about parameters, so it relies entirely on the schema. Baseline 3 is appropriate.

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

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

The description is a question 'Are large holders accumulating or distributing BTC?' which hints at assessing whale flow pressure, but it lacks a clear verb and resource. The title 'Crypto Whale-Flow Pressure' provides context, but the description does not explicitly state what the tool does (e.g., returns a metric, score, or indicator). It is somewhat vague and does not distinguish well from sibling adw tools.

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

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

No guidance is provided on when to use this tool versus other adw tools (e.g., adw.adw_001, adw.adw_005). There is no mention of prerequisites, alternatives, or specific use cases. The agent receives no help in deciding to invoke this tool.

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

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

Annotations already declare readOnlyHint=true, but the description adds no behavioral details (e.g., what the output represents, whether it's a snapshot or series, any limitations). It does not contradict annotations but fails to enrich them.

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

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

The description is extremely concise (one sentence), but this brevity sacrifices completeness. It is front-loaded but not optimally structured for quick 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?

With no output schema, the description should explain what the tool returns (e.g., a value, range, time series). It does not. The tool's simple nature still leaves gaps for an agent to interpret correctly.

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

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

Schema coverage is 100% with a single optional 'days' parameter already described in the schema. The description does not add any additional meaning or context about the parameter 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 is a question ('Is money flowing into or out of equities broadly?') which implies the tool provides an answer, but lacks a clear verb and resource. The title 'Equity Money-Flow Index' is more descriptive. Purpose is vague but not misleading.

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

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

No guidance on when to use this tool versus the many sibling tools. No mention of use cases, prerequisites, or alternatives. The description offers no context for selection.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=false, indicating a safe read operation. The description adds no additional behavioral context beyond what annotations provide. It does not disclose how 'calm' or 'stressed' is determined, any constraints, or side effects.

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, six words), but it sacrifices clarity for brevity. It does not earn its place as it is too vague to be useful. A concise but informative description would be better.

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 one optional parameter and no output schema, the description should explain what the tool returns (e.g., a stress indicator, history data). It lacks sufficient context about the output format or interpretation, making it incomplete for an agent to fully understand the tool's capabilities.

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

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

The schema coverage is 100% (the only parameter 'days' has a detailed description in the schema). The tool description itself does not mention parameters or add meaning beyond the schema. Baseline 3 is appropriate since the schema handles parameter documentation.

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 'Is the metals complex calm or stressed?' implies a status assessment but lacks a clear verb and resource. It is somewhat vague and does not explicitly state what the tool returns (e.g., a stress score or classification). The title 'Metals-Complex Stress' provides context, but the description does not add specificity.

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?

There is no guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, use cases, or when not to use it. It simply poses a question without directing the agent on appropriate invocation context.

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

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

Annotations already declare readOnlyHint=true. The description adds minimal behavioral context beyond that: it does not explain output format, data source, update frequency, or that the tool is a query. The parameter description reveals some functionality (history vs snapshot), but the main description contributes little.

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 short (one sentence), but it is a question rather than a clear, front-loaded directive. It lacks structure that helps an agent quickly grasp the tool's purpose. The conciseness is not effective because it omits crucial 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?

Given no output schema, the description should at least hint at the return value (e.g., a stress score or index) to complete the context. It does not. The tool is also part of a large sibling set with no differentiation, increasing the need for fuller description.

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

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

Schema coverage is 100% and the parameter description clearly explains the 'days' parameter (history mode, tier requirement). The main description adds no further parameter meaning, but schema already does the job, so 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 is a question ('How stressed is the global supply chain?') rather than an explicit action verb. It vaguely implies retrieving a stress indicator but lacks specific verb-resource structure like 'get stress index'. This obscures the tool's exact function for an AI agent.

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

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

No guidance on when to use this tool versus alternatives (many siblings). No mention of use cases, prerequisites, or exclusions. The only nuance is a tier requirement in the parameter description, but it is not framed as usage guidance.

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

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

The description adds no behavioral traits beyond the annotations (readOnlyHint=true). It does not disclose rate limits, auth needs, or what happens with the days parameter (the parameter's schema description covers that separately).

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

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

The description is very concise (one sentence) but lacks detail beyond the question. It is front-loaded but could be more informative without adding length.

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

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

Given the simple tool with one optional param and no output schema, the description does not explain return values or data format. It gives only a high-level purpose, leaving the agent to infer output structure.

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

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

Schema coverage is 100%, baseline is 3. The description does not add any parameter semantics; it does not mention the 'days' parameter or its effect.

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 'How active are major US metros right now?' clearly implies the tool returns current activity data for major US metro areas. It is specific about the resource (major US metros) and the temporal scope (right now), but does not distinguish 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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions. The description only implies usage via the question format.

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

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

The annotations already declare readOnlyHint=true, so the description does not need to re-state safety. However, the description fails to mention the key behavioral nuance that the 'days' parameter triggers a historical series (tier-dependent). No contradiction with annotations.

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

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

The description is a single sentence, front-loaded, and efficiently conveys the core purpose. However, it could be slightly more informative (e.g., making it a statement rather than a question). Minimal waste.

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

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

With one optional parameter, no output schema, and a simple purpose, the description is functional but lacks details such as the format of the density output (e.g., numeric scale) and the distinction between snapshot and history. It is adequate but not comprehensive.

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

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

The input schema provides 100% description coverage for the single optional parameter 'days', including its range and behavior. The tool description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description 'How dense is live US air traffic?' clearly indicates the tool returns a measure of air traffic density, but it is phrased as a question rather than a declarative statement. The verb is implied, and the resource is identifiable. However, it does not differentiate from sibling tools, and the tool name is opaque.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions. The description is minimal and does not help an agent decide when to invoke this tool over others.

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