Skip to main content
Glama
assoujojo82-coder

synergieloc — French Real-Estate Legal Calculations

by assoujojo82-coder
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

cao_mobilier

Furnish 3D scenes with real furniture and decoration objects instead of bare cuboids. Get categorized items with real dimensions for plans, 4K visits, PDF, DXF, and quantities.

Instructions

WHEN you are about to furnish or decorate a scene — call this BEFORE composing mobilier[], and never furnish with boites[]. FREE catalogue (no API key, 0 units) of REAL furniture and decoration objects. Until now a scene could only hold boites[] — bare cuboids — so an « fully furnished » house came back as grey cubes; this is the vocabulary that fixes it. ~50 modelled articles: OUTDOOR (parasol with mast/canopy/base, garden table+chairs set, sun lounger, barbecue, pergola, planter, gate, wrought-iron / wire-mesh / timber fencing, hedge, deciduous & conifer trees, garden shed, bench, pool), BATHROOM (wc, washbasin, shower, bathtub), KITCHEN (sink, fridge, oven, hob, extractor hood, fitted kitchen), LIVING/BEDROOM (sofa, corner sofa, armchair, coffee table, rug, bookcase with books, indoor plant, TV, floor lamp, mirror, framed art, curtains, bed, wardrobe, chest of drawers, bedside table). Each returns {categorie, libelle, cotes_defaut} — dimensions are OPTIONAL, defaults are real commercial sizes (3-seat sofa 2100×950, double bed 2000×1600, parasol Ø3000). Place with {type, x, y, z, rotation} where z is the FLOOR level under the object, not its centre. They appear in the 4K visit, the PDF board, the DXF and the quantities. Plumbing fixtures declared in plomberie[] are now also placed in 3D — do not duplicate them here. REST: GET /api/v1/cao/mobilier.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.1

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden for behavior. It explains the return format (categorie, libelle, cotes_defaut), that dimensions are optional with real commercial defaults, and that items appear in 4K visit, PDF, DXF, and quantities. It does not explicitly state read-only but it is clearly a fetch operation, so the behavior is well conveyed though not explicitly labelled as non-destructive.

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?

The description is detailed and well-organized, starting with the core purpose, then listing categories, return format, placement, and integration with other outputs. It is slightly long but each segment provides necessary context. The structure is logical, allowing quick extraction of key facts, though it could be tightened without losing value.

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?

Given no output schema and no annotations, the description must explain the tool's output and integration context. It fully does so: describes the return structure, dimension defaults, placement semantics, and warns about duplication with plomberie[]. It also indicates how results are consumed (4K visit, PDF, DXF, quantities). This is complete for an agent to use 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?

The input schema is empty (0 parameters), so schema coverage is 100%. The description adds no parameter-specific information because there are none to describe. Per the baseline, a score of 3 is appropriate since the description does not need to clarify parameters that do not exist.

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 clearly states the tool's purpose: to provide a catalog of real furniture and decoration objects for furnishing scenes, with explicit context ('call this BEFORE composing mobilier[]') and a contrast to the 'boites[]' placeholder. It is unambiguous and distinct from sibling tools like DXF generation or rendering.

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 gives explicit when-to-use guidance (before composing mobilier[]), when-not-to-use (avoid boites[], do not duplicate plumbing fixtures), and direct invocation ('REST: GET /api/v1/cao/mobilier'). It also explains placement details with z as floor level. This leaves no ambiguity about how to invoke and use the tool.

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