Silicon Analysts

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

Annotations declare read-only/idempotent, but the description goes far beyond by disclosing error behavior (INVALID_PARAMS), uncertainty (±15–20%), default process node, and scenario-specific caveats (energy as delta, CoPoS as forward-looking). No contradictions with annotations, which are reinforced by the 'Pure-function' framing.

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?

Well-structured with clear sections and front-loaded purpose. Every sentence provides operational guidance (defaults, error behavior, scenario caveats). Length is justified by the tool's complexity and the density of useful 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?

No output schema, but description enumerates all returned fields with units, explains conditional blocks (energy, substrateScenario), provides bounds, defaults, accuracy, and references siblings for external data. For a complex estimator with 18 parameters, this is comprehensive.

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

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

Schema has 0% description coverage for 18 parameters, but the description explains required bounds (1–33 mm), default processNode, energyRegion semantics (scenario delta), energyFacilityOverhead effect (~1.75× multiplier), and substrate scenario behavior—substantially compensating. Remaining numeric params (hbmCost, testCost, etc.) are inferable from names.

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

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

The description opens with a specific verb ('estimates') and resource ('chip cost'), enumerates the computed outputs, and explicitly contrasts with sibling tools (get_accelerator_costs, get_wafer_pricing). This leaves no ambiguity about the tool's scope.

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

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

Provides explicit 'USE THIS for' and 'DO NOT USE for' guidance, naming sibling tools for alternatives (get_accelerator_costs, get_wafer_pricing) and even directing users to get_wafer_pricing for valid process nodes. This is model usage guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds critical behavioral context: heuristic nature, LOW confidence, directional estimates, utilization threshold effects (≤80% best-case, ≥95% worst-case), and citation requirement. No contradiction with annotations—the tool is genuinely a read-only estimator.

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 long but every sentence earns its place. It is front-loaded with the core purpose, then organized into clear sections (USE THIS, DO NOT USE, parameter guidance). No redundancy or filler; structural clarity supports quick scanning.

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

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

Despite no output schema, the description enumerates all return fields (fabDays, fabWeeks, packagingWeeks, totalWeeks, effectiveDpml, operating-curve weight, assumptions, methodology, citations). It covers inputs, outputs, limitations, and alternatives, making the tool fully 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?

Schema description coverage is 0%, so the description carries full responsibility. It explains the maskLayers/processNode mutual exclusivity and acceptable values, packagingType class vs. platform IDs, utilization behavior, and valid ranges. This fully compensates 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 explicitly states the tool is a 'Heuristic chip manufacturing LEAD TIME estimator' with a clear verb ('estimates') and resource ('manufacturing cycle time'). It details inputs and outputs, and distinguishes itself from siblings by explicitly naming alternatives for different use cases (get_foundry_allocation for booking windows, calculate_chip_cost for costs).

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 an explicit 'USE THIS for' block listing appropriate scenarios (wafer-fab cycle time, sensitivity analysis) and a 'DO NOT USE for' block with named alternatives (get_foundry_allocation, calculate_chip_cost/get_accelerator_costs). This is the clearest possible guidance.

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

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

Annotations already declare readOnly/idempotent/hints; the description adds valuable behavioral context: returns empty array instead of erroring on no match, each record includes provenance.last_updated, and data refreshes monthly. 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 long but every sentence earns its place: main output, field list, use cases, exclusions, filter semantics, error behavior, freshness. It is front-loaded with the core purpose and ends with operational details, with no redundant 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 absence of an output schema, the description provides a full list of output fields. It also covers usage context, alternatives, parameter semantics, error behavior, data provenance and refresh cadence. For a tool with 3 optional params and no output schema, it is remarkably 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%, so the description must explain parameters. It does: 'Filters: vendor (enum), chip (substring match), fields (projection list).' This adds meaning beyond the raw schema properties, clarifying filter semantics and the nature of each parameter.

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 begins with a specific verb and resource: 'Returns 13 specific AI accelerators...' and enumerates the exact chips and data fields returned. It clearly distinguishes from siblings by naming its unique scope (cost comparison, published specs) and explicitly differentiating via the DO NOT USE section.

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

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

Provides explicit 'USE THIS for' and 'DO NOT USE for' sections with named alternatives (get_market_pulse, calculate_chip_cost, get_hbm_market_data). This gives unambiguous guidance on when to choose this tool over siblings.

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

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

