Stratalize Finance

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds substantial behavioral transparency beyond that: it states the data source, the return payload (USD price, unit, observation period), the cost ($0.02 atomic), and the post-quantum signed settlement receipt with a verification URL. This gives a complete picture of what the tool does and its side effects, with no contradiction to annotations.

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

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

The description is compact, consisting of three sentences. The first sentence states the core function, the second lists return values and use cases, and the third covers source, cost, and attestation. Each sentence carries relevant information for an agent, with no filler. It is slightly dense but well-structured and front-loaded with the primary purpose.

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

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

For a simple read-only tool with one parameter, annotations, and no output schema, the description is nearly complete. It covers what the tool does, why to use it, what data it returns, the source, cost, and verification mechanism. It does not describe the exact response format or mention rate limits, but these are not essential given the simplicity and available annotations. Overall, it leaves little ambiguity.

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

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

The schema has one required parameter with an enum for the five commodities. The description lists those same commodities, which matches the enum, but adds little beyond the schema. It does add context about what the return includes (USD price, unit, observation period), indirectly giving meaning to the parameter, but the parameter itself is fully specified by the schema. Since schema coverage is 0%, the description partially compensates but does not provide deep semantic additions.

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 retrieves spot agricultural commodity prices for five specific commodities (soybeans, wheat, corn, cotton, coffee) from FRED/IMF data. It uses a specific verb (retrieves) and resource (agricultural commodity price), and narrows the scope enough to distinguish it from the broader sibling tool get_commodity_benchmark.

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

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

The description provides clear usage context by listing concrete use cases (crop hedging, food cost modeling, trade exposure agents) and identifies the data source (FRED/IMF). It does not explicitly exclude alternatives or mention when not to use the tool, but the focused scope and use cases give enough guidance for an agent to 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 and destructiveHint=false, so the safety profile is covered. The description adds meaningful context about the specific data domains included (FinCEN, OFAC, BSA, travel rule, staffing), which goes beyond the annotations and helps the agent understand the tool's scope. However, it does not disclose return format or potential limitations, which would warrant a 5.

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

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

The description is a single, concise sentence that front-loads the key concept ('AML regulatory benchmarks') and efficiently lists content areas and audience. No wasted words or redundant information.

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

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

The tool has two optional enum parameters and no output schema. The description provides a good high-level overview of the data content, but it lacks parameter explanations and usage guidance relative to sibling tools. Given the moderate complexity and the absence of an output schema, the description is adequate but leaves clear gaps in parameter semantics and usage 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 description coverage is 0%, so the description carries the burden for explaining the parameters. It does not mention 'focus' or 'institution_type' at all, leaving the agent to rely solely on the enum names in the schema. While the enum values are somewhat self-explanatory, the description adds zero value for parameter understanding, making this a notable gap.

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

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

The description clearly identifies the tool as providing AML regulatory benchmarks and lists specific data categories (FinCEN SAR filing rates, OFAC SDN counts, BSA enforcement fines, travel rule thresholds, compliance staffing). This distinguishes it from sibling benchmark tools like get_bank_regulatory_benchmark by focusing on AML-specific content.

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 a target audience ('For compliance agents and financial institution risk officers') but provides no guidance on when to use this tool versus alternatives. It does not state exclusions, prerequisites, or compare it with other regulatory benchmark tools, leaving the agent to infer usage from the name and content list.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful behavioral context by stating the data source ('Audit Analytics public aggregate data'), which informs the agent about data provenance and that data is aggregate rather than company-specific. It does not describe return format, but the core side effects are covered.

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

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

The description is compact: two functional sentences and one contextual sentence. It front-loads the primary use case, then defines the output, and ends with data source and audience. No redundant words or repeated schema information.

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

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

For a read-only benchmark tool with 3 parameters and no output schema, the description covers most essentials: purpose, output metrics, dimension breakdown, and data source. Minor gaps remain, such as the meaning of the 'industry' parameter and how revenue bands are defined, but overall it is sufficiently complete for an agent to invoke it correctly.

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

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

Schema description coverage is only 33% (only annual_revenue_usd is described). The description compensates for two of the three params by explaining that benchmarks are 'by company revenue band and auditor tier', directly mapping to annual_revenue_usd and auditor_tier. However, the 'industry' parameter is left unexplained, and the description does not fully cover the schema's undocumented fields.

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

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

The description clearly specifies the tool's purpose: benchmarking audit costs, with concrete output metrics (total fees and fees as a percentage of revenue) broken down by revenue band and auditor tier. It uniquely identifies this as audit-specific among the many benchmark tools in the sibling list, distinguishing it from other get_*_benchmark 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 explicitly states when to use the tool ('Use when benchmarking audit costs, evaluating auditor proposals, or preparing an audit committee RFP'). It does not mention when not to use it or point to alternatives, but the use cases are clear and contextually sufficient.

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

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

With annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds valuable context: it specifies the data source (FDIC BankFind synced call report data), the metrics returned (assets, deposits, capital ratios, loan quality, peer positioning), and provides an illustrative example with numeric thresholds and interpretation clarity. This goes beyond the annotation hints without contradicting 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 four sentences, each earning its place: a use-case opening, a concise list of return metrics, a concrete example with embedded interpretation, and a data-source attribution. No unnecessary filler, and the most important action-oriented phrase is front-loaded.

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

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

Given the tool's low complexity (single required parameter, no output schema), the description is exceptionally complete. It explains when to use it, what data it returns, provides an example with realistic values, and identifies the underlying data source. The absence of an output schema is compensated by the detailed example and metrics enumeration.

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 bank_name, with examples like 'JPMorgan, Wells Fargo, First National Bank.' The description does not add additional parameter semantics beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description clearly states the tool evaluates a bank for acquisition, partnership, correspondent banking, or competitive analysis, and enumerates the returned data: assets, deposits, capital ratios, loan quality, and peer benchmark positioning. This distinguishes it from siblings like get_bank_regulatory_benchmark, which focuses on regulatory benchmarks rather than comprehensive financial intelligence.

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

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

The description explicitly says 'Use when evaluating a bank for acquisition, partnership, correspondent banking, or competitive analysis in a local market,' providing clear context for when to invoke. However, it does not mention when not to use it or name specific alternatives among the many 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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds useful context by citing the FDIC call report as a public data source and listing the benchmark metrics, but it does not describe return format, pagination, or other behavioral details, offering only modest 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 two sentences and roughly 30 words. It front-loads the core purpose and metrics, then adds source and audience. Every phrase adds value; there is 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?

Combined with the input schema and annotations, this description provides enough context for tool selection: domain, metrics, asset-size tiering, and data source. It does not explain the return shape, but no output schema is present and the metric list gives a reasonable picture for a read-only benchmark tool. It could be improved by naming sibling alternatives.

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 0%, so the description must compensate, but it only references 'by asset size tier,' which maps to the required parameter. It does not explain the enum values (e.g., community_under_1b) or the optional bank_type parameter, leaving parameter semantics under-specified beyond the schema's enum names.

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

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

The description opens with 'Bank regulatory capital and financial performance benchmarks' and enumerates specific metrics (CET1, Tier 1 leverage, NIM, efficiency ratio, charge-off rates, loan-to-deposit ratio) 'by asset size tier.' This clearly establishes the tool's scope and differentiates it from sibling tools like credit union or AML benchmarks.

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 explicit when-to-use guidance or mentions of alternatives. The target audience ('bank CFOs, risk officers, bank analysts') implies a use case, but it does not explain when to choose this tool over close siblings like get_bank_financial_intelligence or get_credit_union_benchmark.

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 destructiveHint=false, so the read-only nature is known. The description adds valuable context: it reveals the output contains year-over-year CPI percentages (via the example), highlights data divergence patterns (medical care and housing vs headline), and states the data source (BLS CPI). This goes beyond what annotations provide, though it does not specify pagination or return format.

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 paragraph of four sentences. It front-loads the use cases and then provides a concrete example and source. Every sentence carries useful information, but it is longer than strictly necessary for a simple one-parameter tool, with some redundancy in the use-case list.

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

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

