Skip to main content
Glama
silamir

boondmanager-mcp-server

by silamir

Télécharger un document

boond_documents_get
Read-onlyIdempotent

Retrieve a BoondManager document by ID to get readable content: extracted text from PDF/DOCX, image data, or raw bytes. Use when you need the contents of a CV or supporting document.

Instructions

Télécharge un document BoondManager (CV de candidat/ressource, justificatif, contrat, facture...) par son ID, et le rend lisible : texte extrait pour un PDF ou un DOCX, contenu image (visible par le modèle) pour une image, texte brut pour un fichier texte.

Quand : pour récupérer le contenu d'un CV ou d'un justificatif dont l'ID a été relevé dans un onglet d'entité. Plutôt que : boond_candidates_information / boond_candidates_administrative (relations resumes / files) pour trouver l'ID : celui-ci exige un ID exact, suffixe compris (123_resume), et un ID tronqué désigne un autre document.

Où trouver les IDs de documents : dans les onglets des entités — ex. boond_candidates_information expose les relations 'resumes' (CV) et 'files' (dossier administratif). ⚠️ Reprendre l'ID tel quel, suffixe compris (ex. '123_resume') : un ID tronqué à sa partie numérique ne désigne aucun document.

mode: "text" (défaut) : PDF / DOCX → texte extrait côté serveur (borné à 50000 caractères, taille et nombre de pages d'origine indiqués) ; image PNG / JPEG / GIF / WebP → contenu image jusqu'à 2 Mo. Un PDF scanné ou chiffré, dont rien ne s'extrait, est renvoyé tel quel avec un avertissement. mode: "raw" : le fichier tel quel en ressource embarquée (base64) — coûteux en contexte, à réserver aux cas où les octets sont nécessaires (transfert, format non géré). Taille max téléchargée : 5 Mo.

Returns : texte extrait, contenu image, ou ressource embarquée (blob base64) selon le format et le mode. Un ID inconnu est rejeté explicitement plutôt que de renvoyer la page d'accueil BoondManager, que l'API sert en HTTP 200 à la place d'un 404.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesIdentifiant du document, tel qu'exposé par les relations d'entités (ex. 123_resume)
modeNotext (défaut) : PDF et DOCX renvoyés en texte extrait côté serveur, images en contenu `image` ; raw : le fichier tel quel en ressource embarquée (base64).text

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.17.0
    • addedInput schema / properties / mode
      Added value: +{
      +  "default": "text",
      +  "description": "text (défaut) : PDF et DOCX renvoyés en texte extrait côté serveur, images en contenu `image` ; raw : le fichier tel quel en ressource embarquée (base64).",
      +  "enum": [
      +    "text",
      +    "raw"
      +  ],
      +  "type": "string"
      +}
  2. Changed3 schema fields changedv2.12.2
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • changedInput schema / properties / id / description
      Previous value: -"Identifiant unique de l'entité BoondManager (numérique)"New value: +"Identifiant du document, tel qu'exposé par les relations d'entités (ex. 123_resume)"
    • changedInput schema / properties / id / pattern
      Previous value: -"^\\d+$"New value: +"^\\d+(_[A-Za-z]+)?$"
  3. Addedv2.7.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses concrete behaviors: 50000-character extraction limit, 2 MB image limit, 5 MB download limit, scanned/encrypted PDFs returned as-is with a warning, raw mode returning base64 blob, and explicit rejection of unknown IDs instead of the API's HTTP 200 homepage fallback. This is rich, actionable behavioral context.

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?

Though long, the description is densely informative and well-structured with clear sections (Quand, Plutôt que, Où trouver, mode details, Returns, error behavior). Every sentence adds operational value, and the main purpose is front-loaded. The length is justified by the tool's complexity.

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?

There is no output schema, so the description carries the burden of explaining return values, and it does: extracted text, image content, or embedded base64 blob depending on format and mode. It also covers ID sourcing, limits, mode trade-offs, and error behavior. An agent has everything needed to call this tool correctly.

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 adds meaningful semantics beyond the schema: it warns that a truncated ID (without the suffix) designates a different document or no document, and it explains the practical cost and use cases for mode='raw' versus mode='text'. This goes beyond the schema's basic enum and pattern descriptions.

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 ('Télécharge un document BoondManager'), a clear resource (documents by ID), and the transformation behavior (text extraction for PDF/DOCX, image content, raw text). It also distinguishes itself from sibling tools by naming boond_candidates_information and boond_candidates_administrative as the tools to use for finding IDs, not for downloading content.

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 explicitly provides 'Quand' (when to use), 'Plutôt que' (alternatives and why not to use them), and 'Où trouver les IDs' (where to find document IDs). It also gives mode-selection guidance, warning that raw mode is costly and should be reserved for cases where bytes are necessary.

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