Stratalize Finance Intelligence

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

With no annotations provided, the description must disclose behavioral traits. It only lists data contents, omitting read-only nature, authentication requirements, rate limits, or output format. Minimal transparency beyond data scope.

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

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

The description is a single, relatively concise sentence that front-loads the tool's purpose and lists key data types. However, it lacks structural elements like bullet points that would improve scannability.

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 what data is included but fails to explain how parameters affect output, what the response format is, or any limitations. Given the absence of an output schema and annotations, this is insufficient for proper tool 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 schema has 0% description coverage, so the description must explain parameter meanings. It does not mention the 'focus' or 'institution_type' parameters at all, leaving agents without guidance on how to select benchmarks or filter by institution type.

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

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

The description clearly states the tool provides AML regulatory benchmarks and enumerates specific data types (SAR filing rates, OFAC counts, enforcement fines, etc.). It identifies the target audience, but lacks an explicit verb like 'retrieve' or 'get'. It distinguishes itself from sibling benchmarks by being AML-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?

The description does not provide guidance on when to use this tool vs. alternatives such as get_bank_regulatory_benchmark or other benchmark tools. It only specifies the target users, not usage context or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It mentions the data source (Audit Analytics public aggregate data) but does not disclose behavioral traits like rate limits, data freshness, or that it is a read-only operation. The description is minimal beyond purpose.

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

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

The description is two sentences plus a usage note, all informative with no redundancy. Every sentence adds value, making it efficient and front-loaded.

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

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

Given the tool's simplicity (3 params, no output schema), the description is fairly complete, specifying the two output metrics and segmentation dimensions. It could mention revenue band ranges or data limitations, but overall is adequate 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?

Schema coverage is only 33% (one of three parameters described in schema). The description adds context by mentioning revenue band and auditor tier, which align with two parameters, but the industry parameter is not explained. It partially compensates but does not fully describe all parameters.

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

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

The description clearly states the tool provides audit fee benchmarks, including total fees and fees as a percentage of revenue, segmented by revenue band and auditor tier. It also mentions the source and typical users, making it distinct 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?

The description indicates the tool is used by CFOs and audit committees in RFPs and fee negotiations, providing clear context. However, it does not explicitly state when to use this tool versus other benchmarks or provide exclusions.

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

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

With no annotations, the description must disclose behavioral traits. It states the output format (JSON) and data source (FDIC), implying read-only operation, but lacks details on rate limits, pagination, or potential costs.

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 plus a short phrase, concise and to the point. It front-loads the main function in the first sentence and adds context in the second.

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 parameter and no output schema, the description sufficiently explains the returned data (assets, deposits, etc.), data source (FDIC), and audience. It covers the essential aspects 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?

Schema coverage is 100% with one required parameter 'bank_name'. The description adds example values (JPMorgan, Wells Fargo), which aids understanding but does not provide additional semantics beyond the schema.

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

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

The description clearly states the tool returns JSON financial metrics (assets, deposits, capital ratios, loan quality) sourced from FDIC, specifically for bank credit analysts. It distinguishes from numerous sibling tools by focusing on bank balance-sheet benchmarking.

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

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

The description mentions the target users (bank credit analysts) and data source (FDIC), but does not provide explicit guidance on when to use this tool versus 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?

No annotations are provided, so the description bears full responsibility. It discloses the source (FDIC call report public aggregates) and specific metrics, but lacks details on update frequency, reliability, or any limitations beyond being aggregates.

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 key info (metrics and grouping), then source and audience. No 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?

The description covers domain and source but does not mention output format or that it returns aggregate data. With no output schema, this gap reduces completeness for an agent.

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

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

Schema coverage is 0%, leaving parameters undocumented. The description mentions grouping by 'asset size tier' but does not explain the enum values or the bank_type parameter, relying entirely on the schema's enum names which are self-explanatory but not elaborated.

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 bank regulatory capital and financial performance benchmarks (CET1, Tier 1 leverage, NIM, etc.) by asset size tier, distinguishing it from siblings like get_rwa_benchmark or get_aml_regulatory_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 implies usage for bank CFOs, risk officers, and analysts seeking regulatory benchmarks, but offers no explicit when-to-use or when-not-to-use guidance relative to many similar 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 indicate readOnlyHint=true and destructiveHint=false. The description adds value by citing the BLS as the data source and illustrating the output format with a real-world example (Medical care CPI +3.8% vs headline +3.1%). No contradiction with annotations.

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

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

The description is a single, well-structured paragraph that front-loads usage and provides a concrete example. Every sentence adds value, with no wasted words. It is appropriately sized for the tool's simplicity.

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 a single optional parameter with enums, no output schema, and annotations present, the description sufficiently covers the tool's purpose and data source. It lacks explicit return format details, but the example implies the structure. Completeness is high for a straightforward tool.

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

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