For a simple, one-parameter, read-only tool with no output schema, the description is quite complete: it gives use cases, an illustrative example of the output, and the data source. It does not explicitly describe the return structure (e.g., a percentage value for the selected category), but the example strongly implies it. Overall, the context is sufficient for basic usage.

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

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

The schema has one parameter (category) with an enum but no description coverage (0%). The description references 'spending category' and gives examples for medical care and housing, which hints at the category parameter. However, it does not explain the available enum values or the default (all_items), and the mapping between the parameter and the returned component is only implicit. The enum names are self-explanatory, so moderate compensation, but it could be more explicit.

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 tool's purpose is implied through its name and description: it provides BLS inflation data by spending category. The description mentions 'analyzing inflation exposure by spending category' and uses examples like 'Medical care CPI +3.8% YoY vs headline CPI +3.1%', which clearly point to category-level CPI components. However, it never states a direct verb+resource definition (e.g., 'Gets inflation components for a given category'), and sibling tools like get_inflation_benchmark are not explicitly differentiated.

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

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

The description explicitly lists several use cases: analyzing inflation exposure, structuring vendor contract escalation clauses, benchmarking healthcare/real estate cost inflation, and monetary policy briefs. This gives clear context for when to use the tool. However, it does not mention when not to use it or suggest alternative tools such as get_inflation_benchmark, so it stops short of the full 'when/when-not/alternatives' guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context: it names the data source (BLS Current Employment Statistics), coverage (650,000 US worksites), and notes the Fed uses the same data. It also gives an example of the returned metrics (MoM, YoY, trend). This exceeds the minimal annotation coverage.

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

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

The description is a single paragraph but well-structured: usage cases, output description, example, and source. It is somewhat lengthy but every sentence adds value, especially the example illustrating the output format. It is not overly 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?

There is no output schema, so the description covers the return values (employment, MoM, YoY, trend classification) and provides an example. It also gives source and use cases. For a one-parameter enum tool, this is largely complete, though it could clarify the exact response 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 0%, and the description does not explain each enum value. However, it does mention 'major sector' and provides a healthcare example, adding partial meaning. The parameter is a simple enum of sector names, so the description partially compensates for the missing schema descriptions.

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

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

The description clearly states it 'Returns BLS payroll employment by major sector with month-over-month change, year-over-year change, and trend classification.' It specifies the resource (BLS sector employment data) and distinguishes it from sibling tools by focusing on sector-specific labor market 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 opens with explicit use cases: 'benchmarking workforce planning against sector labor market conditions, assessing industry growth trajectory for strategic planning, providing economic context for board reporting, or evaluating talent acquisition timing.' It does not explicitly mention when not to use or alternatives, but provides clear 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 mark the tool as read-only and non-destructive. The description adds meaningful context by detailing the nature of the output (rollups by company/product) and the data source (CFPB Consumer Complaint Database). It goes beyond the annotation baseline, though it doesn't cover pagination or response formats.

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

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

The description is three information-dense sentences: when to use, what it returns, and a concrete example. Every sentence adds value, and the example makes the purpose immediately understandable. 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?

The description covers the tool's use cases, output content, and provides an example, which suffices for a moderately complex tool with no output schema. It lacks details on filtering behavior beyond product and data limitations, but the example and source mention provide adequate 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?

With schema description coverage at 0%, the description must compensate for missing parameter semantics. It mentions 'by company and product' and gives an example using company_name, but does not explain parameter constraints, optionality, or accepted values. This is partial compensation.

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

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

The description clearly states the tool returns CFPB complaint rollups by company and product, including volume, issue themes, and response rate trends. It includes a concrete example that illustrates the output. This distinguishes it from sibling benchmark tools by focusing on consumer complaint 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 explicitly lists when to use the tool: assessing consumer finance risk, benchmarking complaint volume, or pre-acquisition due diligence. It does not mention when not to use it or name competing alternatives, but the context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat safety. It adds contextual behavior by disclosing data provenance (FEMA NFIP and NGFS scenarios) and the scope of risk categories. This is valuable context beyond the structured fields, though it doesn't discuss rate limits or return formats.

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

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

The description is three sentences, all informative. It front-loads the core purpose, then adds sources and audience. No filler or redundant information—every sentence earns its place.

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

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

With no output schema, the description should explain what the agent receives. It gives a solid overview of the dataset's content (risk types, sources, lender implications) but does not mention response format, default behavior when no parameters are provided, or how multiple risk types are structured. This is adequate for a simple benchmark tool, 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 schema provides enums for region, risk_type, and property_type, but the description only partially compensates for 0% schema_description_coverage. It elaborates on risk_type by defining physical and transition with examples, helping the agent select appropriate values. However, it does not explain the region or property_type parameters nor their default behavior, leaving some gaps.

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

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

The description clearly identifies the tool's purpose: providing climate financial risk benchmarks. It specifies the resource (climate risk), the categories (physical and transition risk), and even gives examples (flood, hurricane, carbon pricing) and sources (FEMA NFIP, NGFS). It distinguishes from sibling tools by focusing explicitly on climate risk rather than generic ESG or other benchmarks.

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

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

The description states the intended audience and use case: 'For ESG and risk agents.' It implicitly signals that this is the tool for climate-related risk benchmarks, setting it apart from generic ESG or financial benchmarks. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so it falls short of a 5.

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

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

The description discloses valuable behavioral context beyond the readOnlyHint/destructiveHint annotations: it names the upstream source (FRED), update frequency (daily), failure behavior (HTTP 503 with no charge, with a specific threshold '>50% of fields'), cost ($0.10 USDC), and the provenance field (data_source: fred_api/fred_csv/fred_mixed). 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 moderately concise but contains redundancy: the HTTP 503 (no charge) clause appears twice in slightly different forms, and 'Live source' is repeated near the 'Live commodity price benchmarks' opener. The structure front-loads the core purpose, but the extra detail could be tightened.

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 enum parameter and no output schema, the description is fairly complete. It covers data source, update frequency, target audience, failure behavior, cost, and hints at response content (weekly/monthly changes, inflation signal, data_source field). It lacks an explicit description of the return structure, but given the low complexity, the gap 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?

The schema has one optional parameter 'category' with an enum (energy/metals/agriculture/all), but the description does not explain how this parameter affects the response. It lists example commodities from different categories but never directly maps the 'category' parameter to filtering behavior. With schema description coverage at 0%, the description should compensate, but it fails to do so.

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

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

The description clearly identifies the tool as providing live commodity price benchmarks for a specific set of commodities (WTI crude, natural gas, gold, copper, wheat, soybeans) plus weekly/monthly changes and an inflation signal. It is a specific verb+resource+scope, but it does not explicitly distinguish itself from siblings like get_copper_price_benchmark or get_agricultural_commodity_benchmark.

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 ('For traders and macro analysts') and lists the specific commodities covered, which implies usage scenarios. However, it does not explicitly state when to use this tool versus sibling tools, nor does it mention when not to use it. The guidance is implied rather than explicit.

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

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

Annotations already declare read-only and non-destructive, but the description adds significant behavioral context: live data source, HTTP 503 with no charge when upstream data is unavailable, a $0.10 USDC per-call SLA, and a data_source field for provenance. This goes well beyond annotation coverage and provides agents with critical failure and cost information. 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 front-loaded with a clear purpose, but it repeats the HTTP 503 no-charge behavior twice: once with '>50% of fields' and once as 'when upstream data sources unavailable.' This redundancy is unnecessary and reduces 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?

