Skip to main content
Glama
silamir

boondmanager-mcp-server

by silamir
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Téléverser un document

boond_documents_create

Attach a document to any BoondManager entity using a URL, local file, upload slot, or base64 content—ideal for CVs, expense receipts, and contracts.

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), justificatif de note de frais (expensesReport), bon de commande, contrat...

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

Input Schema

TableJSON 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. Notables : 'candidateResume' (CV de candidat), 'resourceResume' (CV de ressource), 'candidate'/'resource' (dossier administratif), 'company', 'project', 'invoice'...
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

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+}
  2. 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"
+]
  3. 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#"
  4. Addedv2.7.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare write (readOnlyHint=false), non-idempotent and non-destructive. The description adds genuinely non-structured behavior: filePath is stdio-only and gated behind BOOND_MCP_UPLOAD_DIRS (disabled by default), the 2MB inline cap, format validation on magic bytes rather than extension, and that models can't reliably retranscribe base64. It does not state auth/permission requirements, which is the only remaining gap.

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 core constraint ('exactement une source par appel') followed by tight bulleted modes, then usage and return. Slightly text-heavy in the 'Quand' section, which partly restates the bullets, but every line carries operational meaning.

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?

An output schema exists so return values need not be elaborated, and the description still names the ID return. For an 8-parameter write tool with transport-dependent behavior, all decision-relevant information an agent needs is present.

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, but the description earns above-baseline credit by adding cross-parameter semantics the schema cannot express: exactly one source per call, the fileContent+fileName pairing, the transfer/size constraints per mode, and parsing being confined to candidateResume.

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 ('attache un document à une entité BoondManager') and immediately scopes it as the sole document-write tool, explicitly routing to the sibling relay tool boond_documents_upload_slot for slots. An agent can distinguish this from boond_documents_get and boond_documents_delete without opening any schema.

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?

Has explicit 'Quand' and 'Plutôt que' sections: it names the four mutually exclusive source modes with the conditions that select each, declares there is no alternative writer, and gives concrete fallbacks (fileUrl or fileContent<2MB) when filePath is refused. This is textbook when/when-not guidance.

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