Skip to main content
Glama
assoujojo82-coder

synergieloc — French Real-Estate Legal Calculations

relance_facture_client

Create a payment reminder letter for a contractor to a client, with escalating severity levels (courteous to formal), including invoice amount, due date, and payment IBAN.

Instructions

QUAND un artisan n'est pas payé par SON client (BTP). À ne pas confondre avec relance_impaye, qui vise un locataire. Relance facture client BTP (app Factures en retard), niveaux 1–4. Différent de relance_impaye (locatif). POST /api/v1/documents/relance-facture-client.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ibanNoIBAN d'encaissement rappelé au débiteur. Reproduit tel quel, jamais vérifié ni stocké.
delaiNoDélai accordé avant l'étape suivante — « 8 jours ».
niveauNoDegré de la relance : 1 rappel courtois, 2 relance ferme, 3 mise en demeure. Le niveau 3 fait courir les pénalités de retard.
referenceNoRéférence à rappeler dans le libellé du virement.
client_nomNoClient débiteur.
montant_duNoSomme restant due sur cette facture, en euros.
date_echeanceNoÉchéance dépassée de la facture. Format ISO AAAA-MM-JJ. Par défaut, la date du jour. Entre professionnels, les pénalités courent de plein droit dès le lendemain (art. L441-10 du code de commerce).
date_emissionNoDate d'émission de la relance. Format ISO AAAA-MM-JJ. Par défaut, la date du jour.
client_adresseNoAdresse du destinataire. Sert au bloc fenêtre : il est poussé À DROITE pour une enveloppe à fenêtre.
entreprise_nomNoCréancier qui relance.
facture_numeroNoNuméro de la facture impayée.
entreprise_adresseNoAdresse du créancier, en en-tête.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.1

TDQS

A3.8/5.0
Behavior1/5

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

No annotations are provided, and the description does not disclose any behavioral traits of the tool—such as whether it generates a PDF, sends an email, modifies records, or is read-only. The only consequence mentioned (penalties for level 3) is a legal effect of the input, not a tool behavior.

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 single dense sentence, but it contains redundant warnings about not confusing with relance_impaye (mentioned twice). The structure could be tightened by removing the second mention, though the content is otherwise pertinent.

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 provides essential context about the tool's domain and parameter meanings, but it omits what the tool actually does (e.g., returns a document, sends a message) and any side effects. Given there is no output schema, the absence of this info leaves the tool's behavior ambiguous.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 12 parameters have descriptive explanations in the schema, and the description adds extra semantic details: legal context for date_echeance (Article L441-10), formatting instructions for client_adresse (window envelope positioning), and clarification of level meanings. This goes well beyond the raw 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?

The description clearly states the purpose: generating a reminder for an unpaid invoice from an artisan to a BTP client. It explicitly distinguishes this from the similar landlord-tenant reminder (relance_impaye), making the tool's scope unambiguous.

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 explicitly names the alternative (relance_impaye) and the condition for use: when the debtor is a client in the construction sector vs. a tenant. The mention of level 3 triggering penalties also provides actionable guidance.

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