Given the tool's simplicity (one optional parameter, no output schema), the description covers data sources, usage context, failure modes, cost, and provenance. It hints at output via 'Strong/moderate/weak consumer signal' but does not detail the response structure. Sibling tools follow a similar pattern, so the missing output schema details are less critical.

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 has a single optional parameter 'focus' with enum values, but the description's schema coverage is 0%. The description lists sentiment, spending, and saving categories that map to the enum values, giving indirect meaning. However, it does not explicitly explain how the 'focus' parameter affects the output, leaving the mapping implicit.

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

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

The description clearly identifies the tool as providing live consumer sentiment benchmarks from FRED, enumerating specific indicators (University of Michigan sentiment, Conference Board confidence, retail sales, PCE, personal saving rate). This distinguishes it from sibling tools that focus on individual benchmarks (e.g., get_personal_savings_benchmark, get_retail_sales_benchmark).

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

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

The description provides clear context for when to use the tool: 'Strong/moderate/weak consumer signal for GDP and equity agents.' It implies that this aggregate benchmark is appropriate for broad economic analysis, while sibling tools cover individual metrics. However, it does not explicitly state when not to use it or name 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 and destructiveHint=false. The description adds valuable behavioral context beyond annotations: source (FRED/IMF), atomic cost ($0.02), cryptographic attestation with a post-quantum signed receipt, and a verification URL. This goes beyond the schema and annotations, though it does not detail response structure or rate limits.

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

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

The description is concise and front-loaded: it starts with the core deliverable (price + YoY change), then usage context, source/cost, and attestation. Every sentence earns its place, with 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?

With no output schema, the description adequately covers what the tool returns (price, YoY change, industrial demand note), along with provenance, cost, and how to verify authenticity. This is sufficient for a zero-parameter benchmark tool.

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

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

The tool has zero parameters, and the schema is empty, so the baseline of 4 applies. The description does not need to explain parameter semantics, and it doesn't introduce confusion.

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

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

The description clearly identifies the tool as returning the IMF Grade A copper price in USD per metric ton with year-over-year change and an industrial demand significance note. This specific resource and metric distinguish it from sibling tools like get_commodity_benchmark or get_agricultural_commodity_benchmark.

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

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

It provides an explicit usage context: 'Use as a coincident indicator for global manufacturing and construction cycles.' However, it does not mention when not to use it or name alternative tools, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about the source (S&P Capital IQ, Damodaran), the metrics provided, and the target users (CFOs, treasurers), which goes beyond the annotations. No contradictions found.

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 tight and front-loaded with usage guidance. It uses three sentences to convey purpose, content, source, and audience—no fluff or repetition.

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 provides enough content detail (metrics) to set expectations. It covers use cases, source, and audience, which is complete for a read-only benchmark tool. It lacks caveats about data freshness or limitations, but that is not critical given the annotations.

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 0%, so the description must compensate. It mentions 'by credit rating tier and industry', mapping to the two parameters, but does not explain enum values or how to use them. The schema's enums are self-explanatory to a degree, but the description offers minimal added meaning beyond indicating the dimensions.

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 its purpose: assessing company debt capacity, benchmarking leverage against sector peers, and preparing refinancing or credit rating discussions. It names specific metrics (Net Debt/EBITDA, interest coverage, debt maturity profiles) and differentiates from siblings by focusing exclusively on corporate debt benchmarks.

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?

Provides clear context: 'Use when assessing a company debt capacity, benchmarking leverage against sector peers, or preparing a refinancing or credit rating discussion.' It does not explicitly name sibling alternatives or state when not to use, but the use cases are specific enough to guide 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 and destructiveHint, and the description adds meaningful behavioral context such as HTTP 503 error handling when upstream sources are unavailable, the x402 SLA cost, and the data_source provenance field. It does not contradict the annotations, though it stops short of detailing the complete success response 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?

The description is fairly detailed and front-loads the main content, but it contains redundant error messaging: 'Returns HTTP 503 (no charge) if upstream source unavailable for >50% of fields' is repeated in slightly different words later. This redundancy makes it less concise than it could be.

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 provides a good overview: it lists the data series returned, update frequency, source, error behavior, pricing, and provenance field. It is not exhaustive, but it is sufficiently complete for an agent to invoke the tool correctly.

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

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

With schema description coverage at 0%, the description must clarify the single parameter. It mentions 'OAS by rating tier' which relates to rating_tier, but it does not explain the enum values (all, ig, hy, bbb) or how the parameter affects other metrics like TED spread and 2s10s. The enum is somewhat self-explanatory, but the description does not fully compensate for the lack of schema 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 clearly states the tool provides live investment-grade and high-yield credit spread benchmarks from FRED ICE BofA indices, listing specific metrics (OAS by rating tier, TED spread, 2s10s Treasury spread, distress signal). It distinguishes itself from sibling benchmark tools by focusing on credit spreads and targeting credit analysts and fixed income PMs.

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

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

The description provides clear context for when to use the tool: for credit analysts and fixed income PMs, with daily updates and a live source. However, it does not explicitly mention alternatives or when not to use this tool, which prevents a higher score.

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 destructiveHint=false, so the safety profile is clear. The description adds value by disclosing the source (NCUA public data) and the specific metrics covered, giving context about what the tool returns without needing to restate the annotations.

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

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

Two concise sentences that front-load the primary purpose, follow with the source, and end with the target audience. No filler or redundant 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 description is sufficient for an agent to understand the tool's niche, but omits any explanation of output structure, time periods, or how to interpret the benchmarks. With no output schema and 0% parameter coverage, the description could do more to round out the agent's understanding, though it covers the core purpose well overall.

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 0% and the description only mentions 'by asset size', which relates to asset_size_tier but provides no detail on charter_type. The enum values in the schema are self-explanatory, but the description does not compensate for the lack of parameter descriptions 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 clearly states the tool provides credit union financial performance benchmarks with specific metrics (capital ratios, net interest margin, etc.) and identifies the data source. However, it does not explicitly differentiate from the sibling get_ncua_credit_union_financials, relying on the 'benchmarks' framing.

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 gives a concrete use case ('CFOs preparing for NCUA exams and board reporting') which implies when to use it, but offers no exclusions or comparisons to alternative benchmark tools. The context is present but not explicit about when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context beyond this by specifying the data source (SEC EDGAR aggregate + Sloan accruals model) and the risk components included. It does not contradict annotations and enhances understanding of the tool's 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 concise and well-structured: two sentences that front-load the core purpose, then add source and target audience. Every sentence earns its place with no redundancy.

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

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

The description explains the purpose and context well but lacks details on return values (no output schema) and does not describe the 'revenue_recognition_model' parameter. For a moderate-complexity benchmark tool, it is adequate but leaves key usage details unaddressed.

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 0%, but the description mentions 'by sector', which aligns with the required 'sector' parameter. However, it does not explain the 'revenue_recognition_model' parameter at all, leaving its meaning and usage unclear despite the schema enums. Partial compensation for one parameter only.

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 resource: 'Earnings quality and financial statement risk benchmarks' with specific components (accruals ratio, cash conversion, revenue recognition risk) and sector focus. It distinguishes from sibling tools by emphasizing financial reporting risk benchmarks, though it lacks an explicit verb like 'retrieves' or 'lists'.

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

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

The description provides clear context on when to use this tool: 'For CFOs, auditors, and analysts assessing financial reporting risk before M&A or investment.' It does not explicitly mention alternatives or when not to use it, but the target audience and scenarios are well defined.

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 destructiveHint=false, and the description adds meaningful context by noting the dependency on 'when EIA API is configured' and naming the source as 'US Energy Information Administration.' It also gives example return values, though it doesn't specify frequency or data vintage beyond the example.

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

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

The description is three sentences: a usage statement, a returns statement, and an example with source attribution. It is efficient and front-loaded, though the example could be trimmed without losing much value; still, the extra context supports the use case.

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

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

For a zero-parameter snapshot tool with no output schema, the description covers purpose, exact data returned, example values, API dependency, and source. It is mostly complete, though it doesn't mention whether prices are delayed or real-time, or how often they update.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter-related information, but none is needed since the input schema is complete and empty.

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

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