Annotations already mark readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds substantial behavioral context: the bitemporal nature (as_of vs detected_at), curated backfill, full sourcing metadata taxonomy, grain-dependent rollup semantics, and access-tier behavior (free preview, Pro/Enterprise full, anonymous none). This greatly enhances transparency beyond the annotations.

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

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

Although the description is fairly long, it is well-structured with clear sections (overview, use cases, filters, access) and avoids redundancy. Every sentence contributes actionable information—scope, examples, alternatives, or constraints—making it appropriately sized for a complex tool with many parameters and access tiers.

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 explains return shapes ('month|quarter returns median/min/max rollups', 'raw returns per-source observations') and mentions source metadata fields. It also covers access tiers, filter semantics, and citation guidance, giving a complete picture for an agent to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate—and it does thoroughly. It lists all seven filters, marks benchmark_type as required, enumerates its allowed values, explains grain semantics (raw vs month/quarter rollups), and clarifies from/to as as_of bounds. This gives effective meaning to every parameter despite the schema's missing 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 opens with a specific verb and resource: 'Historical Benchmarks — the bitemporal benchmark-observations ledger...' and enumerates the exact data domains (wafer cost, defect density, CoWoS interposer, etc.). It explicitly differentiates from siblings by naming alternative tools for current point values and other APIs, making the purpose crisp and 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 includes a dedicated 'USE THIS for' block with concrete example queries and a 'DO NOT USE for' block that names specific alternative tools (get_wafer_pricing, get_packaging_costs) and API endpoints (/api/v1/snapshot-series, /api/v1/margin-trends). This offers explicit when-to-use and when-not-to-use guidance, going well beyond a generic statement.

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 idempotentHint=true, so the description focuses on adding value: it explains the default vs series modes, availability_status mapping, sourcing metadata, is_projection flag, and access-tier restrictions (free vs Pro/Enterprise). 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 lengthy but well-structured with clear sections (overview, USE THIS, DO NOT USE, Filters, Access, Cite). It is front-loaded with the core purpose and every section adds relevant operational detail, though it could be trimmed slightly without losing value.

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

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

With no output schema, the description thoroughly explains return contents: fab metadata, availability_status, sourcing metadata, citation, and is_projection. It also covers both modes, access tiers, and example queries, making it complete for a complex time-series 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 the description must carry the burden. It lists all 7 filters and clarifies 'as_of (latest-state cutoff)' and 'series (bool)', but does not explain value formats or matching behavior for fab_id, foundry, country, or tech_node_class. While examples mention node classes and countries, the semantics for exact parameter usage remain partially ambiguous.

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 'per-fab, per-tech-node-class capacity' from a named time-series, with a specific verb ('returns') and resource. It distinguishes from siblings by explicitly listing alternative tools for different granularities (node-level wafer starts, allocation/lead-time), making it 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 'USE THIS for' and 'DO NOT USE for' sections with concrete example queries and names the alternative tools (get_wafer_pricing, get_foundry_allocation). This fully addresses when to use the tool versus alternatives.

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

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

Annotations already cover read-only, idempotent, non-destructive, so the safety profile is known. The description adds valuable behavioral context beyond annotations: 'a delay never overwrites the original plan', 'is_projection for forward-dated milestones', and 'Full history Pro (never a 403)' — all non-obvious behaviors an agent needs to correctly interpret results.

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

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

The description is well-structured and front-loaded: a crisp definition, followed by use cases, exclusions, filters, and data shape. Each sentence adds distinct information, and the 'USE THIS'/'DO NOT USE' formatting makes it scannable. 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?

Without an output schema, the description explains the row structure in detail (foundry, fab_name, event_type, event_date, announced_date, summary, source URL, quote, is_projection). It also covers access levels and citation. The only notable gap is the semantics of the date-range parameters (to/from/since/all), but overall the tool is well understood.

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

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

Schema coverage is 0%, so the description must compensate. It does enumerate the meaningful filters (foundry, fab_id, event_type with allowed values in parentheses, country), which adds real semantics. However, it leaves to/from/since/all/limit undefined, and the difference between 'since' and 'from' is not addressed. Partial compensation warrants a 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?

