A
licenseNot graded
qualityD
maintenanceEnables AI agents to access French residential rental tools including lease creation and e-signing, rent control checks, rent revision, and document generation.
MIT
RemplirPDF
Server Details
French rental documents (leases, rent receipts, inventories) generated as filled PDFs by AI agents.
Ownership verified
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- benjammartin/remplirpdf-mcp
- GitHub Stars
- 0
- Server Listing
- RemplirPDF MCP server
- ChatGPT
- –
- Claude
- –
TDQS
A4.5/5.0
Scored across 5 tools
Disambiguation5/5
Each tool targets a distinct action and resource: the two list_* tools read the catalog vs. the user's documents, get_template reads a schema, generate_document writes, and get_download_link only issues a link. Descriptions explicitly cross-reference each other ("pour générer, utilisez generate_document", "ne crée rien") to prevent misuse.
Naming Consistency5/5
All five names follow the same snake_case verb_noun pattern (list_templates, get_template, generate_document, list_documents, get_download_link). Verb choices are semantically meaningful: list_ for collections, get_ for single-item reads/derivations, generate_ for creation.
Tool Count5/5
Five tools is a tight, well-scoped surface for a template-filling service: browse catalog, inspect schema, generate, list results, re-issue links. No redundant or filler tools, and nothing obviously needed is mashed into an overloaded tool.
Completeness4/5
The core lifecycle (discover template → read fields → generate/overwrite → list → download) is fully covered, and overwrite via document_id provides an update path. The only real gap is deletion of documents and any document-content preview, which agents can work around via get_download_link.
Available Tools
5 toolsgenerate_documentGénérer le PDF rempliADestructiveInspect
Remplit un modèle avec les valeurs fournies et enregistre le PDF dans le compte RemplirPDF de l'utilisateur ; renvoie un lien de téléchargement valable 24 h et le lien du document dans l'application. Vérifie d'abord les champs obligatoires et les formats : en cas d'erreur, rien n'est créé et la réponse liste ce qui manque. Sans document_id, crée toujours un nouveau document ; avec document_id, remplace le contenu d'un document déjà généré avec le même modèle (l'ancienne version est écrasée). Les valeurs doivent être exactes et fournies par l'utilisateur. Nécessite un abonnement RemplirPDF actif, sauf l'état des lieux (entrée, sortie ou modèle général), gratuit comme sur le site : sinon l'outil refuse, sans rien facturer ni démarrer de paiement. Appelez get_template avant pour connaître les champs ; pour retrouver un document existant, utilisez list_documents.
| Name | Required | Description | Default |
|---|---|---|---|
| values | Yes | Valeurs des champs : { nom_du_champ: "valeur" }, avec les noms renvoyés par get_template. Dates AAAA-MM-JJ, mois AAAA-MM, montants 750 ou 750,50, cases à cocher "Oui". Les champs inconnus sont ignorés et listés dans ignored_fields. | |
| template | Yes | Slug du modèle (voir list_templates), par exemple quittance-de-loyer. | |
| document_id | No | Facultatif : identifiant (doc_…) d'un document déjà généré avec ce même modèle, à remplacer au lieu d'en créer un nouveau. Un document qui a déjà une demande de signature n'est jamais modifié : un nouveau document est alors créé. |
Output Schema
| Name | Required | Description |
|---|---|---|
| pages | Yes | Nombre de pages du PDF. |
| title | Yes | Titre du document dans le compte. |
| app_url | Yes | Page du document dans l'application RemplirPDF (connexion requise) : modifier, envoyer, faire signer. |
| template | Yes | Slug du modèle utilisé. |
| next_steps | Yes | Ce que l'utilisateur peut faire ensuite (signature, envoi). |
| document_id | Yes | Identifiant du document (doc_…). |
| download_url | Yes | Lien de téléchargement direct du PDF, sans connexion, valable 24 h. |
| ignored_fields | No | Champs fournis mais inconnus du modèle (ignorés). |
| download_expires_at | Yes | Date d'expiration du lien de téléchargement (ISO 8601). |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, and the description goes well beyond them: it names exactly what is destroyed ('l'ancienne version est écrasée'), the exception where nothing is overwritten (a document with a pending signature request causes a new one to be created), atomic validation ('en cas d'erreur, rien n'est créé'), and the no-charge/no-payment-start refusal path. These are operational facts the agent could not infer from structured fields.
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?
Purpose, side effects, validation, overwrite semantics, and sibling routing are front-loaded in a dense but scannable sequence of semicolon-separated clauses. The line 'Les valeurs doivent être exactes et fournies par l'utilisateur' is close to filler given the schema already constrains values, which keeps it from a 5.
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 mutating, nested-parameter tool this covers everything an agent needs: prerequisites, failure behavior, overwrite risk, and prerequisite tool calls. With an output schema present it needn't explain return structure, yet it still previews the two returned links and the 24 h expiry.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents value formats and document_id semantics, so the baseline applies. The description still adds real meaning: the default 'Sans document_id, crée toujours un nouveau document' branch and the subscription exception that varies by template slug (état des lieux free) are not in the schema.
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?
States a specific verb and resource ('Remplit un modèle ... enregistre le PDF') plus the side effects (download link valid 24 h, document link in the app). The create-vs-overwrite branch on document_id makes it immediately distinguishable from read-only siblings like get_download_link and list_documents.
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?
Explicitly routes the agent: 'Appelez get_template avant pour connaître les champs' and 'pour retrouver un document existant, utilisez list_documents', naming two siblings and the condition that selects them. It also states the eligibility precondition (active RemplirPDF subscription, except état des lieux which is free) and what happens when it fails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_download_linkObtenir un lien de téléchargementARead-onlyIdempotentInspect
Renvoie un nouveau lien de téléchargement du PDF (valable 24 h) et le lien du document dans l'application, pour un document du compte. À utiliser quand un lien précédent a expiré ou pour un document retrouvé avec list_documents ; ne crée ni ne modifie aucun document (pour générer, utilisez generate_document). Nécessite un abonnement RemplirPDF actif, sauf l'état des lieux (entrée, sortie ou modèle général), gratuit comme sur le site : sinon l'outil refuse, sans rien facturer ni démarrer de paiement.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | Identifiant du document (doc_…), renvoyé par generate_document ou list_documents. |
Output Schema
| Name | Required | Description |
|---|---|---|
| title | Yes | Titre du document. |
| app_url | Yes | Page du document dans l'application RemplirPDF (connexion requise) : modifier, envoyer, faire signer. |
| document_id | Yes | Identifiant du document. |
| download_url | Yes | Lien de téléchargement direct du PDF, sans connexion, valable 24 h. |
| download_expires_at | Yes | Date d'expiration du lien de téléchargement (ISO 8601). |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: 24-hour link validity, the two values returned, the subscription requirement with its free exception, and the failure behavior ('refuse, sans rien facturer ni démarrer de paiement'). That is exactly the billing/auth context an agent cannot infer from structured fields.
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 action and validity window are front-loaded, followed by usage routing and then the precondition, which is a sensible order with no filler. It is dense but slightly overloaded in the final clause about subscription and non-billing, which could be trimmed without losing the tool's core selection signal.
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?
Complete for a single-parameter read tool: annotations cover the safety profile, an output schema exists, and the description still adds the expiry, the subscription gate, and the refusal semantics. An agent has everything needed to call it and to predict failure modes.
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 coverage is 100% and the single document_id parameter is already documented in the schema, including its origin ('renvoyé par generate_document ou list_documents'). The description adds only the account-scoping notion ('du compte'), so the baseline 3 applies.
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?
States a specific verb and resource ('Renvoie un nouveau lien de téléchargement du PDF') plus the exact output ('et le lien du document dans l'application') and the scope ('pour un document du compte'). It explicitly distinguishes itself from generate_document, so an agent can separate it from siblings without reading any schema.
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?
Gives concrete trigger conditions ('quand un lien précédent a expiré', 'pour un document retrouvé avec list_documents') and names the correct alternative for the adjacent intent ('pour générer, utilisez generate_document'). It also states a negative condition (no creation/modification) and a precondition (active subscription, with the état des lieux exception).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_templateDécrire un modèleARead-onlyIdempotentInspect
Décrit un modèle : champs à remplir (nom technique, libellé, obligatoire ou non, format attendu, options, valeur par défaut), champs calculés automatiquement et signataires. À appeler avant generate_document pour savoir quelles informations demander à l'utilisateur (ne les inventez pas) ; pour trouver le slug, utilisez list_templates. Lecture seule : ne crée rien.
| Name | Required | Description | Default |
|---|---|---|---|
| template | Yes | Slug du modèle renvoyé par list_templates, par exemple bail-meuble ou quittance-de-loyer. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | Nom du modèle. |
| slug | Yes | Identifiant du modèle. |
| notes | Yes | Règles à connaître avant de générer. |
| pages | No | Nombre de pages du PDF. |
| signers | Yes | Signataires du document. |
| category | Yes | Famille de documents. |
| sections | Yes | Parties du formulaire, dans l'ordre du document. |
| guide_url | Yes | Guide du document sur remplirpdf.fr. |
| document_title | Yes | Titre imprimé sur le document. |
| computed_automatically | Yes | Champs calculés par RemplirPDF : ne pas les fournir. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description reinforces this ("Lecture seule : ne crée rien") and adds genuinely new behavioral guidance — that it is a discovery/prerequisite step and that values must not be fabricated. Minor redundancy with the read-only annotation keeps it from a 5.
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?
Two sentences, front-loaded with the resource description, then the workflow constraint. Every clause carries information — no filler, no repetition of the tool title.
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?
An output schema exists, so return-value shape need not be explained, and annotations cover safety. The description supplies what structured fields cannot: the tool's role as a pre-generation discovery step and the prohibition on inventing field values. Nothing an agent needs to invoke it correctly 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?
With a single required enum parameter at 100% schema coverage, the schema already documents the slug and its allowed values in detail. The description's note that the slug comes from list_templates largely restates the schema's own wording. Baseline 3 is appropriate here.
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 opens with a specific verb and resource ("Décrit un modèle") and then enumerates exactly what is returned: fields to fill with their attributes (technical name, label, required, format, options, default), auto-computed fields, and signatories. This distinguishes it clearly from list_templates (which only yields slugs) and generate_document (which consumes the values).
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?
It gives an explicit ordering rule: call this before generate_document so the agent knows which information to request from the user, plus an explicit anti-pattern ("ne les inventez pas"). It also names the sibling to use for the prerequisite step (list_templates for the slug), so both the when and the alternative are spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_documentsLister mes documents de locationARead-onlyIdempotentInspect
Liste les derniers documents de location générés dans le compte de l'utilisateur (identifiant, titre, modèle, nombre de pages, date de mise à jour), du plus récent au plus ancien. À utiliser pour retrouver un document_id avant get_download_link, ou avant de mettre à jour un document avec generate_document. Lecture seule : ne crée ni ne modifie rien.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Nombre maximum de documents à renvoyer (de 1 à 50, 20 par défaut). |
Output Schema
| Name | Required | Description |
|---|---|---|
| documents | Yes | Documents, du plus récent au plus ancien. |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the closing sentence 'Lecture seule : ne crée ni ne modifie rien' largely restates structured data. What it does add beyond annotations is the ordering guarantee (most recent first) and the returned field list, but no pagination limits, account scoping caveats, or failure modes are covered.
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?
Two sentences, front-loaded with the resource and scope, followed by the routing guidance. Slightly wasteful only in the trailing read-only sentence, which duplicates the annotation hints.
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 simple read-only listing tool with an output schema present, everything an agent needs is covered: what it returns, ordering, and which sibling to call next. The field enumeration mildly duplicates the output schema but leaves no functional gap.
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% and the single 'limit' parameter is fully documented in the schema with default and 1-50 bounds, so the description reasonably leaves it alone. Baseline 3 applies since the description adds no syntax or semantics beyond the schema.
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?
States a specific verb (Liste) and resource (documents de location générés dans le compte) plus the fields returned and the sort order (du plus récent au plus ancien). This clearly separates it from get_download_link and generate_document, which the description explicitly names.
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?
Gives explicit downstream routing: use it to retrieve a document_id before calling get_download_link, or before updating a document with generate_document. That is a concrete when-to-use condition tied to named sibling tools, not an implied one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_templatesLister les modèles de locationARead-onlyIdempotentInspect
Liste les modèles de documents de location français proposés par RemplirPDF, un par page du catalogue (bail meublé, bail vide, bail mobilité, étudiant, colocation, commercial, précaire, état des lieux d'entrée et de sortie, quittance de loyer, avis d'échéance, attestations, acte de caution, préavis, congé pour vente…) avec leur slug, leur catégorie et leurs signataires. À appeler en premier quand le slug du modèle n'est pas encore connu ; pour les champs d'un modèle précis, utilisez get_template. Lecture seule : ne crée rien.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| templates | Yes | Les modèles disponibles. |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the closing 'Lecture seule : ne crée rien' largely restates that. It does add useful non-annotation context: results are paginated one template per catalog page. No auth or rate-limit detail, but the bar is lower with annotations present.
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?
Front-loaded with the purpose and the routing rule before the long parenthetical catalog list. The enumeration of a dozen template types is somewhat verbose, but it is informative and the sentence still earns its place.
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?
An output schema exists, so return values need no explanation, and the description still names the key fields. For a zero-parameter, read-only list tool the definition covers everything an agent needs to select and call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The mention of slug/catégorie/signataires describes output fields rather than inputs, which is harmless.
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?
States a specific verb and resource ('Liste les modèles de documents de location français') and enumerates the catalog contents (bail meublé, bail vide, quittance, etc.) with the fields returned (slug, catégorie, signataires). It explicitly distinguishes itself from the sibling get_template, so an agent can tell the two apart without opening a schema.
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?
Gives an explicit routing rule: call this first when the template slug is unknown, and use get_template instead for the fields of a specific template. The when-to-use and the named alternative are both present, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
generate_document1 field changed- changed
Input schema / properties / template / enumPrevious value: -[ - "etat-des-lieux", - "etat-des-lieux-sortie", - "quittance-de-loyer", - "bail-meuble", - "bail-location-vide", - "bail-mobilite", - "bail-etudiant", - "bail-colocation", - "bail-commercial", - "bail-precaire", - "etat-des-lieux-entree", - "attestation-de-loyer", - "avis-echeance-loyer", - "attestation-hebergement", - "attestation-hebergement-titre-gratuit", - "acte-caution-solidaire", - "preavis-logement", - "conge-pour-vente", - "attestation-fin-de-bail", - "echeancier-paiement-loyer", - "lettre-resiliation-bail-precaire", - "solde-de-tout-compte-location" -]New value: +[ + "etat-des-lieux", + "etat-des-lieux-sortie", + "quittance-de-loyer", + "bail-meuble", + "bail-location-vide", + "bail-mobilite", + "bail-etudiant", + "bail-colocation", + "bail-commercial", + "bail-precaire", + "etat-des-lieux-entree", + "attestation-de-loyer", + "avis-echeance-loyer", + "attestation-hebergement", + "attestation-hebergement-titre-gratuit", + "acte-caution-solidaire", + "preavis-logement", + "conge-pour-vente", + "attestation-fin-de-bail", + "echeancier-paiement-loyer", + "lettre-resiliation-bail-precaire", + "solde-de-tout-compte-location", + "declaration-mise-en-location" +]
- Changed
get_template1 field changed- changed
Input schema / properties / template / enumPrevious value: -[ - "etat-des-lieux", - "etat-des-lieux-sortie", - "quittance-de-loyer", - "bail-meuble", - "bail-location-vide", - "bail-mobilite", - "bail-etudiant", - "bail-colocation", - "bail-commercial", - "bail-precaire", - "etat-des-lieux-entree", - "attestation-de-loyer", - "avis-echeance-loyer", - "attestation-hebergement", - "attestation-hebergement-titre-gratuit", - "acte-caution-solidaire", - "preavis-logement", - "conge-pour-vente", - "attestation-fin-de-bail", - "echeancier-paiement-loyer", - "lettre-resiliation-bail-precaire", - "solde-de-tout-compte-location" -]New value: +[ + "etat-des-lieux", + "etat-des-lieux-sortie", + "quittance-de-loyer", + "bail-meuble", + "bail-location-vide", + "bail-mobilite", + "bail-etudiant", + "bail-colocation", + "bail-commercial", + "bail-precaire", + "etat-des-lieux-entree", + "attestation-de-loyer", + "avis-echeance-loyer", + "attestation-hebergement", + "attestation-hebergement-titre-gratuit", + "acte-caution-solidaire", + "preavis-logement", + "conge-pour-vente", + "attestation-fin-de-bail", + "echeancier-paiement-loyer", + "lettre-resiliation-bail-precaire", + "solde-de-tout-compte-location", + "declaration-mise-en-location" +]
2 tool updates
- Changed
generate_document1 field changed- changed
Input schema / properties / template / enumPrevious value: -[ - "etat-des-lieux", - "etat-des-lieux-sortie", - "quittance-de-loyer", - "bail-meuble", - "bail-location-vide", - "bail-mobilite", - "bail-etudiant", - "bail-colocation", - "bail-commercial", - "bail-precaire", - "etat-des-lieux-entree", - "attestation-de-loyer", - "avis-echeance-loyer", - "attestation-hebergement", - "attestation-hebergement-titre-gratuit", - "acte-caution-solidaire", - "preavis-logement", - "conge-pour-vente", - "attestation-fin-de-bail", - "echeancier-paiement-loyer", - "lettre-resiliation-bail-precaire" -]New value: +[ + "etat-des-lieux", + "etat-des-lieux-sortie", + "quittance-de-loyer", + "bail-meuble", + "bail-location-vide", + "bail-mobilite", + "bail-etudiant", + "bail-colocation", + "bail-commercial", + "bail-precaire", + "etat-des-lieux-entree", + "attestation-de-loyer", + "avis-echeance-loyer", + "attestation-hebergement", + "attestation-hebergement-titre-gratuit", + "acte-caution-solidaire", + "preavis-logement", + "conge-pour-vente", + "attestation-fin-de-bail", + "echeancier-paiement-loyer", + "lettre-resiliation-bail-precaire", + "solde-de-tout-compte-location" +]
- Changed
get_template1 field changed- changed
Input schema / properties / template / enumPrevious value: -[ - "etat-des-lieux", - "etat-des-lieux-sortie", - "quittance-de-loyer", - "bail-meuble", - "bail-location-vide", - "bail-mobilite", - "bail-etudiant", - "bail-colocation", - "bail-commercial", - "bail-precaire", - "etat-des-lieux-entree", - "attestation-de-loyer", - "avis-echeance-loyer", - "attestation-hebergement", - "attestation-hebergement-titre-gratuit", - "acte-caution-solidaire", - "preavis-logement", - "conge-pour-vente", - "attestation-fin-de-bail", - "echeancier-paiement-loyer", - "lettre-resiliation-bail-precaire" -]New value: +[ + "etat-des-lieux", + "etat-des-lieux-sortie", + "quittance-de-loyer", + "bail-meuble", + "bail-location-vide", + "bail-mobilite", + "bail-etudiant", + "bail-colocation", + "bail-commercial", + "bail-precaire", + "etat-des-lieux-entree", + "attestation-de-loyer", + "avis-echeance-loyer", + "attestation-hebergement", + "attestation-hebergement-titre-gratuit", + "acte-caution-solidaire", + "preavis-logement", + "conge-pour-vente", + "attestation-fin-de-bail", + "echeancier-paiement-loyer", + "lettre-resiliation-bail-precaire", + "solde-de-tout-compte-location" +]
2 tool updates
- Changed
generate_document1 field changed- changed
Input schema / properties / template / enumPrevious value: -[ - "etat-des-lieux", - "etat-des-lieux-sortie", - "quittance-de-loyer", - "bail-meuble", - "bail-location-vide", - "bail-mobilite", - "bail-etudiant", - "bail-colocation", - "bail-commercial", - "bail-precaire", - "etat-des-lieux-entree", - "attestation-de-loyer", - "avis-echeance-loyer", - "attestation-hebergement", - "attestation-hebergement-titre-gratuit", - "acte-caution-solidaire", - "preavis-logement", - "conge-pour-vente", - "attestation-fin-de-bail", - "echeancier-paiement-loyer" -]New value: +[ + "etat-des-lieux", + "etat-des-lieux-sortie", + "quittance-de-loyer", + "bail-meuble", + "bail-location-vide", + "bail-mobilite", + "bail-etudiant", + "bail-colocation", + "bail-commercial", + "bail-precaire", + "etat-des-lieux-entree", + "attestation-de-loyer", + "avis-echeance-loyer", + "attestation-hebergement", + "attestation-hebergement-titre-gratuit", + "acte-caution-solidaire", + "preavis-logement", + "conge-pour-vente", + "attestation-fin-de-bail", + "echeancier-paiement-loyer", + "lettre-resiliation-bail-precaire" +]
- Changed
get_template1 field changed- changed
Input schema / properties / template / enumPrevious value: -[ - "etat-des-lieux", - "etat-des-lieux-sortie", - "quittance-de-loyer", - "bail-meuble", - "bail-location-vide", - "bail-mobilite", - "bail-etudiant", - "bail-colocation", - "bail-commercial", - "bail-precaire", - "etat-des-lieux-entree", - "attestation-de-loyer", - "avis-echeance-loyer", - "attestation-hebergement", - "attestation-hebergement-titre-gratuit", - "acte-caution-solidaire", - "preavis-logement", - "conge-pour-vente", - "attestation-fin-de-bail", - "echeancier-paiement-loyer" -]New value: +[ + "etat-des-lieux", + "etat-des-lieux-sortie", + "quittance-de-loyer", + "bail-meuble", + "bail-location-vide", + "bail-mobilite", + "bail-etudiant", + "bail-colocation", + "bail-commercial", + "bail-precaire", + "etat-des-lieux-entree", + "attestation-de-loyer", + "avis-echeance-loyer", + "attestation-hebergement", + "attestation-hebergement-titre-gratuit", + "acte-caution-solidaire", + "preavis-logement", + "conge-pour-vente", + "attestation-fin-de-bail", + "echeancier-paiement-loyer", + "lettre-resiliation-bail-precaire" +]
2 tool updates
- Changed
generate_document1 field changed- changed
Input schema / properties / template / enumPrevious value: -[ - "etat-des-lieux", - "etat-des-lieux-sortie", - "quittance-de-loyer", - "bail-meuble", - "bail-location-vide", - "bail-mobilite", - "bail-etudiant", - "bail-colocation", - "bail-commercial", - "bail-precaire", - "etat-des-lieux-entree", - "attestation-de-loyer", - "avis-echeance-loyer", - "attestation-hebergement", - "attestation-hebergement-titre-gratuit", - "acte-caution-solidaire", - "preavis-logement", - "conge-pour-vente", - "attestation-fin-de-bail" -]New value: +[ + "etat-des-lieux", + "etat-des-lieux-sortie", + "quittance-de-loyer", + "bail-meuble", + "bail-location-vide", + "bail-mobilite", + "bail-etudiant", + "bail-colocation", + "bail-commercial", + "bail-precaire", + "etat-des-lieux-entree", + "attestation-de-loyer", + "avis-echeance-loyer", + "attestation-hebergement", + "attestation-hebergement-titre-gratuit", + "acte-caution-solidaire", + "preavis-logement", + "conge-pour-vente", + "attestation-fin-de-bail", + "echeancier-paiement-loyer" +]
- Changed
get_template1 field changed- changed
Input schema / properties / template / enumPrevious value: -[ - "etat-des-lieux", - "etat-des-lieux-sortie", - "quittance-de-loyer", - "bail-meuble", - "bail-location-vide", - "bail-mobilite", - "bail-etudiant", - "bail-colocation", - "bail-commercial", - "bail-precaire", - "etat-des-lieux-entree", - "attestation-de-loyer", - "avis-echeance-loyer", - "attestation-hebergement", - "attestation-hebergement-titre-gratuit", - "acte-caution-solidaire", - "preavis-logement", - "conge-pour-vente", - "attestation-fin-de-bail" -]New value: +[ + "etat-des-lieux", + "etat-des-lieux-sortie", + "quittance-de-loyer", + "bail-meuble", + "bail-location-vide", + "bail-mobilite", + "bail-etudiant", + "bail-colocation", + "bail-commercial", + "bail-precaire", + "etat-des-lieux-entree", + "attestation-de-loyer", + "avis-echeance-loyer", + "attestation-hebergement", + "attestation-hebergement-titre-gratuit", + "acte-caution-solidaire", + "preavis-logement", + "conge-pour-vente", + "attestation-fin-de-bail", + "echeancier-paiement-loyer" +]
5 tool updates
- First observed
generate_document - First observed
get_download_link - First observed
get_template - First observed
list_documents - First observed
list_templates
Related MCP Connectors
French rental tools: create & e-sign a lease, rent control, IRL, deposit, receipts (France).
Your rental records in your own AI: homes, rent, repairs and renewal proposals. Sign-in required.
Deterministic PDF tools for AI agents: inspect fields, fill forms, merge PDFs, invoices.
FR/EN tools for French rental, frontalier & home-employment (CCN 3239) — sourced, dated answers.
Related MCP Servers
- AlicenseAqualityBmaintenanceExact French real-estate legal calculations for AI agents: IRL rent revision, service-charge reconciliation, compliant rent receipts — legal basis included in every answer.41MIT
- FlicenseNot gradedqualityDmaintenanceEnables users to generate rental agreements and receipts as PDFs through an AI-powered WhatsApp bot. Provides stamp duty information lookup and handles rental document creation with customizable templates.-
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to operate property management systems via natural language, covering repair orders, owner info, payments, notices, and inspections. Features a full agentic workflow with human-in-the-loop and observability.1MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.