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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety behavior is covered. The description adds genuine context beyond them: omitting conta_id widens the result set to all cards, which is a scope behavior an agent must know. It does not mention pagination, rate limits, or authorization needs.

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 short sentences, zero filler, with the resource front-loaded and the parameter behavior immediately after. The first sentence is a bare noun phrase rather than an actionable clause, which slightly weakens the opening.

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?

With an output schema present and rich annotations, the description needn't explain return values or safety. Still, for a tool whose sole parameter is undocumented in the schema, an agent is left guessing what a conta_id refers to, which is a meaningful gap for a 1-param fetch tool.

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% – the only parameter is labeled just 'Conta Id' with no explanation. The description partially compensates by defining omission semantics ('returns from all cards'), but never explains what a conta_id actually is or how to obtain one (presumably via listar_conexoes/listar_contas).

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 names a specific resource (credit card statements, 'faturas de cartao de credito') and its retrieval behavior ('traz de todos os cartoes'), which distinguishes it from siblings like transacoes, saldo, and gastos_por_categoria. The verb is only implicit ('traz' rather than 'list'), so it is clear but not maximally precise.

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 second sentence gives a concrete conditional ('Sem conta_id, traz de todos os cartoes'), which tells the agent what happens when the optional param is omitted. However, it never states when to prefer this tool over siblings such as transacoes or listar_contas, nor where a conta_id comes from.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds meaningful behavior beyond that: only DEBIT outflows are counted, results are grouped by category and currency, and sorted descending. The double-counting caveat for transfers and invoice payments is a genuine non-obvious behavioral trait.

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, no filler. The core operation and ordering come first, and the caveat about excluding categories follows where it is most actionable.

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?

An output schema exists, so return-shape explanation is not needed, and the description covers the operation, grouping, ordering, and the main data-quality pitfall. The remaining gap is date-format/optionality detail for desde and ate.

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 coverage is 0%, so the description must carry parameter meaning. It explains ignorar_categorias substantively (what to pass and why) and implies desde/ate define the period, but gives no format for the date strings and does not indicate that ate is optional/open-ended.

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 operation (sum of DEBIT outflows) with explicit grouping dimensions (category and currency), a time scope (period), and an output ordering (largest to smallest). This clearly separates it from siblings like transacoes (raw listing), saldo (balance) and faturas (invoices).

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 second sentence gives real guidance on how to use ignorar_categorias and why (avoid double-counting internal transfers and invoice payments), which implies the tool's intended use case. However, it never says when to pick this over transacoes or faturas, and no exclusions or alternatives are named.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered. The description adds only the aggregation scope ('todas as conexoes'), which is useful but thin; nothing is said about whether connections must be linked or what happens when none exist.

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?

A single short sentence with no padding, and the scope qualifier is placed where it matters. It is arguably under-specified rather than over-long.

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?

An output schema exists, so return values need no explanation, and with no parameters the schema burden is nil. Still, an open-world tool spanning external connections would benefit from a note on connection prerequisites or empty-state behavior, which is absent.

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?

The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description correctly implies no per-connection filtering is needed.

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?

Names the specific resource (investment positions) and its scope (across all connections), which an agent can distinguish from siblings like saldo, transacoes, or faturas. It omits an explicit verb such as 'list' or 'get', but the meaning is unambiguous.

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?

No guidance on when to use this rather than saldo or transacoes, and no prerequisites stated. The only implied cue is 'todas as conexoes', which hints at an aggregated view but never contrasts with an alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds only a listing of returned fields, which duplicates the output schema, and says nothing about the open-world behavior (external bank connections) or result size.

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?

A single short sentence with no filler. It is front-loaded and efficient, though it spends its few words restating the resource rather than stating an action.

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?

