Skip to main content
Glama
assoujojo82-coder

synergieloc — French Real-Estate Legal Calculations

cao_verifier

Audit a CAO scene for geometric errors before delivery: detect invalid staircases, misplaced openings, roof flaws, and broken building envelope; receive exact corrective fixes.

Instructions

WHEN a scene is composed and BEFORE cao_pdf / cao_generer_dxf / cao_rendu / cao_visite_plan / cao_visite_studio — the cheap check that stops a wrong plan or broken 4K visit from being delivered. FREE geometric audit of a CAO scene (no API key, 0 units). Detects the mistakes that make planches look wrong: openings.z used as absolute altitude instead of relative sill (allège), chien_assis dormers floating outside the roof, upper storey walls with no windows, guardrails far from the building, missing stairs between floors, openings overflowing their wall. ALSO checks that a staircase actually leads somewhere (escalier_traverse_mur — the flight runs into a partition of its own level; escalier_arrivee_hors_batiment — it lands outside the walls). STAIRCASE PLACEMENT is checked in full, because a stair dropped in an absurd spot is the most visible flaw of an AI-composed model: escalier_depart_hors_batiment (it starts in the void), escalier_volee_hors_batiment (the flight leaves the building on the way up), escalier_bloque_ouverture (it seals a doorway), escalier_z_hors_niveau (it floats between two slabs), escalier_hauteur_incoherente (it stops short of the floor above), escalier_chevauche (two flights in the same footprint), and escalier_sans_appui (free-standing mid-room — a WARNING, not blocking: an open stairwell is a legitimate choice). Each one comes with a correctifs[] entry carrying a REAL replacement position (x/y/rotation): the closest valid spot to what you asked for, backed against a wall, arriving in clear space and blocking no door. Apply with POST /api/v1/cao/integrite {appliquer:true, revalider:true} — you never have to guess where to put it. ALSO checks that a dormer sits on the slope (lucarne_profondeur_courte / _longue / lucarne_trop_haute — depth must be ≈ height / roof pitch, otherwise its roof floats above the slope or overshoots the ridge). Returns {ok, erreurs_schema, alertes[{code,severite,message,corriger}], conseils, resume}. Fix severite=critique before delivery. ALSO runs a full STRUCTURAL INTEGRITY check (is the building really closed and roofed?): enveloppe_percee — a wall end joins nothing (T-junctions and door jambs are recognised, so no false alarms) — murs_composantes_isolees — closed wall clusters / pillars / low walls scattered OUTSIDE the main envelope (the 'murs en vrac' Visite 4K defect; correctifs propose null = delete that wall) — bande_ouverte_entre_niveaux, mur_etage_sans_appui, toit_ouvert, toiture_sous_les_murs, ouvertures_chevauchantes. ALSO dalle_flottante / pilier_detache on orphan boxes. It returns integrite.correctifs[]: the exact field to write and the value to write there, e.g. {cible:'murs[3].x2', actuel:10400, propose:11000, raison:…} or {cible:'murs[12]', propose:null} to remove clutter. POST /api/v1/cao/integrite runs that check alone and can APPLY the fixes for you (appliquer:true, revalider:true) — also free, no key. Response includes regles_archi (buildingSMART-inspired principles). ALSO checks DOCUMENT COMPLETENESS (documents): the PDF planche delivers one full plan PER STOREY — 4 storeys means 4 complete plans — so it flags element_hors_plan (a stair/guardrail whose z attaches to no storey: it would vanish from EVERY plan), niveau_non_desservi (no stair ARRIVES at that storey and no lift covers it), arrivee_sans_protection (stair head without guardrail, NF P01-012), hauteur_niveau_insuffisante (<2200 mm). documents.couverture is the announced table of contents of the planche. Standalone: POST /api/v1/cao/documents (free, supports appliquer/revalider too). REST equivalent: POST /api/v1/cao/verifier.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mursNoWalls: plan segments extruded vertically
planNo2D reference lines
boitesNoBoxes (furniture, volumes): center x,y + dims l,p,h (mm)
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).
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`).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.1

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and over-delivers: it discloses the response shape ({ok, erreurs_schema, alertes[{code,severite,message,corriger}], conseils, resume}), the severity model (escalier_sans_appui is 'a WARNING, not blocking: an open stairwell is a legitimate choice'), the optional mutation path (appliquer:true, revalider:true), and even destructive semantics ('correctifs propose null = delete that wall'). It also states cost/side-effect traits (0 units, no API key) that would otherwise be unknowable. No contradiction with annotations since none exist.

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 description front-loads the critical when-to-use and the value proposition, and each check-code paragraph is dense with useful detail. However, it is very long, repeats itself (POST /api/v1/cao/integrite {appliquer:true, revalider:true} appears twice; 'free/no key' appears three times), and the four 'ALSO' segments create a rambling hierarchy that could be grouped more cleanly. Every paragraph earns its place; the redundancies and flat structure keep it from being tight.

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?

For a complex audit tool with no output schema and 10 optional input params, the description is exceptionally complete: it enumerates the full set of checks (geometry, staircase placement, dormer, structural integrity, document completeness), the return envelope, the correctifs[] corrective mechanism with worked examples ({cible:'murs[3].x2', actuel:10400, propose:11000}), severity handling, apply semantics, and standalone endpoints. Nothing an agent needs to invoke and interpret this tool is missing.

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 baseline of 3 applies — every parameter and nested field already carries a description (e.g., ouvertures[].z 'Sill height (mm)', toitures chien_assis 'POSITION it on the carrying roof slope'). The tool description adds little new parameter meaning; its check-specific references (e.g., 'openings.z used as absolute altitude instead of relative sill') restate semantics the schema already documents. It correctly leaves inputs to the schema and focuses on behavior.

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 names a specific verb and resource — 'FREE geometric audit of a CAO scene' — and frames it as 'the cheap check that stops a wrong plan or broken 4K visit from being delivered.' It explicitly distinguishes itself from sibling generation tools by naming them ('BEFORE cao_pdf / cao_generer_dxf / cao_rendu / cao_visite_plan / cao_visite_studio') and even gives the REST equivalent (POST /api/v1/cao/verifier). An agent knows exactly what this tool is and is not.

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 opening states the exact invocation context: 'WHEN a scene is composed and BEFORE' the generation siblings, and the closing directive 'Fix severite=critique before delivery' tells the agent what to do with the result. It also names the alternatives for running subsets of the same checks standalone (POST /api/v1/cao/integrite, POST /api/v1/cao/documents), making the when/which choice explicit rather than implied.

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