Gambit

Get semiconductor world model

get_semis_world

Read-onlyIdempotent

Read Gambit's semiconductor world model (api:read): companies across the chain (upstream equipment and materials, foundry, memory, packaging and assembly, downstream device makers) with tickers, stages and reported revenue; sites (wafer, logic, DRAM, NAND and specialty fabs, advanced packaging, HBM back end, OSAT and assembly plants, substrate, materials and equipment plants, datacenters) with coordinates and capacity; supplier flows (who sells what to whom); device bills of material; dated events; a DRAM supply/demand scenario model run (its fit compared with a no-change baseline, plus a holdout) with each device's memory cost; and a catalog of free official data series with a rights verdict for each. Every number carries its source, as_of and basis (reported, estimated or derived). view=overview (counts, stages, facility types, the model's fit and holdout); companies (filter stage, country, search); company (needs id from view=companies: the company with its sites, sells_to, buys_from, events and products); facilities (kind = facility type such as dram_fab or adv_packaging, country, company, search); flows (company on either side, kind = text in the product so hbm also finds hbm3e and hbm4, search over companies, product and note; the company view shows each flow's share_of_buyer_pct and share_of_seller_pct, each with its own as_of and unit: a seller share can be of revenue (filed customer concentration) or of capacity, so read the unit and note); events (newest first; company, kind, since=YYYY-MM-DD, search); products (kind = category, search); series (curated time series: without id a catalog with rows, first and last period and units, e.g. Korea chip exports since 2015, the Bank of Korea DRAM export price index, TrendForce contract prints back to 2008, accelerator volumes, EUV shipments; ids that come in bulk are one family row whose series ends in :* with a series_count, and search = the family name lists its ids; with id that series' rows, newest kept when truncated; a series can mix units or statistical bases, so read each row's unit and note); model; catalog. Lists return total, returned, truncated and items, limit 1-200 (default 50). Research, log-only: not a forecast claim and not a recommendation. Read-only; a refused query says why.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_semis_world"
  }
}

Input Schema

