Silicon Analysts

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

Describes error behavior (INVALID_PARAMS for bounds), default processNode, and estimation accuracy (±15-20%). No annotations provided, so description carries full burden; it is mostly transparent but could mention idempotency.

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?

Concise and well-structured with clear sections. Every sentence adds value, no fluff. Front-loaded with purpose and output summary.

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?

Covers essential context: return values, required inputs, defaults, bounds, accuracy. Lacks detailed parameter descriptions but sufficient for a costing tool with high-level parameters.

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 coverage, the description adds constraints (1-33 mm reticle limit) and mentions key parameters (dieWidth, dieHeight, processNode, packaging/HBM). However, not all 14 parameters are described, leaving 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 is a 'pure-function chip cost estimator' and lists its outputs. It distinguishes from siblings by specifying exclusions like 'published cost of an existing accelerator' and 'wafer pricing only'.

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 provides 'USE THIS for' and 'DO NOT USE for' sections, naming alternative tools (get_accelerator_costs, get_wafer_pricing) and giving clear when-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?

With no annotations, the description carries full burden. It discloses that the tool returns an empty array with no error on no-match, mentions monthly data refresh and provenance.last_updated. It implicitly suggests read-only behavior but could explicitly state read-only/no-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 economical, front-loading the return structure, followed by usage guidelines, then filter behavior. Every sentence adds value, 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 output schema, the description fully enumerates all return fields, covers parameter semantics, usage boundaries, and data refresh policy. It is complete for the tool's complexity and sibling 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%, but the description explains chip as substring match, fields as projection list, and vendor enum values. This adds significant meaning beyond the bare 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 returns 13 specific AI accelerators with structured fields. It uses a specific verb 'Returns' and resource 'AI accelerators', and distinguishes from siblings by listing explicit alternatives for other 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' guidance, naming specific alternative tools (get_market_pulse, calculate_chip_cost, get_hbm_market_data) and contexts, leaving no ambiguity about 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?

No annotations provided, so the description carries full burden. It transparently states data sources (public estimates, human-reviewed), provenance tracking, and intentional omission of wafer_price. It implies read-only behavior but does not explicitly declare destructiveness or lack thereof. Overall, it provides good behavioral context beyond the minimal schema.

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

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

The description is relatively long but well-structured: a lead sentence, field list, usage guidelines, filter list, and sourcing info. It is front-loaded with the key purpose and uses bullet-like formatting. A few sentences could be trimmed without losing meaning, but it is organized and informative.

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 7 parameters, no output schema, and no annotations, the description covers the data returned, usage context, and data quality. It explains the return fields and sourcing. It does not describe the return structure (e.g., JSON format), which might be needed for full completeness, but it is otherwise comprehensive for an agent to use this tool effectively.

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

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