The description opens with 'Fab Milestones — the dated construction & ramp event log' which clearly identifies the resource and its purpose. It goes on to list concrete event types and explicitly distinguishes from sibling tools like get_fab_capacity and get_foundry_allocation, making the tool's role unmistakable.

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

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

The description provides an explicit 'USE THIS for' section with concrete examples (tracking TSMC Arizona, Intel Ohio, etc.) and a 'DO NOT USE for' section naming alternative tools (get_fab_capacity for capacity, get_foundry_allocation for allocation). This is exactly the kind of when-to-use/when-not-to-use guidance the dimension calls for.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds access-tier behavior: 'full history (from/to/since/all) needs a Pro key — free callers get the latest slice with a note, never an error.' It also reveals the archived nature of data with original publication dates, going beyond structured metadata.

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

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

While longer than average, every sentence adds value: purpose, use cases, exclusions, filters, access tier, and citation. The structure is front-loaded and well-organized, with clear sections for usage, filters, and access rules.

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 there is no output schema, the description details the row structure ('Each row: originator, originator_type, metric, target_period...') and access behavior, making it fully complete for an AI agent to understand what the tool returns and how it behaves. It also covers edge cases like free-tier limitations and citation format.

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

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

With 0% schema description coverage, the description lists all primary filters (originator, originator_type, metric, target_period, entity_id) and explains from/to/since/all functionality, plus enum values and row fields like 'value (num or low/high), unit, as_of'. This substantially compensates for the schema's missing 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 opens with 'Forecast Vintages — third-party forecasts ... archived with their ORIGINAL publication date' and clearly explains the tool queries revision history. It distinguishes itself by stating it is a vintage archive of other organizations' forecasts, not our own scenario models.

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

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

Explicitly states 'USE THIS for: forecast revision tracking...' and 'DO NOT USE for: current cost/pricing values (use get_wafer_pricing / get_accelerator_costs); our own scenario projections...', giving direct alternatives. This provides clear when-to-use and when-not-to-use 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?

Beyond the readOnlyHint, the description adds significant behavioral context: data provenance (public estimates, human-reviewed), confidence tiers per record, intentional omission of wafer_price, citation requirements, and the structure of historical series. This provides a clear picture of what the tool returns and its 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 longer than typical but well-structured with clear sections (fields, use cases, filters, caveats). Every sentence adds value, and the formatting makes it easy to scan. It is appropriately sized for the tool's complexity.

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 the return fields and historical series structure. It also provides usage boundaries, filter options, and provenance details, making it a complete guide for an agent to select and invoke this tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It lists all filters and explains include_history and the history_metric enum values (lead_time, pct_locked, etc.) in the context of the historical series. However, it does not individually detail parameters like 'limit' or 'node', though their meaning is inferable from context.

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 function: 'Foundry & advanced-packaging ALLOCATION — the current-state snapshot per node/tech...'. It specifies the resource (allocation data) and provides a detailed list of fields, distinguishing it from related tools like get_fab_capacity and get_hbm_market_data.

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

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

Explicit 'USE THIS for' and 'DO NOT USE for' sections provide concrete when-to-use and when-not-to-use guidance, listing alternative tool names for each excluded use case (e.g., get_accelerator_costs, get_hbm_market_data).

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

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

Beyond annotations that mark the tool as read-only and idempotent, the description adds extensive context: sourcing from public IR materials, a documented scaling calculation, confidence levels, the free-vs-Pro clamping behavior, the handling of sparse-disclosure foundries with nulls/low confidence, and refresh cadence. It also discloses that node margin estimates are explicitly labelled estimates from public analysis.

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 long, but that length is justified by the tool's complexity and the absence of schema descriptions for 8 parameters. It is well-structured with clear sections for data coverage, usage guidance, filtering behavior, and caveats. Every sentence adds necessary information.

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

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

For a tool with 8 parameters, no output schema, and a mix of free/Pro behavior, the description covers all key aspects: return data, source provenance, confidence levels, node margin estimate details, filter syntax, free-tier limits, error behavior (never an error), and refresh timing. It is exceptionally complete.

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

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

Schema coverage is 0%, but the description richly compensates for every parameter. It explains foundry tokens, node canonical examples (n3, 22-28nm, 18a), node_group examples, quarter pattern (2026Q1|2025FY), and include_facts semantics. It also explains the behavioral meaning of the from/to and limit parameters in the context of Pro-key restrictions.

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

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

