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

boondmanager-mcp-server

by silamir
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Téléverser un document

boond_documents_create

Attach a document to a BoondManager entity from a URL, local path, upload slot, or small base64 payload, with file-type validation and optional CV parsing.

Instructions

Attache un document à une entité BoondManager. Exactement une source par appel :

  • fileUrl : URL https que BoondManager télécharge lui-même ;

  • filePath : chemin absolu d'un fichier local, lu par le serveur MCP — transport stdio uniquement, sous un répertoire de BOOND_MCP_UPLOAD_DIRS (désactivé par défaut) ;

  • uploadSlot : fichier déposé sur un slot de boond_documents_upload_slot — la voie pour une pièce jointe de conversation ;

  • fileContent (base64) + fileName : petit fichier inline, 2 Mo max, réservé à un appelant qui détient déjà les octets exacts (un modèle ne retranscrit pas fiablement une pièce jointe en base64).

Quand : pour attacher un fichier à une entité : URL publique, fichier local (si l'opérateur l'a autorisé), slot du relais d'upload ou petit fichier en base64. Plutôt que : aucune alternative : c'est le seul outil d'écriture de documents. Si filePath est refusé (transport HTTP ou BOOND_MCP_UPLOAD_DIRS non défini), passer par fileUrl ou, sous 2 Mo, par fileContent.

Le format est vérifié sur les premiers octets du fichier (PDF, Office, ODF, RTF, images), pas sur l'extension. Cas d'usage typiques : CV d'un candidat (parentType=candidateResume, parsing=true pour l'analyse IA Boond), pièce jointe d'un besoin / AO (parentType=opportunity), d'un positionnement (positioning), justificatif de note de frais (expensesReport), bon de commande, contrat...

parentType n'est pas limité à une liste fermée : il est transmis tel quel à BoondManager, qui valide le type. Un type que l'API ne gère pas est refusé sans rien écrire.

Returns: Métadonnées du document créé (ID).

Input Schema

NameRequiredDescriptionDefault
fileUrlNoURL (https) du fichier à téléverser — BoondManager télécharge le fichier depuis cette URL.
parsingNoLancer le parsing IA du CV après upload (uniquement pour parentType=candidateResume).
fileNameNoNom du fichier avec son extension (ex. cv.pdf), requis avec fileContent.
filePathNoChemin absolu d'un fichier local, lu par le serveur MCP (transport stdio uniquement, sous un répertoire de BOOND_MCP_UPLOAD_DIRS).
parentIdYesID de l'entité parente
parentTypeYesType d'entité parente, tel que l'attend l'API BoondManager. Notables : 'candidateResume' (CV de candidat), 'resourceResume' (CV de ressource), 'candidate'/'resource' (dossier administratif), 'opportunity' (besoin / AO), 'positioning', 'company', 'project', 'order', 'invoice', 'action'... Un type hors de cette liste est transmis tel quel ; l'API le valide et refuse un type inconnu.
uploadSlotNoIdentifiant d'un slot créé par boond_documents_upload_slot, une fois le fichier déposé.
fileContentNoContenu du fichier en base64 (préfixe data: URI accepté), petits fichiers uniquement. Exige fileName.

Output Schema

NameRequiredDescriptionDefault
idNoIdentifiant de l'entité créée/modifiée
typeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.19.2
    • changedInput schema / properties / parentType / description
      Previous value: -"Type d'entité parente. Notables : 'candidateResume' (CV de candidat), 'resourceResume' (CV de ressource), 'candidate'/'resource' (dossier administratif), 'company', 'project', 'invoice'..."New value: +"Type d'entité parente, tel que l'attend l'API BoondManager. Notables : 'candidateResume' (CV de candidat), 'resourceResume' (CV de ressource), 'candidate'/'resource' (dossier administratif), 'opportunity' (besoin / AO), 'positioning', 'company', 'project', 'order', 'invoice', 'action'... Un type hors de cette liste est transmis tel quel ; l'API le valide et refuse un type inconnu."
    • removedInput schema / properties / parentType / enum
      Removed value: -[
-  "action",
-  "resourceResume",
-  "candidateResume",
-  "resource",
-  "candidate",
-  "expensesReport",
-  "timesReport",
-  "absencesReport",
-  "payment",
-  "company",
-  "project",
-  "order",
-  "product",
-  "purchase",
-  "delivery",
-  "groupment",
-  "inactivity",
-  "positioning",
-  "followeddocument",
-  "appentity",
-  "contract",
-  "invoice",
-  "providerinvoice"
-]
    • addedInput schema / properties / parentType / pattern
      Added value: +"^[A-Za-z][A-Za-z0-9]{0,63}$"
  2. Changed1 schema field changedv2.19.0
    • addedInput schema / properties / uploadSlot
      Added value: +{
+  "description": "Identifiant d'un slot créé par boond_documents_upload_slot, une fois le fichier déposé.",
+  "format": "uuid",
+  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+  "type": "string"
+}
  3. Changed4 schema fields changedv2.18.0
    • addedInput schema / properties / fileContent
      Added value: +{
+  "description": "Contenu du fichier en base64 (préfixe data: URI accepté), petits fichiers uniquement. Exige fileName.",
+  "maxLength": 2796460,
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / fileName
      Added value: +{
+  "description": "Nom du fichier avec son extension (ex. cv.pdf), requis avec fileContent.",
+  "maxLength": 255,
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / filePath
      Added value: +{
+  "description": "Chemin absolu d'un fichier local, lu par le serveur MCP (transport stdio uniquement, sous un répertoire de BOOND_MCP_UPLOAD_DIRS).",
+  "maxLength": 4096,
+  "minLength": 1,
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "parentType",
-  "parentId",
-  "fileUrl"
-]New value: +[
+  "parentType",
+  "parentId"
+]
  4. Changed2 schema fields changedv2.12.2
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedOutput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  5. Addedv2.7.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations only cover the generic safety profile (readOnly=false, destructive=false, idempotent=false); the description adds the real behavioral risks: filePath is stdio-only and gated behind BOOND_MCP_UPLOAD_DIRS which is disabled by default, format is validated on magic bytes rather than extension, and an unknown parentType is rejected without writing anything. Slight deduction because it never warns that a failed/repeated call may create a duplicate attachment given idempotentHint=false.

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?

Front-loaded with the verb and a scannable bullet list of sources, then Quand/Plutôt que and use cases. Slightly repetitive: the 'Quand' paragraph restates the source modes already bulleted above, which is the only wasted space.

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?

For an 8-parameter write tool this is essentially complete: source selection, transport constraints, size limits, format validation, parentType examples, parsing flag behavior, and the return value (created document ID, backed by an output schema). Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, yet the description still adds the crucial constraint the schema cannot express: exactly one source per call, with per-parameter trade-offs (filePath stdio+allowlist only, fileContent capped at 2 MB and unsuitable for models transcribing base64, uploadSlot as the conversation path). It also clarifies that parentType is not a closed enum and is validated server-side.

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?

Opens with a specific verb+resource ('Attache un document à une entité BoondManager') and immediately enumerates the four mutually exclusive source modes. It also declares itself the sole document-write tool, distinguishing it from siblings like boond_documents_get, boond_documents_delete and boond_documents_upload_slot.

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' / 'Plutôt que' sections, plus a documented fallback path when filePath is refused (use fileUrl, or fileContent under 2 MB). It also designates uploadSlot as the route for conversation attachments, which is a decision an agent could not infer from the schema.

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