With an output schema covering return values and annotations covering safety, the description only needed to clarify intent and scope. It does so minimally: an agent knows roughly what it returns but not the list's size, freshness semantics, or relationship to the other connection-adjacent tools.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies.

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 is a noun phrase naming the resource ('Conexoes (itens) configuradas') and enumerates the fields returned (banco, status, data da ultima atualizacao), which helps identify the content. However, it never states the action (listing) explicitly and gives no differentiation from siblings like listar_contas or transacoes beyond the word 'conexoes'.

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?

There is no guidance on when to use this tool versus alternatives such as listar_contas or saldo, and no prerequisites or exclusions are mentioned. The agent must infer usage purely from the resource name.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so safety is covered. The description's only added value is that balances are as reported by the bank (i.e., live/external data), which is useful context for an open-world tool. It says nothing about authorisation, refresh timing, or whether accounts with no bank connection appear.

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?

A single short clause with no padding. It is efficient, though it reads as a fragment rather than a front-loaded statement of what the tool does.

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?

This is a simple, parameterless read with an output schema and full annotation coverage, so return-value detail is unnecessary. The description tells the agent which account types come back; only the differentiation from saldo/listar_conexoes is missing.

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?

The tool takes zero parameters, so there is nothing for the description to compensate for; the baseline for a 0-param schema applies. The mention of which account types are returned is a small extra.

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 names the resource (contas correntes, poupanças, cartões de crédito) and notes the balance is included, but it is a bare noun phrase with no verb — the action ('list') only comes from the tool name. It also does not distinguish this from siblings like saldo or listar_conexoes, which also concern account/balance data.

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?

There is no indication of when to call this instead of saldo (which presumably returns a balance) or listar_conexoes (which presumably returns linked accounts). No prerequisites, no exclusions — the agent must infer selection from the name alone.

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

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds one useful behavioral detail: the value is a cached snapshot from the last synchronization, not a live query. It does not say what happens when an account has never synced or how stale the snapshot may be, so the added context is real but limited.

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 one compact sentence with no filler, and the account scope and provenance are front-loaded. It is appropriately sized for a one-parameter lookup, though the terse phrasing leaves no room for the missing usage and parameter guidance.

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 single-parameter read tool with no output schema, the description conveys the core return concept (current balance) and notes its freshness. It omits what the balance value looks like, currency handling, and the meaning or source of conta_id, so an agent has enough to attempt the call but not enough to use it confidently.

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 single required parameter conta_id is undocumented in both the schema and the description. The description does not say what a conta_id is, where to obtain one, or whether it must come from listar_contas. With low coverage, the description should compensate, and it does not.

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 names a specific resource and scope: the current balance of one account. It also states provenance ('as the bank informed on last sync'), which separates it from transaction or invoice siblings. It stops short of naming which sibling to use instead, so it is clear but not fully differentiated.

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?

There is no explicit when-to-use guidance and no mention of alternatives such as listar_contas or transacoes. An agent can infer this is a point lookup for one account, but nothing in the text confirms that or states when another tool should be preferred.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds date format and the DEBIT/CREDIT output meaning, but omits whether 'ate' is inclusive, ordering, or pagination behavior; an output schema carries the return shape.

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 tight sentences, front-loaded with the core purpose and followed by the filter default and value semantics; every sentence carries meaning.

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?

With an output schema present, return values need no explanation, and the description covers params and defaults adequately. Minor gaps remain around the inclusive/exclusive date boundary and result ordering, but the agent has what it needs to call it correctly.

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 coverage is 0%, so the description must compensate, and it largely does: it specifies the date format (AAAA-MM-DD) for desde/ate and explains that conta_id defaults to all accounts. It does not clarify whether the ate bound is inclusive or how desde/ate interact.

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?

Clear verb+resource: it lists transactions within a date period and clarifies that omitting conta_id returns all accounts. It is distinguishable from listar_contas/saldo, though it never explicitly contrasts with gastos_por_categoria, which also deals with transaction data.

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 'sem conta_id, traz de todas as contas' note gives implied guidance on the optional filter, but there are no explicit when-to-use/when-not rules or named alternatives among the siblings (e.g., gastos_por_categoria for aggregated expense views).

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