The description clearly states the tool's purpose: 'Use when current energy price data is needed' and specifies the exact output: 'Returns WTI crude and natural gas spot prices'. This distinguishes it from sibling benchmark tools by focusing specifically on energy spot prices, with a concrete example in the description.

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?

Provides explicit context for when to use: 'for a commodity brief, input cost analysis, or energy sector context in a CFO or investment brief.' It does not explicitly exclude alternatives, but the context is clear enough to guide selection among the many sibling benchmark 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 and destructiveHint=false. The description adds valuable behavioral context by enumerating the exact output fields (wave position, degree, target high/low, invalidation, confidence) and asset coverage (BTC, SPY, TLT, Gold), going 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?

Three sentences with front-loaded usage guidance, return summary, and a concrete example. Every sentence adds value without padding, making it both concise and logically ordered.

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 having no output schema, the description fully explains what data will be returned and for which assets. It also states the default behavior implicitly (all assets via 'all' parameter). The tool is simple, and the description covers all necessary context for an agent to select and invoke it correctly.

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

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

The schema already fully describes the sole parameter 'asset' with 100% coverage. The description lists example assets, which mildly reinforces possible values, but does not add meaning beyond the schema's 'Asset symbol or all' note. 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 identifies the tool as returning Elliott wave data (wave counts, targets, invalidation) for specific assets (BTC, SPY, TLT, Gold). It uses specific verbs ('Returns') and distinguishes itself from sibling benchmark tools by focusing on technical analysis for these named assets.

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 opening phrase 'Use when a technical trader needs...' provides explicit context for when to invoke this tool. It does not exclude alternatives or name sibling tools, but the use case is clearly defined and distinct from other data retrieval 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 and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the data source (BLS ECI), the cost ($0.10 standard), and the cryptographic attestation and verification process. This goes beyond minimal safety disclosure and informs the agent of trust and contractual aspects.

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

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

The description is three sentences, each earning its place: the first states the data content, the second gives usage context, and the third provides provenance and verification. It is front-loaded with the core meaning, and there is no wasted verbiage.

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

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

With zero parameters and no output schema, the description still tells the agent exactly what the tool returns (year-over-year change for three compensation components) and when to use it. It also covers source, cost, and verification, making it complete for an agent to invoke and trust the result.

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

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

The tool has zero parameters, so there is no parameter burden to compensate. The schema coverage is 100% (empty schema), and the description explains what the retrieved data are, making parameter semantics unnecessary. Baseline for 0 params is 4, and the description meets that.

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

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

The description clearly states the tool provides BLS Employment Cost Index year-over-year change for total compensation, wages, and benefits. It uses a specific noun phrase that identifies the exact data product, and the specificity distinguishes it from sibling tools like inflation benchmark or labor market benchmark.

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

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

The description explicitly says 'Use when modeling labor cost inflation, contract escalation, and margin pressure in operating plans,' giving clear use cases. It does not explicitly mention when not to use or alternatives, but the provided context is strong and sufficient for an agent to select this tool appropriately.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful behavioral context by specifying data sources (EPA GHGRP, MSCI ESG methodology) and the exact metrics included. However, it does not disclose aggregation details, time periods, or potential data caveats.

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

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

The description is two sentences, front-loaded with the core purpose ('ESG benchmarks by sector'), and every phrase adds value. No filler or redundancy.

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

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

For a read-only benchmark tool with two optional enum parameters, the description covers the subject matter and intended audience. However, it omits details about output format, units, or how to combine parameters, which would be helpful given no output schema exists.

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

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

Schema coverage is 0%, so the description must compensate. It partially does by listing metric areas that map to the focus parameter (carbon, social, governance) and stating 'by sector' for the sector parameter. However, it does not explicitly explain how parameters filter or describe the meaning of each enum option.

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

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

The description clearly identifies the resource as ESG benchmarks by sector and lists specific metrics (carbon intensity, net zero commitments, SBTi alignment, board independence, pay equity, ESG composite scores). It distinguishes from sibling tools by focusing on ESG specifics and naming sources. However, it lacks an explicit verb like 'retrieves', relying on the tool name for the action.

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

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

The description states a target audience ('for sustainability agents and ESG analysts') but provides no explicit guidance on when to use this tool vs the many sibling benchmark tools. It does not mention alternatives, exclusions, or decision 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 and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by characterizing the output as 'illustrative' and a 'scenario planning tool', plus an example conditioned on fed funds and CPI. This goes beyond annotations with important caveats about what the numbers represent, though it does not mention data freshness or potential volatility.

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 tightly written: three sentences covering use case, return value, caveat, plus one illustrative example and source. Every sentence adds distinct value; no filler or redundant phrases beyond minor overlap between 'illustrative' and 'scenario planning tool'. It is front-loaded with the primary usage trigger.

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

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

For a zero-parameter, no-output-schema tool with read-only annotations, the description is remarkably complete. It clarifies the purpose, use case, nature of the results (illustrative, not market-implied), provides an example output for shape, and cites the data source. There is no ambiguity about what the tool returns or when to employ it.

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

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

The tool has zero parameters, so no parameter documentation is needed. The description provides all necessary input context by explaining the data source and example conditioning. This aligns with the baseline expectation for no-parameter tools.

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

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

The description states a specific action ('Returns illustrative cut, hike, and hold probabilities for the next three FOMC meetings') with a clear resource and basis ('current FRED fed funds data'). It distinguishes itself from sibling benchmark tools by focusing on FOMC probability estimates and explicitly notes it is not futures-implied odds, which prevents confusion with market-data tools.

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

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

The description opens with an explicit when-to-use statement ('Use when providing monetary policy narrative context for a macro brief, investment committee, or CFO rate planning session'). It also includes a clear exclusion ('not futures-implied market odds'), but does not name an alternative tool or state 'do not use for...'. This meets the 'clear context, no exclusions' threshold.

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 substantial context beyond the readOnlyHint annotation: it discloses the data source (FRED), update frequency (daily), pricing (x402 SLA), failure behavior (503 when upstream unavailable), and the data_source field. This exceeds the baseline expectations for a read-only tool.

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

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

The description is dense but information-rich. It front-loads the main content and includes important operational details. Minor redundancy exists around the 503 and SLA mention, but every sentence adds value.

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

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

The tool has no output schema, so the description partially compensates by listing the data fields (pairs, changes, data_source). However, it does not specify the exact response format or units. For a simple tool with one optional parameter, the coverage is nearly complete.

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

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

The schema has one optional parameter (base_currency) with enum values, but schema description coverage is 0%. The description does not explain what base_currency does or how it affects the results, leaving the agent to infer from the enum values alone. This is a significant gap.

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

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

The description clearly specifies the resource: live major currency pair benchmarks, listing concrete pairs and indices (USD/EUR, USD/JPY, etc.), source (FRED), and update frequency. It distinguishes from sibling benchmark tools by focusing on FX rates.

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

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

The description implies this tool is for FX rate benchmarks, but it does not explicitly state when to use it versus alternatives. No exclusions or alternative tool references are provided, so the guidance is only implied.

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 substantial behavioral context: live data source, HTTP 503 with no charge when upstream is unavailable, the x402 SLA cost, and the data_source field disclosing provenance. It also mentions the risk-on/risk-off signal as an output. This goes beyond the annotations and provides valuable operational details.

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

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

The description is front-loaded with the core content and then includes operational details separated by a pipe. However, the HTTP 503 behavior is stated twice in redundant terms, adding unnecessary length. The structure is acceptable but could be tighter.

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 covers the indices, metrics, failure behavior, cost, and data provenance, providing a solid understanding of the tool's capabilities. The main gap is the lack of clarity about the region parameter's effect on the returned data, which is a notable omission. Overall, it's fairly complete for the tool's 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?