The description opens with a specific, resource-rich definition: 'per-foundry, per-process-node, per-fiscal-quarter wafer ASP and fab UTILIZATION'. It also distinguishes from siblings by naming concrete data sets (get_wafer_pricing, get_foundry_allocation) to avoid overlap.

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 includes explicit 'USE THIS for' and 'DO NOT USE for' sections with concrete example queries and alternative tool names. It clearly states when this tool is appropriate and when other tools are the correct choice.

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 note the tool is read-only, idempotent, and non-destructive. The description adds valuable context beyond this: it discloses the internal error condition when upstream tables are unreachable, the refresh schedule, and a semantic clarification about bitDemand (not a workload split). These are behavioral traits not captured by annotations.

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

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

The description is well-structured with clear sections and front-loaded purpose. While longer than average, every sentence earns its place—covering usage, exclusions, error behavior, and refresh schedule—without repetition or filler.

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

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

Given the tool's complexity and lack of an output schema, the description is remarkably complete. It covers what data is returned, how to filter, when not to use it, failure modes, and refresh timing, giving the agent everything needed for correct invocation.

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

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

The schema provides the optional `table` parameter with a 10-value enum. The description adds meaning by explaining that omitting the parameter returns all 10 sub-tables and by illustrating the kinds of data available (specs, market share, pricing, bit demand). However, it does not detail each enum value individually, so a 4 is appropriate.

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

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

The description clearly states that the tool returns 10 named HBM market sub-tables, with a specific verb ('Returns') and resource. It also distinguishes itself from siblings by explicitly naming alternative tools for different use cases.

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 'USE THIS for' and 'DO NOT USE for' sections, including named alternatives (get_accelerator_costs, calculate_chip_cost). This gives the agent clear decision rules for tool selection.

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

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

Annotations already declare readOnly and idempotent hints. The description adds substantial context: daily refresh, human review of status changes, return structure (matrix/timelines), anonymous truncation behavior, and citation requirements. No contradictions with annotations; instead, it enriches the agent's understanding of data freshness and access 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?

Well-structured with clear sections: core purpose, use/non-use examples, filter list, access details, and citation. Every sentence adds valuable information without redundancy. Despite its length, it remains focused and easy to scan.

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 thoroughly covers return objects (matrix and timelines) including example status transitions (sampling → in_qualification → qualified → volume_shipping). It also addresses freshness, review process, and anonymous limitations, making it complete for an agent to select and invoke the tool correctly.

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

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

Schema has 0% description coverage, so the description must carry the parameter burden. It lists all four filters and adds semantic detail (customer as substring, include_timelines as boolean controlling timeline output). However, it does not explain default values, filter combination logic, or the effect of omitting all filters, leaving some room for inference.

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 tracks HBM qualification status across vendors, customers, generations, and stack heights, with concrete examples (e.g., 'who supplies HBM4 for Vera Rubin?'). The DO NOT USE section explicitly distinguishes it from get_hbm_market_data and get_accelerator_costs, resolving sibling ambiguity.

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

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

Provides explicit USE THIS for and DO NOT USE for sections with alternative tool names, covering ideal use cases and exclusions. Also notes anonymous callers get truncated timelines and how to obtain full history, giving complete operational 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?

Beyond the annotations (readOnly, idempotent, destructive false), the description adds rich behavioral context: only human-confirmed wins are returned, nothing unvetted is exposed, timestamps are immutable, returns facts not claims, and the result set is empty until a win is confirmed. 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 long but highly structured with bolded sections (USE THIS, DO NOT USE, Filters). Every sentence adds distinct value: definition, output shape, use cases, exclusions, parameter semantics, emptiness behavior, and citation. No redundant or filler content.

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

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

With no output schema, the description thoroughly explains the return shape (first-seen timestamp, source publication time, first English coverage timestamp + URL/publisher, lead hours). It also covers filters, emptiness until confirmation, and citation guidance, making the tool fully understandable 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 description coverage is 0%, but the description names all three parameters with valid values and defaults (limit 1-100 default 25, order_by lead_time|recent, event_kind hbm_qual|capacity_signal|market_intelligence). This compensates for the lack of schema descriptions, though it does not deeply elaborate on the meaning of each event_kind value.

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

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

