Skip to main content
Glama

get_hbm_market_data

Read-onlyIdempotent

Returns 10 HBM market sub-tables: accelerators, specs, marketShare, spotPrices (RETIRED 2026-07-28 — frozen), leadingIndicators, qualificationFeed, revenueForecast, supplierRevenue, validationChecks, bitDemand. Optional table parameter narrows to a single sub-table; omitting returns all 10.

USE THIS for: HBM3/3e/4 generation specs, SK Hynix/Samsung/Micron share of HBM revenue (marketShare: Q2 2026, Counterpoint Research, the latest quarter; the quarterly series and IDC full-year actuals are get_market_dataset dataset='hbm-market-share'; not share of bit shipments), derived HBM bit demand by SKU class and customer type (bitDemand, EB ranges, monthly).

spotPrices is a RETIRED series: no public HBM spot market exists in any generation — HBM sells via annual/multi-year LTAs. Its rows are frozen estimates served for the record with per-row retired marking; for current, sourced HBM pricing use get_market_dataset with dataset='hbm-pricing'.

bitDemand is NOT a workload split — it is a SKU-class/customer-type cut. Dominant HBM SKUs are dual-use, so a training-vs-inference HBM attribution would be dishonest; no public source publishes one.

DO NOT USE for: HBM price history or current HBM pricing (use get_market_dataset dataset='hbm-pricing'); 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. Only two sub-tables refresh on a schedule: qualificationFeed (Mon/Thu) and bitDemand (monthly, 1st). accelerators, specs and validationChecks are hand-curated reference tables, the editorial tables are revised by hand, and spotPrices is frozen (retired 2026-07-28). meta.table_freshness dates each sub-table; meta.data_freshness.stale flags an overdue refresh.

Input Schema

NameRequiredDescriptionDefault
tableNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / table / enum
      Previous value: -[
      -  "accelerators",
      -  "specs",
      -  "marketShare",
      -  "spotPrices",
      -  "leadingIndicators",
      -  "qualificationFeed",
      -  "revenueForecast",
      -  "supplierRevenue",
      -  "validationChecks"
      -]New value: +[
      +  "accelerators",
      +  "specs",
      +  "marketShare",
      +  "spotPrices",
      +  "leadingIndicators",
      +  "qualificationFeed",
      +  "revenueForecast",
      +  "supplierRevenue",
      +  "validationChecks",
      +  "bitDemand"
      +]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial operational context: INTERNAL_ERROR on upstream Supabase failure, per-sub-table refresh schedules (qualificationFeed Mon/Thu, bitDemand monthly), which tables are hand-curated vs. frozen, and the meta.table_freshness / meta.data_freshness.stale fields. The spotPrices retirement on 2026-07-28 is disclosed precisely.

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

Conciseness4/5

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

Front-loaded with the return shape and the narrowing behavior, followed by well-organized USE / DO NOT USE blocks. It runs long and repeats the ten sub-table names in the opening list and again during explanation, which is a minor redundancy rather than padding.

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 carries the return-value burden itself, exposing the meta freshness/staleness fields and the error mode. For a ten-sub-table aggregator with one optional enum parameter, an agent has everything needed to select a sub-table correctly and interpret freshness.

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

Parameters4/5

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

Schema coverage is 0% though the enum supplies the ten valid values; the description compensates by characterizing several of them (marketShare's source/period and its non-bit-shipment caveat, spotPrices' retired status, bitDemand's SKU-class/customer-type cut) and by explaining the semantics of omitting the parameter entirely (returns all 10). It falls short of describing all ten sub-tables equally.

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?

States a specific verb (Returns) and resource (10 HBM market sub-tables), enumerates them by name, and explains the optional narrowing behavior. It explicitly differentiates itself from siblings like get_market_dataset, get_accelerator_costs, and calculate_chip_cost by naming the separate sub-resources each covers.

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, each routing to a named alternative tool or dataset (e.g., 'use get_market_dataset dataset=hbm-pricing'). It also pre-empts a plausible misuse ('bitDemand is NOT a workload split') and corrects a common conflation (share of revenue vs. share of bit shipments).

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.

Resources