The input schema has one parameter (region) with an enum but zero description coverage. The description does not mention the parameter at all, so it fails to explain how to use the region filter or what each enum value returns. This is a complete miss for parameter semantics, as the description must compensate for the 0% 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 identifies the resource as global equity index benchmarks, listing specific indices and metrics (YTD returns, P/E ratios, risk-on/risk-off signal). This distinguishes it from other benchmark tools that focus on commodities, credit, or other asset classes. However, it lacks an explicit verb like 'retrieves' or 'provides,' instead using a noun phrase, 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?

The description conveys the content domain (global equities) and the signal it provides, implying when it would be used. It does not explicitly state when to use this tool instead of alternatives, nor does it mention exclusions or alternate tools. The sibling list provides indirect differentiation, but the description itself lacks direct guidance.

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

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

Annotations already declare this as a safe read-only operation, so the bar is lower. The description adds useful behavioral context: it notes the data is a 'static composite' with 'semi-annual update' and provides an example of the output values, which informs the agent about the nature and freshness of the data. 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 concise and front-loaded with the primary usage guidance. Four sentences cover usage, return content, an illustrative example, and source/update frequency without redundancy. Every sentence contributes value, earning a top score.

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

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

For a zero-parameter tool with no output schema, the description fully explains what data is returned, provides a concrete example, notes the update cadence and source, and gives clear use-case scenarios. This is complete for the agent to invoke and interpret the result appropriately.

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

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

There are zero parameters, so schema coverage is trivially 100%. The description compensates by explaining what the tool returns (GDP growth, inflation, current account balance by country group) and gives an example of the data format, which adds meaning beyond the empty schema.

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

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

The description clearly states a specific action ('Returns IMF WEO macro composites') and identifies the resource (IMF WEO) and the specific metrics (GDP growth, inflation, current account balance by country group). It distinguishes itself from sibling tools by focusing on global macro context and country-group aggregates, which is unique among the listed benchmarks.

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

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

The description explicitly specifies when to use the tool: 'when providing global macro context for an international expansion brief, country risk assessment, or board-level economic outlook presentation.' It does not mention alternatives or exclusions, but the use cases are clearly identified, giving the agent strong guidance on appropriate invocation.

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

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

Beyond the readOnlyHint annotation, the description discloses important behavioral details: the live source, HTTP 503 behavior with no charge when upstream data is unavailable, the cost per call ($0.10 USDC), and the data_source field for provenance. This adds substantial value beyond the annotations.

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

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

The description is front-loaded with core content but contains redundancy: the 503 behavior is stated twice. It also includes some necessary details (cost, provenance) but could be more concise. Overall structure is adequate but not tight.

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 and no output schema, the description covers the essential aspects: what data is returned, the source, cost, failure mode, and provenance field. It lacks an explicit description of the return format, but the listed content and the data_source field give reasonable completeness.

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

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

The schema has one optional 'measure' parameter with enums, but the description does not explain how to use 'measure' or what each enum value maps to. With 0% schema description coverage, the description fails to compensate by clearly mapping the listed indicators (CPI, PCE, breakeven, etc.) to the parameter values, leaving ambiguity.

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

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

The description clearly identifies the tool's purpose: 'Live inflation benchmarks from FRED' with a specific list of indicators (CPI, PCE, breakevens, components). It also implicitly distinguishes from siblings like get_bls_inflation_components by specifying FRED as the source and the types of measures.

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

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

The description provides clear context for when to use the tool (when live FRED inflation benchmarks are needed) and notes the live source and policy implications. However, it does not explicitly state when not to use it or name alternative sibling tools, so usage guidance is more implied than explicit.

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 destructiveHint=false, so the agent knows it's a safe read operation. The description adds the data source (NAIC annual statistical report) and metric scope, but does not disclose other behaviors like output format or pagination. This is acceptable given annotation coverage, so a neutral score of 3.

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

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

The description is three short, information-dense segments, front-loaded with the core purpose. It avoids redundancy and every sentence adds context (scope, source, audience).

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 benchmark tool with only two parameters and no output schema, the description covers the essential aspects: what (metrics), how (by line of business), where (NAIC source), and who (insurance professionals). It doesn't describe the exact return structure, but that's less critical with no output schema and a clear data product.

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 has zero description coverage, so the description carries the burden. It explains that benchmarks are broken down by line_of_business and lists the metrics returned, but it does not describe the company_size parameter at all. The enum values are self-explanatory, but a full parameter description is missing.

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

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

The description clearly identifies the tool as providing insurance financial performance benchmarks, enumerates the specific metrics (combined ratio, loss ratio, expense ratio, reserve adequacy), and distinguishes it from sibling industry benchmarks by specifying the insurance domain. While it lacks a verb, the tool name 'get' plus the description makes the purpose unambiguous.

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

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

The description states the target audience and use case ('For insurance CFOs, actuaries, and analysts reviewing underwriting performance'), giving clear context. It does not explicitly name alternatives or exclusions, but the insurance-specific framing implicitly differentiates it from sibling benchmark 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 and destructiveHint=false. The description adds useful behavioral context beyond this: source (BLS JOLTS), cost ($0.10), cryptographic attestation, and a verification URL. This is more than just restating safety hints and enriches the agent's understanding of reliability and cost.

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

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

Three sentences, each earning its place. The opening line immediately conveys the core purpose and metrics, followed by use cases and then source/cost/attestation details. It is front-loaded, jargon is meaningful, and there is no wasted text.

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

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

Given no parameters and no output schema, the description fully compensates by enumerating the data points included (job openings, quits rate, layoffs rate, interpretation), source, pricing, and verification steps. It gives an agent enough information to decide to call it and understand what it will receive.

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

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

The tool has zero parameters, so schema coverage is effectively 100%. Per the rubric, the baseline for 0 params is 4. The description does not need to add parameter semantics since there are none, and it correctly focuses on the output content and use cases.

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

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

The description clearly states it provides JOLTS labor market intelligence from BLS, listing specific metrics (job openings, quits rate, layoffs rate) and an interpretation. This distinguishes it from all sibling tools, none of which mention JOLTS, and gives a specific verb+resource (get intelligence).

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

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

Explicitly states use cases: 'Use for workforce planning, wage pressure forecasting, and recession early-warning agents.' This provides clear context for when to invoke the tool, though it does not mention alternatives or when-not-to-use scenarios, which would make it a 5.

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

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

Annotations already declare read-only safety. Description adds failure mode (HTTP 503 with no charge when upstream unavailable), cost ($0.10 USDC per call via x402 SLA), and data_source provenance field. Slight redundancy in the two identical 503 statements, but overall meaningful behavioral 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?

Information is front-loaded with metric list, but the 503 status is repeated twice in slightly different wording, adding unnecessary length. The SLA/cost line is useful but could be more compact.

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 clarify the response structure, but it only mentions the data_source field. The focus parameter's effect and the definition of tight/balanced/loosening signal are also unspecified. Despite rich operational details, these gaps make 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 has one optional focus parameter (employment/wages/openings/all) with no descriptions (0% coverage). The description lists metrics but doesn't explain how focus selects among them, leaving the agent to infer the mapping. This is a significant gap for correct invocation.

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 specifies the tool retrieves live labor market benchmarks from FRED, naming concrete metrics (unemployment, U-6, JOLTS, quit rate, labor participation, weekly claims, wage growth) and a derived tight/balanced/loosening signal. This clearly distinguishes it from sibling benchmark tools covering different domains.

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?

Clearly contextualizes usage for macro agents and portfolio managers and emphasizes the live source and SLA pricing, aiding selection. However, it doesn't explicitly contrast with overlapping siblings like get_job_openings_intelligence or get_employment_cost_index.

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 destructiveHint=false. The description adds behavioral context by enumerating the returned data items (active regime, verifiable FOMC facts, live market snapshot, etc.), which goes beyond the annotations. It doesn't describe rate limits or auth, but none are implied.

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

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

The description is three short sentences: a usage trigger, a list of return contents, and an example. Every sentence adds value with no repetition or filler. The most important usage instruction is front-loaded.

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

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

