osint

Query AI Infrastructure Construction (data centers + fabs)

query_ai_infrastructure_construction_v1

Read-onlyIdempotent

Query verified U.S. private construction spending ($ millions) for data centers and semiconductor/computer-electronics manufacturing plants, from the U.S. Census Bureau's Value of Construction Put in Place (C30).

Use this for "how much is being spent BUILDING data centers (or chip fabs) in the US" questions — the construction buildout in dollars, not capacity or investment. Filter by category ("data_center" — Census's named subcategory under Office; or "computer_electronic_electrical" — the semiconductor/computer-electronics manufacturing line under Manufacturing), basis ("seasonally_adjusted" = a seasonally-adjusted ANNUAL RATE, or "not_seasonally_adjusted" = the NOT-adjusted MONTHLY LEVEL), data_month (one month, ISO first-of-month e.g. "2026-04-01") or the data_month_from/data_month_to range, year, and revision_status ("preliminary", "revised", or "final"). Group by any of category, basis, data_month, year, or revision_status. Pass each parameter as a top-level key of params (flat — not nested under a filter, filters, or where key). Example: {"category": "data_center", "basis": "seasonally_adjusted", "data_month": "2026-04-01"} for one month; add "group_by": ["data_month"] over a data_month_from/data_month_to range for a series. Returns JSON aggregates with citations and optional row-level records when include_records is true — every value cites the exact Census workbook, sheet, row, and column.

The two categories are DISTINCT series and are never conflated: data_center is data-center buildings; computer_electronic_electrical is the chip/electronics-manufacturing (fab) line — the CHIPS-Act build-out. basis is the other fork: the seasonally-adjusted series is an ANNUAL RATE (what the current monthly pace annualizes to), while the not-seasonally-adjusted series is the actual MONTHLY LEVEL. revision_status carries Census's own preliminary/revised/final marking verbatim.

Data is monthly; the data-center series begins 2014-01. The response as_of is the release vintage (Census revises monthly); pin as_of to an earlier vintage to reproduce what was served then.

NOT additive: construction_spending_musd is a published per-(category, basis, month) reading, so a total that mixes the two bases (an annual rate + a monthly level), or that sums the seasonally-adjusted ANNUAL-RATE series across months, is not a real figure — such a result carries a construction_aggregation scope note and ranking remainders omit the metric. Filter to one basis and group_by data_month for a series over time.

Does not determine total data-center INVESTMENT (servers, chips, cooling, equipment — this is construction put-in-place only; Census does not publish an investment total), data-center MW capacity, count, square footage, or location (use the power.* capabilities for capacity and the interconnection queue), which company or project is building (Census C30 has no operator breakdown), public or government construction (this is PRIVATE construction only), or construction outside these two categories.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral context beyond these: monthly data cadence, 2014-01 start, Census revision vintage semantics via as_of, category/basis distinct-series behavior, non-additivity warnings, aggregation scope notes, and citation/row-level record behavior. No contradiction with annotations.

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

Conciseness5/5

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

Although long, the description is densely informative and excellently structured: opening purpose, explicit usage trigger, filter/parameter walkthrough, example, category/basis semantics, caveats, and exclusions. The formatting uses short paragraphs and bullet-like enumerations that make scanning easy, and every sentence contributes necessary operational detail.

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, minimal schema, and broad sibling set, the description is remarkably complete. It covers return behavior (JSON aggregates, citations, row-level records), data semantics, aggregation pitfalls, revision handling, and boundary exclusions. The presence of an output schema means return-value explanation is not required, and the description still adds plenty of context.

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?

Schema coverage for the single generic params object is 0%, so the description must fully document parameters. It does: it names category, basis, data_month, data_month_from/to, year, revision_status, group_by, and include_records, explains allowed values, gives a flat-structure rule, and provides concrete JSON examples. This is far beyond typical compensation for an opaque 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 specific verb and resource: 'Query verified U.S. private construction spending ($ millions) for data centers and semiconductor/computer-electronics manufacturing plants, from the U.S. Census Bureau's Value of Construction Put in Place (C30).' This precisely distinguishes it from sibling query_ai_infrastructure_* tools (employment, equipment trade, production, trade) and from power.* tools by explicitly scoping to construction spending.

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?

The description explicitly states when to use the tool: 'Use this for "how much is being spent BUILDING data centers (or chip fabs) in the US" questions.' It also gives clear exclusions and alternatives, e.g., 'use the power.* capabilities for capacity and the interconnection queue,' and lists many non-covered topics such as investment totals, MW capacity, and operator breakdown.

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

All osint tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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

Need Help?