alterar_conta_corrente

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

With no annotations, the description carries the full burden and does disclose a key behavioral trait: 'só os informados são atualizados' (only provided fields are updated), indicating PATCH-like partial update semantics. It also states the identification requirement. It omits response shape or error behavior, but the provided behavioral detail goes beyond a minimal statement.

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 a single well-structured sentence that leads with the primary action, then gives the identification rule, and closes with the partial-update behavior. No redundant words; every clause earns its place.

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?

Given 13 parameters, no output schema, and no annotations, the description covers the essential operational aspects (how to identify, what updates occur) but is thin on validation details, return values, and error scenarios. It is minimally viable for a straightforward update operation but does not fully compensate for the lack of schema descriptions.

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 0%, so the description must compensate. It adds meaning for the two identifier parameters (codigo_conta_corrente and codigo_integracao) and distinguishes them from updatable fields. However, it does not explain the remaining 11 parameters (e.g., saldo_data, ocultar_do_fluxo, tipo_conta_corrente), leaving the agent to infer from names alone.

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 uses the specific verb 'Altera' (alters) with the resource 'conta corrente existente' (existing current account), clearly distinguishing it from sibling tools like incluir_conta_corrente (create), excluir_conta_corrente (delete), and consultar_conta_corrente (query). It unambiguously states the tool's function as an update operation.

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 description provides clear guidance on how to identify the target account: 'Informe codigo_conta_corrente ou codigo_integracao' and clarifies that other fields are optional with partial-update semantics. It does not explicitly name alternatives or say when not to use the tool, but the context is strong enough to infer this is for existing accounts only.

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