With zero parameters and no output schema, the description fully carries the burden of explaining what the agent will receive. It lists six distinct output components and gives an example, making the tool's behavior clear and complete for a read-only information retrieval tool.

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

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

The tool has zero parameters, so the baseline is 4. The description mentions requesting regime label and tactical positioning, which aligns with what the tool returns, though there are no parameter details to document.

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

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

The description clearly states the tool's purpose: it provides a current regime label and tactical positioning for traders/PMs. It also lists specific return components (FOMC facts, market snapshot, model interpretation, playbooks, key levels), distinguishing it from sibling benchmark tools that focus on single metrics.

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

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

The description explicitly says 'Use when a trader or portfolio manager needs current regime label and tactical positioning,' giving a clear triggering context. It does not mention when not to use it or name alternative tools, but the context is sufficient for a zero-parameter read-only 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 and destructiveHint=false, so the safety profile is known. The description adds the data source (Damodaran dataset and public deal aggregates) and the metrics available, but does not disclose additional behavioral traits such as update frequency, data limitations, or output format. No contradiction with annotations.

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

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

The description is three sentences, front-loaded with the use case, followed by the data provided and source/audience. All sentences are relevant, though the audience sentence is somewhat redundant with the first sentence. No waste, but not as tight as a two-sentence version.

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

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

For a simple two-parameter tool with no output schema, the description covers purpose, use cases, metrics, dimensions, source, and audience. It does not describe the exact response shape, but the simple nature of the tool and the provided context make it adequately complete.

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

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

Schema coverage is 0%, but the description explicitly mentions 'by industry and deal size,' directly mapping to the two parameters (industry, deal_size_tier). It also describes the return metrics (EV/EBITDA, EV/Revenue, control premiums), adding meaningful context beyond the schema's enum values.

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 M&A transaction multiples (acquisition EV/EBITDA, EV/Revenue, control premiums) for valuing acquisition targets, benchmarking deal pricing, and fairness opinions. It distinguishes from siblings like get_public_market_multiples by emphasizing acquisition-specific metrics and sources.

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

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

The description explicitly says 'Use when valuing an acquisition target, benchmarking deal pricing, or preparing a fairness opinion,' giving clear contexts. It does not explicitly name alternatives or when not to use it, but the use cases are sufficiently specific to guide 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 and destructiveHint=false, so the agent knows this is a safe read operation. The description adds valuable context about the data's regulatory origin, the 7% net worth threshold, and an example output pattern. This goes beyond the annotations, though it doesn't discuss edge cases like name matching or state filtering.

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

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

The description is well-structured, starting with usage, then returns, followed by context, threshold, example, and source. The example is slightly long but illustrative and earns its place. Every sentence adds value, though it could be tightened.

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, the description lists the returned fields and provides a concrete example with realistic numbers. It also explains the well-capitalized threshold for interpreting net worth ratio. Missing explicit parameter semantics (state) and return format details, but overall it is fairly complete for a financial data lookup.

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 0%, so the description must compensate. It implies the credit union name is needed via the example but doesn't explicitly state that credit_union_name is required. The optional state parameter is entirely omitted, leaving agents without guidance on how state filtering works.

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

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

The description clearly states the tool returns NCUA call report financials with specific fields (assets, deposits, loans, net worth ratio, delinquency rate, ROA) and peer comparison signals. The verb 'Returns' is specific, and the resource is unambiguous. It distinguishes itself from sibling benchmark tools by focusing on individual credit union financials rather than broad benchmarks.

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

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

The description explicitly provides usage contexts: 'Use when evaluating a credit union for partnership, acquisition, membership, or competitive benchmarking in a local market.' However, it doesn't name alternative tools or when-not conditions, which prevents a 5.

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

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

Annotations already mark the operation as read-only and non-destructive. The description adds useful behavioral context by noting the data source (Cambridge Associates) and that these are 'public benchmark summaries,' implying aggregate summary-level data rather than underlying transactions. It also states the target users, providing context for suitability.

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

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

The description is three sentences, front-loaded with use cases and followed by metrics, source, and audience. No filler; each sentence adds distinct value.

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

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

With no output schema, the description compensates by naming the expected return metrics (IRR, TVPI, DPI) and the data source. It fails to mention the full set of supported strategies and the optional nature of vintage_year, but overall it provides a strong context for a benchmark query 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 has 0% description coverage, so the description must explain parameters. It mentions 'vintage year' and 'strategy' and lists three example strategies, but it omits the 'real_estate_pe' and 'credit' enum values and does not explain the format or optionality of vintage_year. This partial coverage risks misleading the agent into thinking only buyout, growth equity, and venture are supported.

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 private equity and venture return benchmarks (IRR, TVPI, DPI) segmented by vintage year and strategy. It uses a specific verb ('get' implied) and resource, and distinguishes from sibling benchmark tools by naming Cambridge Associates as the source and specifying PE/venture 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?

The description explicitly states when to use the tool (benchmarking fund performance, setting LP return expectations, evaluating GP track records). However, it does not mention real estate and credit strategies that are present in the schema's enum, and it does not exclude alternatives, so the guidance is slightly incomplete.

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 destructiveHint=false, and the description adds meaningful context: the data source (FRED/BEA), the computation (long-run average comparison), the cost ($0.02 atomic), and cryptographic attestation with verification URL. This goes beyond annotations, though it does not describe return format or time range.

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

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

The description is compact and front-loaded: the first sentence states the core deliverable, the second states when to use it, and the next two provide sourcing, cost, and verification details. Every sentence adds distinct 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 zero-parameter, read-only benchmark tool with good annotations, the description covers the key aspects: what is returned, the source, the use cases, and additional trust/cost details. It lacks explicit return format or units, but the complexity is low and the description is sufficiently complete for selection and 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 tool has zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 applies because there is nothing to document and the description still clarifies what the returned metric represents.

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

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

The description clearly states what the tool provides: the BEA personal saving rate from FRED, along with a long-run average comparison and an above-average flag. This distinguishes it from sibling benchmark tools by naming the specific economic indicator and the value-added comparison.

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 gives explicit use cases ('Use when assessing household balance sheet health, consumption durability, and macro recession risk'), telling the agent when to select this tool. It does not mention exclusions or alternatives, but the context is clear and sufficient given the narrow tool scope.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context: the pricing ($0.10), the cryptographic attestation with post-quantum signed receipt, and the verification URL. This goes beyond annotations and helps the agent understand side effects and verification needs.

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

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

Four sentences total with the core purpose front-loaded first, followed by use case, source, and cost/attestation details. No significant verbosity; the description earns each sentence.

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

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

For a one-parameter read-only lookup with no output schema, the description adequately covers the purpose, use case, source, cost, and the response content (index level and year-over-year change). It could specify the response structure more explicitly, but the given information is sufficient for the agent to decide whether to invoke the tool.

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

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

The single 'industry' parameter has a full enum in the schema, and the description simply repeats those enum values in prose without adding extra meaning (e.g., what each industry means, data granularity per industry). Schema coverage is 0%, but the enum is self-documenting, so the description only mildly compensates for the lack of prose parameter docs.

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

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

The description clearly states the tool returns 'BLS Producer Price Index by industry with index level and year-over-year change' and enumerates the specific industries covered (software, healthcare, etc.), distinguishing it from sibling inflation/benchmark tools. The verb+resource+scope is explicit and specific.

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?

Provides an explicit use case: 'Use for input cost benchmarking and PPI pass-through analysis.' This gives clear context for when to use the tool, though it does not mention when not to use it or name alternative 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 and destructiveHint=false, so safety is covered. The description adds context about the data source and vintage (Damodaran January 2024), the 'Free' cost, and the percentile band output. It does not go deeper into behavior like caching or data coverage limitations, so it adds some but not rich 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 paragraph of four sentences, front-loaded with 'Use when...' and containing no fluff. Minor redundancy exists ('benchmark' appears three times, 'fundraising' twice), and 'Free' is a bit tacked on, but overall it is efficient.

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

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

