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

With no annotations provided, the description carries the full burden. It usefully discloses that months without data are omitted and what the response contains, but never states that this is a read-only operation, makes no mention of permissions or performance considerations, and does not describe pagination or ordering.

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 dense sentence that front-loads the scope ('Visão anual') and then lists the returned fields. Nothing is wasted, though the long comma-separated enumeration is slightly harder to scan than a structured list.

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?

There is no output schema, so the description must convey return content, and it does so thoroughly by naming every metric and the year totals. For a one-parameter read tool this is largely sufficient, with only the omission of read-only/permission framing and ordering behavior keeping it from being complete.

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?

Only one parameter (year) exists and schema description coverage is 100%, with the schema itself supplying the example '2026'. The description adds no additional meaning about the parameter (e.g., valid range or handling of future years), so baseline 3 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 clearly identifies the resource (annual overview) and enumerates the exact metrics returned per month (income, fixed/budgeted expenses, savings, extras, net balance, closing balance) plus year totals. It is readily distinguishable from get_month_summary by scope, though it relies on an implied verb ('Visão anual') rather than an explicit one.

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 guidance on when to use this tool versus siblings such as get_month_summary or get_month_summary/list_months. A competent agent can infer annual-vs-monthly scope, but the description states no conditions, prerequisites, or exclusions.

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?

With no annotations the description carries the full burden, and it discloses two genuinely useful traits: expenses are returned as positive values (sign convention) and the closing balance is real when the month is closed but projected otherwise. It omits permission requirements and behavior when a month has no data, but the disclosed semantics exceed what the schema provides.

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?

Front-loaded with the core purpose, followed by a dense but necessary enumeration of return fields, the sign convention, and the detail-tool routing. Three sentences, no filler; the field list is long but justified because there is no output schema.

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?

Since no output schema exists, the description does the work of enumerating the returned figures and their real-vs-projected semantics, which is the key information an agent needs. Edge cases (empty month, invalid range errors) are left unstated but are partly covered by the schema's min/max constraints.

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?

Both parameters (year, month) are fully documented in the schema, including the 1-12 range for month. The description adds no param-level detail beyond that, so the baseline of 3 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?

States a specific resource (monthly totals) and enumerates exactly which totals are returned: income, fixed expenses, variable/budget expenses, savings, extras, savings withdrawals, and opening/closing balances. It also names the sibling tool (list_movements) that covers the detail case, so an agent can tell it apart from the other list_* tools without opening a schema.

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?

Explicitly routes the agent: use list_movements to see the underlying detail, implying get_month_summary is the aggregate view. It does not address when to prefer this over get_annual_overview or list_months, but the use context is clear and actionable.

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?

With no annotations this description carries the full burden, and it does disclose meaningful behavior: it returns per-account cash, asset, debt, and net-worth figures, the same grouping the app shows (Principais, Investimentos, Outras Contas), plus totals. It still omits whether the read is authenticated/live and whether results are paginated, but the data-shape disclosure is substantial.

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 core resource and return content, and every clause adds information (asset types, grouping, totals, app parity). It is dense rather than padded, though the long parenthetical lists make it slightly heavy.

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?

There is no output schema and no annotations, so the description must explain return values, and it does so well by enumerating the account fields, grouping, and totals. Missing only invocation-time concerns like freshness or permissions, which are minor for a parameterless read 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate at the input level; 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 clearly scopes the resource: user accounts with cash balance, asset value (securities, funds, deposits), debt (credit card), and net worth per account, grouped into app categories plus totals. This is specific enough to distinguish it from movement/category siblings, though it never states an explicit verb like 'list/retrieve' and relies on the name for that.

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?

Usage is only implied: an agent can infer this is the tool for account balances and the 'Contas' page equivalent. There is no explicit when-to-use vs. get_annual_overview / get_month_summary guidance and no stated prerequisites or exclusions.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses return content: grouping by bucket, an active flag, and the monthly reference value when present. However, it never states this is a read-only, side-effect-free call, nor anything about permissions or result size, leaving the safety profile to be inferred from the name.

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?

Three sentences, front-loaded with the resource and grouping, then the returned fields, then the cross-tool usage note. No filler, though the bucket enumeration is dense and could be trimmed.

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?