The input schema has one parameter (category) with enum values, but schema description coverage is 0%. The description provides context about categories (medical care, housing) but does not enumerate or explain all options. Baseline 3 is appropriate as the enum is somewhat self-explanatory, though the description could compensate more for the coverage 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 states the tool retrieves BLS inflation components for analyzing inflation exposure by spending category, with specific examples like medical care and housing CPI. It distinguishes from siblings such as get_inflation_benchmark and get_bls_sector_employment by emphasizing component-level detail and divergence from headline inflation.

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

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

The description provides explicit when-to-use scenarios (e.g., vendor contract escalation clauses, healthcare budget planning) and gives a concrete example. It does not explicitly state when not to use, but the context is clear enough for an agent to infer appropriate usage.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds valuable behavioral context: it mentions the data source (BLS Current Employment Statistics, 650,000 US worksites), its credibility (used by the Federal Reserve), and the nature of the output (month-over-month, year-over-year, trend). This fully discloses the tool's behavior.

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

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

The description is a single paragraph that front-loads use cases, then explains output, then provides an example. It is slightly wordy but each sentence adds value. A more concise structure could improve readability, but it is still effective.

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

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

Given the tool has one parameter, no output schema, and good annotations, the description provides comprehensive context: it explains what the output contains (MoM, YoY, trend), gives a specific example, and notes the authoritative source. An agent can fully understand the tool's inputs and expected output.

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

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

The input schema has one parameter 'sector' with enum values, and the description adds an example output for healthcare, showing the format and metrics. While the schema already clearly defines allowed values, the description enhances understanding with a concrete example and hints at the output structure.

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 payroll employment by major sector with specific metrics (MoM change, YoY change, trend classification). It distinguishes from siblings by focusing on sector employment data, while many sibling tools cover benchmarks, financials, or other domains. The use cases are explicitly listed, making the purpose unambiguous.

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

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

The description provides explicit scenarios for when to use the tool, such as benchmarking workforce planning, assessing industry growth, and providing economic context. However, it does not mention when not to use it or suggest alternative tools among the many siblings, which is a minor gap.

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

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

No annotations are provided, so the description must disclose behavioral traits. It includes a disclaimer that the data is not legal advice, but it does not mention data freshness, rate limits, authentication requirements, or idempotency. The word 'Synced' hints at periodic updates but lacks detail. Behavioral transparency is insufficient.

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

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

The description is relatively concise with three sentences. The first sentence conveys the main action, the second adds context, and the third is somewhat redundant. It is efficient but could be streamlined further.

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 parameters, no nested objects, no output schema), the description covers the basic purpose and parameters. However, it lacks details on output format, error handling, and data freshness. It is minimally complete for a straightforward data 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?

Schema description coverage is 0%, so the description must compensate. It explains that 'company_name' is required and 'product' is optional, but it does not provide details on their formats, allowed values, or examples. The description adds minimal value beyond the schema field 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 clearly specifies what the tool does: it returns a CFPB consumer complaint rollup JSON by company name with an optional product filter. It also mentions the content (synced complaint volume and issue themes) and includes a disclaimer. The purpose is distinct from sibling tools which focus on various benchmarks and financial data.

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

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

The description implies the tool is for risk teams seeking consumer finance complaint data, but it does not explicitly state when to use it versus alternatives. No comparisons to sibling tools or usage limitations are provided. 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?

No annotations are provided, so the description must fully disclose behavioral traits. It mentions data sources but does not state if it is read-only, side effects, authentication needs, or error behavior.

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

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

The description is concise with two sentences, but the first sentence is a bit dense. No redundant information; front-loaded with key terms.

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

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

Without an output schema, the description should explain the output format or structure. It only mentions sources and types, leaving the return value ambiguous.

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

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

Schema description coverage is 0%, but enums are self-explanatory. The description adds some context by listing risk types (physical, transition) and data sources, though it does not explicitly map parameters to their meanings.

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 climate financial risk benchmarks covering physical and transition risks, with specific examples. It distinguishes itself from numerous sibling tools by explicitly naming the domain 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?

No guidance on when to use this tool vs. alternatives. The only hint is 'For ESG and risk agents,' but there is no explicit differentiation or conditional advice.

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

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

The description discloses data source (FRED), update frequency (daily), and content scope (changes, inflation signal). However, with no annotations, it fails to mention response format, pagination, or any limitations, leaving behavioral gaps.

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

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

The description is compact with three sentences: first introduces the tool and examples, second mentions changes and signal, third gives source and frequency. It is front-loaded and contains no wasted words.

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

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

For a simple tool with one optional parameter and no output schema, the description adequately covers purpose, data content, source, and frequency. Missing output structure details are minor given the tool's straightforward nature.

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

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

The description adds meaning to the 'category' parameter by listing commodities that map to each category (energy, metals, agriculture), compensating for the 0% schema description coverage and providing context beyond the 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 live commodity price benchmarks for specific commodities (WTI crude, natural gas, gold, copper, wheat, soybeans) with weekly/monthly price changes and inflation pressure signal, differentiating 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?

