create_bank_movement

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that this creates a real bank movement and that data is sent verbatim, but it does not explain permissions, idempotency, side effects, validation behavior, or what happens on failure, which are important for an unannotated write operation.

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?

The description is two compact sentences with the mutating nature and resource front-loaded. Every element, including the documentation link, serves a clear purpose without repetition.

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 write tool with a required nested data object, no output schema, and no annotations, the description delegates the payload structure entirely to an external URL. An agent can identify the tool's high-level purpose but lacks enough local detail to confidently construct a valid bank movement payload.

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 schema already documents both parameters. The description reinforces that data is sent verbatim and provides an external documentation link, but it adds little beyond what the schema fields state, especially for the nested data object whose allowed fields are not described.

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?

The description states a specific verb and resource: 'creates a real bank movement in a treasury account,' and identifies the API version. It is clearly distinguishable from read-oriented siblings like list_bank_movements, but it does not explicitly contrast itself with reconcile_bank_movement or explain when this creation path is appropriate.

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 signals a mutating operation, but there is no explicit guidance on when to use this tool versus alternatives such as create_treasury or reconcile_bank_movement. It also omits prerequisites, constraints, and when-not-to-use conditions for creating a real bank movement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.