The description clearly states the tool returns human-vetted, dated, immutable proof of time-advantage for semiconductor supply-chain events. It specifies the exact resource (Market Advantage evidence) and distinguishes it from siblings by explicitly saying it is not for underlying data and naming alternative 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 includes explicit 'USE THIS for' and 'DO NOT USE for' sections with concrete example queries and named sibling tools (get_recent_changes, get_market_intelligence, get_hbm_qualification). It also notes that unconfirmed/pending races are not exposed, providing clear selection criteria.

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

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

Annotations indicate read-only, idempotent, non-destructive behavior; description adds tiering (anonymous vs free key vs Pro), methodUrl for methodology, and explains data point typing (Confirmed/Estimate/Projection) with no contradiction.

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

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

The description is fairly long but well-structured with clear sections and bullet points. Every sentence adds value; minor redundancy could be trimmed but remains efficient for the complexity.

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

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

Despite no output schema, description details return fields (value_low/mid/high, confidence, data_type, source), explains methodUrl, and mentions CSV/JSONL export for Pro callers, covering all necessary user context.

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

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

Schema coverage is 100% (baseline 3). Description adds context: dataset='list' enumerates catalog, series_key is optional filter, and tiering affects data access, providing extra guidance beyond schema.

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

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

The description clearly states it provides curated market-data time series with per-point sourcing, listing specific datasets (HBM pricing, component lead times, wafer price, etc.) and distinguishing itself from sibling tools for current snapshots or IR-derived 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?

Explicit sections 'USE THIS for' and 'DO NOT USE for' list appropriate use cases (e.g., HBM contract price history) and forbidden ones (e.g., current HBM snapshot, use get_hbm_market_data instead), guiding the agent to correct tool selection.

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

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

Annotations already indicate read-only and idempotent, but the description adds rich behavioral context: generated daily via Tavily + Claude, returns all severities with 'published' flag, public sources only, omits N2/Apple for conflict-safety, and per-record provenance. These details go well beyond the annotation hints.

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?

Although longer than typical, the description is efficiently structured into function, return fields, usage guidance, exclusions, and filters. Every sentence contributes necessary information for selection and invocation, and it is front-loaded with the core purpose.

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

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

With no output schema, the description thoroughly enumerates all return fields (title, severity, confidence_score, quantitative_impact, executive summary, analysis, category, sources, entities, impact, related) and explains filtering behavior. It is comprehensive enough for an agent to understand expected outputs and constraints.

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

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

The input schema has no property descriptions, but the description lists each filter with type details (severity, category, since as ISO timestamp, publishedOnly as bool, limit 1-100 default 25). This fully compensates for the 0% schema coverage, adding meaning beyond the raw 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 states the tool's purpose with a specific verb and resource: returns 'semiconductor market briefs' with daily generation and details each returned field. It distinguishes from siblings by mentioning 'UNIQUELY' features and explicitly listing alternatives in the DO NOT USE section.

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?

Explicit 'USE THIS for' and 'DO NOT USE for' sections provide concrete use cases and name alternative tools (get_accelerator_costs, get_wafer_pricing, calculate_chip_cost, get_recent_changes, get_foundry_allocation), making it clear when to select this tool versus others.

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

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

Annotations already indicate read-only/idempotent behavior. The description adds valuable non-obvious details: default filters (all categories/trends/no limit), date format caveat (not ISO 8601), server-side cache of 5 minutes, and empty-array behavior when filters match nothing. 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 well-structured with a clear first line stating the primary purpose, followed by usage guidance, exclusions, and caveats. Every sentence adds value, and the USE THIS/DO NOT USE sections make it scannable without excess verbosity.

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 list-returning tool with no output schema, the description is comprehensive. It explains what items contain (headline, trend, source, impact), available filters, default behavior, date formatting, cache behavior, and edge case (empty array). This is sufficient for an agent to invoke the tool correctly and interpret results.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions categories and trend direction in the main sentence and explains defaults ('Defaults to all categories, all trends, no limit'). However, it does not explicitly explain the 'limit' parameter semantics (e.g., maximum number of items) or clarify whether category/trend accept multiple values (schema shows single enum). Partial compensation but not complete.

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 curated supply-chain headlines with trend direction, source attribution, and impact analysis. It specifies categories (logic, memory, packaging, etc.) and defaults, making the scope distinct from siblings. The explicit 'DO NOT USE' section further differentiates it from pricing and cost 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?