The description implies usage for traders and macro analysts but does not explicitly state when to use this tool over alternatives like get_inflation_benchmark or get_gas_benchmark. It provides context but lacks exclusion criteria.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions live data and a consumer signal (strong/moderate/weak), but does not disclose update frequency, historical range, error handling, or how the signal is computed. Key behavioral traits are missing.

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 long, concise, and front-loaded with the purpose. It avoids extraneous detail, but the second sentence could be clearer. Overall, it earns its length.

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

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

Given the complexity of aggregating multiple indicators into a composite signal and the absence of an output schema, the description should explain the return format, frequency, and data range. It mentions 'strong/moderate/weak consumer signal' but not how it is represented (e.g., text, numeric score). Key contextual information 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?

The schema has one parameter ('focus') with enum values ('sentiment', 'spending', 'saving', 'all'), and schema description coverage is 0%. The description lists data sources (sentiment, retail sales, PCE, saving rate) that partially map to enum options, but does not explicitly explain the parameter or how each focus value affects the output. The description adds minimal value beyond the 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 clearly states the tool provides live consumer sentiment benchmarks from FRED, listing specific indicators (University of Michigan sentiment, Conference Board confidence, etc.) and mentions outputting a consumer signal strength. It distinguishes the tool as aggregating multiple data points into a signal, but does not explicitly differentiate from sibling tools like 'get_inflation_benchmark' or 'get_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 implies the tool is used for assessing consumer health for GDP and equity analysis, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.

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

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

No annotations are provided; the description reveals the data source (S&P Capital IQ, Damodaran) and return metrics but does not disclose other behaviors such as rate limits, authentication, or read-only nature. It adequately describes what the tool returns but lacks additional context.

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

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

The description is concise, two sentences long, and front-loaded with the core purpose. Every sentence adds value without redundancy.

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

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

Given no output schema and no annotations, the description covers the purpose and data source but omits details on return format or behavioral aspects. It is minimally adequate for a simple data query tool but could be improved.

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 2 parameters with enums but 0% description coverage. The description mentions grouping by credit rating and industry but does not explain the parameter values or add meaning beyond the schema. Consequently, it fails to compensate for the lack of 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 the tool provides corporate leverage and debt benchmarks (Net Debt/EBITDA, interest coverage, debt maturity profiles) by credit rating tier and industry. It also specifies the data source and use cases, distinguishing 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?

The description targets CFOs and treasurers for refinancing, covenant setting, and credit rating management, but does not explicitly state when not to use this tool or direct to alternatives 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?

No annotations exist, so the description carries full burden. It discloses that data is live, updates daily, and comes from FRED ICE BofA indices. It lists what the tool returns. This is adequate for a read-only benchmark tool, though it does not elaborate on rate limits or authentication.

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: first presents the tool's offerings, second notes update frequency, third states audience. No unnecessary words; key information is front-loaded.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description covers the essential aspects: data source, specific metrics, update cycle, and target users. It does not explain every term (e.g., distress signal) but assumes domain knowledge, which is reasonable.

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

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

The only parameter 'rating_tier' is described indirectly: the description mentions 'OAS by rating tier' and lists 'investment grade and high yield', which aligns with the enum values (ig, hy, bbb, all). The description adds meaning beyond the raw enum list by connecting it to the tool's outputs.

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 spread benchmarks' from specific indices (FRED ICE BofA) and lists concrete data points (OAS by rating tier, TED spread, 2s10s Treasury spread, distress signal). It distinguishes itself from sibling benchmark tools by focusing on credit spreads.

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 targets credit analysts and fixed income PMs, implying the tool is for credit spread analysis. It does not explicitly state when not to use or list alternatives, but the specificity to credit spreads provides sufficient guidance among many sibling benchmarks.

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

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

No annotations are provided, so the description carries the full burden. It implies read-only behavior by describing a benchmark tool, but does not specify important details like data refresh frequency, historical range, or whether results are aggregated. Adequate but could add more behavioral context.

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

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

The description is three sentences, front-loaded with the main purpose, and contains no unnecessary words. It efficiently conveys the tool's function, metrics, source, and target 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?

Given no output schema, the description sufficiently explains what data is returned and its use case. It lacks details on how parameters combine (e.g., charter_type filter) and return format, but for a benchmark tool, the provided context is mostly complete.

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

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

The schema has 2 parameters with enums and 0% description coverage. The description mentions 'by asset size' aligning with the required asset_size_tier parameter, but does not mention the optional charter_type. The enum values are self-explanatory, so the description adds some value but does not fully compensate for the lack of 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 the tool provides credit union financial performance benchmarks and lists specific metrics (capital ratios, net interest margin, loan growth, delinquency rates) and source. It distinguishes from the many sibling benchmark tools by targeting credit unions and specifying NCUA 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 mentions the target user ('credit union CFOs preparing for NCUA exams and board reporting'), providing clear context for when to use. It does not explicitly state when not to use or suggest alternatives among siblings, but the context is 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?

