Updates a treasury bank account in Holded by sending specified fields as the request body to the API v2 endpoint.
WRITE: updates a treasury bank account in Holded (API v2). data is sent verbatim as the request body — see https://www.holded.com/es/desarrolladores/referencia-api (Tesorería → Actualizar cuenta).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Fields to update, sent verbatim as body | |
| accountId | Yes | Bank account ID |
Changes observed during successful MCP inspections.
v2.0.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does useful work by labeling the operation WRITE and warning that the body is sent verbatim with no field mapping or validation, which is real behavioral signal. However it omits permissions, reversibility, partial-vs-full update semantics (are omitted fields cleared?), and error behavior — significant gaps for an unannotated mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the operation type and no filler. It is efficient, though the brevity shades into under-specification given the free-form nested body.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation with a free-form nested `data` object, no annotations, and no output schema, the description leans on an external URL to carry the field contract, which is a fragile dependency for an agent that may not fetch it. Minimum viable, but it should at least characterize the response and key constraints inline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds one meaningful clarification — that `data` passes through verbatim rather than being transformed — but gives no hint about which fields are valid, deferring entirely to the external Holded reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("updates a treasury bank account") and scopes it to Holded API v2, so it is distinguishable from get_bank_account / delete_bank_account / archive_bank_account by name alone. It does not explicitly name those siblings or contrast the operation, keeping it below a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The "WRITE:" prefix implies a mutation but there is no when-to-use guidance, no exclusion versus archive/delete, and no stated prerequisites (auth scope, account state, required fields). The agent must infer all routing decisions from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.