Skip to main content
Glama
fauguste

boondmanager-mcp-server

by fauguste
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Modifier un(e) ressource

boond_resources_update
Idempotent

Update an existing resource by ID with partial field changes; only supplied fields are modified, and array fields are replaced rather than merged.

Instructions

Met à jour un(e) ressource existant(e), identifié(e) par son ID.

Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : boond_resources_create si l'enregistrement n'existe pas encore.

  • Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place.

  • Attention aux champs de type tableau, qui sont remplacés et non fusionnés.

Returns : confirmation et fiche mise à jour.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesID de la ressource à modifier
cityNoVille
noteNoNotes
stateNoÉtat
titleNoTitre / poste
email1NoEmail principal
phone1NoTéléphone
countryNoPays
lastNameNoNom
firstNameNoPrénom

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoIdentifiant de l'entité créée/modifiée
typeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.15.0
    • changedInput schema / properties / email1 / pattern
      Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
  2. Changed2 schema fields changedv2.12.2
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedOutput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  3. Changed1 schema field changedv2.7.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "id": {
+      "description": "Identifiant de l'entité créée/modifiée",
+      "type": "string"
+    },
+    "type": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  4. First observedv2.1.0

TDQS

A4.6/5.0
Behavior5/5

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

The description discloses two key behaviors beyond annotations: (1) partial update – only provided fields are modified; (2) array fields are replaced, not merged. Annotations declare idempotentHint=true and destructiveHint=false, and the description is consistent with those. It also states the return value ('Returns the updated record'). This is substantive 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?

Four short scannable sections (description/quand/plutôt que/remarques). No fluff. Every sentence earns its place.

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 an update tool with a fully-described schema indu, the description covers the usage decision, the key behavioral nuance (partial write, no array merge), and the return value. With annotations indicating idempotent=true and destructive=false, plus output schema present, nothing necessary is missing.

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% and every parameter has a description. The description adds that only provided fields are written, which is the key semantic needed to interpret 'partial update'. It doesn't add per-parameter detail beyond the schema, but the schema is already complete. The array-replacement warning adds value for fields like positionings that are arrays.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb-resource pair: 'modifier un(e) ressource existant(e)' (update an existing resource). It differentiates from boond_resources_create by explicitly saying 'si l'enregistrement n'existe pas encore' use create. It doesn't explicitly distinguish from boond_resources_information/other resource-actions, but the update/create distinction is the most relevant and is covered.

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 an explicit 'Quand' (when) – for updating a few fields of an existing record – and an explicit alternative: use boond_resources_create if the record doesn't exist yet, and boond_resources_delete if deletion is the goal. This is textbook usage guidance.

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