Skip to main content
Glama
silamir

boondmanager-mcp-server

by silamir
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Détails d'un(e) contact

boond_contacts_get
Read-onlyIdempotent

Retrieve a full contact record by numeric ID to access detailed attributes not shown in search summaries. Optionally specify a tab for targeted sections like administrative or actions.

Instructions

Récupère la fiche complète d'un(e) contact par son ID numérique.

Quand : après un boond_contacts_search, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : boond_contacts_search si l'ID n'est pas connu (cet outil n'accepte pas de nom), ou boond_find pour résoudre un nom / un e-mail en ID.

  • tab cible un onglet précis (information, technical-data, administrative, actions…) ; sans tab, seule la fiche de base est renvoyée, pas la réunion des onglets.

  • Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de boond_contacts_search, jamais d'une supposition.

Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesIdentifiant unique de l'entité (numérique)
tabNoOnglet spécifique à récupérer (information, technical, financial, actions, contracts, documents)

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. Changed4 schema fields changedv2.7.0
    • changedInput schema / properties / id / description
      Previous value: -"Identifiant unique de l'entité"New value: +"Identifiant unique de l'entité (numérique)"
    • removedInput schema / properties / id / minLength
      Removed value: -1
    • addedInput schema / properties / id / pattern
      Added value: +"^\\d+$"
    • addedInput schema / properties / tab / pattern
      Added value: +"^[a-zA-Z][a-zA-Z-]*$"
  3. First observedv2.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already establish read-only/idempotent/non-destructive behavior, and the description adds meaningful beyond-schema context: without `tab` only the base fiche is returned, not a union of tabs; unknown IDs surface the raw BoondManager error; and IDs must come from search, never guessed. This is valuable operational transparency.

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 front-loaded with the core purpose and then structured with clear 'Quand', 'Plutôt que', bullet points, and a Returns line. Every sentence earns its place; there is 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?

Even without an output schema, the description states the return shape (JSON entity with attributes and relations), declares read-only behavior, explains tab semantics, covers error behavior, and routes to the right sibling tools. This is complete for a two-parameter read tool.

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 adds extra meaning: `tab` targets a specific tab and omitting it returns only the base record, not aggregated tabs. It also reinforces that `id` must come from boond_contacts_search. This goes beyond the schema's bare field 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+resource: 'Récupère la fiche complète d'un(e) contact par son ID numérique.' It clearly differentiates from boond_contacts_search and boond_find, so an agent can tell which tool to use without opening schemas.

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 gives explicit when-to-use guidance ('après un boond_contacts_search'), explicit alternatives ('Plutôt que : boond_contacts_search si l'ID n'est pas connu ... ou boond_find pour résoudre un nom / un e-mail en ID'), and explains tab behavior. No inference is needed.

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