boondmanager-mcp-server

Créer une facture fournisseur

boond_provider_invoices_create

Create a supplier invoice to record a provider's bill for a subcontractor's services. Handles provider company, contact, resource, and period details.

Instructions

Crée une facture fournisseur (facture reçue d'un prestataire).

Quand : pour enregistrer la facture émise par un sous-traitant. Plutôt que : boond_invoices_create pour une facture de vente adressée à un client — les deux sens ne partagent pas d'endpoint.

resource, providerCompany et providerContact sont attendus sous forme d'ID numériques.
Écriture non idempotente.

Returns : confirmation et fiche de la facture fournisseur créée, avec son ID dans structuredContent.id.

Input Schema

TableJSON Schema

Name	Required	Description
`state`	No	État de la facture fournisseur : ID de `boond://dictionary/states/provider-invoices`
`endDate`	Yes	Date de fin de période (YYYY-MM-DD)
`currency`	No	Devise Boond
`companyId`	No	ID de la société fournisseur, mappé vers providerCompany
`contactId`	No	ID du contact fournisseur, mappé vers providerContact
`reference`	Yes	Référence de la facture fournisseur
`startDate`	Yes	Date de début de période (YYYY-MM-DD)
`resourceId`	Yes	ID de la ressource portée par la facture fournisseur
`invoiceDate`	No	Date de facture (YYYY-MM-DD)
`exchangeRate`	No	Taux de change
`currencyAgency`	No	Devise agence
`amountExcludingTax`	No	Montant HT
`amountIncludingTax`	No	Montant TTC
`exchangeRateAgency`	No	Taux de change agence

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	No	Identifiant de l'entité créée/modifiée
`type`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv2.17.0Sep 26, 2026

changedInput schema / properties / companyId / description

Previous value: -"ID de la societe fournisseur, mappe vers providerCompany"New value: +"ID de la société fournisseur, mappé vers providerCompany"

addedInput schema / properties / companyId / pattern
```
Added value: +"^\\d+$"
```

changedInput schema / properties / contactId / description

Previous value: -"ID du contact fournisseur, mappe vers providerContact"New value: +"ID du contact fournisseur, mappé vers providerContact"

addedInput schema / properties / contactId / pattern
```
Added value: +"^\\d+$"
```

changedInput schema / properties / endDate / description

Previous value: -"Date de fin de periode (YYYY-MM-DD)"New value: +"Date de fin de période (YYYY-MM-DD)"

changedInput schema / properties / reference / description

Previous value: -"Reference de la facture fournisseur"New value: +"Référence de la facture fournisseur"

changedInput schema / properties / resourceId / description

Previous value: -"ID de la ressource portee par la facture fournisseur"New value: +"ID de la ressource portée par la facture fournisseur"

removedInput schema / properties / resourceId / minLength
```
Removed value: -1
```
addedInput schema / properties / resourceId / pattern
```
Added value: +"^\\d+$"
```

changedInput schema / properties / startDate / description

Previous value: -"Date de debut de periode (YYYY-MM-DD)"New value: +"Date de début de période (YYYY-MM-DD)"

changedInput schema / properties / state / description

Previous value: -"Etat de la facture fournisseur"New value: +"État de la facture fournisseur : ID de `boond://dictionary/states/provider-invoices`"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "id": {
+      "description": "Identifiant de l'entité créée/modifiée",
+      "type": "string"
+    },
+    "type": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedv2.12.2Aug 14, 2026
- removedInput schema / $schema
```
Removed value: -"http://json-schema.org/draft-07/schema#"
```
Addedv2.8.0Jun 29, 2026

TDQS

A4.4/5.0

Behavior4/5

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

The description adds behavioral context beyond annotations: it specifies that the operation is non-idempotent (though `idempotentHint=false` already indicates this), and it details the expected format of `resource`, `providerCompany`, and `providerContact` as numeric IDs. It also describes the return value, including where the new invoice's ID appears in `structuredContent.id`. This adds value beyond the annotations.

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?

The description is concise and well-structured, with a clear purpose statement, a 'Quand' section for usage, a 'Plutôt que' section for alternatives, a bullet point for parameter format, and a 'Returns' section. Every sentence adds value, and the most important information is front-loaded.

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?

The tool has 14 parameters (4 required) but the schema covers all of them, and an output schema exists. The description provides the necessary context about when to use it, how it differs from siblings, and what the response contains. It is sufficiently complete for an agent to call this tool correctly without missing critical information.

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?

The input schema has 100% description coverage, so the baseline is 3. The description adds some semantic context by noting that `resource`, `providerCompany`, and `providerContact` should be numeric IDs, but this is already implied by the schema's pattern constraints on `resourceId`, `companyId`, and `contactId`. The description does not provide additional meaning beyond what the schema already conveys, so a 3 is appropriate.

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 tool's purpose: 'Crée une facture fournisseur' (creates a provider invoice) and explicitly distinguishes it from the sibling tool `boond_invoices_create` for sales invoices. It is specific and 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 provides explicit guidance on when to use this tool ('pour enregistrer la facture émise par un sous-traitant') and when not to, naming the alternative `boond_invoices_create` and explaining that the two endpoints are distinct. This is complete usage guidance.

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

Deploy Server