Skip to main content
Glama
inakirealise

BoondManager MCP Server

by inakirealise

boond_accounts_update

Update account details in BoondManager by providing the account ID and setting a new role, email, status, or username.

Instructions

Update an existing account

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
roleNo
emailNo
statusNo
usernameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.6/5.0
Behavior2/5

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

No annotations exist, so the description carries the full burden of behavioral disclosure. 'Update' implies mutation, but the description does not state whether this is a partial or full update, what happens to unspecified fields, whether re-authentication is needed, or any side effects. This is a significant gap for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler or repetition. It is concise and easy to parse, though the brevity sacrifices informative content. No structural issues.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With five parameters, no output schema, and no annotations, this one-sentence description is severely under-specified. An agent cannot know which parameters are intended to be updated together, whether all fields are optional besides id, the effect on the account, or the expected response. This is grossly inadequate for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no parameter information at all. The schema itself provides field names and enums, but the description does not clarify semantics like whether 'status' and 'role' are limited to the enum values, whether 'id' must identify an existing account, or if updating one field preserves others. The description fails to compensate for the schema's lack of textual guidance.

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 states a clear action and resource: 'Update an existing account.' It distinguishes the operation (update vs. search/get/create) and names the resource, which is sufficient to identify what the tool does. However, it doesn't mention which fields are updatable or any specifics beyond the generic verb-resource pairing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives like boond_accounts_create or boond_accounts_get. No conditions, prerequisites, or exclusions are provided. The agent must infer usage solely from the name and sibling list.

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