No annotations are provided, so the description carries full burden. It discloses the data source and model (SEC EDGAR aggregate + Sloan accruals model) but does not explicitly state read-only behavior, rate limits, or data availability limitations.

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

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

The description is concise at two sentences, front-loaded with the purpose and metrics, and every sentence adds value without fluff.

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

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

Given the tool has two parameters and no output schema, the description is adequate but incomplete: it does not describe the output format or provide examples, which would be helpful for an agent to understand what the tool returns.

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

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

Schema coverage is 0%, and the description does not mention the 'revenue_recognition_model' parameter at all. While it implies the 'sector' parameter is used for filtering, it adds little meaning beyond what the enum values provide, leaving the optional parameter unexplained.

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 earnings quality and financial statement risk benchmarks, listing specific metrics (accruals ratio, cash conversion, revenue recognition risk) and data source, distinguishing it from many 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?

The description specifies the target users (CFOs, auditors, analysts) and context (assessing financial reporting risk before M&A or investment), providing clear guidance on when to use the tool, though it does not explicitly mention when not to use it.

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

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

The description discloses the API key dependency, non-realtime nature, and fallback behavior ('empty or guidance per resolver'). However, 'Energy price strip dependency' is unclear without elaboration.

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 short but uses jargon ('style JSON', 'per resolver') that may confuse. Could be more concise and clear.

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

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

Given no parameters and no output schema, the description provides basic context (API key, realtime status) but lacks details on return structure or usage examples.

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

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

Input schema has no parameters, so description doesn't need to add parameter details. Baseline 4 applies since no parameters exist to explain.

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

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

The description specifies the tool returns 'EIA spot-price style JSON' for commodity strategists, clearly identifying the target audience and data type. The mention of API key configuration distinguishes it from sibling tools that don't require such setup.

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

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

No explicit guidance on when to use this tool vs siblings. The description implies it's for energy price data but doesn't contrast with other benchmarking tools or specify use cases.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds context by detailing the output (positions, targets, levels, confidence) and providing an example. This is sufficient and consistent 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 two sentences plus an example, all front-loaded with purpose. Every sentence adds value without redundancy or extraneous information.

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

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

With no output schema, the description fully explains what the tool returns (position, targets, invalidation levels, confidence scores) and gives a concrete example. The single parameter is adequately described, making the tool's functionality completely understandable 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 input schema for 'asset' is already described well (symbol or 'all'), but the description adds concrete examples of valid assets (BTC, SPY, TLT, Gold) and implies the default is 'all', which goes beyond the schema's generic description.

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

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

The description clearly states it provides Elliott Wave positions, targets, invalidation levels, and confidence scores for specific assets (BTC, SPY, TLT, Gold). The example further clarifies the output. This distinctively differentiates it from sibling tools focused on other financial 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 indicates the tool is for traders and portfolio managers tracking technical market structure, providing clear usage context. However, it does not mention when not to use it or explicitly compare to siblings like 'get_market_structure_signal', missing some guidance on alternatives.

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

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

With no annotations, the description must convey behavioral traits. It discloses data sources (EPA GHGRP, MSCI ESG methodology) and listed metrics, which adds context. However, it does not mention whether the tool is read-only, requires authentication, has rate limits, or what the return format is.

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 long, front-loading the core purpose and key details (metrics, sources, audience). It is efficient and avoids redundancy, though it could optionally add a brief usage note.

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

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

Given the lack of an output schema and the simplicity of the tool (2 enum parameters), the description provides moderate completeness by listing output metrics and sources. However, it does not describe the response structure or how to interpret the benchmarks, leaving some ambiguity.

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

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

The description mentions 'by sector' but does not explicitly map to the sector parameter enum values. It lists metrics that correspond to the focus parameter (carbon, social, governance, all) but does not explain the parameter or its options. With 0% schema coverage, the description should provide more parameter guidance.

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 ESG benchmarks by sector and lists specific metrics (carbon intensity, net zero commitments, SBTi alignment, etc.), which distinguishes it from many sibling tools focused on financial or market benchmarks. However, it does not explicitly differentiate from other ESG-related tools on the server.

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

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

The description implies the tool is for sustainability agents and ESG analysts, but provides no explicit guidance on when to use it versus alternative tools, no when-not-to-use conditions, and no prerequisites or context for invoking the 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?

With no annotations, the description discloses that the tool is illustrative, conditioned on the latest FRED fed funds print, and not market odds. This provides sufficient transparency for a read-only, educational tool.

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

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

The description is a single, well-structured sentence that front-loads the purpose, resource, scope, and key caveats without any wasted words.

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

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

Given no parameters, no output schema, and no annotations, the description fully covers the tool's purpose, audience, data source, and limitations, making it self-contained 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?

There are no parameters, and schema coverage is 100%. The description adds no parameter details, but the baseline for no parameters is 4.

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

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