For a read-only, simple two-parameter tool with no output schema, the description is quite complete: it covers use cases, data content, source, and cost. It lacks an explicit list of sector enum values, but the schema supplies that. The return format is not described, but there is no output schema to match, and the context of use cases provides enough guidance.

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 0%, so the description must compensate. It mentions 'by sector' for the sector parameter, and the use cases (IPO, fundraising, board prep) map directly to the context enum values. Yet it doesn't explicitly name or describe the parameters, leaving some inference needed.

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

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

The description clearly identifies the tool's purpose: fetching public market valuation multiples (EV/EBITDA, EV/Revenue, P/E, P/S) by sector with p25/p50/p75 bands. It differentiates from sibling tools by naming the source (Damodaran January 2024) and specific metrics, making it unmistakable.

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

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

The description explicitly states when to use it: 'building a public comps table, benchmarking a private company valuation, or preparing a fundraising benchmark.' It also lists downstream use cases like board prep and M&A pricing. However, it does not mention exclusions or name alternative tools for when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description complements this by adding source ('FRED / US Census Bureau'), cost ('$0.02 atomic'), and attestation details ('Cryptographically attested with a post-quantum signed settlement receipt'). It does not mention potential data revisions or update frequency, which could matter for advance estimates, but the added context goes beyond the annotations.

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

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

The description is three sentences that front-load the core data content, then provide use cases, source, cost, and verification. Every sentence earns its place with no redundancy.

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

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

For a simple parameterless data-fetching tool, the description fully covers what data is returned, in what units, and for what purpose. The lack of an output schema is mitigated by specifying the data fields. The source and cost information further complete the context for 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 input schema has zero parameters with 100% coverage, so the baseline is 4. The description adds value by describing the output content (billions USD and MoM/YoY changes), which is relevant for interpreting results even without parameters.

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

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

The description clearly identifies the tool as returning 'US advance retail sales from FRED in billions USD with month-over-month and year-over-year percent change.' This specifies the exact resource, metric, and units, distinguishing it from sibling tools like get_consumer_sentiment_benchmark or get_bls_sector_employment. The verb is implied but unambiguous.

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

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

The description explicitly states 'Use for consumer demand monitoring, recession signals, and revenue forecasting agents,' providing clear use cases. It does not name alternatives or exclusions, but the specific topic makes it obvious when to select this tool over siblings. This is a minor gap compared to an explicit 'when not to 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?

With annotations already declaring the tool read-only and non-destructive, the description adds valuable behavioral context: data provenance (SEC EDGAR), cryptographic attestation with a post-quantum signed settlement receipt, and a verification URL. It also discloses the output as an activist signal. This goes beyond the annotations without contradicting 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 compact and front-loaded, with the core purpose in the first sentence and supporting details (return signal, source, attestation, verification) in following clauses. Every sentence adds relevant information, and there is no fluff or repetition of schema/annotation content.

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

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

For a single-parameter read-only tool with no output schema, the description is largely complete: it explains the filing types, the shareholder threshold, the intent classification, the return signal, the source, and verification method. The main gap is the lack of output structure detail, but the high-level 'returns activist signal' is sufficient for a simple data retrieval use case.

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 only provides a 'ticker' parameter with length constraints and no description. The tool description never explains what the ticker should be, its format, or its meaning beyond what the parameter name implies. With schema_description_coverage at 0%, the description fails to compensate for the missing 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 clearly states the tool identifies Schedule 13D/13G beneficial ownership filings and distinguishes activist (13D) versus passive (13G) 5%+ shareholders. It names a specific resource (SEC EDGAR beneficial ownership filings) and a specific actionable output (activist signal), making its purpose distinct from sibling tools like get_sec_insider_trading.

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

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

The description provides clear context on what the tool returns (activist/passive classification and activist signal), but it does not explicitly state when to use this tool versus alternatives such as get_sec_insider_trading. There are no exclusions or alternative recommendations, so usage guidance is implied rather than explicit.

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

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

Annotations already declare the tool read-only and non-destructive. The description adds valuable behavioral context about the data source (SEC EDGAR) and the cryptographic attestation/verification process, which goes beyond the annotation baseline. It does not describe return format or pagination, but the attestation detail is significant.

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 information-dense, front-loading the core definition of SEC Form 4 insider transactions and then adding source, payload, and verification details. Every sentence contributes unique value, with no redundant phrasing or excessive 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?

For a single-parameter, read-only tool with no output schema, the description covers the data source, time window, and output type (filings with dates/links) reasonably well. However, 'returns insider activity signal' is somewhat vague, leaving the exact return structure unclear, which slightly detracts from completeness.

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

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

The schema provides only the parameter name 'ticker' and basic string constraints with 0% description coverage. The description does not explain what ticker means, provide examples, or clarify format, so it fails to compensate for the schema's sparse documentation, leaving the parameter semantics mostly to inference from the name.

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

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

The description clearly identifies the resource (SEC Form 4 insider transaction history) and the specific scope (executive buy/sell filings, last 90 days, filing dates/links), distinguishing it from siblings like get_sec_beneficial_ownership by highlighting the Form 4 focus and the 90-day window.

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

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

No explicit when-to-use or alternative guidance is provided. The tool's purpose implies it is for insider trading data from SEC filings, but there is no mention of when not to use it or what to use instead for broader ownership data, leaving usage context merely implied.

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 read-only and non-destructive behavior, so the description adds valuable extras: the $0.02 atomic cost, post-quantum signed settlement receipt, and verification URL. These disclose financial and cryptographic traits beyond the annotations, which is useful 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 concise and front-loaded with the core purpose and usage, followed by source, cost, and attestation details. It is not overly verbose, though it could be slightly tighter without losing information.

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

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

For a tool with no input parameters and no output schema, the description is fully complete: it explains what data is provided, the trend classification, the five-year average, the source, cost, and verification process. Nothing essential is missing.

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

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

There are zero parameters, so the schema needs no additional explanation. The description does not need to add parameter details. The baseline for 0 params is 4, and the description appropriately omits irrelevant parameter info.

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 the Baltic Dry Index shipping cost benchmark from FRED with trend classification and a five-year average. This is a specific verb+resource combination, and it distinguishes itself from sibling benchmark tools by naming a unique index and source.

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

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

It explicitly says to use when assessing global trade volume, freight inflation, or supply chain cost pressure. This provides clear context for when to use the tool, though it does not explicitly mention alternative tools or when not to use it, which is acceptable given the specificity.

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 destructiveHint=false, but the description adds valuable behavioral context: auth requirements (public no-auth vs OAuth), x402 micropayment pricing tiers, and that this is a discovery tool. It also states the catalog covers various verticals, giving the agent a clear sense of what invoking this tool will yield. No annotation 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 front-loaded with 'START HERE — Returns the complete Stratalize tool catalog' and each clause provides substantive information: categories, auth paths, pricing, and a call instruction. The pricing list is dense but relevant for an agent deciding whether to invoke. Slightly longer than needed, but every sentence earns its place.

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

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

Given no output schema, the description clearly states the return value (tool catalog) and the categories covered, along with access and authentication context. For a zero-parameter overview tool, this is sufficiently complete to set expectations and guide invocation. Sibling tools are numerous but this is clearly the entry point.

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

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

The input schema has zero parameters, so per the rubric baseline is 4. The description compensates by explaining that the tool's role is to expose other tools; no parameter details are needed. It does not add extra parameter knowledge, but none is necessary.

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

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

The description uses a specific verb ('Returns') and identifies the exact resource ('complete Stratalize tool catalog') with clear scope. 'START HERE' distinguishes this as the entry-point discovery tool versus the many sibling benchmark tools. It also enumerates covered verticals, providing explicit 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?

