immobilier
Server Details
Exact French real-estate legal calculations for AI agents: rent revision, charges, receipts.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.5/5 across 7 of 7 tools scored. Lowest: 2.6/5.
Each tool has a clearly distinct purpose within its domain; no two tools perform the same function. The CAO tools (generation, quantities, rendering) are distinct, and the rent management tools (revision calculation, letter, receipt, charge regularization) are also distinct.
All tool names use consistent snake_case and are descriptive, primarily in French. However, there is slight inconsistency in verb positioning (e.g., 'avenant_revision_irl' vs 'irl_revision_loyer') and some names are more noun-like while others include verbs.
7 tools is a reasonable number for a focused server. It is not too few or too many; each tool serves a specific purpose without redundancy.
The tool set covers two subdomains (rent management and CAO) but has notable gaps. For rent management, there are no tools for lease creation, tenant management, or payment tracking. For CAO, scene editing and other import/export formats are missing. The surface feels incomplete for a comprehensive real estate server.
Available Tools
7 toolsavenant_revision_irlCInspect
Courrier de révision de loyer IRL prêt à envoyer au locataire (HTML imprimable ; PDF via /api/v1/documents/avenant-irl). Calcule et notifie le nouveau loyer.
| Name | Required | Description | Default |
|---|---|---|---|
| lieu | No | ||
| date_effet | Yes | ||
| irl_nouveau | Yes | ||
| bailleur_nom | Yes | ||
| loyer_actuel | Yes | ||
| irl_reference | Yes | ||
| locataire_nom | Yes | ||
| bailleur_adresse | No | ||
| logement_adresse | Yes | ||
| trimestre_nouveau | No | ||
| trimestre_reference | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions it calculates the new rent and generates HTML with PDF option, disclosing output format. However, it omits details on side effects (e.g., does 'notifie' mean a notification is sent?) and does not cover permissions or limits. With no annotations, more transparency would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with parenthetical detail, making it concise. However, it lacks structured breakdown of behavior or parameters, and could be more informative without significant expansion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and no annotations, the description fails to provide adequate context. It does not explain what the tool returns (beyond output format) or how parameters interrelate, leaving the agent with substantial ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description adds no explanation for any of the 11 parameters. The agent must infer meaning from parameter names alone, which may be ambiguous (e.g., 'lieu', 'trimestre_nouveau'). This is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a rent revision letter ('Courrier de révision de loyer IRL') and indicates output formats (HTML, PDF). However, it does not differentiate from the sibling tool 'irl_revision_loyer', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states what it does without specifying use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cao_generer_dxfAInspect
Draw a building scene autonomously and get an AutoCAD-compatible DXF file. Describe walls (2D plan coordinates in mm, extruded to 3D), boxes and 2D plan lines/circles — returns the DXF R12 text (save it as .dxf, opens in AutoCAD/LibreCAD). Perfect for AI agents that design floor plans, gardens or landscape layouts. Same scene format as cao_metres and cao_rendu. Scene schema + examples: GET https://synergieloc.fr/api/v1/cao/schema — human guide: https://synergieloc.fr/guides/cao-3d-artisan
| Name | Required | Description | Default |
|---|---|---|---|
| murs | No | Walls: plan segments extruded vertically | |
| plan | No | 2D reference lines | |
| boites | No | Boxes (furniture, volumes): center x,y + dims l,p,h (mm) | |
| cercles | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the output format (DXF R12 text) and expected usage (autonomous generation). Since no annotations are provided, the description carries the burden but does not cover potential side effects, authentication, rate limits, or error behavior. There is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four well-structured sentences. The first sentence immediately states the primary purpose, followed by a list of supported elements, then output format compatibility, and finally links for further guidance. No redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the output format and references the shared scene schema, which is critical for use. It lacks details on error handling or limits, but for a generation tool with no output schema, it provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 parameters have descriptions). The description repeats some schema details (e.g., 'walls: plan segments extruded vertically') but adds little beyond what the schema already provides. The external schema link is a bonus, but not directly adding parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool draws a building scene and returns an AutoCAD-compatible DXF file. It specifies supported elements (walls, boxes, 2D lines/circles) and distinguishes from sibling tools by noting 'Same scene format as cao_metres and cao_rendu'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: 'Perfect for AI agents that design floor plans, gardens or landscape layouts' and mentions the shared scene format with siblings. However, it does not explicitly state when to avoid using this tool or which alternative to choose for other needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cao_metresBInspect
Compute quantities (metrés) from a CAO scene: wall linear/surface (ml, m²), boxes surface/volume (m², m³), footprint (m²) — feeds a quote directly. Same scene format as cao_generer_dxf.
| Name | Required | Description | Default |
|---|---|---|---|
| murs | No | Walls: plan segments extruded vertically | |
| plan | No | 2D reference lines | |
| boites | No | Boxes (furniture, volumes): center x,y + dims l,p,h (mm) | |
| cercles | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose whether the operation is read-only, any side effects, permissions needed, or rate limits. The output structure is not described, and the behavioral implications beyond the stated purpose are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose, and contains no redundant or extraneous information. Every word contributes to understanding the tool's function and input constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description is incomplete. It does not specify the return format or structure (e.g., whether the tool returns JSON with the computed quantities). The mention of 'feeds a quote directly' hints at the output use but lacks concrete details needed for agent execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 75% schema description coverage, the schema already documents three of four parameters (murs, plan, boites). The description adds context about what quantities each parameter contributes (e.g., walls produce ml/m²), but does not add new parameter-level semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Compute' and lists the exact quantities (ml, m², m³, footprint) for walls, boxes, and footprint. It also references a sibling tool (cao_generer_dxf) to clarify the input format, distinguishing it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that the tool 'feeds a quote directly', implying its usage for generating cost estimates. It mentions the input format is shared with cao_generer_dxf, but does not provide explicit when-to-use or when-not-to-use conditions compared to other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cao_renduAInspect
Render a top-down preview (plan view) of a CAO scene, as SVG (default, vector text) or PNG (base64 image) — lets an AI agent visually verify what it just designed before delivering it. Same scene format as cao_generer_dxf.
| Name | Required | Description | Default |
|---|---|---|---|
| murs | No | Walls: plan segments extruded vertically | |
| plan | No | 2D reference lines | |
| boites | No | Boxes (furniture, volumes): center x,y + dims l,p,h (mm) | |
| format | No | svg | |
| cercles | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions the output formats and that it is a preview (non-destructive), but does not disclose performance considerations, limits, or authentication requirements. It is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose and key output details (SVG/PNG), and includes a helpful note about the scene format matching another tool. Every sentence is informative without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested objects, no output schema), the description covers the main purpose and output format but omits details like coordinate system, scale, or response structure. It is mostly complete but leaves some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning beyond the input schema, which already describes the parameters (walls, plan, boites, format, cercles) with 60% coverage. The baseline of 3 is appropriate as the schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a top-down preview of a CAO scene, outputs SVG or PNG, and explicitly mentions the same scene format as the sibling cao_generer_dxf. This distinguishes it from other sibling tools like cao_generer_dxf and cao_metres.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for visual verification after design, and references the same scene format as cao_generer_dxf, suggesting a workflow. However, it does not explicitly state when not to use it or what the alternatives are, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
irl_revision_loyerAInspect
Révision annuelle d'un loyer d'habitation indexée sur l'IRL (art. 17-1 loi 89-462). Fournir le loyer actuel et les deux indices IRL (INSEE). Renvoie le nouveau loyer plafonné, la formule et les avertissements légaux.
| Name | Required | Description | Default |
|---|---|---|---|
| irl_nouveau | Yes | Dernier IRL publié (même trimestre, année suivante) | |
| loyer_actuel | Yes | Loyer mensuel hors charges (€) | |
| irl_reference | Yes | IRL du trimestre de référence du bail | |
| charges_actuelles | No | Provisions de charges (optionnel) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that the tool returns the new rent capped, the formula, and legal warnings, but does not mention whether it is a read-only calculation, any authentication needs, rate limits, or side effects. Since it is a calculation tool, the lack of destructive action disclosure is acceptable, but more detail on output behavior would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no unnecessary words. It front-loads the purpose and lists key inputs and outputs. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (3 required), no output schema, no annotations, and sibling tools, the description is fairly complete. It explains the legal basis, inputs, and outputs. However, it does not explain how the optional 'charges_actuelles' is used or provide guidance on constraints like IRL values being from INSEE. Output format is implied but not detailed. Slight gap prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a description in the schema. The tool description reinforces the purpose of the parameters ('Fournir le loyer actuel et les deux indices IRL') but adds no new meaning beyond what the schema provides. The optional 'charges_actuelles' parameter is mentioned but not explained further. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs annual rent revision indexed on IRL, citing the specific law (art. 17-1 loi 89-462). It specifies the required inputs (current rent, two IRL indices) and outputs (new capped rent, formula, legal warnings). This distinguishes it from siblings like 'avenant_revision_irl' (likely amending a lease) and 'quittance_loyer' (rent receipt).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for annual revisions but does not explicitly state when to use it versus alternatives, nor does it mention when not to use it. There is no guidance on prerequisites or conditions beyond the required inputs. The context is clear but lacks exclusions or sibling tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quittance_loyerAInspect
Génère une quittance de loyer conforme (art. 21 loi 89-462), renvoyée en HTML imprimable (mentions légales incluses). Le même appel sur /api/v1/documents/quittance renvoie le PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| lieu | No | ||
| loyer | Yes | ||
| charges | No | ||
| periode | Yes | ex. 01/07/2026 au 31/07/2026 | |
| bailleur_nom | Yes | ||
| date_paiement | Yes | ||
| locataire_nom | Yes | ||
| bailleur_adresse | No | ||
| logement_adresse | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adds some transparency by stating the output is HTML imprimable and mentions a PDF alternative via a different endpoint. However, it does not disclose authentication needs, side effects, or constraints beyond format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading purpose and output format. Every word earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no annotations, the description is too sparse. It omits details on required vs. optional fields, default values, error handling, and the exact content of the returned HTML. This leaves significant gaps for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema parameter description coverage is only 11% (only 'periode' has a description). The tool description adds no explanation for parameters like 'lieu', 'charges', or required fields, leaving the agent to infer meaning from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Génère une quittance de loyer conforme (art. 21 loi 89-462)', specifying a verb (génère) and a resource (quittance de loyer) with legal context, distinguishing it from siblings that handle rent revision or charges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for generating rent receipts, but provides no explicit guidance on when to use this tool versus alternatives like avenant_revision_irl or regularisation_charges. No when-not or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
regularisation_chargesBInspect
Régularisation annuelle des charges locatives (décret 87-713) : quote-part locataire par tantièmes et prorata temporis, décompte détaillé, solde (trop-perçu à rembourser ou complément à réclamer).
| Name | Required | Description | Default |
|---|---|---|---|
| charges | Yes | ||
| jours_periode | No | ||
| tantiemes_total | Yes | ||
| jours_occupation | No | Jours d'occupation (optionnel, prorata) | |
| tantiemes_locataire | Yes | ||
| provisions_encaissees | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses the calculation method (prorata temporis, tantièmes) and output (solde, overpayment/underpayment). However, it does not mention behavioral traits like idempotency, authorization needs, or error handling. With no annotations, the description offers moderate transparency but lacks depth on side effects or return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key action and resource. It is concise and contains no redundant information. However, it could be slightly improved by breaking into bullet points for clarity, and it is only in French.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (3 required) and no output schema or annotations, the description explains the overall purpose and calculation method but fails to detail input requirements (e.g., format of 'charges' array, meaning of 'tantiemes') or the output structure (e.g., detailed breakdown format). It is partially complete for a domain expert but needs more for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only 'jours_occupation' described). The description provides high-level context for tantièmes and prorata but does not explain individual parameters such as 'charges' array structure, 'provisions_encaissees', or the meaning of 'tantiemes' values. It insufficiently compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('régularisation') and resource ('charges locatives'), includes legal reference (décret 87-713), and specifies the calculation method (quotité par tantièmes et prorata temporis). It is distinct from sibling tools (avenant_revision_irl, irl_revision_loyer, quittance_loyer) which deal with rent revisions and receipts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for annual charge adjustment but does not provide when-not-to-use or mention any prerequisites or context conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!