Name	Required	Description	Default
`id`	No	Company id for view=company (ids from view=companies, such as samsung), or a series id for view=series (ids from view=series).
`kind`	No	facilities: facility type (view=overview facility_types); flows: text in the product (hbm matches hbm3e, hbm4); events: event kind; products: category.
`view`	No	Besides the views in the tool description: dependencies (needs id = a company) walks the supplier flows up to 3 hops each way: upstream is what the company depends on (its suppliers, then theirs), downstream is who is hit if it stops, each with the shortest path, the products on every hop and any recorded share, plus recent events at companies within 2 hops (since=YYYY-MM-DD, default the last 90 days) and the company's equity and joint-venture ties; kind=upstream or downstream keeps one side. chokepoints lists where the recorded chain is thin: dominant_sources (one seller covers at least half of a buyer's purchases of a product), customer_dependence (one buyer takes at least 15% of what a seller sells) and most_depended_on (companies ranked by how many buyers they dominate, then by how many buyers they have). Both describe the flows the model records, not the whole industry: a company with few edges is thinly researched, not independent. throughput is the hardware side of token prices: tokens per second per accelerator (H100, H200, B200, B300, MI300X, MI355X and others) on LLM benchmarks, derived from MLPerf Inference datacenter results (the system result divided by its accelerator count: our division, not an MLPerf metric), with mtok_per_gpu_hour, usd_per_mtok_per_usd_gpu_hour (multiply by a GPU-hour rental price for a cost per million tokens at benchmark load) the purchase price per token-per-second where a price is recorded, and energy where NVIDIA publishes a DGX power rating for the accelerator (kWh per GPU-hour and per million tokens at the eight-GPU system's maximum rated power divided by eight, priced at the US average industrial electricity rate; a proxy from NVIDIA's rating, not the benchmarked server's measured power; those are chassis figures, and with_facility_overhead brackets cooling and facility overhead as [low, high] pairs using Google's fleet PUE and a survey average for sites of 20 MW and above, other sites' overhead and not this one's); id = accelerator, kind = benchmark such as llama3.1-405b, search = server or offline. Benchmark load is not one user's speed and fleets run below it. frontier shows that trade directly, from MLPerf Endpoints results: for a served system and model (NVIDIA GB300 and GB200 NVL72 racks, an 8 x MI300X server, 4 x Intel Arc Pro B70, a CPU-only server; DeepSeek-R1, gpt-oss-120b, Llama 3.1 8B) measured at a ladder of concurrent loads, the load with the highest total tokens per second (peak) and, for median per-user streaming speeds of 20, 50 and 100 tokens per second, the highest-throughput load at which the median request still streams that fast (half the requests at that load stream slower, so it is the typical user's speed and not a guaranteed floor), with million tokens per accelerator-hour at each and its share of peak; id = a system (such as nvidia-gb300-nvl72) adds every measured point with first-token delay, kind = model. Only the system total and the first-token delay come from the result, and each point's basis says whether the total is the result's reported figure or derived from its token count and run time; median per-user speed (one over the median time per output token) and per-accelerator figures are our derivations, not MLPerf metrics. The model also records the financial rails AI agents use: settlement networks (stage=rail: Hyperliquid, Base, Robinhood Chain, Arc, Tempo, Elysium and others), venues, tokens and agent-payment standards (stage=payment_standard: x402, AP2, ACP, MPP, ERC-8004), who operates each, which standards each implements, and which on-chain instruments reference a company (a company's ties with relation listing); series ids starting hl_ and x402_ hold a dated snapshot. rails compares those networks in one table: stablecoins on each with the largest issuers, DeFi value locked, the last complete month of spot DEX volume, the change over twelve months, each rail's share of the listed rails and how often its stablecoins turned over in spot trading, plus Hyperliquid's exchange fees and the part that buys or burns HYPE (DefiLlama's adapter figures: perp fees include a stablecoin reserve-yield share and spot fees include auction burns, as the block's method line says); id = one rail (such as hyperliquid, base, robinhood_chain) adds gas fees, a 13-month history and, for Hyperliquid, HYPE's price and supply with what the Assistance Fund holds and paid (Hyperliquid's own API) and a one-month run rate against circulating value. Those figures are DefiLlama's (monthly series ids start rail_ and hl_exchange_); spot DEX volume leaves out perps. The model also records who powers and houses AI compute (stage=power, power_equipment, cooling or datacenter: utilities, nuclear and gas generators, reactor and fuel-cell makers, data-centre landlords) with their contracts to labs and clouds; a flow or hop may carry status = supplying (flowing now), signed (contracted, not yet delivering) or announced (a framework, option or forecast: a plan, not a supply), and series such as pjm_capacity_auction_clearing_price:rto, utility_datacenter_contracted_gw:<utility> and us_industrial_electricity_price track the grid side; uncommenced_lease_commitments_usd_b:<company> (microsoft, meta, amazon, google, oracle, coreweave, and five_total for the first five) is each company's leases signed but not yet commenced, mostly data centres, by quarter from its 10-Q or 10-K: commitments to pay once space is delivered, not spending to date. supply_commitments_usd_b:<company> (nvidia, amd, broadcom; each scoped as its filing scopes it) is the upstream mirror: what each has committed to buy from its suppliers, by quarter. commitments lines those order books up in one table, from the companies' own filings: backlog (contracted_backlog_usd_b:<company>: revenue Microsoft, Oracle, Amazon, Alphabet, CoreWeave and Micron have under contract and not yet recognised), leases and supply, each with the newest figure, the figure a year and a quarter earlier, the change (with scope_change set to the company's own statement when it changed what the figure covers between the two dates: quote it with the change), and for a tenant its uncommenced leases per dollar of its own backlog; totals gives each family's sum; kind = backlog, leases or supply; id = a company adds its history. They are obligations and contracts, not cash spent or revenue earned, and the families are layers of one chain, so do not add them together. view=catalog takes kind = a rights verdict (ok, gray, blocked, unknown) and search.	overview
`limit`	No	List size, 1-200, default 50.
`since`	No	Events only: YYYY-MM-DD, events on or after it.
`stage`	No	Companies only: a supply-chain stage from view=overview stages.
`search`	No	Case-insensitive text: companies, facilities, flows, events, products.
`company`	No	Company id: facilities, flows (either side) and events.
`country`	No	Companies and facilities: country code, such as KR or TW.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 10, 2026

changedInput schema / properties / view / description

Previous value: -"Besides the views in the tool description: dependencies (needs id = a company) walks the supplier flows up to 3 hops each way: upstream is what the company depends on (its suppliers, then theirs), downstream is who is hit if it stops, each with the shortest path, the products on every hop and any recorded share, plus recent events at companies within 2 hops (since=YYYY-MM-DD, default the last 90 days) and the company's equity and joint-venture ties; kind=upstream or downstream keeps one side. chokepoints lists where the recorded chain is thin: dominant_sources (one seller covers at least half of a buyer's purchases of a product), customer_dependence (one buyer takes at least 15% of what a seller sells) and most_depended_on (companies ranked by how many buyers they dominate, then by how many buyers they have). Both describe the flows the model records, not the whole industry: a company with few edges is thinly researched, not independent. throughput is the hardware side of token prices: tokens per second per accelerator (H100, H200, B200, B300, MI300X, MI355X and others) on LLM benchmarks, derived from MLPerf Inference datacenter results (the system result divided by its accelerator count: our division, not an MLPerf metric), with mtok_per_gpu_hour, usd_per_mtok_per_usd_gpu_hour (multiply by a GPU-hour rental price for a cost per million tokens at benchmark load) the purchase price per token-per-second where a price is recorded, and energy where NVIDIA publishes a DGX power rating for the accelerator (kWh per GPU-hour and per million tokens at the eight-GPU system's maximum rated power divided by eight, priced at the US average industrial electricity rate; a proxy from NVIDIA's rating, not the benchmarked server's measured power; those are chassis figures, and with_facility_overhead brackets cooling and facility overhead as [low, high] pairs using Google's fleet PUE and a survey average for sites of 20 MW and above, other sites' overhead and not this one's); id = accelerator, kind = benchmark such as llama3.1-405b, search = server or offline. Benchmark load is not one user's speed and fleets run below it. frontier shows that trade directly, from MLPerf Endpoints results: for a served system and model (NVIDIA GB300 and GB200 NVL72 racks, an 8 x MI300X server, 4 x Intel Arc Pro B70, a CPU-only server; DeepSeek-R1, gpt-oss-120b, Llama 3.1 8B) measured at a ladder of concurrent loads, the load with the highest total tokens per second (peak) and, for median per-user streaming speeds of 20, 50 and 100 tokens per second, the highest-throughput load at which the median request still streams that fast (half the requests at that load stream slower, so it is the typical user's speed and not a guaranteed floor), with million tokens per accelerator-hour at each and its share of peak; id = a system (such as nvidia-gb300-nvl72) adds every measured point with first-token delay, kind = model. Only the system total and the first-token delay come from the result, and each point's basis says whether the total is the result's reported figure or derived from its token count and run time; median per-user speed (one over the median time per output token) and per-accelerator figures are our derivations, not MLPerf metrics. The model also records the financial rails AI agents use: settlement networks (stage=rail: Hyperliquid, Base, Robinhood Chain, Arc, Tempo, Elysium and others), venues, tokens and agent-payment standards (stage=payment_standard: x402, AP2, ACP, MPP, ERC-8004), who operates each, which standards each implements, and which on-chain instruments reference a company (a company's ties with relation listing); series ids starting hl_ and x402_ hold a dated snapshot. rails compares those networks in one table: stablecoins on each with the largest issuers, DeFi value locked, the last complete month of spot DEX volume, the change over twelve months, each rail's share of the listed rails and how often its stablecoins turned over in spot trading, plus Hyperliquid's exchange fees and the part that buys or burns HYPE (DefiLlama's adapter figures: perp fees include a stablecoin reserve-yield share and spot fees include auction burns, as the block's method line says); id = one rail (such as hyperliquid, base, robinhood_chain) adds gas fees, a 13-month history and, for Hyperliquid, HYPE's price and supply with what the Assistance Fund holds and paid (Hyperliquid's own API) and a one-month run rate against circulating value. Those figures are DefiLlama's (monthly series ids start rail_ and hl_exchange_); spot DEX volume leaves out perps. The model also records who powers and houses AI compute (stage=power, power_equipment, cooling or datacenter: utilities, nuclear and gas generators, reactor and fuel-cell makers, data-centre landlords) with their contracts to labs and clouds; a flow or hop may carry status = supplying (flowing now), signed (contracted, not yet delivering) or announced (a framework, option or forecast: a plan, not a supply), and series such as pjm_capacity_auction_clearing_price:rto, utility_datacenter_contracted_gw:<utility> and us_industrial_electricity_price track the grid side; uncommenced_lease_commitments_usd_b:<company> (microsoft, meta, amazon, google, oracle, and five_total) is each company's leases signed but not yet commenced, mostly data centres, by quarter from its 10-Q or 10-K: commitments to pay once space is delivered, not spending to date. supply_commitments_usd_b:<company> (nvidia, amd, broadcom; each scoped as its filing scopes it) is the upstream mirror: what each has committed to buy from its suppliers, by quarter. view=catalog takes kind = a rights verdict (ok, gray, blocked, unknown) and search."New value: +"Besides the views in the tool description: dependencies (needs id = a company) walks the supplier flows up to 3 hops each way: upstream is what the company depends on (its suppliers, then theirs), downstream is who is hit if it stops, each with the shortest path, the products on every hop and any recorded share, plus recent events at companies within 2 hops (since=YYYY-MM-DD, default the last 90 days) and the company's equity and joint-venture ties; kind=upstream or downstream keeps one side. chokepoints lists where the recorded chain is thin: dominant_sources (one seller covers at least half of a buyer's purchases of a product), customer_dependence (one buyer takes at least 15% of what a seller sells) and most_depended_on (companies ranked by how many buyers they dominate, then by how many buyers they have). Both describe the flows the model records, not the whole industry: a company with few edges is thinly researched, not independent. throughput is the hardware side of token prices: tokens per second per accelerator (H100, H200, B200, B300, MI300X, MI355X and others) on LLM benchmarks, derived from MLPerf Inference datacenter results (the system result divided by its accelerator count: our division, not an MLPerf metric), with mtok_per_gpu_hour, usd_per_mtok_per_usd_gpu_hour (multiply by a GPU-hour rental price for a cost per million tokens at benchmark load) the purchase price per token-per-second where a price is recorded, and energy where NVIDIA publishes a DGX power rating for the accelerator (kWh per GPU-hour and per million tokens at the eight-GPU system's maximum rated power divided by eight, priced at the US average industrial electricity rate; a proxy from NVIDIA's rating, not the benchmarked server's measured power; those are chassis figures, and with_facility_overhead brackets cooling and facility overhead as [low, high] pairs using Google's fleet PUE and a survey average for sites of 20 MW and above, other sites' overhead and not this one's); id = accelerator, kind = benchmark such as llama3.1-405b, search = server or offline. Benchmark load is not one user's speed and fleets run below it. frontier shows that trade directly, from MLPerf Endpoints results: for a served system and model (NVIDIA GB300 and GB200 NVL72 racks, an 8 x MI300X server, 4 x Intel Arc Pro B70, a CPU-only server; DeepSeek-R1, gpt-oss-120b, Llama 3.1 8B) measured at a ladder of concurrent loads, the load with the highest total tokens per second (peak) and, for median per-user streaming speeds of 20, 50 and 100 tokens per second, the highest-throughput load at which the median request still streams that fast (half the requests at that load stream slower, so it is the typical user's speed and not a guaranteed floor), with million tokens per accelerator-hour at each and its share of peak; id = a system (such as nvidia-gb300-nvl72) adds every measured point with first-token delay, kind = model. Only the system total and the first-token delay come from the result, and each point's basis says whether the total is the result's reported figure or derived from its token count and run time; median per-user speed (one over the median time per output token) and per-accelerator figures are our derivations, not MLPerf metrics. The model also records the financial rails AI agents use: settlement networks (stage=rail: Hyperliquid, Base, Robinhood Chain, Arc, Tempo, Elysium and others), venues, tokens and agent-payment standards (stage=payment_standard: x402, AP2, ACP, MPP, ERC-8004), who operates each, which standards each implements, and which on-chain instruments reference a company (a company's ties with relation listing); series ids starting hl_ and x402_ hold a dated snapshot. rails compares those networks in one table: stablecoins on each with the largest issuers, DeFi value locked, the last complete month of spot DEX volume, the change over twelve months, each rail's share of the listed rails and how often its stablecoins turned over in spot trading, plus Hyperliquid's exchange fees and the part that buys or burns HYPE (DefiLlama's adapter figures: perp fees include a stablecoin reserve-yield share and spot fees include auction burns, as the block's method line says); id = one rail (such as hyperliquid, base, robinhood_chain) adds gas fees, a 13-month history and, for Hyperliquid, HYPE's price and supply with what the Assistance Fund holds and paid (Hyperliquid's own API) and a one-month run rate against circulating value. Those figures are DefiLlama's (monthly series ids start rail_ and hl_exchange_); spot DEX volume leaves out perps. The model also records who powers and houses AI compute (stage=power, power_equipment, cooling or datacenter: utilities, nuclear and gas generators, reactor and fuel-cell makers, data-centre landlords) with their contracts to labs and clouds; a flow or hop may carry status = supplying (flowing now), signed (contracted, not yet delivering) or announced (a framework, option or forecast: a plan, not a supply), and series such as pjm_capacity_auction_clearing_price:rto, utility_datacenter_contracted_gw:<utility> and us_industrial_electricity_price track the grid side; uncommenced_lease_commitments_usd_b:<company> (microsoft, meta, amazon, google, oracle, coreweave, and five_total for the first five) is each company's leases signed but not yet commenced, mostly data centres, by quarter from its 10-Q or 10-K: commitments to pay once space is delivered, not spending to date. supply_commitments_usd_b:<company> (nvidia, amd, broadcom; each scoped as its filing scopes it) is the upstream mirror: what each has committed to buy from its suppliers, by quarter. commitments lines those order books up in one table, from the companies' own filings: backlog (contracted_backlog_usd_b:<company>: revenue Microsoft, Oracle, Amazon, Alphabet, CoreWeave and Micron have under contract and not yet recognised), leases and supply, each with the newest figure, the figure a year and a quarter earlier, the change (with scope_change set to the company's own statement when it changed what the figure covers between the two dates: quote it with the change), and for a tenant its uncommenced leases per dollar of its own backlog; totals gives each family's sum; kind = backlog, leases or supply; id = a company adds its history. They are obligations and contracts, not cash spent or revenue earned, and the families are layers of one chain, so do not add them together. view=catalog takes kind = a rights verdict (ok, gray, blocked, unknown) and search."

changedInput schema / properties / view / enum

Previous value: -[
-  "overview",
-  "companies",
-  "company",
-  "facilities",
-  "flows",
-  "dependencies",
-  "chokepoints",
-  "events",
-  "products",
-  "throughput",
-  "frontier",
-  "rails",
-  "series",
-  "model",
-  "catalog"
-]New value: +[
+  "overview",
+  "companies",
+  "company",
+  "facilities",
+  "flows",
+  "dependencies",
+  "chokepoints",
+  "events",
+  "products",
+  "throughput",
+  "frontier",
+  "rails",
+  "commitments",
+  "series",
+  "model",
+  "catalog"
+]

Changed1 schema field changedNov 10, 2026

changedInput schema / properties / view / description

Previous value: -"Besides the views in the tool description: dependencies (needs id = a company) walks the supplier flows up to 3 hops each way: upstream is what the company depends on (its suppliers, then theirs), downstream is who is hit if it stops, each with the shortest path, the products on every hop and any recorded share, plus recent events at companies within 2 hops (since=YYYY-MM-DD, default the last 90 days) and the company's equity and joint-venture ties; kind=upstream or downstream keeps one side. chokepoints lists where the recorded chain is thin: dominant_sources (one seller covers at least half of a buyer's purchases of a product), customer_dependence (one buyer takes at least 15% of what a seller sells) and most_depended_on (companies ranked by how many buyers they dominate, then by how many buyers they have). Both describe the flows the model records, not the whole industry: a company with few edges is thinly researched, not independent. throughput is the hardware side of token prices: tokens per second per accelerator (H100, H200, B200, B300, MI300X, MI355X and others) on LLM benchmarks, derived from MLPerf Inference datacenter results (the system result divided by its accelerator count: our division, not an MLPerf metric), with mtok_per_gpu_hour, usd_per_mtok_per_usd_gpu_hour (multiply by a GPU-hour rental price for a cost per million tokens at benchmark load) the purchase price per token-per-second where a price is recorded, and energy where NVIDIA publishes a DGX power rating for the accelerator (kWh per GPU-hour and per million tokens at the eight-GPU system's maximum rated power divided by eight, priced at the US average industrial electricity rate; a proxy from NVIDIA's rating, not the benchmarked server's measured power; those are chassis figures, and with_facility_overhead brackets cooling and facility overhead as [low, high] pairs using Google's fleet PUE and a survey average for sites of 20 MW and above, other sites' overhead and not this one's); id = accelerator, kind = benchmark such as llama3.1-405b, search = server or offline. Benchmark load is not one user's speed and fleets run below it. frontier shows that trade directly, from MLPerf Endpoints results: for a served system and model (NVIDIA GB300 and GB200 NVL72 racks, an 8 x MI300X server, 4 x Intel Arc Pro B70, a CPU-only server; DeepSeek-R1, gpt-oss-120b, Llama 3.1 8B) measured at a ladder of concurrent loads, the load with the highest total tokens per second (peak) and, for median per-user streaming speeds of 20, 50 and 100 tokens per second, the highest-throughput load at which the median request still streams that fast (half the requests at that load stream slower, so it is the typical user's speed and not a guaranteed floor), with million tokens per accelerator-hour at each and its share of peak; id = a system (such as nvidia-gb300-nvl72) adds every measured point with first-token delay, kind = model. Only the system total and the first-token delay come from the result, and each point's basis says whether the total is the result's reported figure or derived from its token count and run time; median per-user speed (one over the median time per output token) and per-accelerator figures are our derivations, not MLPerf metrics. The model also records the financial rails AI agents use: settlement networks (stage=rail: Hyperliquid, Base, Robinhood Chain, Arc, Tempo, Elysium and others), venues, tokens and agent-payment standards (stage=payment_standard: x402, AP2, ACP, MPP, ERC-8004), who operates each, which standards each implements, and which on-chain instruments reference a company (a company's ties with relation listing); series ids starting hl_ and x402_ hold a dated snapshot. rails compares those networks in one table: stablecoins on each with the largest issuers, DeFi value locked, the last complete month of spot DEX volume, the change over twelve months, each rail's share of the listed rails and how often its stablecoins turned over in spot trading, plus Hyperliquid's exchange fees and the part that buys or burns HYPE (DefiLlama's adapter figures: perp fees include a stablecoin reserve-yield share and spot fees include auction burns, as the block's method line says); id = one rail (such as hyperliquid, base, robinhood_chain) adds gas fees, a 13-month history and, for Hyperliquid, HYPE's price and supply with what the Assistance Fund holds and paid (Hyperliquid's own API) and a one-month run rate against circulating value. Those figures are DefiLlama's (monthly series ids start rail_ and hl_exchange_); spot DEX volume leaves out perps. The model also records who powers and houses AI compute (stage=power, power_equipment, cooling or datacenter: utilities, nuclear and gas generators, reactor and fuel-cell makers, data-centre landlords) with their contracts to labs and clouds; a flow or hop may carry status = supplying (flowing now), signed (contracted, not yet delivering) or announced (a framework, option or forecast: a plan, not a supply), and series such as pjm_capacity_auction_clearing_price:rto, utility_datacenter_contracted_gw:<utility> and us_industrial_electricity_price track the grid side. view=catalog takes kind = a rights verdict (ok, gray, blocked, unknown) and search."New value: +"Besides the views in the tool description: dependencies (needs id = a company) walks the supplier flows up to 3 hops each way: upstream is what the company depends on (its suppliers, then theirs), downstream is who is hit if it stops, each with the shortest path, the products on every hop and any recorded share, plus recent events at companies within 2 hops (since=YYYY-MM-DD, default the last 90 days) and the company's equity and joint-venture ties; kind=upstream or downstream keeps one side. chokepoints lists where the recorded chain is thin: dominant_sources (one seller covers at least half of a buyer's purchases of a product), customer_dependence (one buyer takes at least 15% of what a seller sells) and most_depended_on (companies ranked by how many buyers they dominate, then by how many buyers they have). Both describe the flows the model records, not the whole industry: a company with few edges is thinly researched, not independent. throughput is the hardware side of token prices: tokens per second per accelerator (H100, H200, B200, B300, MI300X, MI355X and others) on LLM benchmarks, derived from MLPerf Inference datacenter results (the system result divided by its accelerator count: our division, not an MLPerf metric), with mtok_per_gpu_hour, usd_per_mtok_per_usd_gpu_hour (multiply by a GPU-hour rental price for a cost per million tokens at benchmark load) the purchase price per token-per-second where a price is recorded, and energy where NVIDIA publishes a DGX power rating for the accelerator (kWh per GPU-hour and per million tokens at the eight-GPU system's maximum rated power divided by eight, priced at the US average industrial electricity rate; a proxy from NVIDIA's rating, not the benchmarked server's measured power; those are chassis figures, and with_facility_overhead brackets cooling and facility overhead as [low, high] pairs using Google's fleet PUE and a survey average for sites of 20 MW and above, other sites' overhead and not this one's); id = accelerator, kind = benchmark such as llama3.1-405b, search = server or offline. Benchmark load is not one user's speed and fleets run below it. frontier shows that trade directly, from MLPerf Endpoints results: for a served system and model (NVIDIA GB300 and GB200 NVL72 racks, an 8 x MI300X server, 4 x Intel Arc Pro B70, a CPU-only server; DeepSeek-R1, gpt-oss-120b, Llama 3.1 8B) measured at a ladder of concurrent loads, the load with the highest total tokens per second (peak) and, for median per-user streaming speeds of 20, 50 and 100 tokens per second, the highest-throughput load at which the median request still streams that fast (half the requests at that load stream slower, so it is the typical user's speed and not a guaranteed floor), with million tokens per accelerator-hour at each and its share of peak; id = a system (such as nvidia-gb300-nvl72) adds every measured point with first-token delay, kind = model. Only the system total and the first-token delay come from the result, and each point's basis says whether the total is the result's reported figure or derived from its token count and run time; median per-user speed (one over the median time per output token) and per-accelerator figures are our derivations, not MLPerf metrics. The model also records the financial rails AI agents use: settlement networks (stage=rail: Hyperliquid, Base, Robinhood Chain, Arc, Tempo, Elysium and others), venues, tokens and agent-payment standards (stage=payment_standard: x402, AP2, ACP, MPP, ERC-8004), who operates each, which standards each implements, and which on-chain instruments reference a company (a company's ties with relation listing); series ids starting hl_ and x402_ hold a dated snapshot. rails compares those networks in one table: stablecoins on each with the largest issuers, DeFi value locked, the last complete month of spot DEX volume, the change over twelve months, each rail's share of the listed rails and how often its stablecoins turned over in spot trading, plus Hyperliquid's exchange fees and the part that buys or burns HYPE (DefiLlama's adapter figures: perp fees include a stablecoin reserve-yield share and spot fees include auction burns, as the block's method line says); id = one rail (such as hyperliquid, base, robinhood_chain) adds gas fees, a 13-month history and, for Hyperliquid, HYPE's price and supply with what the Assistance Fund holds and paid (Hyperliquid's own API) and a one-month run rate against circulating value. Those figures are DefiLlama's (monthly series ids start rail_ and hl_exchange_); spot DEX volume leaves out perps. The model also records who powers and houses AI compute (stage=power, power_equipment, cooling or datacenter: utilities, nuclear and gas generators, reactor and fuel-cell makers, data-centre landlords) with their contracts to labs and clouds; a flow or hop may carry status = supplying (flowing now), signed (contracted, not yet delivering) or announced (a framework, option or forecast: a plan, not a supply), and series such as pjm_capacity_auction_clearing_price:rto, utility_datacenter_contracted_gw:<utility> and us_industrial_electricity_price track the grid side; uncommenced_lease_commitments_usd_b:<company> (microsoft, meta, amazon, google, oracle, and five_total) is each company's leases signed but not yet commenced, mostly data centres, by quarter from its 10-Q or 10-K: commitments to pay once space is delivered, not spending to date. supply_commitments_usd_b:<company> (nvidia, amd, broadcom; each scoped as its filing scopes it) is the upstream mirror: what each has committed to buy from its suppliers, by quarter. view=catalog takes kind = a rights verdict (ok, gray, blocked, unknown) and search."

Changed2 schema fields changedNov 10, 2026

changedInput schema / properties / view / description

Previous value: -"Besides the views in the tool description: dependencies (needs id = a company) walks the supplier flows up to 3 hops each way: upstream is what the company depends on (its suppliers, then theirs), downstream is who is hit if it stops, each with the shortest path, the products on every hop and any recorded share, plus recent events at companies within 2 hops (since=YYYY-MM-DD, default the last 90 days) and the company's equity and joint-venture ties; kind=upstream or downstream keeps one side. chokepoints lists where the recorded chain is thin: dominant_sources (one seller covers at least half of a buyer's purchases of a product), customer_dependence (one buyer takes at least 15% of what a seller sells) and most_depended_on (companies ranked by how many buyers they dominate, then by how many buyers they have). Both describe the flows the model records, not the whole industry: a company with few edges is thinly researched, not independent. throughput is the hardware side of token prices: tokens per second per accelerator (H100, H200, B200, B300, MI300X, MI355X and others) on LLM benchmarks, derived from MLPerf Inference datacenter results (the system result divided by its accelerator count: our division, not an MLPerf metric), with mtok_per_gpu_hour, usd_per_mtok_per_usd_gpu_hour (multiply by a GPU-hour rental price for a cost per million tokens at benchmark load) the purchase price per token-per-second where a price is recorded, and energy where NVIDIA publishes a DGX power rating for the accelerator (kWh per GPU-hour and per million tokens at the eight-GPU system's maximum rated power divided by eight, priced at the US average industrial electricity rate; a proxy from NVIDIA's rating, not the benchmarked server's measured power, with no cooling or facility overhead); id = accelerator, kind = benchmark such as llama3.1-405b, search = server or offline. Benchmark load is not one user's speed and fleets run below it. The model also records the financial rails AI agents use: settlement networks (stage=rail: Hyperliquid, Base, Robinhood Chain, Arc, Tempo, Elysium and others), venues, tokens and agent-payment standards (stage=payment_standard: x402, AP2, ACP, MPP, ERC-8004), who operates each, which standards each implements, and which on-chain instruments reference a company (a company's ties with relation listing); series ids starting hl_ and x402_ hold a dated snapshot. The model also records who powers and houses AI compute (stage=power, power_equipment, cooling or datacenter: utilities, nuclear and gas generators, reactor and fuel-cell makers, data-centre landlords) with their contracts to labs and clouds; a flow or hop may carry status = supplying (flowing now), signed (contracted, not yet delivering) or announced (a framework, option or forecast: a plan, not a supply), and series such as pjm_capacity_auction_clearing_price:rto, utility_datacenter_contracted_gw:<utility> and us_industrial_electricity_price track the grid side. view=catalog takes kind = a rights verdict (ok, gray, blocked, unknown) and search."New value: +"Besides the views in the tool description: dependencies (needs id = a company) walks the supplier flows up to 3 hops each way: upstream is what the company depends on (its suppliers, then theirs), downstream is who is hit if it stops, each with the shortest path, the products on every hop and any recorded share, plus recent events at companies within 2 hops (since=YYYY-MM-DD, default the last 90 days) and the company's equity and joint-venture ties; kind=upstream or downstream keeps one side. chokepoints lists where the recorded chain is thin: dominant_sources (one seller covers at least half of a buyer's purchases of a product), customer_dependence (one buyer takes at least 15% of what a seller sells) and most_depended_on (companies ranked by how many buyers they dominate, then by how many buyers they have). Both describe the flows the model records, not the whole industry: a company with few edges is thinly researched, not independent. throughput is the hardware side of token prices: tokens per second per accelerator (H100, H200, B200, B300, MI300X, MI355X and others) on LLM benchmarks, derived from MLPerf Inference datacenter results (the system result divided by its accelerator count: our division, not an MLPerf metric), with mtok_per_gpu_hour, usd_per_mtok_per_usd_gpu_hour (multiply by a GPU-hour rental price for a cost per million tokens at benchmark load) the purchase price per token-per-second where a price is recorded, and energy where NVIDIA publishes a DGX power rating for the accelerator (kWh per GPU-hour and per million tokens at the eight-GPU system's maximum rated power divided by eight, priced at the US average industrial electricity rate; a proxy from NVIDIA's rating, not the benchmarked server's measured power; those are chassis figures, and with_facility_overhead brackets cooling and facility overhead as [low, high] pairs using Google's fleet PUE and a survey average for sites of 20 MW and above, other sites' overhead and not this one's); id = accelerator, kind = benchmark such as llama3.1-405b, search = server or offline. Benchmark load is not one user's speed and fleets run below it. frontier shows that trade directly, from MLPerf Endpoints results: for a served system and model (NVIDIA GB300 and GB200 NVL72 racks, an 8 x MI300X server, 4 x Intel Arc Pro B70, a CPU-only server; DeepSeek-R1, gpt-oss-120b, Llama 3.1 8B) measured at a ladder of concurrent loads, the load with the highest total tokens per second (peak) and, for median per-user streaming speeds of 20, 50 and 100 tokens per second, the highest-throughput load at which the median request still streams that fast (half the requests at that load stream slower, so it is the typical user's speed and not a guaranteed floor), with million tokens per accelerator-hour at each and its share of peak; id = a system (such as nvidia-gb300-nvl72) adds every measured point with first-token delay, kind = model. Only the system total and the first-token delay come from the result, and each point's basis says whether the total is the result's reported figure or derived from its token count and run time; median per-user speed (one over the median time per output token) and per-accelerator figures are our derivations, not MLPerf metrics. The model also records the financial rails AI agents use: settlement networks (stage=rail: Hyperliquid, Base, Robinhood Chain, Arc, Tempo, Elysium and others), venues, tokens and agent-payment standards (stage=payment_standard: x402, AP2, ACP, MPP, ERC-8004), who operates each, which standards each implements, and which on-chain instruments reference a company (a company's ties with relation listing); series ids starting hl_ and x402_ hold a dated snapshot. rails compares those networks in one table: stablecoins on each with the largest issuers, DeFi value locked, the last complete month of spot DEX volume, the change over twelve months, each rail's share of the listed rails and how often its stablecoins turned over in spot trading, plus Hyperliquid's exchange fees and the part that buys or burns HYPE (DefiLlama's adapter figures: perp fees include a stablecoin reserve-yield share and spot fees include auction burns, as the block's method line says); id = one rail (such as hyperliquid, base, robinhood_chain) adds gas fees, a 13-month history and, for Hyperliquid, HYPE's price and supply with what the Assistance Fund holds and paid (Hyperliquid's own API) and a one-month run rate against circulating value. Those figures are DefiLlama's (monthly series ids start rail_ and hl_exchange_); spot DEX volume leaves out perps. The model also records who powers and houses AI compute (stage=power, power_equipment, cooling or datacenter: utilities, nuclear and gas generators, reactor and fuel-cell makers, data-centre landlords) with their contracts to labs and clouds; a flow or hop may carry status = supplying (flowing now), signed (contracted, not yet delivering) or announced (a framework, option or forecast: a plan, not a supply), and series such as pjm_capacity_auction_clearing_price:rto, utility_datacenter_contracted_gw:<utility> and us_industrial_electricity_price track the grid side. view=catalog takes kind = a rights verdict (ok, gray, blocked, unknown) and search."

changedInput schema / properties / view / enum

Previous value: -[
-  "overview",
-  "companies",
-  "company",
-  "facilities",
-  "flows",
-  "dependencies",
-  "chokepoints",
-  "events",
-  "products",
-  "throughput",
-  "series",
-  "model",
-  "catalog"
-]New value: +[
+  "overview",
+  "companies",
+  "company",
+  "facilities",
+  "flows",
+  "dependencies",
+  "chokepoints",
+  "events",
+  "products",
+  "throughput",
+  "frontier",
+  "rails",
+  "series",
+  "model",
+  "catalog"
+]

Changed4 schema fields changedNov 10, 2026

changedInput schema / properties / kind / description

Previous value: -"facilities: facility type (view=overview facility_types); flows: product; events: event kind; products: category."New value: +"facilities: facility type (view=overview facility_types); flows: text in the product (hbm matches hbm3e, hbm4); events: event kind; products: category."

changedInput schema / properties / search / description

Previous value: -"Case-insensitive text: companies, facilities, events, products."New value: +"Case-insensitive text: companies, facilities, flows, events, products."

addedInput schema / properties / view / description

Added value: +"Besides the views in the tool description: dependencies (needs id = a company) walks the supplier flows up to 3 hops each way: upstream is what the company depends on (its suppliers, then theirs), downstream is who is hit if it stops, each with the shortest path, the products on every hop and any recorded share, plus recent events at companies within 2 hops (since=YYYY-MM-DD, default the last 90 days) and the company's equity and joint-venture ties; kind=upstream or downstream keeps one side. chokepoints lists where the recorded chain is thin: dominant_sources (one seller covers at least half of a buyer's purchases of a product), customer_dependence (one buyer takes at least 15% of what a seller sells) and most_depended_on (companies ranked by how many buyers they dominate, then by how many buyers they have). Both describe the flows the model records, not the whole industry: a company with few edges is thinly researched, not independent. throughput is the hardware side of token prices: tokens per second per accelerator (H100, H200, B200, B300, MI300X, MI355X and others) on LLM benchmarks, derived from MLPerf Inference datacenter results (the system result divided by its accelerator count: our division, not an MLPerf metric), with mtok_per_gpu_hour, usd_per_mtok_per_usd_gpu_hour (multiply by a GPU-hour rental price for a cost per million tokens at benchmark load) the purchase price per token-per-second where a price is recorded, and energy where NVIDIA publishes a DGX power rating for the accelerator (kWh per GPU-hour and per million tokens at the eight-GPU system's maximum rated power divided by eight, priced at the US average industrial electricity rate; a proxy from NVIDIA's rating, not the benchmarked server's measured power, with no cooling or facility overhead); id = accelerator, kind = benchmark such as llama3.1-405b, search = server or offline. Benchmark load is not one user's speed and fleets run below it. The model also records the financial rails AI agents use: settlement networks (stage=rail: Hyperliquid, Base, Robinhood Chain, Arc, Tempo, Elysium and others), venues, tokens and agent-payment standards (stage=payment_standard: x402, AP2, ACP, MPP, ERC-8004), who operates each, which standards each implements, and which on-chain instruments reference a company (a company's ties with relation listing); series ids starting hl_ and x402_ hold a dated snapshot. The model also records who powers and houses AI compute (stage=power, power_equipment, cooling or datacenter: utilities, nuclear and gas generators, reactor and fuel-cell makers, data-centre landlords) with their contracts to labs and clouds; a flow or hop may carry status = supplying (flowing now), signed (contracted, not yet delivering) or announced (a framework, option or forecast: a plan, not a supply), and series such as pjm_capacity_auction_clearing_price:rto, utility_datacenter_contracted_gw:<utility> and us_industrial_electricity_price track the grid side. view=catalog takes kind = a rights verdict (ok, gray, blocked, unknown) and search."

changedInput schema / properties / view / enum

Previous value: -[
-  "overview",
-  "companies",
-  "company",
-  "facilities",
-  "flows",
-  "events",
-  "products",
-  "series",
-  "model",
-  "catalog"
-]New value: +[
+  "overview",
+  "companies",
+  "company",
+  "facilities",
+  "flows",
+  "dependencies",
+  "chokepoints",
+  "events",
+  "products",
+  "throughput",
+  "series",
+  "model",
+  "catalog"
+]

Changed2 schema fields changedNov 8, 2026

changedInput schema / properties / id / description

Previous value: -"Company id, required for view=company (ids from view=companies, such as samsung)."New value: +"Company id for view=company (ids from view=companies, such as samsung), or a series id for view=series (ids from view=series)."

changedInput schema / properties / view / enum

Previous value: -[
-  "overview",
-  "companies",
-  "company",
-  "facilities",
-  "flows",
-  "events",
-  "products",
-  "model",
-  "catalog"
-]New value: +[
+  "overview",
+  "companies",
+  "company",
+  "facilities",
+  "flows",
+  "events",
+  "products",
+  "series",
+  "model",
+  "catalog"
+]

AddedNov 8, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, and the description is consistent ('Read-only'). Beyond that it discloses provenance rules ('every number carries its source, as_of and basis'), truncation semantics ('newest kept when truncated', 'lists return total, returned, truncated and items'), unit pitfalls ('a series can mix units or statistical bases', seller share may be of revenue or capacity), family-row collapsing for bulk series ids, and an explicit framing disclaimer ('Research, log-only: not a forecast claim and not a recommendation'). That is rich behavior the annotations cannot convey.

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

Conciseness3/5

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

It is front-loaded with the purpose in the first clause, and nearly every sentence carries distinct information, so it is dense rather than padded. But it is a single semicolon-chained block of roughly 800 words covering a dozen views, with no paragraph or list structure, and it substantially overlaps the very long view-enum description already in the schema. An agent must parse a wall of text to find the routing rule it needs.

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 9 optional parameters, no output schema, and a wide multi-view surface, the description still covers the return envelope (total/returned/truncated/items), the paging default, per-view id requirements, and the caveats that make the numbers safe to use. Nothing an agent needs to call a given view correctly appears to be missing.

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 description coverage is 100%, so the baseline is 3, but the description adds interpretation beyond the schema: that flows' kind is a text match so 'hbm also finds hbm3e and hbm4', that id is either a company id or a series id depending on view, that search spans companies/product/note, and the limit default and range. Some of this duplicates the view enum's own long description, which caps it at 4 rather than 5.

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

Purpose4/5

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

Opens with a specific verb and resource: 'Read Gambit's semiconductor world model', then enumerates the contents (companies, sites, flows, BOMs, events, scenario model, series catalog) and the view selector. An agent knows exactly what domain this covers. It never names a sibling tool or states how it differs from, say, get_gambit or get_compute_pricing, so it stops short of a 5.

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

Usage Guidelines4/5

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

Gives per-view routing instructions: 'view=company (needs id from view=companies)', 'view=flows (company on either side, kind = text in the product...)', 'view=series (without id a catalog...; with id that series' rows)'. It also flags that lists default to 50 and cap at 200, and that a refused query explains itself. There is no when-not-to-use guidance and no comparison to alternative tools, which keeps it at 4.

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

All Gambit tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?