Skip to main content
Glama
assoujojo82-coder

synergieloc — French Real-Estate Legal Calculations

by assoujojo82-coder
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

cao_generer_dxf

Generate an AutoCAD DXF file of a building scene from walls, openings, roofs, and fixtures, with geometry verification via cao_verifier to catch errors.

Instructions

WHEN the drawing must leave as a real CAD file, openable by an architect or a draughtsman. Draw a building scene and get an AutoCAD DXF. Call cao_verifier first to catch geometry mistakes. Scene schema: GET https://synergieloc.fr/api/v1/cao/schema. JSON response includes alertes[] when issues remain.

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

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full disclosure burden. It adds genuinely useful behavior: the JSON response includes alertes[] when issues remain, and the output is a real CAD/DXF file. However, it does not disclose the DXF return format (file URL vs base64), auth/API-key needs, or failure/error behavior — notable gaps for a file-generating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five short sentences with zero filler. The trigger condition is front-loaded, followed by the core action, the prerequisite verifier call, and the schema/response pointers. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential call arc: when to use → what it does → prerequisite (cao_verifier) → schema location → response warnings (alertes[]). Gaps remain: no output schema exists, so how the DXF is delivered is unexplained; no auth guidance despite an obtenir_cle_api sibling; and retry semantics after alertes[] are implicit. Adequate but not complete for a 10-parameter generation 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%, with extensive per-field documentation (toitures type/defaults, reseaux enums, position semantics, electricite NF C 15-100 defaults). The description adds a pointer to the canonical schema endpoint (GET /api/v1/cao/schema), which is a small bonus, but the inline schema already does the heavy lifting. Baseline 3 is appropriate.

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 uses a specific verb+resource pairing: 'Draw a building scene and get an AutoCAD DXF.' The WHEN clause ('must leave as a real CAD file, openable by an architect or a draughtsman') gives clear purpose context. It does not explicitly name sibling tools like cao_generer_ifc or cao_pdf, so differentiation is implicit rather than stated, which keeps it at 4.

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?

States a clear trigger condition ('WHEN the drawing must leave as a real CAD file') and gives explicit sequencing guidance ('Call cao_verifier first to catch geometry mistakes'). Lacks explicit when-not conditions or named alternative tools, so it stops just short of a 5.

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

Deploy Server

Other Tools