HORIZON SHIELD Construction Cost Data: JCCDB (Japan) and USCCDB (United States)

Get U.S. Material Price Chain (landed import cost to wholesale, retail and contractor)

get_us_price_chain

Read-only

米国で建材や化学品が流通の各段でいくらになるかを計算して返す: 輸入の陸揚げ原価(Census の輸入統計、CIF + 関税、232 条などの追加関税を含む)から、卸(業種の平均の粗利率、Census AIES 2024)、小売(直接輸入と卸経由の幅)、元請(Caltrans の材料の上乗せ 15%)まで。HS 10 桁か英語の品名で引く。各行に式・出典の URL と sha256・卸の業種の当て方の確度・BEA 2007 の流通構造との照合が付く。推計(computed:true)で、見積の良し悪しを判定する値ではない。例: query='plywood'、hs='2523290000'(ポルトランドセメント)。 / Estimated U.S. prices along the distribution chain for construction materials and chemicals: landed import cost (Census, CIF plus duty including Section 232) to wholesale (industry-average gross margin, Census AIES 2024), retail (range: direct import vs via wholesale) and contractor (Caltrans materials markup 15%). Look up by HS code or English product name; every row carries the formula, source URLs and hashes, mapping confidence and a BEA 2007 cross-check. Estimates (computed:true), not a verdict on any quote.

Input Schema

TableJSON Schema

Name	Required	Description
`hs`	No	HS の頭 2〜10 桁(例 2523 セメント、4412 合板、3917 樹脂管、6907 タイル)。 / HS code prefix.
`limit`	No	返す行の上限(1〜50)。 / Maximum rows to return (1 to 50).
`query`	No	英語の品名(例 plywood, portland cement, pvc pipe, ceramic tiles)。 / Product name in English.
`include_thin`	No	取引の薄い品目も入れる(既定は外す)。 / Include thinly traded items.

Output Schema

TableJSON Schema

Name	Required	Description
`rows`	No	品目ごとの陸揚げ・卸・小売・元請(式・出典・sha256) / landed, wholesale, retail, contractor with formula and sources
`count`	No	How many records matched. 0 means the source was read and nothing matched. It never means the source could not be read, that returns isError: true.
`lookup`	No	ok = the source was read and something matched. absent = the source was read and nothing matched. A source that could NOT be read never appears here: that returns isError: true and makes no claim about what does or does not exist.
`markups`	No	元請の上乗せ率(州の交通局の原本) / contractor markups from state DOT originals
`how_to_cite`	No	引用の仕方 / how to cite
`source_read`	No	true on every successful result. A failed lookup does not return a result at all, so this is never false, it is declared so a consumer can assert on it.
`did_you_mean`	No	Near matches, when an exact match was not found.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 2, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description goes further, disclosing that every row carries a formula, source URLs with sha256, mapping confidence, and a BEA 2007 cross-check, and that values are flagged computed:true estimates. That provenance detail is genuinely additive, though auth/rate-limit behavior is not addressed.

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?

The content is front-loaded and each element is substantive, but the full text is duplicated verbatim in Japanese and English, roughly doubling the length without adding information. For an agent, the redundancy is tolerable but not tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a complex multi-stage pricing tool with an output schema and full annotation coverage, the description is largely complete: it covers inputs, data provenance, estimate status, and row contents. Minor gaps remain around when to choose it over sibling pricing tools.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all four parameters with examples. The description's examples (query='plywood', hs='2523290000') largely repeat what the schema provides, so the baseline of 3 applies.

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+resource with full scope: computes U.S. prices for construction materials and chemicals at each distribution stage, from landed import cost through wholesale, retail and contractor. It names its data sources and inputs, making it clearly distinguishable from siblings like get_us_import_landed_cost or get_us_trade_margins.

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?

Explains how to invoke it (by HS 10-digit code or English product name) and gives concrete examples, plus a caveat that results are estimates not a verdict on a quote. It does not, however, explicitly say when to prefer this tool over the more granular sibling tools such as get_us_import_landed_cost.

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

All HORIZON SHIELD Construction Cost Data: JCCDB (Japan) and USCCDB (United States) 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.