Skip to main content
Glama
Sign In

Structomat

by com.structomat
OverviewDiscussionsAdmin

Estimate the cost of a steel structure from its IFC model

estimate_steel_cost
Read-onlyIdempotent

Cost of fabricating and erecting a steel structure, worked out part by part from its IFC model: every part, hole, weld and lift is timed as a shop or site operation and priced at the region's employer labour cost, steel price and crane rate. Returns the cost floor (total, per tonne, per m2 of floor) with its breakdown, the published market band next to it and the gap, the process groups that drive the cost, the ten costliest parts with their IFC ids, a programme from shop drawings to erection in working days, upfront embodied carbon (modules A1-A5: steel production, fabrication, delivery, erection), and what an example design review (lighter sections, fewer plate fittings) would save in cost and carbon. Regions: UK, DE (Germany), US, AU, or own rates in any currency. Give the IFC as a public link (ifc_url, up to 30 MB) or as its text (ifc_text, up to 12 MB), or sample=true for a sample 18 x 30 m portal frame shed. It is the engine of Structomat's free Steel Cost Estimator page, which shows the same result with a 3D cost heat map when the same IFC is dropped on it. An estimate, not a quote. The IFC is read in memory and not stored.

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": "estimate_steel_cost"
  }
}

Input Schema

NameRequiredDescriptionDefault
shopNomixed (default) = automated saw-drill line and plate cutting plus handling and marking; cnc = machine times only; manual = conventional shop.
paintNoShop blasting and painting (default true).
ratesNoOptional overrides of the region's rates (required for region "own"): currency code, eur_rate = 1 EUR in that currency, shop_wage and site_wage = employer cost per hour worked (not a sell rate), steel_per_t, crane_per_day (with operator), overhead_pct, profit_pct.
regionNoLabour, steel and crane rates and the market band: UK (GBP), DE (EUR), US (USD), AU (AUD), or own = your rates in "rates". Default UK.
sampleNotrue = use the sample building (18 x 30 m portal frame shed, 799 parts) instead of an IFC.
ifc_urlNoPublic http(s) link to the IFC file (IFC2x3 or IFC4, up to 30 MB).
erectionNonorms (default) = crew man-hours by section class; cycle = crane lift cycles per piece (reads low on single-storey sheds).
ifc_textNoThe IFC file content as text (STEP, starting with ISO-10303-21), up to 12 MB. Use instead of ifc_url.
programmeNoProgramme inputs in working days: drawing_days (shop drawings + approval, default 10), lead_days (steel lead time, default 10), shop_crew (default 4).
scrap_pctNoMaterial scrap, % (default 10).
carbon_routeNoSteel route for embodied carbon: bof = blast furnace mix, eaf = electric arc (recycled). Default eaf for US, bof elsewhere.
transport_kmNoShop to site, km (default 250).
design_reviewNoExample design review: steel_saved_pct (default 10) and plate_fittings_removed_pct (default 25, smallest plates first).
erection_crewNoErection crew size (default 5).
floor_area_m2NoGross floor area, m2. Default: the column grid found in the model.
market_price_per_tNoregion "own": the market price per tonne you see, to show the gap to the floor.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description adds genuinely new behavioural facts: 30 MB URL / 12 MB text limits, in-memory reading with no storage, and the important caveat 'An estimate, not a quote'. It also pre-frames what comes back (cost floor vs published market band, programme, A1-A5 carbon). It does not discuss failure modes for malformed IFC or runtime/rate limits, which keeps it off a 5.

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 opening purpose is front-loaded, but it is delivered as one enormous run-on sentence enumerating nine separate return components, followed by a second long sentence covering regions and input modes. Much of that enumeration and the size limits duplicate schema text. It is dense and informative but hard to scan; a short structured layout would earn the same content in less space.

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?

With 16 parameters, nested objects and no output schema, the description correctly takes on the burden of describing the return value in detail — cost floor, breakdown, market band and gap, cost drivers, top ten parts with IFC ids, programme, A1-A5 carbon, design-review savings. Input modes, region defaults and the not-a-quote caveat are all present. The only real omission is any statement of how it relates to the near-duplicate sibling tool.

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% and every nested field (rates, programme, design_review) is documented in the schema, so the baseline is 3. The description mostly restates what the schema already says (region options, ifc_url size, sample shed dimensions) rather than adding semantics the schema lacks. The one bit of added meaning is the relationship that 'rates' is required when region is 'own', which the schema also states.

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?

States a specific verb+resource combination: costing the fabrication and erection of a steel structure, itemised part by part from an IFC model. That is far more concrete than a bare 'estimate cost'. It never names or contrasts the obvious sibling estimate_portal_frame_steel, which covers closely overlapping ground, so sibling differentiation has to be inferred.

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

Usage Guidelines3/5

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

Provides clear input-selection guidance at the parameter level ('Give the IFC as a public link... or as its text... or sample=true'), plus defaults like 'Default UK' and 'Default eaf for US'. What it never does is say when to choose this tool over estimate_portal_frame_steel or analyze_frame, or when an IFC-based estimate is inappropriate. Usage is implied through inputs, not routed.

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

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