The description clearly states that the tool returns 'illustrative cut, hike, hold probabilities' for the next three FOMC meetings, targeted at 'macro educators'. It differentiates itself from market-implied odds by stating 'explicitly not futures-implied market odds'.

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 defines the audience ('macro educators') and context ('scenario planning narrative only'), implying it is not for real trading. However, it does not explicitly state when not to use or compare with alternatives.

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

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

No annotations are provided; the description adds some transparency by noting source (FRED) and update frequency (daily) but does not disclose behavioral traits like idempotency, authentication needs, 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?

Two concise sentences front-load key information (list of benchmarks, source, update frequency) with no unnecessary words.

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

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

For a simple 1-parameter tool with no output schema, the description is nearly complete. It covers available benchmarks and update cadence; only lacking detail on output format or sample response.

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

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

Schema description coverage is 0%. The description lists currency pairs but does not explain the only parameter (base_currency) or how it affects results, missing an opportunity to clarify parameter meaning.

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

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

The description explicitly states it provides live major currency pair benchmarks, listing specific pairs and metrics, which clearly differentiates it from many sibling tools.

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

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

The description implies use for currency benchmarks but does not provide explicit when-to-use or when-not-to-use guidance relative to many siblings.

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

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

No annotations are provided, so the description must cover behavioral traits. It mentions the output (YTD returns, P/E ratios, risk signal) but fails to disclose any side effects, permissions required, rate limits, or data freshness. For a tool likely performing a read-only query, this is insufficient.

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

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

The description is two sentences with no filler. It front-loads the list of indices and then specifies the data points, efficiently conveying the tool's output.

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

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

Given the tool's simplicity (one optional param, no output schema), the description adequately explains what the tool returns. However, it lacks details on how the 'region' parameter filters results or the exact format of the output, which could be improved.

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 enum values, but the description provides no additional meaning or usage guidance for it. With 0% schema description coverage, the description should compensate but does not mention the parameter at all.

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 global equity index benchmarks, listing specific indices (S&P 500, Nasdaq, etc.) and the data points (YTD returns, P/E ratios, risk signal). This is a specific verb-resource combination that distinguishes it from sibling tools focused on other benchmarks like cost or regulatory 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 implies use for global equity benchmarks but does not explicitly state when to use this tool over alternatives. No exclusion criteria or alternative tool names are mentioned, leaving the agent to infer from the tool name and listed indices.

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

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

With no annotations provided, the description carries the full burden. It discloses the tool is read-only ('returns'), static, and not live, which adequately conveys behavioral traits for a simple data retrieval tool. No contradictions, but could mention any constraints like data frequency or update schedule.

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?

Description is three concise sentences, each serving a clear purpose: what it returns, the specific content, and its academic positioning. No fluff, front-loaded with key differentiators. Highly efficient.

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

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

Given no parameters or output schema, the description is fairly complete. It specifies the return type (JSON static composites), content focus (GDP, inflation), and use case (academic briefing). Missing details like exact time periods covered or update frequency, but overall adequate for a simple snapshot 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?

Input schema has zero parameters, and schema coverage is 100% (trivially). The description adds value beyond the schema by explaining the content (global GDP, inflation, academic macro briefing card) and nature (static, curated), which sets proper expectations for the output.

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

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

Description clearly states the tool returns static IMF WEO-style macro composites JSON, specifying it is curated tables, not live API pulls or country desks. It identifies the specific resource (Global GDP and inflation reference snapshot) and distinguishes from siblings by emphasizing 'static' nature, making purpose specific and unique among many similar 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?

Description provides context by stating it returns static curated data, not live IMF pulls, which implies when to use (for static reference) and when not (for live data). However, it does not explicitly name alternative tools or provide direct when-to-use vs when-not-to-use guidance, leaving some inference to the agent.

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

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

No annotations are provided, so the description must carry the full burden. It does not disclose behavioral traits such as data freshness, rate limits, or API dependencies. While it describes the output, it lacks transparency about the source call (e.g., FRED API call, possible failures).

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

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

The description is a single well-structured sentence that front-loads the core purpose and lists key outputs. Every part adds value, with no redundant or filler words.

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

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

Given the simple schema (one optional parameter) and no output schema, the description adequately explains what data is returned (specific indicators and policy implications). It could mention data frequency or update cadence, but is still quite complete for its complexity.

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

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

The schema has one optional enum parameter 'measure' with schema coverage 0%. The description compensates by listing the values (CPI, core CPI, PCE, core PCE, breakeven, components, all) and what they include, adding meaning beyond the 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 clearly states it provides 'live inflation benchmarks from FRED' and lists specific components (CPI, core CPI, PCE, etc.) and outputs (Fed target gap, anchoring signal, policy implication). It is specific, uses a strong verb-resource combination, and distinguishes from siblings like get_fomc_rate_probability.

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

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

The description implies usage for obtaining inflation benchmarks for macro analysis, but does not explicitly state when to use this tool versus alternatives like get_fomc_rate_probability or other macro tools in the sibling list. No exclusions or prerequisites are mentioned.

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

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

