Skip to main content
Glama
assoujojo82-coder

synergieloc — French Real-Estate Legal Calculations

by assoujojo82-coder
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

bon_intervention

Read-onlyIdempotent

Generate a maintenance intervention request PDF to order repairs from a tradesperson or report issues to the property owner, including urgency, cost limit, and detailed work scope for clear instructions.

Instructions

QUAND une réparation doit être commandée à un artisan ou signalée au propriétaire. Bon / demande d'intervention maintenance. PDF via POST /api/v1/documents/bon-intervention.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lotsNoLots de copropriété concernés, quand l'intervention est refacturée à plusieurs.
typeNoCorps d'état concerné : plomberie, électricité, serrurerie, chauffage, menuiserie.
titreYesObjet de l'intervention en une ligne — « Fuite sous l'évier, cuisine ».
urgenceNoDegré d'urgence : « normale », « urgente » (sous 48 h) ou « immédiate » (sécurité, dégât des eaux, coupure).
echeanceNoDate souhaitée d'achèvement, format ISO AAAA-MM-JJ.
agence_nomNoNom du donneur d'ordre — agence ou syndic qui commande l'intervention.
cout_estimeNoPlafond de dépense autorisé sans nouvel accord, en euros. Le mandat de gérance en fixe souvent le seuil.
descriptionNoConstat détaillé : ce qui est cassé, depuis quand, ce qui a déjà été tenté. C'est ce que l'artisan lira pour chiffrer.
agence_adresseNoAdresse du donneur d'ordre, pour la facturation.
prestataire_nomNoArtisan ou entreprise à qui le bon est adressé.
prestataire_adresseNoAdresse du prestataire. Sert au bloc fenêtre, poussé À DROITE.
adresse_interventionNoAdresse exacte du lieu à dépanner, avec bâtiment, étage et numéro de lot si nécessaire.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.1

TDQS

B3.2/5.0
Behavior1/5

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

The annotations declare readOnlyHint=true, but the description says 'PDF via POST /api/v1/documents/bon-intervention', a POST to a documents endpoint that implies creating or generating a resource. This directly contradicts the read-only hint, so the score is 1 per the rubric.

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 very short: trigger, resource type, and output endpoint, with no filler. The fragmentary structure and uppercase 'QUAND' are slightly awkward, which keeps it from a 5.

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?

Given 12 parameters and no output schema, the description provides the essential trigger and PDF output, but it does not explain how the PDF is returned, what the generated bon contains, or how to choose between 'commandée à un artisan' and 'signalée au propriétaire'. The rich parameter schema compensates, but gaps remain.

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% with detailed per-parameter descriptions (titre, urgence, cout_estime, description, addresses, etc.), so the baseline is 3. The tool description adds no parameter-specific meaning beyond what the schema already provides.

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 states the trigger ('QUAND une réparation doit être commandée à un artisan ou signalée au propriétaire') and identifies the resource as a 'Bon / demande d'intervention maintenance'. It also mentions the PDF output, which helps distinguish it from estimate or site-report siblings, though it never names them explicitly.

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?

The opening 'QUAND...' provides a clear condition for use: when a repair must be ordered from a tradesperson or reported to the owner. It does not list when-not-to-use or alternative sibling tools, so it stops short of a 5, but the context is sufficiently clear.

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