Skip to main content
Glama
Sign In
boondmanager-mcp-server

boondmanager-mcp-server

by silamir
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Rechercher des achats/sous-traitance

boond_purchases_search
Read-onlyIdempotent

Search BoondManager purchases and subcontracting by company or project to track spend commitments and subcontracting. Use for purchase commitments, not received supplier invoices.

Instructions

Recherche des achats et sous-traitances dans BoondManager, avec filtres par société et projet.

Quand : pour suivre les engagements de dépense et la sous-traitance. Plutôt que : boond_provider_invoices_search pour les factures effectivement reçues : l'achat est l'engagement, la facture fournisseur le document qui le solde.

companyId / projectId sont convertis en références keywords (CSOC / PRJ) : l'API n'a pas de paramètre dédié.

Returns: Liste des achats correspondants.

  • fields : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages.

  • Pagination : pageSize 1–500 (défaut 30), page 1–100 — au-delà : refus, affiner les filtres.

Input Schema

NameRequiredDescriptionDefault
pageNoNuméro de page (défaut: 1, max: 100)
fieldsNoProjection : attributs ou relations (type#id) par résultat (ex: ['title','dependsOn']). Absent = résumé standard. Noms inconnus ignorés.
keywordsNoMots-clés de recherche
pageSizeNoNombre de résultats par page (max: 500, défaut: 30)
companyIdNoFiltrer par ID société (référence keywords CSOC<id>)
projectIdNoFiltrer par ID projet (référence keywords PRJ<id>)

Output Schema

NameRequiredDescriptionDefault
countYesNombre d'éléments retournés sur cette page
itemsYes
totalNoNombre total de résultats côté BoondManager

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.18.0
    • changedInput schema / properties / fields / description
      Previous value: -"Projection : attributs à afficher par résultat (ex: ['title','updateDate']). Absent = résumé standard. Noms inconnus ignorés."New value: +"Projection : attributs ou relations (type#id) par résultat (ex: ['title','dependsOn']). Absent = résumé standard. Noms inconnus ignorés."
  2. Changed7 schema fields changedv2.17.0
    • changedInput schema / properties / companyId / description
      Previous value: -"Filtrer par ID société"New value: +"Filtrer par ID société (référence keywords CSOC<id>)"
    • addedInput schema / properties / companyId / pattern
      Added value: +"^\\d+$"
    • changedInput schema / properties / page / description
      Previous value: -"Numéro de page (max: 100)"New value: +"Numéro de page (défaut: 1, max: 100)"
    • changedInput schema / properties / pageSize / description
      Previous value: -"Résultats par page"New value: +"Nombre de résultats par page (max: 500, défaut: 30)"
    • changedInput schema / properties / projectId / description
      Previous value: -"Filtrer par ID projet"New value: +"Filtrer par ID projet (référence keywords PRJ<id>)"
    • addedInput schema / properties / projectId / pattern
      Added value: +"^\\d+$"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "count": {
+      "description": "Nombre d'éléments retournés sur cette page",
+      "type": "number"
+    },
+    "items": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "attributes": {
+            "additionalProperties": {},
+            "description": "Attributs projetés (présent si `fields` est fourni)",
+            "propertyNames": {
+              "type": "string"
+            },
+            "type": "object"
+          },
+          "id": {
+            "type": "string"
+          },
+          "summary": {
+            "description": "Résumé standard (absent si `fields` est fourni)",
+            "type": "string"
+          },
+          "type": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total": {
+      "description": "Nombre total de résultats côté BoondManager",
+      "type": "number"
+    }
+  },
+  "required": [
+    "count",
+    "items"
+  ],
+  "type": "object"
+}
  3. Changed1 schema field changedv2.12.2
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  4. Changed1 schema field changedv2.9.0
    • addedInput schema / properties / fields
      Added value: +{
+  "description": "Projection : attributs à afficher par résultat (ex: ['title','updateDate']). Absent = résumé standard. Noms inconnus ignorés.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  5. First observedv2.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld, so safety is covered. The description adds real behavioral context beyond them: the 'fields' projection is MCP-side and never transmitted to the API, and pagination caps (>500 or page>100) cause an outright refusal requiring filter refinement. Auth needs and rate limits remain unstated, keeping it from 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.

Conciseness5/5

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

Front-loaded with a labeled structure ('Quand :', 'Plutôt que :', 'Returns:') and bullets for fields and pagination. Every sentence earns its place; no filler.

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?

Output schema exists, so return-value detail isn't required, yet the description still gives a one-line return summary. Combined with routing guidance, projection semantics, and pagination bounds, an agent has everything needed to call this correctly against a large sibling set.

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 100%, so the baseline is 3. The description exceeds that by disclosing that companyId/projectId are internally translated to keywords references (CSOC<id>/PRJ<id>) because the API has no dedicated parameter, and by clarifying that 'fields' replaces the standard résumé and that unknown names are ignored — semantics the schema alone doesn't convey as clearly.

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 and resource (recherche des achats et sous-traitances dans BoondManager) and immediately scopes it to filters by company and project. It distinguishes itself from the many sibling *_search tools by naming the conceptual object it operates on.

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?

Explicit 'Quand :' clause gives the trigger (suivre les engagements de dépense et la sous-traitance) and the 'Plutôt que :' clause names boond_provider_invoices_search with the exact decision rule (achat = engagement, facture fournisseur = document qui le solde). Nothing is left to inference.

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