Skip to main content
Glama

bimhouse

by house.bim

create_house

[EN] Build a new house (bim.json) from an address alone (geocoded, auto-named, climate-aware) or full elements; returns slug + edit_token + viewer/permit URLs + inline houki & structure verdicts. No auth (private by default, rate-limited). / 新しい物件 (bim.json) を作成する。name か address のどちらか必須 — 住所だけ渡せば geocode で座標を引き「<地名>の家」と自動命名して家が建つ (REINFOLIB_KEY 設定時は用途地域も実値注入)。elements (bim.json v1 要素配列) を渡すとそのまま保存、省略すると敷地寸法から住宅 BIM を自動生成。name/rooms に「薪ストーブ・土間・ロフト・カーポート・書斎・ピアノ・サウナ」等の言葉が入ると対応する要素 (煙突・炉台・はしご込み) を自動配置し、寒冷地住所ならトリプルガラス+付加断熱+雪止めに外皮を格上げ。「平屋」「2階建て」も階数に反映。slug と edit_token、viewer/json/permit URL と適用 features・site (座標/用途地域ソース) を返す。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo物件名 (address を渡せば省略可 — 地名から自動命名)
roomsNo室構成サマリー
floorsNo階数 (既定 1)
zoningNo用途地域 (例: 近隣商業地域)
addressNo所在地 (これだけでも家が建つ。geocode で座標解決・気候/積雪も住所から自動設定)
lot_d_mNo奥行 m (簡易シェル生成に使用)
lot_w_mNo間口 m (簡易シェル生成に使用)
privateNotrue で物件一覧 (/property) に非掲載・直リンクのみ。既定 false=掲載。
elementsNobim.json v1 要素配列。各要素 {id,cls,label,descr,shape:'box'|'cylinder',x,y,z,w,d,h,rotation?} (mm)。省略可。
gross_m2No延床面積 ㎡
structureNo構造 (例: RC 打放しコンクリート)
land_area_m2No敷地面積 ㎡
project_typeNo[EN] 'new' (default) builds a from-scratch cost estimate. 'renovation'/'change_of_use' treat this as an EXISTING building being remodeled: foundation/frame/roof default to ¥0 (reused as-is) and only the trades in renovation_scope are costed at renovation unit rates. / 既定は new=新築(ゼロから建てる前提の概算)。renovation/change_of_use を指定すると『既存建物の改修』として扱われ、基礎・躯体・屋根等は既定でコスト¥0(既存流用)になり、renovation_scope で指定した工種だけを改修単価で見積もる。get_build_plan の結果も新築フル工程でなく改修工程 (解体・調査系を含む) に切り替わる。
construction_jpyNo概算工事費 円
renovation_scopeNo改修対象の工種 code 配列 (demo/interior/fittings/electrical/plumbing/hvac/roof/exterior/frame/found/temp/pv)。project_type=renovation|change_of_use のときのみ有効。省略時は典型的なフルリノベ (demo+内装+建具+電気+給排水+空調) を既定スコープとして使う。
seismic_retrofitNotrue で耐震補強費 (建物全体延床×単価) を概算に含める。project_type=renovation|change_of_use のときのみ使う。
existing_year_builtNo既存建物の建築年 (西暦)。1981年5月以前は旧耐震 (耐震診断推奨)、2006年以前(または未指定)はアスベスト事前調査を概算に自動計上する。project_type=renovation|change_of_use のときのみ使う。
renovation_scope_m2No実際に改修する範囲の面積㎡ (例: 3階建282㎡の建物のうち1階94㎡だけ改修するなら94)。省略時は gross_m2 (建物全体) を使う。project_type=renovation|change_of_use のときのみ有効。

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the tool is rate-limited, creates private houses by default, auto-generates elements if not provided, and responds with specific URLs and verdicts. It also covers climate-aware upgrades and auto-placement of features based on room names. Minor omission: does not mention error handling or idempotency.

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 thorough and front-loads the core purpose. It covers many details in a structured way, though it is somewhat lengthy due to bilingual content. Most sentences add value, but it could be slightly more concise without losing information.

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 18 parameters and no output schema, the description covers input behavior and return values (slug, edit_token, URLs, verdicts) well. It explains auto-generation logic and project type impacts. It could mention the structure of the returned verdicts, but overall it is complete for a complex tool.

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 100%, providing a baseline of 3. The description adds significant value beyond schema, e.g., for 'address' it explains geocoding and auto-naming; for 'rooms' it lists auto-features; for 'project_type' it details cost implications. This enriches parameter understanding.

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 clearly states the tool creates a new house from address or full elements, with specific verb 'Build' and resource 'house'. It distinguishes from sibling tools like 'update_house' and 'get_house_bim' by focusing on creation and listing the return items (slug, edit_token, URLs, verdicts).

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?

The description explains that address alone can be used for automatic geocoding and naming, and that elements can be provided to override auto-generation. It also mentions project types (new, renovation, change_of_use) and their effects. However, it does not explicitly state when not to use this tool or list alternatives, though the context of creation vs. updating is implied.

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

All bimhouse toolsInspect
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

A3.6/5.0
Disambiguation4/5

Most tools have distinct purposes, but some potential overlap exists (e.g., get_site_context and get_houki_rules both provide site conditions, and set_site_context vs. upsert_zoning_rule could be confused). Overall, descriptions help disambiguate.

Naming Consistency4/5

Tools predominantly use a verb_noun pattern (e.g., create_house, update_house, set_visibility). A few outliers like houki_check and whoami break the pattern, but naming is mostly consistent.

Tool Count3/5

29 tools is heavy but covers a broad domain (house design, construction, catalog, contractors, admin). Some tools are niche (e.g., list_incomplete_addresses, set_forkable), but each serves a clear purpose. Could be streamlined.

Completeness4/5

Core operations for house lifecycle (create, read, update, check) are present. Lacks explicit delete/archive for houses (only set_visibility), and no tool to update site context directly (only set via set_site_context). Minor gaps but domain is well-covered.

Resources