Skip to main content
Glama
VoxFactura

voxfactura-mcp

by VoxFactura
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

creer_devis_brouillon

Create a draft quote for a client and project with line items, then review and send it manually in VoxFactura; no automatic sending.

Instructions

Crée un devis en BROUILLON (permission devis:write). client_id et chantier_id sont les numéros du client et du chantier dans le compte. Chaque ligne : {designation, quantite, unite, prix_unitaire_ht, taux_tva}, plus en option prestation_id (numéro de la prestation du catalogue ; prix omis, la ligne prend le prix de ce client, sinon celui du catalogue) et nature (« bien » pour une vente, « service » sinon ; omise, elle suit la prestation du catalogue puis le réglage du compte). validite_jours : durée de validité (omis = celle réglée sur le compte, 30 jours par défaut). delai_execution : délai imprimé sur le devis (ex. « 3 semaines après acceptation »). Le devis n'est jamais envoyé automatiquement : l'artisan le relit et l'envoie dans VoxFactura. Son numero est nul tant qu'il est brouillon : le numéro définitif lui est attribué à l'envoi.

Input Schema

NameRequiredDescriptionDefault
notesNo
objetNo
lignesYes
dossierNo
client_idYes
chantier_idNo
validite_joursNo
delai_executionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.1
    • addedInput schema / properties / dossier
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Dossier"
+}
  2. Changed3 schema fields changedv0.2.0
    • addedInput schema / properties / delai_execution
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Delai Execution"
+}
    • addedInput schema / properties / notes
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Notes"
+}
    • addedInput schema / properties / validite_jours
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Validite Jours"
+}
  3. First observedv0.1.1

TDQS

A4.3/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 and does well: it discloses the required permission, that the quote stays draft, that numero is null until sent and assigned on send, and that sending is never automatic. It omits error/validation behavior and return values, keeping it short of 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph, front-loaded with the action and state, then the parameter semantics, then the draft/numbering behavior. Information-dense with little waste, though it could be split for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter mutation tool with no annotations and no output schema, the description covers permissions, draft lifecycle, defaults and the nested line schema. Remaining gaps are notes/objet/dossier and any statement of what is returned, which is acceptable given no output schema exists.

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 0%, so the description must compensate and largely does: it defines client_id/chantier_id, the per-line structure {designation, quantite, unite, prix_unitaire_ht, taux_tva}, the optional prestation_id with its pricing-fallback logic, nature defaults, and validite_jours default. It leaves notes, objet and dossier undocumented, so not a full 5.

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 (crée) and resource (devis) plus the exact state produced (BROUILLON). No sibling tool operates on devis, so it is trivially distinguishable from the read-oriented list/export siblings.

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?

Clarifies the workflow context ("Le devis n'est jamais envoyé automatiquement : l'artisan le relit et l'envoie dans VoxFactura") and the required permission (devis:write), so the agent knows this only creates a draft. It gives no explicit alternatives or exclusions, but none exist among the siblings.

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