Skip to main content
Glama

Estimate construction cost

cao_devis
Read-only

WHEN a client or a contractor needs the QUANTITIES to price a house, trade by trade — the skeleton of a French DPGF. From the CAO scene, completed by the rules if needed: structural works (footings and lintels from the structure, ground slab, floors, load-bearing walls by thickness, gables), roofing, windows and doors by size, partitions, linings and ceilings, electrical points by type and cable length by cross-section, plumbing, heating and ventilation (radiators, heat pump, pipes, vents, ducts), floors and paint. No price is ever invented: pass your own unit prices in prix (and tva_pct) to get totals; items left without a price are listed in sans_prix.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mursNoWalls: plan segments extruded vertically. Every coordinate in this whole scene is in MILLIMETRES, in a single plan frame whose origin you choose — X to the right, Y upward, Z up from the floor. Keep one consistent origin across murs/boites/plan: the generators never recentre anything for you.
planNo2D reference lines — drawn flat, never extruded and never counted in the quantities. Use them for axes, plot limits or setting-out marks.
prixNoOptional unit prices excluding VAT, keyed by the item codes this tool returns, e.g. {'GO-SEMELLES': 250, 'CV-RADIATEUR': 450}.
boitesNoBoxes (furniture, volumes): a rectangular block placed by its CENTRE, not by a corner. Millimetres, same frame as murs[].
georefNoOptional Lambert-93 (EPSG:2154) false origin for IfcMapConversion. Local millimetres are scaled by 0.001 to CRS metres. Do not invent coordinates: omit est/nord if unknown (origin stays 0). orientation is the angle in degrees of project X from map East, counterclockwise.
cerclesNoCircles on the 2D plan, alongside plan[] lines: each has a centre and a radius, in the same unit as the plan. Use for round shapes a polyline would render badly — fillets, posts, manholes.
reseauxNoPlumbing pipe runs (EF/EC/EU/EV/EP/chauffage) — used only by cao_pdf (technical plan + linear-meter quantities per type).
tva_pctNoOptional VAT rate in percent (5.5, 10 or 20 in France), to add a total including tax.
toituresNoRoofs — used only by cao_pdf. WITHOUT this field: a flat roof is auto-generated over the footprint of ALL walls (legacy default). WITH it: compose freely — each entry can target a subset of walls (via `murs`), letting you build an L-shaped building's roof, or add a dormer on top of a main roof.
plomberieNoSanitary fixtures (sink, WC, shower…) — used only by cao_pdf. Same positioning as electricite.
decorationNoPaint/finish per wall — used only by cao_pdf. Colors the elevations (exterior face) and the axonometric view (face auto-detected by orientation relative to the building's centroid).
ouverturesNoDoors/windows embedded in a wall — used only by cao_pdf (elevations + axonometric view), no effect on dxf/metres.
electriciteNoElectrical symbols (outlets, switches, lights…) — used only by cao_pdf (dedicated technical plan + quantities), no effect on dxf/metres/render. Position: attached to a wall (`mur`+`position`, like ouvertures) or free (`x`,`y`).
compositionsNoNamed wall/slab layer sets declared by the project. A key that matches an inferred kind (mur_exterieur, refend, cloison, plancher, toiture) or murs[].composition drops the Hypothese flag. Each value is {libelle, couches: [{cle, epaisseur?}]}. cle: enduit, bloc_beton, isolant, ba13, ossature, enduit_platre, beton_arme, tuile, charpente, etancheite. Omit epaisseur on the load-bearing layer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world). The description adds genuinely useful behavioral context beyond them: it auto-completes from the CAO scene "completed by the rules if needed" and never invents prices, surfacing unpriced items in sans_prix. What happens to input geometry is not fully described, but the pricing contract is explicit.

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?

Front-loaded with the WHEN clause, then a single long trade enumeration that is dense but earns its place by scoping the tool's coverage. The final sentence carries the pricing contract compactly; nothing is obviously redundant.

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?

For a 14-param, nested-schema, no-output-schema tool the description covers the essential purpose, price-input contract and the sans_prix output hint. It does not explain how scene inputs map to returned item codes or the overall result structure, which would help given the absent output schema.

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%, so the schema already documents all 14 params. The description nonetheless adds value by foregrounding the two params that drive output totals (`prix`, `tva_pct`) and naming the returned sans_prix convention, which the schema alone does not connect.

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?

The description states a specific verb+resource: it computes trade-by-trade QUANTITIES to price a house (the skeleton of a French DPGF), enumerating the covered trades. However it does not distinguish itself from close siblings like cao_metres, cao_nomenclatures or devis_travaux, leaving the agent to infer the boundary.

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?

"WHEN a client or a contractor needs the QUANTITIES to price a house" gives a clear use context, and the price-handling rule (pass your own prices, unpriced items go to sans_prix) is stated. There is no explicit when-not or a named alternative to route to, so it stops short of full guidance.

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.

Resources