Provides explicit USE THIS examples ('what's happening in HBM this quarter?') and DO NOT USE cases with named alternatives (get_wafer_pricing, get_hbm_market_data, get_accelerator_costs). This gives the agent clear decision criteria for tool selection.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful context: returns INVALID_PARAMS for unknown type and refreshes monthly. This discloses error behavior and data staleness, going beyond what annotations provide.

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

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

The description is well-structured and front-loaded: it starts with the main return values, then the optional parameter, then usage guidelines, then error and refresh behavior. Every sentence earns its place, with no redundancy.

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

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

For a read-only lookup tool with one optional parameter, the description covers the return structure, parameter semantics, error behavior, refresh frequency, and alternative tools. No output schema exists, but the return values are described adequately, making it complete for an agent to select and invoke the tool.

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

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

The schema has no description for the `type` parameter, so the description compensates by explaining it as an optional filter narrowing the packaging array to one technology. It also lists example technologies elsewhere in the description, giving the agent a good sense of valid values, though not an exhaustive list.

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 two sub-arrays (`packaging` and `hbmSpecs`) with specific content, using a specific verb and listing technology types. It also distinguishes from sibling tools by naming alternatives in the DO NOT USE section.

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 includes explicit 'USE THIS for' and 'DO NOT USE for' sections, naming get_hbm_market_data and get_accelerator_costs as alternatives. This provides clear when-to-use and when-not-to-use guidance, making the choice straightforward.

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, idempotentHint=true, destructiveHint=false. The description adds substantial context beyond this: it is grounded in government primary documents, excludes rumored/anticipated actions, notes tiered access ('Latest slice for all tiers; full history Pro (never a 403)'), and explicitly lists the output row fields. No contradictions with annotations.

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

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

Although the description is lengthy, it is well-organized with clear sections: definition, use cases, exclusions, filters, and access limitations. It is front-loaded with the core purpose and every sentence adds valuable operational information. There is no fluff or repetition of structured schema fields.

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

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

There is no output schema, but the description fully compensates by enumerating every row field (jurisdiction, agency, event_type, title, dates, affected_entities, node_threshold, document reference, source URL, verbatim quote). It also covers fidelity, scope, filter hints, and access tiering, making the tool's behavior and results predictable for an agent.

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

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

Schema has 0% description coverage and no enums, so the description must compensate. It explains jurisdiction (with enumerated allowed values), agency (with examples like BIS, USTR, MOFCOM), and event_type. However, it does not explain 'to', 'from', 'since', 'limit', or 'all' beyond their names, leaving some parameters under-specified. This is adequate but has clear 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 opens with a specific, concrete definition: 'Trade-Policy Timeline — the dated log of semiconductor trade-policy actions...' anchored to primary documents. This clearly distinguishes it from siblings like get_market_intelligence and get_fab_events by focusing on government policy events, not analysis or fab-level events.

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 'USE THIS for' and 'DO NOT USE for' guidance, naming the alternative tool (get_market_intelligence) and clarifying that only published actions are recorded. It also gives concrete example use cases, making it unmistakable when to invoke this tool.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description richly discloses behavior: returned fields (direction, magnitude, pct_delta vs pp_delta, old/new values, dates, window_days_actual with clamping behavior), provenance, N2/Apple omission, and the empty-array behavior instead of an error. This goes far beyond what annotations alone convey.

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

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

The description is front-loaded with the core purpose, then uses labeled sections (USE THIS, DO NOT USE, Filters) to organize information. Every sentence adds value—edge cases, parameter semantics, and output details—with no fluff. The length is justified by the tool's complexity and the absence of an output schema.

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 specifies the response structure including all fields and their types, explains the clamping behavior for young ledger history, edge cases like empty results, and the citation string. It also covers all parameters and domain list, making it entirely self-sufficient for an agent to select and invoke correctly.

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

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

Despite 0% schema description coverage, the description compensates fully by explaining every parameter: window's options and default, since's ISO date semantics and override behavior, datasetId limiting to one domain, minDelta as significance threshold, and limit. It adds meaning far beyond the bare schema types and constraints.

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

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

The description opens with 'What Changed' — recent MOVEMENTS... clearly identifying the tool's unique purpose of exposing deltas over 7d/30d windows rather than absolute values. It explicitly distinguishes itself from siblings by naming get_wafer_pricing / get_accelerator_costs / get_foundry_allocation for absolute values, and lists domains. This is a specific verb+resource+scope with clear sibling differentiation.

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

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

The description provides explicit 'USE THIS for' and 'DO NOT USE for' sections with concrete example queries and named alternative tools. It contrasts with sibling tools for absolute values and the specific allocation lead-time trend use case, covering both when to use and when not to use.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds multiple behavioral details beyond annotations: the exact error behavior 'Returns INVALID_PARAMS if node is not in the valid set', data freshness ('Refreshes monthly'), and presence of source attribution in each record. These are useful operational traits not inferable from the annotations.

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

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

The description is well-structured and front-loaded: the first sentence states the core output and valid inputs. Usage guidance is clearly formatted with 'USE THIS' and 'DO NOT USE' lines. Each sentence adds new information (error behavior, refresh cadence, source attribution) without redundancy. It is appropriately sized for the content it conveys.

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

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

For a tool with one optional parameter and no output schema, this description is exceptionally complete. It covers the return fields (price ranges, defect density, NRE/mask cost, node maturity), the closed set of valid nodes, error semantics, data freshness, and source attribution. It also positions the tool within the broader toolset via use/do-not-use guidelines, making it fully actionable for an agent.

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

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

The input schema only has a bare string property 'node' with zero documentation and no enum. The description fully compensates by enumerating the valid node values (tsmc-n3, tsmc-n5, tsmc-n7, tsmc-28, samsung-3nm, samsung-5nm, intel-16), explaining the optional filter behavior, and specifying the invalid-input error. This turns a cryptic schema into a fully self-documented parameter.

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 starts with a specific action and resource: 'Returns 300mm wafer price ranges (min/avg/max USD), defect density, NRE/mask-set cost, and node maturity' for a clearly enumerated list of nodes (tsmc-n3, tsmc-n5, etc.). It also distinguishes itself from siblings by explicitly stating what it covers (wafer cost, foundry comparison) and what it does not cover (per-chip cost, packaging). This is a textbook clear purpose with sibling differentiation.

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

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

The description explicitly states 'USE THIS for: looking up wafer cost for cost modeling, comparing foundries at the same node.' and then provides 'DO NOT USE for: per-chip cost (use get_accelerator_costs or calculate_chip_cost); packaging-related cost (use get_packaging_costs).' This names exact alternatives and exclusion criteria, going well beyond implied 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 already declare read-only, idempotent, non-destructive. The description adds valuable behavioral context beyond that: currency is never converted, includes source URL and verbatim quote, access tiers ('latest slice all tiers, full history Pro'), and an explicit note about never returning 403. This enriches the agent's understanding of what to expect.

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

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

The description is well-structured with clear sections: introduction, row format, usage guidance, filters, and access notes. Every sentence carries meaningful information without fluff. It is appropriately sized for the tool's complexity.

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 compensates by detailing the row structure (company, fiscal_period, metric, value(s), unit, as_of, source URL, verbatim quote) and the overall purpose of as a leading indicator. It covers access tiers and citations. Minor gaps remain regarding combining filters and date range semantics, but overall it is quite complete.

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

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

Schema coverage is 0%, so the description must compensate. It explains the key domain filters (company, metric, segment, fiscal_period) with explicit enum values for company and metric examples. However, generic parameters like to, from, since, all, and limit are not explained, leaving gaps in understanding how to query date ranges or pagination. The description adds value but is incomplete for all 9 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's function: retrieving WFE order-book signals from wafer-fab-equipment makers (ASML, AMAT, Lam, KLA, TEL) including bookings, backlog, segment revenue, and guidance. It specifies the data scope, currency behavior, and relationship to fab capacity, distinguishing it from the sibling tools via the 'USE THIS' and 'DO NOT USE' sections.

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?

Explicit usage guidance is provided: 'USE THIS for' lists concrete use cases and example questions, while 'DO NOT USE for' names specific alternatives (get_fab_capacity, get_foundry_economics). This gives the agent clear decision criteria for tool selection.

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