No annotations are provided, so the description carries full burden. It lacks disclosure of behavioral traits such as data freshness, whether the operation is read-only, or any potential side effects. The description only states the source but no further behavioral 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 two sentences with no wasted words. It front-loads the key purpose and provides source and audience efficiently.

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

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

Given the lack of output schema and annotations, the description is adequate but incomplete. It covers purpose and source but does not describe the output format or any constraints (e.g., data range, update frequency).

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

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

The input schema has 0% description coverage, and the description does not explain the parameters. It implies filtering by line of business but does not mention 'company_size' or clarify that 'line_of_business' is required. The description adds little meaning 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 returns insurance financial performance benchmarks with specific metrics (combined ratio, loss ratio, etc.) and identifies the source (NAIC annual statistical report). It distinguishes itself from sibling tools by being specifically for insurance underwriting 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 mentions target users (CFOs, actuaries, analysts) and context (reviewing underwriting performance), but does not provide explicit guidance on when to use this tool versus 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?

No annotations are provided, and the description does not disclose behavioral traits such as data freshness, rate limits, authentication needs, or side effects. It only lists indicators.

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

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

Two sentences, front-loaded with critical information, no redundant words. Lists indicators efficiently.

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

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

For a simple tool with one optional parameter and no output schema, the description is mostly complete, though it does not describe the output format. The list of indicators and signal provides sufficient context.

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

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

Schema coverage is 0% but the description lists indicators that map to the enum values of the 'focus' parameter, partially compensating. However, it does not explicitly explain the parameter's role.

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 labor market benchmarks from FRED, listing specific indicators and mentioning a computed signal. It is well-differentiated from sibling tools which cover other benchmarks (e.g., inflation, yield curve).

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 use for labor market analysis but does not explicitly specify when to use this tool vs. alternatives, nor does it provide exclusions or prerequisites.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description does not need to reiterate safety. The description adds limited behavioral context (e.g., 'current' playbook) but lacks details on data source or update frequency.

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 key content (list of playbook components), and an example. No wasted words.

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

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

For a zero-parameter read-only tool with no output schema, the description is fairly complete, listing what the playbook contains and the intended users. It could mention data freshness or format, but it's adequate.

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 baseline is 4. The description does not need to explain parameters and does not add any parameter semantics.

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

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

The description clearly states it provides a current macro trading playbook with specific elements like active regime label, positioning themes, risk triggers, and tactical opportunities. This distinguishes it from sibling tools which are mostly benchmarking 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 specifies the target audience (traders, portfolio managers, macro allocators), indicating who should use it. However, it does not provide explicit when-to-use guidance or compare with 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?

The description discloses the data source (Damodaran dataset and public deal aggregates), which adds behavioral context beyond the simple get operation, but lacks detail on response format, pagination, or authorization requirements. Since no annotations are provided, more transparency would be beneficial.

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 (two sentences), front-loaded with the core purpose, and includes source and use case without unnecessary words. 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?

Given no output schema, the description partially compensates by listing the return metrics (EV/EBITDA, EV/Revenue, control premiums), but it does not describe the output structure or format, leaving ambiguity about what exactly the agent receives.

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

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

The description adds meaning by stating the tool filters 'by industry and deal size,' mapping directly to the two parameters, but does not elaborate on the enum values or provide additional semantics beyond what the schema provides. With 0% schema description coverage, more parameter-specific detail would be helpful.

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 M&A transaction multiples (EV/EBITDA, EV/Revenue, control premiums) by industry and deal size, effectively distinguishing it from sibling benchmark tools that focus on other domains like public market multiples or PE returns.

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 specifies target users (corp dev, PE deal teams, M&A advisors, CFOs) and a use case (preparing fairness opinions), providing clear context for when to use the tool, though it does not explicitly exclude alternatives or give when-not 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 indicate read-only behavior. The description adds context beyond annotations by noting the data source (NCUA examiners) and regulatory threshold (7% net worth ratio), but does not detail error cases or side effects.

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

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

The description is three sentences, conveying purpose, use case, and an example efficiently. It is front-loaded with the primary usage scenario, though the first sentence is slightly dense.

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 two parameters and no output schema, the description covers the core purpose, use cases, a threshold value, and an illustrative example. It is sufficient for an agent to understand the tool's function.

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

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

The input schema has 0% description coverage for its two parameters. The description does not explain the 'state' parameter or provide details on 'credit_union_name' beyond its implication from the tool name, failing to compensate for the schema 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 states the tool's verb ('returns') and resource ('NCUA call report financials' for credit unions), with specific metrics listed. It distinguishes itself from siblings like 'get_credit_union_benchmark' by referencing NCUA data and peer comparison, making the purpose unambiguous.

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

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

The description explicitly starts with 'Use when evaluating a credit union for partnership, acquisition, membership, or competitive benchmarking,' providing clear usage context. While it doesn't list alternatives or exclusions, the purpose is sufficiently scoped.

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

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

