Skip to main content
Glama
silamir

boondmanager-mcp-server

by silamir

Détails d'un(e) opportunité

boond_opportunities_get
Read-onlyIdempotent

Retrieve full opportunity details by numeric ID, optionally targeting a tab for information, technical, financial, or other data. Use after search to access attributes missing from list summaries.

Instructions

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

Quand : après un boond_opportunities_search, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : boond_opportunities_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_opportunities_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?

Beyond the read-only/idempotent annotations, the description reveals two important behaviors: omitting tab returns only the base record rather than merging tabs, and an unknown ID surfaces the raw BoondManager error. It also confirms read-only, consistent with 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 definition is compact, front-loaded with the core action, and uses short labeled sections and bullets. No sentence is redundant with the schema except the final read-only note, which is harmless.

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?

For a simple two-parameter read tool with rich annotations and no output schema, the description covers return format, tab behavior, and error semantics. An agent has everything needed to decide when to call it and what to expect.

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 real semantic value by explaining the consequence of omitting tab and warning that IDs must come from a search. The only minor blemish is an example value mismatch (technical-data in the description vs technical in the schema).

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 specific verb and resource: it retrieves the full opportunity record by numeric ID. It also explicitly distances itself from boond_opportunities_search (which returns a list summary) and boond_find (which resolves names/emails), so an agent can distinguish it from the closest siblings.

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 gives an explicit 'Quand' (after a search, to fetch attributes absent from the list summary) and a 'Plutôt que' section naming the alternatives and the conditions under which they should be used instead. This is exactly the level of routing guidance expected.

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