Schema description coverage is 0%, so the description must compensate. It lists the seven filter parameters (foundry, node, etc.) and provides context through usage examples (e.g., 'what's the booking lead time for N2?'). However, it does not explain each parameter's meaning or format in detail, leaving some ambiguity for an agent.

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 current allocation snapshot and optional history for foundries/advanced packaging, with a specific verb 'get' and resource 'foundry allocation'. It distinguishes from siblings by explicitly listing alternative tools for related queries (e.g., per-chip cost, HBM 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 includes explicit 'USE THIS for' and 'DO NOT USE for' sections, providing concrete query examples and naming the correct sibling tools (get_accelerator_costs, get_hbm_market_data, etc.), making it unambiguous when to select 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?

Discloses potential INTERNAL_ERROR when upstream tables are unreachable and monthly data refresh. Without annotations, this is sufficient behavioral context, though idempotency is implied but not stated.

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?

Five sentences covering all necessary information without redundancy. Slightly could be improved with bullet points for the list, but overall efficient.

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

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

Given the single optional parameter and no output schema, the description fully covers input, output, error scenarios, refresh cadence, and usage boundaries, making it complete 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?

With 0% schema description coverage, the description compensates by explaining that omitting the parameter returns all 9 sub-tables and specifying the effect of using it, adding meaning beyond the enum list in the schema.

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

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

The description clearly states it returns 9 specific HBM market sub-tables, lists them, and explains the optional table parameter. It distinguishes from sibling tools by specifying what not to use it for.

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 provides 'USE THIS for' and 'DO NOT USE for' sections with specific alternative tools (get_accelerator_costs, calculate_chip_cost), guiding 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?

Although no annotations are provided, the description discloses behavioral traits such as daily refresh, human review of status changes, truncation of timelines for anonymous callers, and the requirement of an API key for full history. This adds value beyond typical read-only expectations.

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

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

The description is well-structured with sections, but is somewhat lengthy. However, it front-loads the core purpose and uses bullet-like lists for clarity. Every sentence serves a purpose, though minor trimming could improve conciseness.

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

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

Despite lacking an output schema, the description details the return structure (matrix and timelines with per-relationship history). It covers all relevant context: filters, use cases, data freshness, source attribution, and access restrictions. The tool is fully explained without requiring further inference.

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, so the description compensates by explaining each filter: vendor (enum), customer (substring), generation (enum), include_timelines (boolean). It adds meaning by describing how to use them (e.g., substring matching for customer) and notes the truncation behavior for timelines.

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 defines the tool as a 'Sourced HBM qualification tracker' that returns qualification status per vendor, customer, and generation. It uses specific verbs like 'returns' and lists outputs (matrix, timelines), distinguishing it from sibling tools with explicit 'USE THIS for' and 'DO NOT USE for' 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?

The description explicitly states when to use this tool (e.g., 'who supplies HBM4 for Vera Rubin?') and when not to use it, naming alternatives like get_hbm_market_data and get_accelerator_costs. This provides clear decision guidance for 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 provided, so description fully covers behavior: defaults (all categories, all trends, no limit), date format (non-ISO 8601 strings), cache duration (5 minutes server-side), and response when all items filtered out (empty array). No contradictions with missing 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?

Description is efficient: first sentence captures core function, second provides usage guidance, third handles exclusions, fourth adds technical details. Every sentence adds value with 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?

Despite no output schema, description covers return content (headlines with trend, source, impact), filtering behavior, date format, caching, and edge case (empty array). Complete for a headline 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%, but description adds meaning to all three parameters: lists category enum values, explains trend direction, and clarifies limit (default no limit). Also explains per-item date format not reflected in 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 curated supply-chain headlines with trend direction, source attribution, and impact analysis. It specifies categories (logic, memory, etc.) and distinguishes itself from sibling tools by explicitly stating when NOT to use it.

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 concrete example queries like 'what's happening in HBM this quarter?' and explicit exclusions: 'DO NOT USE for structured pricing data (use get_wafer_pricing, get_hbm_market_data); published cost of a specific chip (use get_accelerator_costs).'

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?

Discloses behavior: returns two sub-arrays, optional filter, error handling (INVALID_PARAMS for unknown type), and refresh cadence (monthly). Somewhat lacking explicit read-only hint, but overall transparent given no annotations.

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

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

Three concise paragraphs. First sentence states return structure, second gives use/non-use guidance, third covers error and refresh. No fluff; 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?

Covers return structure, parameter usage, error handling, refresh rate, and differentiation from siblings. No output schema provided, but description sufficiently explains return format for a lookup 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 0% description coverage, but description compensates by explaining that optional 'type' filter narrows the packaging array to one technology. Could be improved by listing valid technology values, but adds meaningful context beyond bare 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?

Description uses specific verb 'Returns' and clearly identifies two sub-arrays ('packaging' and 'hbmSpecs'), listing exact technologies included. Differentiates from siblings by explicitly stating when not to use (e.g., use get_hbm_market_data for market dynamics).

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?

Includes explicit 'USE THIS for:' and 'DO NOT USE for:' sections with concrete alternative tool names (get_hbm_market_data, get_accelerator_costs), leaving no ambiguity about 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?

With no annotations, the description fully discloses behavior: return fields (direction, magnitude, old/new values, dates), clamping of window for young ledger, empty array on no changes, omission of N2/Apple, and citation instruction.

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 labeled sections, providing substantial information without being overly verbose; minor redundancy in the first sentence could be tightened.

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

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

The description covers input parameters, output fields, edge cases (young ledger, empty array), usage guidance, and domain list, making it fully informative for an agent to 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 coverage, the description explains each parameter's role and acceptable values (e.g., window as 7d|30d, datasetId as domain, minDelta as significance threshold), adding necessary 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 identifies the tool as returning recent movements in data over 7d/30d windows, with explicit domains and contrast to sibling tools like get_wafer_pricing and get_foundry_allocation.

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 'USE THIS for' and 'DO NOT USE for' sections provide concrete scenarios and direct alternatives, making it extremely clear when to invoke 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?

Without annotations, the description discloses error behavior (returns INVALID_PARAMS for invalid nodes), data freshness (monthly refresh), and source attribution. It implicitly indicates a read-only query. Slight deduction for not explicitly stating idempotency or lack of side effects, but sufficient for a pricing 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?

Four sentences front-load the core purpose, then provide usage guidelines, then error behavior and refresh. 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?

Covers all key aspects: input (allowed nodes, optional filter), output (price ranges, defect density, NRE/mask-set, node maturity), error handling, and data freshness. No gaps remain given the tool's 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 parameter with no description (0% coverage). The description adds full meaning by listing valid values and explaining the optional filter. This compensates completely for the schema's lack of detail.

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

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

The description clearly states 'Returns 300mm wafer price ranges...' for specific nodes, making the verb and resource explicit. It distinguishes from sibling tools by specifying alternatives for per-chip and packaging 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?

Explicitly provides 'USE THIS for' and 'DO NOT USE for' sections, naming alternative tools like get_accelerator_costs and get_packaging_costs. This leaves no ambiguity about 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.