Skip to main content
Glama

cao_verifier

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)
cerclesNo
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`).

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 does so thoroughly. It details numerous specific checks (e.g., 'openings.z used as absolute altitude instead of relative sill', 'escalier_depart_hors_batiment'), explains return format ('{ok, erreurs_schema, alertes[...], conseils, resume}'), states severity rules ('Fix severite=critique before delivery'), discloses that some checks are WARNING-level and why ('an open stairwell is a legitimate choice'), and describes the correctifs[] array with real replacement positions. It also mentions that applying fixes is possible via another endpoint, avoiding misleading the agent about this tool's own side effects.

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 is a dense, unstructured paragraph that is very long. While it is front-loaded with the key usage guidance, it becomes verbose and repetitive: it mentions 'correctifs[]' multiple times, states 'free, no key' twice, and lists REST endpoints repeatedly (POST /api/v1/cao/integrite appears twice, plus the standalone documents endpoint and the REST equivalent). It lacks clear section breaks or bullet points, making it harder to scan, though all content is relevant. It is not concise, but the information is valuable.

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 tool with 10 parameters, no output schema, and no annotations, the description is exceptionally complete. It covers the purpose, the full range of checks (geometric, structural, document completeness), the return structure, the severity levels, the correction mechanism, how to apply fixes via separate endpoints, and even mentions the 'regles_archi' output. It also clarifies that certain checks are non-blocking warnings. There is no missing critical information for an agent to invoke and interpret the tool correctly.

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 90%, so the schema already documents parameter meanings (e.g., 'murs: Walls: plan segments extruded vertically', 'ouvertures.z: Sill height (mm)'). The description does add context by explaining how certain parameters are interpreted in checks (e.g., 'openings.z used as absolute altitude instead of relative sill'), but this is more about behavioral insight than new parameter semantics. The tool description does not systematically elaborate on each parameter beyond what the schema offers, so baseline 3 is appropriate.

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 provides a specific verb ('geometric audit', 'checks') and resource ('CAO scene'), and clearly distinguishes from sibling tools by naming 'cao_pdf', 'cao_generer_dxf', 'cao_rendu', 'cao_visite_plan', 'cao_visite_studio' as the tools to run after this check. It is explicit about being the pre-delivery verification step, leaving no doubt about the tool's function.

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 description opens with a precise usage window: 'WHEN a scene is composed and BEFORE cao_pdf / cao_generer_dxf / cao_rendu / cao_visite_plan / cao_visite_studio', and explains it is 'the cheap check that stops a wrong plan or broken 4K visit from being delivered'. It also mentions standalone REST endpoints for specific sub-checks (POST /api/v1/cao/integrite, /api/v1/cao/documents) and the REST equivalent, giving clear when-to-use context. No exclusion criteria stated, but the positioning is explicit.

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.

TDQS

B3.2/5.0
Disambiguation4/5

Most tools are clearly distinct by purpose (e.g., quittance_loyer vs relance_impaye, or relance_facture_client vs relance_impaye). A few pairs like bon_intervention and fiche_mission could cause confusion, but detailed descriptions help resolve ambiguity.

Naming Consistency3/5

Tool names mix French and English, and use inconsistent patterns: some are noun-based (annonce_location, quittance_loyer), some verb-based (decide_campagne, obtenir_cle_api), and the cao_* tools use a prefix convention. Still readable but not uniform.

Tool Count2/5

41 tools is excessive for most servers, even one covering real estate and CAD. While the breadth is justified by multiple subdomains, the sheer number makes the surface hard to navigate and suggests possible over-fragmentation.

Completeness4/5

The tool set covers a wide range: rental lifecycle (annonce, EDL, quittance, relance), owner reporting, artisan documents, fiscal synthesis, CAD generation and verification, outreach, and guides. Minor gaps exist (e.g., no direct tenant/property CRUD), but for a document-generation server it is quite complete.

Resources