Explicitly instructs to 'Call this first to discover tools by role or vertical', giving a clear trigger. It also notes that some tools require OAuth while others are available without auth, offering context on when to use this overview versus direct sibling calls. However, it does not explicitly say 'instead of' or name alternative tools, so not a full 5.

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

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

Annotations already establish the read-only, non-destructive nature. The description adds meaningful context: the data source (FRED/EIA), the distinction between 'verifiable FOMC facts' and 'model interpretation,' and the inclusion of cross-asset sentiment. These go beyond the annotation safety profile and help set expectations.

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

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

Two sentences, front-loaded with the trigger condition and purpose, followed by a dense but complete list of included signals and a clarifying example. Every word serves a purpose; no filler or redundancy.

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

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

For a zero-parameter tool with no output schema, the description thoroughly covers the response contents, data source, and a concrete use case. Nothing critical is omitted, and the tool's role in a macro context is well understood.

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

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

With zero parameters and 100% schema coverage, the schema already conveys all needed parameter info. The description adds no parameter details, but none are required; the baseline of 4 applies.

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

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

The description states the tool's purpose directly: 'full live signal stack in one call' and enumerates the exact indicators returned (Fed funds, 2s10s, VIX, BTC, WTI, etc.). This clearly differentiates it from sibling tools that focus on single benchmarks or 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?

Opens with an explicit usage context: 'Use when a macro agent needs a full live signal stack in one call.' It implies this is a composite alternative to calling multiple individual data tools, but does not explicitly name alternatives or exclusions, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context by citing the data source (Carta State of Private Markets quarterly) and the data content, which goes beyond the annotations. It does not disclose limitations or output format, but for a simple read-only benchmark tool this is acceptable.

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

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

Two concise sentences that are front-loaded with the resource name and key data elements. The second sentence adds source and audience without redundancy. No filler or 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?

With only 2 parameters, no output schema, and a niche domain, the description covers content, source, and intended use. It does not specify the exact return format, but for a benchmark lookup tool this is sufficient. The description is well-rounded and complete given the tool's 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 description coverage is 0%, so the description must compensate. It explicitly mentions 'by stage and sector,' mapping to the two parameters and providing semantic meaning. The enum values are left to the schema, which is fine since they are self-explanatory.

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 venture capital round benchmarks, listing specific metrics (pre-money valuation, round size, dilution, option pool standards) and filtering dimensions (stage, sector). This distinguishes it from sibling benchmark tools like get_agricultural_commodity_benchmark or get_pe_return_benchmark.

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

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

The description provides clear usage context: 'Used by founders, VC CFOs, and early-stage investors for round pricing and cap table modeling.' It does not explicitly mention alternatives or when-not-to-use, but the intended audience and purpose are clear.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context about data source ('Damodaran annual dataset') and update frequency ('Updated January annually'), which helps set expectations about data freshness and provenance.

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

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

The description is concise and front-loaded with the most important usage guidance. It delivers purpose, use cases, source, and update cadence in three sentences without redundancy or fluff.

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

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

For a simple read-only benchmark lookup, the description covers usage, data source, and update frequency. It doesn't describe the return format or structure, but given the tool's simplicity and the absence of an output schema, this is not a critical gap. The description is sufficiently complete for an agent to understand when and how to use it.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'by sector and market cap tier,' which maps directly to the two parameters, but provides no additional meaning beyond the enum names. The enum values themselves are self-explanatory enough for basic use, but the description doesn't elaborate on how to choose or interpret them.

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 provides WACC benchmarks by sector and market cap tier from the Damodaran annual dataset. It uses a specific verb and resource, distinguishing it from sibling benchmark tools by explicitly naming WACC and its data source.

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 first sentence gives explicit use cases: 'Use when valuing a business, setting hurdle rates, or benchmarking discount rates for M&A analysis or capital allocation.' This provides clear context for when to invoke the tool, though it does not mention alternatives 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that data comes from Hackett Group annual survey and BLS composite, and positions it as a CFO/treasury benchmark. This provides source credibility and context beyond the safety annotations, though it doesn't describe exact return format or pagination.

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

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

Three concise sentences, front-loaded with the primary use case. Every sentence adds value: usage, metrics, and source. 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 simple read-only benchmark tool with no output schema, the description is quite complete. It covers what the tool does, what metrics are included, the data source, and primary use cases. It doesn't detail return formatting but that's likely straightforward given the metric list.

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

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

With 0% schema description coverage, the description compensates by explaining the tool breaks down benchmarks 'by industry and company size', which maps directly to the two parameters. This gives semantic meaning to industry and company_size even though enum values are only 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 clearly states the tool benchmarks working capital efficiency and lists the specific metrics (DSO, DPO, DIO, CCC) by industry and company size. The verb 'benchmarking' and resource 'working capital' distinguish it from sibling benchmark 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?

It provides explicit use cases: 'Use when benchmarking working capital efficiency or preparing a CFO cash management brief.' It also names contexts like lender covenant prep and cash flow optimization. However, it doesn't explicitly exclude alternatives or name sibling tools, so it's clear but not fully explicit about when-not-to-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 cover read-only safety. The description adds useful behavioral context: data coverage (>200 countries), update frequency (quarterly), and output style (5-year trend and direction). This goes beyond the annotations, though it could add details like return format or rate limits.

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

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

The description is a single dense paragraph that front-loads use cases, then returns details, coverage, example, and source. The example is illustrative but earns its place by demonstrating output interpretation. Slightly verbose but each sentence adds value.

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

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

Given the tool's simplicity (2 params, no output schema), the description covers purpose, data source, coverage, update frequency, and an example. It does not fully specify output structure, but the mention of '5-year trend and direction' gives a reasonable sense of 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?

The schema documents country_code but only enlists indicator values without descriptions. The description adds meaning by interpreting several indicator types (e.g., ease of doing business rank, FDI inflows) and provides a concrete example, partially compensating for the 50% 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 with a specific verb ('Returns World Bank development indicators') and lists the indicator types. It also contextualizes usage for country risk assessment, market evaluation, and ESG scoring, distinguishing it from sibling tools via the World Bank data 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?

The description explicitly states when to use the tool ('Use when assessing country risk...') with concrete scenarios. However, it does not mention alternatives or when not to use it, so it lacks the complete when/when-not structure of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, meaning the tool is safe. The description adds valuable behavioral context: it returns HTTP 503 when upstream data is unavailable (with no charge), includes a data_source field for provenance, and states the per-call cost. This goes beyond the annotations without contradicting 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 front-loaded with the core content but contains redundancy: 'Returns HTTP 503 (no charge) if upstream source unavailable for >50% of fields' is repeated as 'Returns HTTP 503 (no charge) when upstream data sources unavailable.' Pricing info is useful but could be more concise. The structure is acceptable but not tight.

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 lacking an output schema, the description lists the key return items (yields, bp changes, spreads, inversion signal, SOFR, curve shape) and important context (source, failure mode, provenance, cost). The main gap is inadequate explanation of the 'tenor' parameter, which is relevant to using the tool. Overall, the description is fairly complete for a read-only data 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 has one parameter 'tenor' with enum values (2y, 10y, 30y, all) and no description (0% schema coverage). The description does not explain what 'tenor' controls or how it affects the output. Additionally, the description mentions '1M through 30Y yields' but the enum lacks 1M or other short-term tenors, which could confuse users unless 'all' is understood to cover them. The parameter semantics are left entirely to 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 identifies the tool as providing Live US Treasury yield curve data with specific details (yields, spreads, inversion signal, SOFR, curve shape) and the source (FRED). This specific verb and resource description distinguishes it from siblings like get_agricultural_commodity_benchmark or get_fx_rate_benchmark.

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

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

The description provides clear context: it's for US Treasury yield curve data, live from FRED, with specific contents. While it doesn't explicitly name alternatives, the specificity makes the intended use case evident. It also notes when the tool will fail (503) and cost, which aids usage decisions, though it lacks explicit exclusions.

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