Skip to main content
Glama

Query AI Infrastructure Production (semiconductor output and utilization)

query_ai_infrastructure_production_v1
Read-onlyIdempotent

Query verified U.S. semiconductor & electronic-component PRODUCTION and CAPACITY UTILIZATION — the Federal Reserve's monthly G.17 industrial-production index (2017=100) and capacity-utilization rate (percent) for NAICS 3344 — from the Board's own release, history to 1972.

Use this for "are the domestic fabs actually producing / how hot are they running" questions — the OUTPUT leg of the fab lifecycle: construction spending (ai_infrastructure.construction) measures the shell, equipment imports (ai_infrastructure.equipment_trade) the tools flowing in, chip imports (ai_infrastructure.trade) what crosses the border; this measures domestic production and how much of the installed capacity is in use. NAICS 3344 is "semiconductor and OTHER electronic component" manufacturing — the finest split the Fed publishes here (broader than semiconductors alone, and NOT the same slice as QCEW's 334413). Filter by series_kind ("ip" = the production index, on both bases; "capacity_utilization" = percent of capacity in use, seasonally adjusted only; "capacity" = the capacity index behind the rate), series_name (the verbatim Fed series, e.g. "IP.G3344.S", "CAPUTL.G3344.S"), basis ("seasonally_adjusted" / "not_seasonally_adjusted" — IP only), year, data_month (ISO first-of-month, e.g. "2026-05-01") or the data_month_from/data_month_to range. Group by any of series_name, series_kind, basis, data_month, or year. Pass each parameter as a top-level key of params (flat — not nested). Example: {"series_kind": "capacity_utilization", "group_by": ["data_month"], "data_month_from": "2024-01-01"} for the utilization trend; {"series_kind": "ip", "basis": "seasonally_adjusted", "group_by": ["year"]} for the production index by year (an average per year). Returns JSON aggregates with citations and optional row-level records when include_records is true — every value cites the exact Fed SDMX observation, re-verifiable via get_source_evidence_v1.

Measures are avg/min/max per reading — avg_ip_index, avg_capacity_utilization_pct, avg_capacity_index (+ min/max variants): an index or a rate is INTENSIVE, so multi-month figures are AVERAGES, never sums (the Fed publishes its own quarterly/annual aggregations, which this block does not serve — monthly grain only). An index is not dollars and not unit counts (2017=100). Capacity and utilization exist seasonally adjusted only — their not-seasonally-adjusted cells are structurally absent, never zero. Averaging the IP index across both bases returns a production_aggregation note — filter or group by basis instead. National industry aggregate: no state, county, fab, or company breakdown. Every monthly release revises history (as_of carries the vintage).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.9/5.0
Behavior5/5

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

Despite annotations already declaring read-only/idempotent/non-destructive, the description adds substantial behavioral context: measures are intensive and averaged not summed, capacity/utilization are SA-only with structurally absent NSA cells, averaging across bases triggers a production_aggregation note, no breakdowns by state/fab/company, revisions are as_of tagged, and citations are re-verifiable. This goes far beyond the annotation safety profile.

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?

The description is long (several paragraphs) but densely packed with essential information that compensates for the absent schema detail. It is logically structured: what, when to use, parameters, examples, behavior, limitations. While some sentences could be tightened, the length is justified given the tool's complexity and the lack of schema-level parameter documentation.

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?

Given the tool's complexity, the opaque schema (0% coverage), and the rich annotations, the description is remarkably complete. It explains return aggregates, averaging behavior, data grain (monthly only, not quarterly/annual), limitations, and revision handling. It even notes the absence of state/county/fab/company breakdowns. There is little the agent would need to guess.

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?

The input schema is effectively opaque (only a params object with additionalProperties), but the description fully compensates by enumerating all filter parameters (series_kind, series_name, basis, year, data_month, data_month_from/to, group_by, include_records), their valid values, and giving concrete examples like {"series_kind": "capacity_utilization", "group_by": ["data_month"], "data_month_from": "2024-01-01"}. This provides complete semantic meaning beyond the schema.

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 opens with a precise, specific verb+resource: 'Query verified U.S. semiconductor & electronic-component PRODUCTION and CAPACITY UTILIZATION — the Federal Reserve's monthly G.17 industrial-production index (2017=100) and capacity-utilization rate (percent) for NAICS 3344 — from the Board's own release, history to 1972.' It clearly distinguishes this tool from siblings by positioning it as the OUTPUT leg of the fab lifecycle, contrasting with construction, equipment trade, and imports.

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?

Explicit when-to-use guidance is provided: 'Use this for "are the domestic fabs actually producing / how hot are they running" questions.' It names alternatives (ai_infrastructure.construction, ai_infrastructure.equipment_trade, ai_infrastructure.trade) and clarifies the NAICS scope difference from QCEW's 334413, helping the agent choose correctly among siblings.

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/5.0
Disambiguation4/5

Each capability has a clearly named describe/query pair, and domains like power, AI infrastructure, robotics, and space are distinct. The generic describe_capability_v1/query_capability_v1 could be confused with the named variants, and the many ISO-specific interconnection queues share similar names, but descriptions explicitly disambiguate them.

Naming Consistency5/5

All tools follow a consistent lowercase snake_case verb_noun pattern: describe_<capability>_v1 and query_<capability>_v1, with a few utility tools like list_capabilities_v1 and get_source_evidence_v1. There is no mixing of conventions.

Tool Count2/5

At 62 tools, the set is far too large for typical server scope. The describe/query pairs inflate the count even though each is justified, and the generic capabilities plus per-ISO variants make it feel heavy and hard to navigate.

Completeness4/5

The server covers each domain thoroughly with describe, query, and evidence verification, plus generic fallbacks for capabilities not yet in the client's tool list. Minor gaps exist (e.g., no county/state attribution for some data, no load types in ISO queues) but they are explicitly documented and workable.

Resources