No annotations are provided, so the description must carry the full burden. It describes the data source (Cambridge Associates public summaries), the metrics returned, and filtering options. It implies a read-only operation, which is appropriate for a 'get' tool. However, it could be more explicit about the absence of side effects.

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

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

The description is two sentences long, front-loaded with the main purpose, then source, then users. Every sentence adds value with no redundancy.

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

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

Given the tool's simplicity (2 params, no output schema), the description provides sufficient context: the metrics returned, the data source, and typical use cases. It lacks information on pagination, rate limits, or error handling, but those are less critical for a straightforward data 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?

Schema coverage is 0% (no property descriptions), but the description adds meaning by listing the strategy examples (buyout, growth equity, venture) and mentioning vintage year filtering. It does not explain all enum values (real_estate_pe, credit) or provide format for vintage_year. The description partially compensates for the low 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 it returns PE and venture return benchmarks (IRR, TVPI, DPI) by vintage year and strategy, with the specific source (Cambridge Associates). It uses a specific verb ('get') and resource ('return benchmarks'), and distinguishes itself from siblings like get_venture_benchmark by specifying the metrics 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?

The description mentions target users (PE GPs, LPs, fund CFOs) and use cases (performance reporting, fundraising), but does not explicitly state when not to use this tool or provide alternatives 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?

No annotations provided, so description carries full burden. It discloses that data is free, sourced from Damodaran January 2024 dataset, and returns percentile bands. No mention of destructive behavior or auth needs, but given it's a read-only public data tool, this is adequate.

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 with no wasted words. The description is front-loaded with the core offering and efficiently adds source and use cases.

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

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

Given no output schema and no annotations, the description covers the tool well: multiples, source, data period, use cases, and cost. It does not detail the output format or interpretation of percentiles, but is largely complete for a data 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?

Schema coverage is 0%, so description must compensate. It mentions 'by sector' implying the sector parameter, but does not describe the context parameter or add syntax details. The schema already lists enums, so the description adds minimal value beyond what the schema provides.

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

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

Description clearly states the tool provides public market valuation multiples (EV/EBITDA, EV/Revenue, P/E, P/S) with percentile bands by sector, including source and use cases. This is specific and distinguishes 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?

Description lists explicit use cases (board prep, M&A pricing, fundraising, DCF sanity checks), but does not provide when-not-to-use or alternatives among siblings. Context is clear enough for an agent.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'No auth required' and describes the output as a catalog with counts and recommendations. This gives a good sense of what the tool does and its safety profile, though it could mention idempotency or freshness.

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 sentence with no wasted words. It front-loads the key directive 'START HERE', and efficiently conveys purpose, content, and access requirement.

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 sufficiently explains the return value: a complete tool catalog with role-based recommendations. It mentions counts (107 public, 69 org) and content categories. For a discovery tool, this is adequate, though specifying output format or size limits could add clarity.

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 100%. The description naturally does not need to explain parameters. Baseline 4 is appropriate as there is no missing parameter information.

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

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

The description clearly states the tool returns the complete Stratalize tool catalog with role-based recommendations, and it explicitly positions itself as the entry point ('START HERE'). This differentiates it from the many sibling tools that each focus on a specific benchmark or intelligence area.

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 advises 'Call this first to discover all available tools', providing a clear usage context as an initial discovery step. It lists included content types (C-suite briefs, benchmarks, governance, org intelligence) but does not explicitly exclude scenarios where it might not be needed.

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 and destructiveHint. The description adds behavioral context by specifying exactly what signals are returned and providing an example. It doesn't cover rate limits or auth, but annotations suffice for safety profile.

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 plus a source line, all front-loaded with usage guidance and essential details. No redundant information; 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?

Since no output schema exists, the description must explain return values, which it does thoroughly by listing all signals and providing an example. It also notes data sources (FRED/EIA), making it fully self-contained.

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

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

There are no parameters, so the schema provides no meaning. The description compensates by fully enumerating the return fields and giving a usage example, adding significant value beyond the empty schema.

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

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

The description clearly states the tool's purpose: returning a full live signal stack for a macro agent. It lists specific signals (Fed funds, 2s10s, VIX, etc.) and provides an example, making it distinct from sibling tools which are 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 says when to use ('when a macro agent needs a full live signal stack in one call'). It does not directly name alternatives, but the context implies this is for composite signals, and the example usage further clarifies applicability.

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

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

With no annotations provided, description carries full burden. It states data source (Carta quarterly) but does not disclose behavioral traits like return format, update frequency, or read-only nature. Adequate but incomplete.

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 succinct sentences: what it provides, data source, and intended use. No fluff, front-loaded with key information.

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

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

Given no annotations or output schema, description covers main purpose and source but lacks return structure, limitations, or any behavioral details. Adequate for a simple query 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?

Schema description coverage is 0%, but parameter names and enum values are self-explanatory. Description mentions 'by stage and sector' but does not list specific enums; schema provides full set. No extra value beyond schema; baseline score of 3.

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

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

