Skip to main content
Glama

Silicon Analysts

by io.github.SiliconAnalysts

estimate_lead_time

Read-onlyIdempotent

Heuristic chip manufacturing LEAD TIME estimator (MANUFACTURING CYCLE TIME). Given total mask layers (or a processNode to default them), foundry utilization % (optional — defaults from live foundry-allocation data), and packagingType, returns min/max bands: fabDays, fabWeeks, packagingWeeks, totalWeeks, plus effectiveDpml (days per mask layer), the operating-curve weight, a resolved-inputs echo, assumptions, methodology, and public-source citations.

USE THIS for: "how long to manufacture this chip" — wafer-fab cycle time + packaging assembly/test time for hypothetical chips; cycle-time sensitivity to fab utilization or packaging class (conventional vs flip-chip vs CoWoS).

DO NOT USE for: booking windows / allocation lead time — how long until a booked-out foundry STARTS wafers, publicly 52–156+ weeks at N3-class nodes and CoWoS (use get_foundry_allocation); chip cost (use calculate_chip_cost / get_accelerator_costs).

Provide maskLayers (integer 10–200) or processNode (tsmc-n3 | tsmc-n5 | tsmc-n7 | tsmc-n16 | tsmc-28 | samsung-3nm | samsung-5nm | samsung-7nm | samsung-14nm | intel-7 | intel-16 | gf-12lp | gf-fdx | umc-22-28 | umc-40 | smic-28). packagingType accepts coarse classes (conventional | flip-chip | cowos, default flip-chip) or any platform packaging id (fc-bga, wirebond-bga, cowos-l, copos, ...). Utilization ≤80% settles at the best-case band; ≥95% converges to the worst-case bound (FabTime operating-curve shape). Heuristic from public DPML benchmarks — directional, confidence LOW, not a foundry quote. Cite as "Silicon Analysts — Lead Time Estimator".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
maskLayersNoTotal mask-layer count, integer 10–200. REQUIRED unless the other of maskLayers/processNode is provided.
processNodeNoProcess node id, e.g. 'tsmc-n3'. Supplies the node-typical mask count. REQUIRED unless the other of maskLayers/processNode is provided.
utilizationNoFoundry utilization, percent 0–100. Genuinely optional — defaults from live foundry-allocation data.
packagingTypeNoPackaging class or platform packaging id. Genuinely optional — defaults to 'flip-chip'.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed4 schema fields changed
    • addedInput schema / properties / maskLayers / description
      Added value: +"Total mask-layer count, integer 10–200. REQUIRED unless the other of maskLayers/processNode is provided."
    • addedInput schema / properties / packagingType / description
      Added value: +"Packaging class or platform packaging id. Genuinely optional — defaults to 'flip-chip'."
    • addedInput schema / properties / processNode / description
      Added value: +"Process node id, e.g. 'tsmc-n3'. Supplies the node-typical mask count. REQUIRED unless the other of maskLayers/processNode is provided."
    • addedInput schema / properties / utilization / description
      Added value: +"Foundry utilization, percent 0–100. Genuinely optional — defaults from live foundry-allocation data."
  2. Added

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description goes well beyond that: it discloses that the estimate is heuristic, directional, low-confidence, NOT a foundry quote, that it returns min/max bands rather than point values, that it echoes resolved inputs, and that it includes assumptions, methodology, and public-source citations. No contradiction with annotations exists.

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

Conciseness5/5

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

The description is long but tightly structured into purpose, use-cases, exclusions, input requirements, behavioral thresholds, and citation guidance. Every major section carries decision-relevant information, and the most critical routing information is front-loaded with the USE/DO NOT USE sentences.

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

Completeness5/5

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

For a tool with four parameters, no output schema, and twenty siblings, this description covers everything an agent needs to invoke it correctly: inputs, defaults, accepted values, return fields, limitations, methodology, and alternatives. The inclusion of the required mutual-exclusion constraint and the public citation naming removes the remaining ambiguity.

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

Parameters5/5

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

Although schema description coverage is 100%, the description adds meaning the schema lacks: the maskLayers/processNode are mutually exclusive alternatives with 'REQUIRED unless the other is provided', the full accepted processNode list appears only in the description, packagingType is grouped into coarse classes vs platform IDs with a default, and utilization semantics include real behavioral thresholds. This materially improves correct parameter selection.

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

Purpose5/5

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

The description names a specific resource and verb: a heuristic chip-manufacturing LEAD TIME estimator (manufacturing cycle time). It enumerates the returned fields and explicitly distinguishes itself from siblings by stating what it is NOT for—allocation lead time and chip cost—so the agent can disambiguate it from get_foundry_allocation, calculate_chip_cost, and get_accelerator_costs.

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

Usage Guidelines5/5

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

The description contains explicit USE THIS FOR and DO NOT USE FOR sections that name the alternative tools to choose instead and the exact conditions that route to them. It also provides decision-relevant boundary behavior for utilization values (≤80% best-case, ≥95% worst-case), making the intended invocation unambiguous.

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

All Silicon Analysts toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation3/5

Several tools overlap in domain and purpose, such as get_market_pulse vs get_market_intelligence and get_wafer_pricing vs get_foundry_economics. The detailed USE/DO NOT USE sections help, but the tool names alone do not always make the distinction obvious, requiring careful reading to avoid misselection.

Naming Consistency4/5

18 of 20 tools follow a consistent get_<noun> pattern, with calculate_chip_cost and estimate_lead_time as minor deviations. No chaotic mixing of camelCase or inconsistent verb styles; the overall scheme is predictable and readable.

Tool Count4/5

20 tools is slightly above the ideal 3-15 range but reasonable for the server's broad scope covering cost modeling, capacity, allocation, HBM, policy, and market intelligence. Each tool has a distinct niche, though a few could potentially be consolidated.

Completeness4/5

The server provides comprehensive coverage of semiconductor cost estimation, market data, fab capacity, allocation, HBM qualification, and policy timelines. Minor gaps exist (e.g., no dedicated memory pricing tool or general search), but these are covered through get_market_dataset and other tools; there are no critical missing functions for the stated domain.

Resources