boondmanager-mcp-server

Ouvrir un slot d'upload

boond_documents_upload_slot

Opens a one-time upload slot to send a file from the client's runtime environment to BoondManager, useful for conversation attachments not available via public URL or server path.

Instructions

Ouvre un slot d'upload à usage unique sur le relais de stockage configuré par l'opérateur (BOOND_MCP_UPLOAD_RELAY, ex. SharePoint), pour transmettre à BoondManager un fichier qui n'est ni à une URL publique ni sur le poste du serveur — typiquement une pièce jointe de conversation, présente dans l'environnement d'exécution de code du client.

Quand : pour attacher à Boond une pièce jointe de conversation (fichier présent dans l'environnement d'exécution de code, pas sur le poste du serveur). Plutôt que : boond_documents_create directement si le fichier est à une URL publique (fileUrl) ou sur le poste du serveur (filePath). Ne jamais retranscrire la pièce jointe en base64 : passer par ce slot.

Déroulé : (1) appeler cet outil avec le nom du fichier ; (2) déposer le fichier sur uploadUrl en une seule requête PUT depuis l'environnement d'exécution, avec la commande curl renvoyée — les octets ne passent pas par la réponse du modèle ; (3) appeler boond_documents_create avec uploadSlot. Le fichier est vérifié (taille, premiers octets), transmis à Boond par une URL de lecture temporaire, puis supprimé définitivement du relais.

Slot valable 15 min, un seul fichier, un seul usage. uploadUrl est pré-authentifiée : ne pas la réutiliser ni la partager.

Returns: uploadSlot, uploadUrl, expiresAt, maxBytes, fileName et la commande d'upload.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`fileName`	Yes	Nom du fichier à déposer, avec son extension (ex. cv.pdf). Il deviendra le nom du document dans Boond.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`fileName`	Yes
`maxBytes`	Yes
`expiresAt`	Yes
`uploadUrl`	Yes
`uploadSlot`	Yes
`uploadCommand`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.19.0Oct 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) by disclosing the 15-minute validity, single-file/single-use constraint, that uploadUrl is pre-authenticated and must not be reused or shared, that the file is verified for size and first bytes, transferred via a temporary read URL, and then permanently deleted. This is exactly the operational context an agent needs before invoking a multi-step upload.

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 and organized into labeled sections (purpose, Quand, Plutôt que, Déroulé, constraints, returns), so the agent can scan it quickly. It is on the verbose side with parenthetical examples and env-var references, but the length is largely justified by the multi-step nature of the tool.

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?

This is a complex multi-step tool (slot creation, external PUT, subsequent create call) and the description covers the entire workflow, the constraints on the slot, and even enumerates the returned fields. Since an output schema exists it need not explain returns, but doing so adds helpful completeness rather than clutter.

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?

Only one parameter exists and schema coverage is 100%, so the schema already fully documents fileName (including that it becomes the document name in Boond). The description restates that the tool is called with the file name but adds no format, validation, or constraint beyond the schema. Baseline 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 states a specific verb (ouvre un slot d'upload) and resource (single-use upload slot on the operator-configured storage relay) and precisely scopes the case: files that are neither at a public URL nor on the server host. It explicitly distinguishes itself from the sibling boond_documents_create, so an agent can route without opening either 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?

Dedicated 'Quand' and 'Plutôt que' sections give explicit when-to-use and when-to-use-an-alternative guidance, naming boond_documents_create for the public-URL and server-host cases. It also supplies a full 3-step workflow and a hard rule against base64 transcription.

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

Deploy Server