Description clearly states it provides venture capital round benchmarks (pre-money valuation, round size, dilution, option pool) by stage and sector, distinguishing it from many sibling benchmark tools like get_saas_metrics_benchmark or get_pe_portfolio_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?

Description mentions intended users (founders, VC CFOs, investors) and use cases (round pricing, cap table modeling), providing clear context. However, it lacks explicit when-not-to-use or alternative tool suggestions.

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

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

With no annotations, the description must disclose behavior. It reveals the data source (Damodaran's dataset), update frequency (annually in January), and that it's a benchmark. However, it does not clarify if the operation is read-only, what the return format looks like, or any limitations.

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

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

The description is two sentences plus an update note, very concise and front-loaded with the essential purpose. Every sentence adds value with no redundancy.

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

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

Given no annotations or output schema, the description covers source, use cases, parameters, and update cycle. It is sufficient for an agent to understand when to call this tool, though details on return format or error handling are missing.

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

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

The description mentions 'by sector and market cap tier,' which aligns with the two parameters. But with 0% schema description coverage, it adds little beyond the enum names themselves. No guidance on how to choose sectors or tiers is provided.

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

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

The description clearly states the tool provides WACC benchmarks by sector and market cap tier from Damodaran's dataset, listing specific use cases like DCF valuation and M&A pricing. It distinguishes itself from many benchmark siblings by focusing on WACC.

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 gives clear context for usage (DCF, M&A, board approval, capital allocation) and claims it's the most cited benchmark, implying it's the primary choice for WACC. However, it does not explicitly state when not to use or mention alternatives.

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

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

No annotations provided, so description carries full burden. It lacks behavioral details such as data freshness, update frequency, limits, or whether it returns a snapshot or historical data.

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

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

Two concise sentences front-loaded with key metrics and sources, no wasted words.

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

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

For a simple two-parameter benchmark tool with no output schema, the description covers what it returns and sources, though it could specify response format or scope more explicitly.

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%; description partially compensates by explaining that benchmarks are broken down by industry and company size, but does not list enum values or clarify optionality.

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?

Clearly states it provides working capital benchmarks (DSO, DPO, DIO, CCC) by industry and company size, distinguishing it from many other benchmark tools on the server.

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?

Mentions specific use case (CFO/treasury benchmark for lender covenant prep and cash flow optimization), but does not explicitly exclude alternatives or state 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 (readOnlyHint: true, destructiveHint: false) indicate safe read-only operation. The description adds value beyond annotations by detailing data source (World Bank), coverage (200+ countries, 1,400+ indicators, quarterly updates), and includes an illustrative example for Brazil, aligning with the read-only nature.

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 well-structured sentences: first sets usage context, second describes functionality and data source, third provides a concrete example. It is front-loaded and every sentence earns its place without redundancy.

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

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

Given no output schema, the description adequately explains return value (indicators with 5-year trend and direction) and provides data context. The example gives concrete expectation. Minor gap: precise output format is not specified, but the description is sufficient for tool 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 input schema covers two parameters with 50% description coverage (country_code explained; indicator has enums but no description). The description lists many indicators and explains their context (e.g., '5-year trend and direction'), adding meaning beyond the schema. However, not all enum values are explicitly enumerated in the description.

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

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

The description clearly states the tool's verb (Returns) and resource (World Bank development indicators) with specific indicators listed: GDP, inflation, unemployment, ease of doing business, government debt, FDI inflows. This distinguishes it from numerous sibling benchmark tools that focus on other 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?

The description explicitly lists use cases: assessing country risk, evaluating foreign markets, benchmarking economic trajectory, ESG scoring. It provides clear context for when to use, though it does not explicitly mention when not to use or direct to 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?

No annotations are provided, so the description must carry the burden. It mentions 'Live' and 'Source: FRED', indicating real-time data from a specific source. However, it does not disclose update frequency, rate limits, or error handling behaviors.

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

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

The description is a single well-structured sentence that front-loads key information: 'Live US Treasury yield curve' followed by specific metrics and data source. Every element 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?

Given the complexity of the tool (multiple yield curve metrics) and no output schema, the description lists the main return components. It is mostly complete but could clarify the return format (e.g., single object or time series). Still, the listed items provide good 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% and the description does not explain the single parameter 'tenor'. Moreover, the description mentions yields from 1M whereas the enum only includes 2y,10y,30y,all, creating a slight mismatch. No parameter semantics are added beyond the schema.

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

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

The description clearly states the tool provides 'Live US Treasury yield curve' with specific components like yields from 1M to 30Y, basis point changes, spreads, inversion signal, SOFR, and curve shape classification. It is specific and distinguishes from sibling tools.

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

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

The description implies usage for treasury yield curve data, but does not explicitly provide guidance on when to use this tool versus alternatives like get_yield_curve_data, which may be a sibling. No when-not-to-use or alternative references.

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