Skip to main content
Glama
fauguste

boondmanager-mcp-server

Détails d'un(e) société

boond_companies_get
Read-onlyIdempotent

Retrieve complete company details by numeric ID, including specific tabs like information, technical, or financial data. Use after a search to access full attributes not shown in list summaries.

Instructions

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

Quand : après un boond_companies_search, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : boond_companies_search si l'ID n'est pas connu (cet outil n'accepte pas de nom).

  • 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_companies_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.5/5.0
Behavior4/5

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

The description discloses that without a `tab`, only the base record is returned, not a merge of all tabs, and that an unknown ID yields a raw BoondManager error. It also states it is read-onlyais, which is already in annotations. It adds some value beyond annotations, though it doesn't cover authentication or rate limits.

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 concise, well-organized with bullet points for when/where to use and return behavior. Every sentence adds value; no fluff. Ideal length and structure for an agent-facing description.

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?

Given the read-only nature, the tool is fully described: when to use, when not to, tab behavior, error on unknown ID, and response format (JSON). The annotation already covers read-only. There is no missing critical information.

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?

The description adds context for the `tab` parameter (specific tabs like information, technical-data) and notes that without it you get the base record. However, the input schema already describes parameters well, so the description only slightly enhances. The unknown-ID error is about parameter id, which is useful but not deeply detailed.

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 opens with a crisp statement of purpose: 'Récupère la fiche complète d'une société par son ID.' It is obvious what the tool does and how it differs from the list-level search tool.

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?

Explicitly positions the tool as a follow-up to `boond_companies_search`, tells the agent when NOT to use it (unknown ID, use search instead), and even warns that the ID must be a real one, never guessed. This is ideal 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