Skip to main content
Glama
fauguste

boondmanager-mcp-server

by fauguste
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Anticipation des fins de mission

boond_workflow_fin_de_mission
Read-onlyIdempotent

Generates a runbook for identifying assignments ending within a set horizon, highlighting those with no replacement yet, to plan repositioning.

Instructions

Liste les ressources dont la mission se termine dans les prochains jours, pour anticiper le repositionnement. Met en évidence les fins imminentes sans relais identifié.

Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP fin_de_mission si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal prompts/get (claude.ai notamment).

  • N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP.

Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
manager_idNoManager pour restreindre à son équipe. Accepte soit l'ID numérique, soit « Prénom Nom » (le serveur résoudra automatiquement via `boond_resources_search`). Si absent, scope = mon équipe via `perimeterDynamic: ['managers']`.
horizon_joursNoNombre de jours à anticiper (défaut: 60). Ex: '30' pour ne voir que les fins très proches.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.12.2
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  2. First observedv2.1.0

TDQS

A4.7/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 that the tool makes no API call, reads no data, generates its answer server-side, and only returns instructions that the model must execute. This prevents the agent from assuming side effects or live data retrieval and fully aligns with the annotations.

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?

The description is structured with clear labels (Quand, Plutôt que, Returns) and every sentence carries information: scope, routing, side-effect disclaimer, and output format. It is front-loaded with the main purpose and contains 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?

With no output schema, the description correctly explains the return value (a text runbook with ordered calls and exact filters) and the follow-up behavior required from the model. Combined with annotations and parameter schema, nothing essential is missing for correct invocation.

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?

Schema description coverage is 100%, with both manager_id and horizon_jours already documented in the input schema. The tool description does not add parameter-level detail beyond that, so the baseline 3 applies.

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 scenario (resources whose missions end soon) and the actual deliverable (a text runbook of ordered Boond calls). It distinguishes itself from direct API tools by explicitly saying no API is called, and from sibling workflow tools by naming the fin_de_mission scenario and the MCP prompt alternative.

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?

It has an explicit 'Quand' section that tells the agent when to prefer this tool, and a 'Plutôt que' section that names the exact alternative (the MCP prompt fin_de_mission) and the condition under which to use this tool instead. This is model-friendly routing information.

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