boondmanager-mcp-server

Créer un paiement

boond_payments_create

Record a supplier payment against an existing purchase to settle it partially or fully. Requires a valid purchase ID; each call creates a new payment.

Instructions

Enregistre un paiement / règlement fournisseur adossé à un achat.

Quand : pour solder tout ou partie d'un achat existant. Plutôt que : boond_purchases_create si l'achat lui-même n'existe pas encore — un paiement ne peut pas être orphelin.

L'API /payments exige une relation purchase : sans ID d'achat valide, l'appel est refusé.
Écriture non idempotente : deux appels identiques enregistrent deux règlements.

Returns : confirmation et fiche du paiement créé, avec son ID dans structuredContent.id.

Input Schema

TableJSON Schema

Name	Required	Description
`note`	No	Note interne, mappée vers informationComments
`state`	No	État du paiement : ID de `boond://dictionary/states/payments`
`amount`	No	Montant HT du paiement, mappé vers amountExcludingTax
`endDate`	No	Date de fin couverte (YYYY-MM-DD)
`taxRates`	No	Taux de taxes Boond
`reference`	No	Référence bancaire ou règlement
`startDate`	No	Date de début couverte (YYYY-MM-DD)
`purchaseId`	Yes	ID de l'achat réglé
`paymentDate`	No	Date du paiement (YYYY-MM-DD), mappée vers date
`expectedDate`	No	Date de paiement attendu (YYYY-MM-DD)
`paymentMethod`	No	Mode de paiement : ID de `boond://dictionary/paymentMethods`
`performedDate`	No	Date de paiement effectif (YYYY-MM-DD)
`amountExcludingTax`	No	Montant HT du paiement

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.

Changed11 schema fields changedv2.17.0Sep 26, 2026

changedInput schema / properties / amount / description

Previous value: -"Montant HT du paiement, mappe vers amountExcludingTax"New value: +"Montant HT du paiement, mappé vers amountExcludingTax"

changedInput schema / properties / note / description

Previous value: -"Note interne, mappee vers informationComments"New value: +"Note interne, mappée vers informationComments"

changedInput schema / properties / paymentDate / description

Previous value: -"Date du paiement (YYYY-MM-DD), mappee vers date"New value: +"Date du paiement (YYYY-MM-DD), mappée vers date"

changedInput schema / properties / paymentMethod / description

Previous value: -"Methode de paiement"New value: +"Mode de paiement : ID de `boond://dictionary/paymentMethods`"

changedInput schema / properties / purchaseId / description

Previous value: -"ID de l'achat regle"New value: +"ID de l'achat réglé"

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

changedInput schema / properties / reference / description

Previous value: -"Reference bancaire ou reglement"New value: +"Référence bancaire ou règlement"

changedInput schema / properties / startDate / description

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

changedInput schema / properties / state / description

Previous value: -"Etat du paiement / achat"New value: +"État du paiement : ID de `boond://dictionary/states/payments`"

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.7/5.0

Behavior5/5

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

Beyond the annotations, the description explicitly discloses that the API requires a purchase relation and that the operation is non-idempotent ('deux appels identiques enregistrent deux règlements'). This adds meaningful behavioral context that an agent needs to avoid duplicate payments, and it aligns with the idempotentHint=false annotation.

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 well-structured with clear sections: purpose, when to use, alternative, key behavioral warnings, and return value. Every sentence adds value, and the most important constraints are front-loaded. It is concise without sacrificing critical information.

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?

Given the tool's 13 parameters, full schema coverage, output schema, and annotations, the description covers the essential contextual gaps: when to use it, what not to confuse it with, the mandatory purchase relation, non-idempotency, and where to find the created payment's ID. Nothing critical is missing for an agent to invoke it correctly.

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%, so the schema already documents all 13 parameters. The description reinforces the critical role of purchaseId but does not add parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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: 'Enregistre un paiement / règlement fournisseur adossé à un achat.' It clearly distinguishes itself from boond_purchases_create by stating that a payment must be attached to an existing purchase. This makes the tool's purpose unambiguous even among many sibling tools.

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 when-to-use guidance ('pour solder tout ou partie d'un achat existant') and explicitly names the alternative tool with the condition for choosing it ('Plutôt que boond_purchases_create si l'achat lui-même n'existe pas encore'). It also states the hard requirement for a valid purchaseId, leaving no ambiguity about prerequisites.

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

Deploy Server