Skip to main content
Glama

get_wafer_pricing

Read-onlyIdempotent

Returns 300mm wafer price ranges (min/avg/max USD), defect density, NRE/mask-set cost, and node maturity for: 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. Optional node filter narrows to one. ALWAYS read citation before using a price in a cost model: it names the corroborating sources and carries the caveat that decides whether the number is usable. Some sellers report a foundry segment operating loss, so their quote is a positioning price rather than a cost-recovering one; citation says so explicitly, and defectDensity/nreCost are null where no public basis exists rather than being estimated.

USE THIS for: looking up wafer cost for cost modeling, comparing foundries at the same node.

DO NOT USE for: per-chip cost (use get_accelerator_costs or calculate_chip_cost); packaging-related cost (use get_packaging_costs).

Returns INVALID_PARAMS if node is not in the valid set. Each record carries the source attribution string. Refreshes monthly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodeNo

Schema Changelog

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

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds significant behavioral context: always read `citation` before using a price, caveat about operating loss quotes, null values where no public basis exists, INVALID_PARAMS error, and monthly refresh. 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.

Conciseness5/5

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

The description is longer than typical, but every sentence adds value: core data fields, valid nodes, usage guidance, data caveats, and error/refresh behavior. It is well-structured with clear sections (what, usage, important caveat, error/refresh) and no filler.

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?

With no output schema, the description must explain return values, which it does thoroughly: it lists all data fields (price ranges, defect density, NRE, maturity), mentions source attribution and null values, and states the refresh schedule. Considering complexity (many nodes, multiple fields, caveats), the description is fully adequate for an agent to correctly select and invoke the tool.

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?

Only one parameter `node` exists, and the description gives a full list of valid values, states that it's optional, and explains the consequence of passing an invalid node (INVALID_PARAMS). This far exceeds the 0% schema description coverage, fully compensating for the lack of enum definitions.

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 clearly states the tool 'Returns 300mm wafer price ranges (min/avg/max USD), defect density, NRE/mask-set cost, and node maturity' for a specific enumerated list of nodes. It uses a specific verb and resource, and explicitly distinguishes itself from sibling tools like get_accelerator_costs and get_packaging_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?

Provides explicit 'USE THIS for' and 'DO NOT USE for' sections with named alternatives (get_accelerator_costs, calculate_chip_cost, get_packaging_costs). Also clarifies that the `node` filter is optional and gives error behavior for invalid input.

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

Try in Browser

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