Silicon Analysts
Server Details
Semiconductor data: AI accelerator costs, HBM, wafer pricing, packaging, chip cost calculator.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 6 of 6 tools scored.
Each tool targets a distinct aspect of semiconductor cost analysis (hypothetical chip cost, existing accelerator costs, HBM market data, market pulse news, packaging costs, wafer pricing). The extensive 'USE THIS for / DO NOT USE for' guidance eliminates ambiguity, making it clear which tool to select for a given query.
Five of six tools follow a consistent 'get_' pattern (get_accelerator_costs, get_hbm_market_data, get_market_pulse, get_packaging_costs, get_wafer_pricing). The outlier calculate_chip_cost uses 'calculate_' instead of 'get_', but this verb accurately reflects its computational nature, making the deviation minor and meaningful.
With six tools covering chip cost estimation, existing accelerator data, HBM market data, market news, packaging costs, and wafer pricing, the count is well-scoped for the domain of semiconductor cost analysis. Each tool earns its place, and the set is not overly large nor insufficient.
The tools cover the core lifecycle of cost analysis: hypothetical chip modeling, actual chip costs, wafer pricing, packaging, HBM market data, and market pulse. Minor gaps exist (e.g., no dedicated tool for advanced packaging beyond CoWoS, or for long-term supply forecasts), but the surface is largely complete for typical cost-query workflows.
Available Tools
6 toolscalculate_chip_costAInspect
Pure-function chip cost estimator. Given die dimensions (mm), process node, and optional packaging/HBM parameters, returns: estimatedChipCost (USD), dieArea (mm²), grossDiesPerWafer, frontendYield (%), totalYield (%), and a costBreakdown {waferCostPerGoodDie, packagingAndTestCost, hbmCost, marginCost}.
USE THIS for: hypothetical chip cost modeling, sensitivity analysis, fabless tapeout decisions.
DO NOT USE for: published cost of an existing accelerator (use get_accelerator_costs); wafer pricing only (use get_wafer_pricing).
Required: dieWidth, dieHeight (1–33 mm reticle limit). Errors with INVALID_PARAMS if outside bounds. processNode defaults to tsmc-n5; valid nodes via get_wafer_pricing. Estimates are directional ±15–20%.
| Name | Required | Description | Default |
|---|---|---|---|
| volume | No | ||
| hbmCost | No | ||
| dieWidth | Yes | ||
| testCost | No | ||
| dieHeight | Yes | ||
| hbmStacks | No | ||
| waferCost | No | ||
| yieldModel | No | ||
| processNode | No | ||
| backendYield | No | ||
| marginTarget | No | ||
| defectDensity | No | ||
| packagingCost | No | ||
| packagingType | No |
Tool Definition Quality
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.
get_accelerator_costsAInspect
Returns 13 specific AI accelerators (H100/H200/B100/B200/GB200, MI300X/MI355X, Gaudi 3, TPU v5p, Trainium 2, Maia 100, MTIA v2) with structured fields: chip, vendor, processNode, dieSizeMm2, memoryType, memoryCapacityGb, memoryBandwidthTbS, fp8TflopsSparse, bf16TflopsDense, packageType, estMfgCostUsd, estSellPriceUsd, chipGrossMarginPct, costBreakdown.{logicDie, hbm, packaging, testAssembly}, interconnect.
USE THIS for: comparing manufacturing cost or sell price across vendors; looking up published specs of a specific shipping accelerator.
DO NOT USE for: chips not yet shipping (use get_market_pulse for forecasts); custom chip cost modeling (use calculate_chip_cost); HBM market dynamics (use get_hbm_market_data).
Filters: vendor (enum), chip (substring match), fields (projection list). Returns empty array if filters match nothing — does not error. Each chip record carries provenance.last_updated; data refreshes monthly.
| Name | Required | Description | Default |
|---|---|---|---|
| chip | No | ||
| fields | No | ||
| vendor | No |
Tool Definition Quality
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.
get_hbm_market_dataAInspect
Returns 9 HBM market sub-tables: accelerators, specs, marketShare, spotPrices, leadingIndicators, qualificationFeed, revenueForecast, supplierRevenue, validationChecks. Optional table parameter narrows to a single sub-table; omitting returns all 9.
USE THIS for: HBM3/3e/4 generation specs, SK Hynix/Samsung/Micron market share, spot vs. contract pricing.
DO NOT USE for: per-accelerator HBM cost in a specific chip (use get_accelerator_costs.costBreakdown.hbmCostUsd); HBM cost in a hypothetical chip cost calc (use calculate_chip_cost with hbmStacks/hbmCost).
Returns INTERNAL_ERROR if the upstream Supabase HBM tables are unreachable. Data refreshes monthly.
| Name | Required | Description | Default |
|---|---|---|---|
| table | No |
Tool Definition Quality
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.
get_market_pulseAInspect
Returns curated supply-chain headlines with trend direction (up/down/neutral), source attribution, and impact analysis. Categories: logic, memory, packaging, connectivity, power, geopolitics. Defaults to all categories, all trends, no limit.
USE THIS for: "what's happening in HBM this quarter?", "any geopolitical moves affecting TSMC?", recent supply/demand inflections.
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).
Per-item dates are formatted strings (e.g., "Jan 2026") — not ISO 8601. Cache: 5 minutes server-side. Returns empty array if all items filtered out.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| trend | No | ||
| category | No |
Tool Definition Quality
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.
get_packaging_costsAInspect
Returns two sub-arrays: packaging (per-tech cost benchmark + capability matrix for CoWoS-S/L, EMIB, SoIC, InFO-PoP, FC-BGA, FC-CSP, etc.) and hbmSpecs (HBM2 through HBM4 cost per stack + bandwidth/capacity). Optional type filter narrows packaging array to one technology.
USE THIS for: packaging cost lookup, comparing CoWoS variants, getting HBM stack pricing for cost modeling.
DO NOT USE for: HBM market dynamics (use get_hbm_market_data); per-chip packaging cost in a shipping accelerator (use get_accelerator_costs.costBreakdown.packagingCostUsd).
Returns INVALID_PARAMS for unknown type. Refreshes monthly.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No |
Tool Definition Quality
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.
get_wafer_pricingAInspect
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-28, samsung-3nm, samsung-5nm, intel-16. Optional node filter narrows to one.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| node | No |
Tool Definition Quality
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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!