There is no output schema and no parameters, so the description must explain what is returned, which it does (bucket grouping, active status, monthly reference value). Given the tool's simplicity, an agent has enough to call it and use its output 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?

The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description does not need to compensate for any schema gap.

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 (list) and resource (categories), and adds scope detail: categories grouped by bucket type with the enumerated buckets (rendimento, despesas fixas, orçamento, extras, poupança). This distinguishes it from siblings like list_movements and list_accounts without ambiguity.

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?

Explicitly routes the agent to a sibling: 'Use os nomes daqui no filtro de list_movements', telling it where the category names are consumed. It gives clear context for use but states no when-not or alternatives to list_categories itself, so it stops short of full 5-level guidance.

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?

With no annotations, the description carries the full burden and does disclose meaningful traits: deterministic ordering, what the state field means (open/closed), and the important caveat that months may be missing because users create them one at a time. It does not explicitly state read-only/permission behavior, but 'Lista' strongly implies a read.

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?

Three front-loaded sentences: what it returns first, then the state semantics and data-completeness caveat, then the usage pointer. Every sentence earns its place, though the state glosses add modest length.

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?

No output schema exists, so the description must describe the return payload, and it does: the set of months, their open/closed state, and each month's net balance, plus the caveat about gaps. Nothing an agent needs in order to call and interpret this tool 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 per the rubric the baseline is 4. There is nothing parameter-related for the description to clarify, and the schema is trivially complete.

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 (lista) and resource (meses), plus scope details: ordering (oldest to newest), per-month state with enum meanings, and net balance. An agent can distinguish this from get_month_summary or list_movements without inspecting schemas.

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?

Explicitly says to use it before requesting summaries or movements, which routes the agent away from get_month_summary/list_movements for this step. It gives clear context but no hard exclusions or prerequisites (e.g., auth, empty-state handling).

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?

No annotations exist, so the description carries the full burden and does well: it discloses ordering by date, the signed-amount convention (negative = outflow), that imports and manual entries are both included, and that the returned `id` feeds update_movement, delete_movement and consolidate_movements. It omits any statement about result limits/pagination or permissions, keeping it from a 5.

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?

Front-loaded with the resource and scope, then the filter behavior, then the sibling routing and id semantics, all in three compact sentences in the domain language. Dense but each clause carries distinct information; the field enumeration is slightly heavy but earns its place given no output schema.

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 no output schema and no annotations, the description covers return fields, ordering, sign convention, filter behavior, sibling routing and downstream id usage — enough to call the tool correctly. It could be more complete about volume limits or whether results are paginated.

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 100% and already documents year/month, so the baseline is 3; the description adds meaning the schema lacks — that the category filter is partial and accent-insensitive ("parcial, sem acentos"), which materially affects how the agent should pass that argument.

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 (listar) and resource (movimentos) scoped to one month of 1fluxo, and explicitly distinguishes itself from the sibling search_movements for multi-month text search. It also enumerates the returned fields so the agent knows exactly what this list call yields.

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?

Names the alternative (search_movements) and the condition that selects it (text search across several months), which is clear routing guidance. It does not state explicit when-not conditions for this tool itself, so it falls short of a full 5.

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?

With no annotations, the description carries the full burden and does well: it discloses accent- and case-insensitive substring matching, the default 12-month window, the all-accounts scope, the most-recent-first ordering, and the returned total. It omits pagination/result limits, which is the only notable gap.

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?

Three tight sentences, front-loaded with the verb and resource; the search semantics, scope, default window, and return behavior each earn their clause with no filler.

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 3-param search tool with no output schema, the description covers search semantics, date defaults, account scope, sort order, and the aggregate return. Only result-size/pagination behavior is unaddressed.

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, but the description adds genuine meaning: 'text' is matched partially against both descrição and notas and is accent/case-insensitive, and omitting from/to silently defaults to the last 12 months rather than being unbounded.

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 (Pesquisa) plus resource (movimentos) and the search key (descrição ou notas), and scopes it to all accounts including off-budget ones. It is distinguishable from list_movements by the text-search semantics, though it never names the sibling explicitly.

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?

Implies when to use it (text search over descriptions/notes) and supplies the fallback window when dates are omitted (last 12 months), which is real usage context. However, it never contrasts itself with list_movements or states any when-not condition, so routing is left to inference.

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