Organizze

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

Annotations provide idempotentHint=true and destructiveHint=false, and the description adds meaningful context beyond that: the token is a JWT, login can be permanent via server config or session-only, and calling with no args returns the login link. This transparently explains the auth flow and side effects.

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 dense and front-loaded, immediately explaining the login flow. It is slightly run-on and mixes best-practice advice with invocation instructions, but every sentence adds useful information and there is no padding.

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 optional parameter and no output schema, the description covers all necessary invocation paths and even explains the recommended permanent configuration. An agent has enough context to authenticate successfully or ask the user for the token.

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 schema only defines token as a string with no description, so the description carries the full burden. It explains that token is optional, expects a JWT pasted by the user, and that omitting it returns the login link. This fully compensates for the schema's lack of detail.

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 this as an authentication/login tool with specific behaviors: get a login link, accept a token, and establish either permanent or session-only access. It is easily distinguished from the many data-operation sibling tools like organizze_list_transactions.

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 gives explicit instructions for two usage modes: configuring a permanent Authorization header vs. passing a token for session-only login, plus the no-args option to obtain the login link. This leaves little ambiguity about when and how to invoke the tool.

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 establish the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral detail: the authenticated:true condition, empty pending[] behavior, and the connect_url payload when credentials are missing. No contradiction with annotations.

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-load the primary result and add conditional behavior without waste. 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?

For a zero-parameter status tool, the description covers the main success and failure-ish states plus what URLs are returned. 'Per-install URLs' is somewhat ambiguous and there is no output schema to clarify the exact response shape, so it stops short of a 5.

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 has zero parameters and the schema is trivially complete, so the description does not need to compensate for parameter documentation. 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 states the tool returns connection status and URLs, with specific details about authenticated and pending states. It does not explicitly distinguish itself from close siblings like authenticate or organizze_get_bank_connections, so it misses the top score.

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 explains what happens in different connection states but does not explicitly say when to use this tool versus alternatives. Context is implied—call this to check connection status—but no exclusions or alternatives are mentioned.

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?

Despite annotations already carrying readOnly=false, openWorld=true, idempotent=false, destructive=false, the description adds substantial behavioral detail: invoke runs one-off without installing or bloating the tool list, credential gaps return a connect link, payment gaps return a checkout/top-up link, writes require workspace owner/admin, and the prompt share link opens without login. These behaviors are not visible in the annotations and are clearly disclosed.

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 long but densely informative and thematically organized: core flow first, then invoke-specific caveats, billing/auth, write-permission context, and the separate prompt library. Every sentence adds value, but the sheer volume of detail makes it harder to parse quickly; better paragraph breaks would help.

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 14-action dispatcher with no output schema and 23 undocumented parameters, the description is unusually complete: it covers discovery, invocation, one-off vs permanent install, auth, payment, permissions, billing actions, and prompt-library behavior. Still, some actions are omitted (resume is never described, uninstall only appears in the permissions sentence) and it does not describe expected return shapes, which would be materially useful for a no-output-schema 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?

With 23 parameters and 0% schema description coverage, the description carries a heavy burden, and it does decode the action enum and core flow concepts like action, query, mcp_id, tool_id, and arguments. However, many parameters are left completely untouched: limit, immediate, tier_slug, request_name, cancel_reason, cancel_comment, report_context, prompt_body, prompt_slug, prompt_tool, prompt_vars, conversation, prompt_title, prompt_description, prompt_targets, prompt_category, and request_details. The agent must infer much of the parameter semantics from names and defaults 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 states an exact purpose: it is the mcp.ai marketplace used to discover, describe, and run MCPs/tools. It explains the core action flow (search -> describe -> invoke) and explicitly names the intent categories it covers ('find an MCP that does X', 'consulta um CPF'). It also separates the prompt-library function from the MCP-catalog function, making the dual nature clear and avoiding confusion with sibling tools.

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 gives explicit when-to-use guidance: prefer invoke for single/occasional use, use install only to make an MCP PERMANENT, use list_tools to see callable tools now, subscribe/cancel for per-MCP billing, report_bug for feedback, and request_mcp when nothing fits. It even tells the agent what to do when a connect or checkout link is returned (user opens it, then retry). This is strong routing 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?

Annotations only express generic flags; the description adds meaningful behavior: tags 'acumula sobre as existentes' and 'máx. 200'. This clarifies that the operation is additive and bounded, which is valuable beyond the structured annotations.

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 compact sentences with no filler. The main purpose is front-loaded, and every clause adds useful constraints: multi-transaction, single call, accumulation behavior, max 200, and per-item format.

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 batch mutation tool with no output schema, the description covers the core invocation data: what the tool does, how many items are allowed, identifier options, and tag format. It does not describe failure modes or duplicate-tag behavior, but the essential context is present.

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 schema has 0% description coverage and only shows an 'items' array, so the description must compensate. It explains that each item must have either transaction_id or transaction_uuid plus tags, and formats tags as comma-separated string or list. The 'ou lista' phrasing is slightly ambiguous against the schema's string type, preventing a 5.

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 states the operation: 'Adiciona tags a VÁRIAS transações em uma chamada', identifying both the action and the resource. Mentioning 'VÁRIAS transações' distinguishes this from single-transaction tools like organizze_update_transaction.

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?

It explicitly conveys the intended use case: batch-tagging of multiple transactions in one call, with a 200-item cap. It does not name alternative tools or state when-not-to-use conditions, which keeps it from a 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?

Annotations mark the tool as not read-only, not idempotent, and not destructive. The description adds meaningful behavioral context by explaining that existing destination budgets are not overwritten, which clarifies the tool's safety profile and partially explains its non-idempotent/non-destructive nature. It also discloses the current-month default.

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 concise, front-loaded sentence plus a short default note. Every phrase adds information: the operation, source, destination, non-overwrite behavior, and default. No filler or redundancy.

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 simple tool with two optional numeric parameters and no output schema, the description covers the main invocation concerns: what the tool does, when it will not act, and what happens when parameters are omitted. It does not explain return behavior or error cases, but the tool is simple enough that this is a minor gap rather than a blocking omission.

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 does clarify that omitted parameters default to the current month, which is useful. However, it does not explicitly describe what 'year' and 'month' represent beyond the implied destination month, nor does it specify accepted ranges or required formats. The guidance is adequate for simple numeric parameters but not 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?

The description clearly states the operation: cloning previous month's budgets into a destination month. The verb 'clona' and the explicit source/destination make it immediately distinguishable from sibling tools like organizze_create_budget, organizze_list_budgets, and organizze_update_budget.

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 context: it copies budgets from the previous month and does not overwrite a month that already has budgets. It also states the default destination is the current month. It does not name alternative tools explicitly, but the behavioral guidance is sufficient for an agent to decide when to use it.

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 description adds behavioral context beyond the annotations by explaining that the tool supports batched execution via institution_ids. Annotations already signal a write operation (readOnlyHint=false) and non-destructive behavior, so the description does not need to restate those, but it does not disclose side effects, auth requirements, or limits.

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 short sentences, with the primary purpose front-loaded and the bulk behavior as a separate concise note. Every sentence earns its place and there is no repetition or 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?

With 5 parameters, zero schema descriptions, no output schema, and minimal annotations, the description leaves important details uncovered such as required fields, how initial_balance is used, and the distinction between institution_id and institution_ids. The bulk-support note adds value but the overall definition is not complete enough for reliable invocation.

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 for missing parameter meaning. It only sheds light on institution_ids via the bulk-support sentence; the roles of name, description, institution_id, and initial_balance remain undocumented in both the schema and description. This is insufficient for 5 parameters.

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 states the verb 'Cria' (creates) and the resource 'conta bancária manual' (manual bank account), which distinguishes it from sibling tools like organizze_create_credit_card, organizze_create_transaction, and organizze_create_transfer. The bulk-support note adds further specificity about what this tool can do beyond a simple single-account creation.

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 usage context is implied by the phrase 'Cria uma conta bancária manual' and the bulk-support note indicates when the institution_ids parameter would be used. However, there is no explicit guidance on when to prefer this tool over alternatives, nor any exclusions or preconditions.

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 signal a mutating, non-read-only, non-idempotent operation, and the description aligns by saying 'Cria'. It adds context about the default activity_type and the preference for category names. However, it doesn't disclose possible side effects like duplicate handling or whether an existing budget for the same category/period is replaced.

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 dense sentences, front-loaded with the core action, and every phrase adds useful guidance. There is no redundant or filler text.

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?

The description covers the core purpose and the two most likely ambiguities (category name vs id and expense vs income). However, year/month remain undocumented, there is no output schema to clarify the response, and it doesn't state whether the category must already exist. It is adequate but has clear gaps.

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?

With 0% schema description coverage, the description must compensate. It clarifies that category should be a category NAME and that activity_type accepts 'earning' for income goals, defaulting otherwise to expense. 'Limite de gastos' implies amount is the spending limit. But it does not explain year/month semantics, period defaults, or the full set of accepted activity_type values.

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 the specific action (Cria = creates) and resource (spending limit/budget for a category), and adds the useful expense-vs-earning distinction. It differentiates at a glance from update/delete/list/clone budget tools, though it doesn't name those alternatives 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?

The tool's use is implied by 'Cria um limite de gastos' and by the sibling names, but there is no explicit guidance about when to choose create_budget over update_budget or clone_budgets. It does provide useful context about defaulting to expense and using activity_type 'earning' for revenue goals.

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 signal readOnlyHint=false, so the write behavior is expected. The description adds context about expense vs revenue categories, root vs subcategory creation, and batch execution. However, it does not disclose side effects, validation, authentication requirements, or what happens on duplicate names.

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, focused sentences. The core purpose is front-loaded and the bulk capability is added without repetition or 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?

With seven parameters, 0% schema coverage, no output schema, and no alternative tool guidance, the description is too thin for reliable invocation. An agent would still need to infer required parameter formats, valid kind values, and expected response behavior.

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 carries the burden. It clarifies kind via 'despesa ou receita' and parent_id via subcategory creation, and hints that plural ids support batching. But it leaves name, color, group_id, and the semantic meaning of group_ids/parent_ids largely unexplained.

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: 'Cria uma categoria de despesa ou receita' (creates an expense or revenue category). It also clarifies the hierarchy scope, 'raiz ou subcategoria via parent_id', which distinguishes it from category lookup, update, or delete tools.

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 or when-not-to-use guidance relative to sibling tools such as organizze_mass_manage_categories or organizze_update_category. The bulk-support sentence implies batch usage, but it does not tell an agent when to prefer this tool over alternatives.

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 signal a write operation (readOnlyHint=false) and non-idempotent/non-destructive behavior. The description adds meaningful side-effect context: invoices are automatically generated after creation, and batch execution is supported through payment_account_ids. This goes beyond the structured hints, though it does not discuss permissions or failure behavior.

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 paragraphs, with the core purpose and the manual/automatic distinction front-loaded. The batch note is placed in a separate short sentence, minimizing reading cost.

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?

The description covers the main behavioral contract (manual cards, auto-generated invoices, batch support) but does not explain several parameters (flag, limit, payment_account_id) and gives no return/output expectations. With no output schema and zero schema descriptions, an agent may still have to guess when calling, so the definition is not fully 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?

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It clarifies payment_account_ids for bulk execution, but leaves name, billing_due_day, billing_cycle_day, flag, limit, and payment_account_id without additional meaning. This is insufficient compensation for seven undocumented parameters.

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 opens with a specific verb and resource, 'Cria um cartão de crédito MANUAL', and immediately distinguishes this from automatic cards sourced via bank connections. This makes the tool's purpose unambiguous and separates it from related credit-card operations.

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?

It explicitly states the manual-card use case and explains that automatic cards come from bank connections, implying this tool should not be used for those. It also notes bulk support via payment_account_ids, giving a clear condition for batched execution, though it does not name an alternative tool.

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 are all false/default (readOnlyHint false, idempotentHint false, destructiveHint false), providing no effective safety or behavior profile, so the description carries the burden. It does not disclose what happens on creation — no mention of idempotency despite an idempotency_key parameter, no duplicate/error behavior, no response description. The 'never invent UUID' rule guides agent input but does not reveal tool behavior.

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 short sentences, each earning its place: purpose first, then the critical value rule with the prerequisite sibling tools, then a concrete example. No fluff, no repetition of schema content, and the most important constraint (names not IDs) is front-loaded.

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?

The description is sufficient for a basic invocation of the five required parameters — account and is_income are clarified, and description/amount/date are self-evident. But with no output schema, empty annotations, and 13 parameters, it leaves meaningful gaps: idempotency_key semantics, recurring/periodicity behavior, the done flag, and the distinction from mass_create_transactions all go unaddressed. Adequate for selection, incomplete for advanced correct invocation.

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?

With schema description coverage at 0%, the description compensates partially: the example (account: 'Nubank', category: 'Alimentaçao', is_income: false) gives real value semantics for three parameters — human-readable names, not IDs — which the bare string schema completely lacks. However, 9 of 13 parameters (date format, done, tags, times, recurring, observation, periodicity, idempotency_key) receive no explanation, so the compensation is incomplete.

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 — 'Cria uma transaao (receita ou despesa)' — and the parenthetical clarifies the two accepted transaction types. Among the many create_* siblings (account, budget, category, credit_card, transfer), the resource word 'transaao' makes the target unambiguous. It lacks an explicit contrast with sibling create tools, but the verb+resource pairing is specific enough to select it correctly.

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 gives actionable when-to-use guidance: 'Prefira NOMES de conta/cartão e categoria (list_accounts / list_credit_cards / list_categories primeiro se não souber)' names the exact sibling tools to call first and the condition that triggers them. 'Nunca invente UUID/id' sets a hard behavioral rule. It does not, however, contrast with alternatives like mass_create_transactions or update_transaction, so exclusion guidance is partial.

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 only signal non-readOnly, non-idempotent, and non-destructive, so the description carries the main behavioral burden. It adds useful behavior: recurrence is supported and account parameters should be names, not IDs. But it does not disclose side effects such as balance updates, validation behavior, or response/error details.

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 three short sentences with no filler. It front-loads the main purpose and then gives two high-value usage instructions, making it easily scannable for an AI agent.

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 10-parameter mutation tool with no output schema, the description covers the core purpose and the account-naming convention but omits date formats, periodicity values, optional-field semantics, and any indication of the result. It is adequate for high-level selection but not fully complete for precise invocation.

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?

With 0% schema_description_coverage, the description must compensate. It clarifies the two account parameters by saying 'Prefira NOMES de conta' and hints at periodicity/recurrence semantics. However, it leaves amount, date, done, tags, observation, and periodicity values undocumented.

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 opens with a specific verb and resource: 'Cria uma transferência entre duas contas bancárias.' It also distinguishes itself from credit-card-related tools with 'Não envolve cartões de crédito' and adds recurrence scope, so an agent can clearly tell it apart from organizze_create_transaction and similar siblings.

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?

It gives clear context: use this for bank account transfers, and it explicitly excludes credit cards. It also provides a strong practical instruction to prefer account names rather than inventing IDs. However, it does not explicitly name alternative tools or describe when a regular transaction should be used instead of a transfer.

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 description clearly warns that all transactions of the account are deleted in background, which is important behavioral context. However, the annotation destructiveHint: false contradicts the description's stated destructive effect, so this dimension must be scored as an annotation contradiction.

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 brief, front-loads the core action, and places the critical warning prominently. Every sentence adds meaningful information: what is deleted, the background behavior, and the exclusion for automatic accounts.

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?

The tool is simple with one parameter, and the description provides important caveats. However, it does not specify how to identify the account for the parameter, and the destructiveHint annotation directly contradicts the described behavior, leaving the overall picture inconsistent.

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%, and the description does not explain what the required 'account' parameter should contain (ID, name, or other identifier). The word 'conta' adds no semantic information beyond the parameter name itself, so the agent is left without guidance for filling the only required field.

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 ('Exclui') and resource ('conta'), making it clear that this tool deletes an account. It is therefore distinguishable from sibling tools like organizze_delete_budget or organizze_delete_credit_card.

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?

It explicitly gives an exclusion: automatic accounts cannot be deleted, and it steers the agent to the connections menu as the alternative. A general when-to-use statement is missing, but the when-not-to-use guidance is strong.

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 description describes removing/deleting a budget, yet the annotations declare destructiveHint: false, sending opposite signals on the central question of whether invoking this tool destroys anything. Beyond the bulk note, no idempotency behavior, error handling, or reversibility is disclosed, and idempotentHint is false. This is an annotation contradiction.

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 with the core purpose front-loaded and the bulk capability following; no filler or repetition. The Portuguese-only description amid English sibling names is a minor structural weakness but does not hurt scannability.

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 delete tool with no output schema and 0% parameter coverage, the definition omits success/error behavior, what happens when budget_id doesn't exist, and the relationship between the two parameters. The annotation contradiction leaves the side-effect profile unresolved, so an agent cannot confidently predict consequences.

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 bears the responsibility of defining the parameters; it only states that budget_ids enables 'batched execution,' leaving budget_id's meaning to inference from the tool name. It doesn't clarify whether budget_id and budget_ids are mutually exclusive, optional together, or how batch failures are reported.

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 a specific verb ('Remove') tied to a concrete resource — 'um orçamento (limite de gastos) de uma categoria' — clarifying the domain meaning of a budget as a category spending limit. Within the budget-related sibling set (create_budget, update_budget, clone_budgets, list_budgets), the delete intent is unambiguous. It doesn't explicitly contrast with update_budget, which keeps it from 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?

There is no guidance on when to use this tool versus siblings like organizze_update_budget (adjust an existing limit) or organizze_clone_budgets (copy budgets). The bulk-support sentence explains how to batch calls, not when this tool is the right choice; no exclusions or alternatives are mentioned.

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?

Annotation Contradiction: destructiveHint is false even though the description says the tool deletes a category and that subcategories 'somem' (disappear). The description adds useful side effects like transaction reassignment and root-cascade behavior, but the direct contradiction with the annotation makes the behavioral signal unreliable, requiring a score of 1.

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 short sentences with no filler: the main action, the destination of transactions, and two key constraints. Every sentence contributes essential information and the most important fact is front-loaded.

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?

The description covers the main deletion semantics, the default-category restriction, and the root-cascade side effect. However, with no output schema and an annotation set that contradicts the destructiveness of the operation, it leaves ambiguity about parameter format and return behavior, so it is only partially 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?

Schema description coverage is 0%, so the description must carry the burden of explaining the two string parameters. It explains that substitute_category receives the transactions or that a default category is used, but it leaves 'category' under-specified, such as whether it expects an ID or name, and does not fully compensate for the missing schema documentation.

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 states the operation: 'Exclui uma categoria' (deletes a category), identifying both the verb and the resource. It does not explicitly differentiate from sibling tools like organizze_mass_manage_categories or organizze_update_category, so it stops short of a top score.

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 concrete usage constraints: default categories cannot be deleted, and deleting a root category causes subcategories to disappear. It does not name alternative tools or explicitly state when to use a bulk management sibling, but the constraints give clear contextual guidance for when deletion is or is not appropriate.

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 description warns that all transactions and invoices are deleted, which is clearly destructive behavior, but the annotations set destructiveHint to false. This is an annotation contradiction, so per rubric this dimension scores 1.

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 fluff: first states the action, second gives the critical warning and exception. The information is front-loaded and each sentence 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?

The description covers the operation, cascade side effects, and the automatic-card exception, but it omits how to identify the target card and what the return/response behavior is. With no output schema and no parameter documentation, an agent still cannot reliably call this tool 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 only parameter 'credit_card' has no schema description and the description never explains what value it expects (ID, name, slug) or how to format it. With 0% schema description coverage, the description was required to compensate and did 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 states a specific action and resource: 'Exclui um cartão de crédito' (deletes a credit card). This clearly distinguishes from sibling update/list/get tools for credit cards, and there is no other sibling that deletes a credit card specifically.

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?

It provides an explicit exclusion and alternative action: automatic cards cannot be deleted and should be disconnected via the connections menu. It doesn't spell out general when-to-use vs alternatives like update_credit_card, but the deletion intent is clear.

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 description states 'Exclui uma transação', which is an explicit destructive action, but the annotations declare destructiveHint=false. This is a direct contradiction. The description does add useful behavioral context, such as Open Finance restrictions and bulk support, but the contradiction forces a score of 1.

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 dense but well-organized: action, exclusions, routing, ID provenance, and bulk support. It is front-loaded and contains no fluff, though the relationship between the bulk support paragraph and the mass_delete_transactions recommendation could be slightly clearer.

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?

The description covers key invocation constraints and sibling routing, but leaves gaps around the delete_recurrence parameter, which parameter combinations are valid, and what the tool returns. The annotation contradiction also undermines completeness for a destructive operation.

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?

With 0% schema description coverage, the description must compensate. It explains that transaction_id/uuid must be copied from list/search/get and never invented, and mentions transaction_ids for bulk. However, it does not explain the delete_recurrence parameter's accepted values or clarify how the four parameters relate to one another.

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 opens with a specific verb and resource: 'Exclui uma transação' (deletes a transaction). It also differentiates from sibling tools by explicitly routing recurrent transactions to delete_recurrence and multi-line deletions to mass_delete_transactions.

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 gives explicit when-to-use guidance: automatic Open Finance transactions cannot be deleted, recurrent transactions should use delete_recurrence, and multiple lines should use mass_delete_transactions. It also provides a strong constraint on where transaction IDs must come 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 mark this as read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations: duplicate detection criteria and the default date range. No contradiction with annotations.

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 short, purposeful sentences with no filler. The main behavior and criteria are front-loaded, followed by the use case and default behavior. Every sentence 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?

For a read-only duplicate finder with 4 optional parameters and no output schema, the description conveys the core purpose and default behavior adequately but leaves parameter semantics and return details underspecified. More detail would be needed for fully confident invocation.

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 for the 4 undocumented parameters. It only vaguely relates to start_date/end_date via 'Padrão: mês atual' and does not explain days_threshold, include_automatic, or date formats. This is a significant 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?

The description states a specific verb ('Encontra') and resource ('transações possivelmente duplicadas'), and defines the detection criteria: same value, similar description, and close dates. This clearly differentiates it from listing, searching, or finding installments/subscriptions.

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?

It clearly frames the intended use case: cleaning up double-entered transactions, and notes the default current-month window. It does not explicitly mention alternatives or when-not-to-use cases, so it misses the top tier.

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=true and idempotentHint=true. The description adds valuable behavioral context: it combines structured installments with heuristic detection for Open Finance and labels results as 'possível parcelamento'. This informs the agent that results may include uncertain classifications, which is useful beyond the annotations.

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 compact and front-loaded, with the core purpose in the first sentence and each additional sentence adding distinct information: heuristic behavior, default date range, and filter capability. There is no filler or redundancy.

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 read-only discovery tool, the description covers the essential operational context: what it finds, how the heuristic works, default time range, and filtering options. The main gaps are the lack of any output schema or return-format description and the unexplained 'min_occurrences' parameter, but these are not fatal given the tool's simplicity.

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?

With 0% schema description coverage, the description must compensate for the four undocumented parameters. It provides some relevant context: date parameters are optional and default to the last 12 months, and the 'account' parameter appears to support filtering by account/card. However, 'min_occurrences' is not explained at all, leaving a clear gap in parameter understanding.

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 tool's purpose: finding installment purchases ('Encontra COMPRAS PARCELADAS') in a period, and explicitly distinguishes it from text search ('use isto, não busca por texto'). This makes it easy for an agent to differentiate from sibling tools like search_transactions.

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 gives explicit guidance to use this tool instead of text search and clarifies the default behavior when no dates are provided ('Sem datas, últimos 12 meses'). It also mentions optional filtering by account/card. However, it does not name specific sibling alternatives or state when NOT to use this tool beyond the text-search exclusion.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses key behavior: heuristic detection based on repeated merchants, combination with fixed registered accounts, classification by amount stability, limitation to connected accounts, and a fixed 6-month window with no date filtering. This is substantial transparency about how the tool actually behaves.

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 longer than average but every sentence carries distinct value: purpose, user intents, scope, algorithm, classification, exclusions, and time window. It is front-loaded with the main purpose and contains 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?

The description covers purpose, when-to-use, exclusions, and algorithm, which is strong for a read-only detection tool. However, there is no output schema and no explanation of return shape, and several input parameters remain undocumented, so an agent may still struggle to invoke it fully correctly in all cases.

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 input schema has 0% description coverage, so the description must compensate, but it only hints at parameters. 'Sem datas, últimos 6 meses' implies start_date/end_date are ignored, and 'mesmo estabelecimento repetido em vários meses' vaguely suggests min_occurrences, but account, end_date, and include_recurrences are not meaningfully explained.

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 opens with a specific verb and resource: 'Detecta ASSINATURAS e serviços recorrentes' and gives concrete examples such as Netflix, Spotify, and rent. It also explicitly differentiates the tool from the sibling find_installments, making its scope unmistakable.

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?

It lists direct user intents ('minhas assinaturas', 'o que pago todo mês', 'o que posso cancelar') and states the operational context (Open Finance connected accounts/cards). It also provides an explicit when-not-to-use rule and names the alternative: 'NÃO inclui parcelamentos (use find_installments)'.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds what data is returned (entity, plan, date, compact lists) but does not disclose exact list limits or response shape details. This adds moderate context without contradiction.

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 tightly written sentences: the first lists the returned contents, the second gives the usage instruction. No filler words, and the key information is front-loaded.

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 zero-parameter, read-only context tool with no output schema, the description provides the essential payload contents (entity, plan, timezone date, compact id↔name lists). It lacks exact response fields or size limits, but the tool is simple enough that this is a minor gap.

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 has zero parameters and an empty input schema, so no parameter documentation is necessary. Baseline of 4 for zero-parameter tools is appropriate; the description correctly focuses on return behavior instead.

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 very specific composite purpose: return connected entity, plan, today's date in the user's timezone, and compact id↔name lists of accounts, cards, and categories in one call. This clearly distinguishes it from the list_* siblings, which are individual listing tools.

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 gives explicit guidance to call it at the beginning ('Chame no início') to avoid multiple list_* calls, directly naming the alternative tool family. It could add a note about when not to use it, but the placement guidance is clear.

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 establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral nuance beyond annotations by clarifying the cash-basis calculation and explicitly noting that installments and future invoices are not treated as debt.

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 compact and front-loaded, starting with the core concept 'Saldo consolidado' and immediately enumerating the result components. Every sentence adds useful information, and the example queries at the end are practical, not 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 zero-parameter, read-only aggregate tool, the description fully explains what the agent should expect: account balances, open invoices, and net worth calculation. There is no output schema, so the description adequately covers return semantics on its own.

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 has zero parameters and 100% schema description coverage, so there are no parameter semantics the description must explain. The baseline of 4 applies because the tool is parameterless and the description adds clarifying context about what data is returned.

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 states the tool's output: consolidated balance with current account balances, current open credit card invoices, and net worth (accounts minus open invoices). It also gives concrete example user queries it serves, making its purpose immediately obvious and distinguishable from other reporting tools.

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 explicitly says when to use this tool: for questions like 'qual meu saldo total', 'quanto tenho', and 'patrimônio'. It gives strong usage context, though it does not name specific sibling alternatives or state when not to use it.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond that: it explicitly notes the tool does not force synchronization, clarifies it only returns ACTIVE connections, and enumerates the status values (estável/indisponível). No contradiction with annotations.

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 short sentences, each earning its place: purpose with output scope, behavioral caveat (no sync), and usage trigger. Front-loaded with the main function, zero waste.

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 zero-parameter, read-only tool with annotations covering the safety profile and no output schema, this description is complete: it conveys the resource, scoping (active only), status vocabulary, side-effect disclaimer, and the user intent it serves. Nothing an agent needs to call it correctly 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 input schema has zero parameters, so the baseline is 4. There is nothing for the description to add semantically; the empty schema combined with the description's output focus fully covers invocation.

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: it lists active bank connections (Open Finance/Connected) and their status (stable/unavailable). It is clear and specific, but does not explicitly name or differentiate from sibling tools, particularly organizze_get_open_finance_status, which appears closely related.

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 gives explicit when-to-use guidance via the quoted user intent 'meu banco não atualiza' ('my bank is not updating'), which is excellent for agent intent-matching. However, it does not state when-not-to-use or name alternatives such as organizze_get_open_finance_status, leaving disambiguation implicit.

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 cover readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds the default current-month behavior and the fact the output includes alert states. It does not contradict the annotations.

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?

One succinct sentence front-loads the core output (summary of limits with alerts) and ends with the default behavior. There is no filler or redundant restatement of the tool name.

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 read-only summary with two optional parameters, the description covers purpose, output highlights, and default period. However, with no output schema and no parameter-level documentation, it leaves the exact return format and parameter constraints ambiguous.

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 schema has zero description coverage, so the description must carry the parameter semantics. It says the summary is for a month and defaults to the current month, implying year/month are optional selectors. It does not specify valid ranges or how the two params 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?

The description states the tool returns a summary of monthly spending limits with alerts for budgets that are exceeded or close to the limit. The 'estou no controle?' phrase makes the user intent clear. It does not explicitly contrast with siblings like organizze_list_budgets or organizze_get_financial_summary, but the focus on limits plus alerts is distinctive enough.

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 explicit when-to-use or alternative tools are mentioned. The 'estou no controle?' phrasing implies it is for checking budget control, and 'Padrão: mês atual' gives default-call guidance. However, an agent is not told when to choose this over organizze_list_budgets or organizze_get_financial_summary.

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?

As anotações já indicam readOnlyHint, idempotentHint e destructiveHint false, e a descrição agrega contexto comportamental relevante: o cálculo começa do saldo atual, aplica lançamentos não pagos, retorna saldo final e menor ponto, e define o período padrão. Isso vai muito além das anotações e não as contradiz.

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 descrição é curta, direta e bem estruturada: começa pelo propósito, explica o método, menciona o retorno e fecha com o comportamento padrão. Cada frase contribui sem repetir informações do schema ou das anotações.

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?

Para uma ferramenta sem output schema e com parâmetros opcionais, a descrição cobre bem o comportamento, o retorno e a exclusão de faturas de cartão. A lacuna principal é a falta de detalhes sobre 'start_date' e a definição exata de 'contas manuais', mas o contexto geral é suficiente para uma invocação razoável.

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?

Com 0% de cobertura de descrição no schema, a descrição precisa compensar. Ela menciona a janela e o padrão de 30 dias, o que ajuda a entender o parâmetro 'days', mas não explica o formato ou a semântica de 'start_date' nem como os dois parâmetros interagem. A compensação é parcial.

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?

A descrição define claramente o que a ferramenta faz: projeta fluxo de caixa a partir do saldo atual e lançamentos não pagos, retornando saldo projetado e risco de negativo. Também diferencia a ferramenta de alternativas ao explicitar que não projeta faturas de cartão e que usa base caixa.

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?

A descrição informa o escopo de uso (contas manuais, base caixa, janela padrão de 30 dias) e traz uma exclusão relevante ('não projeta faturas de cartão'). Porém, não nomeia explicitamente ferramentas alternativas nem diz 'use quando' versus outros relatórios financeiros.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying the default time window of the last 3 months, but it does not disclose output shape, pagination, or other runtime behavior. Given the annotations, this is a reasonable baseline.

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 extremely concise: three short clauses with no filler. The core purpose is front-loaded, followed by the key use case and then the default behavior. Every sentence 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?

The tool has 6 parameters, no output schema, and no parameter descriptions. While the default behavior and periodicity options are mentioned, an agent would still struggle to understand the meaning of category_ids, only_parent_category, or how the response is structured. The description gives a good overview but is not complete enough for a tool of this parameter complexity.

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 maps fairly well to several parameters: 'gastos/receitas' suggests the lens values, 'diário/semanal/mensal' maps to periodicity, and 'últimos 3 meses' implies start_date/end_date defaults. However, category_ids and only_parent_category are not explicitly explained, leaving some parameters to inference.

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 states a specific resource (expense/revenue by category) and a temporal dimension (evolution over time with daily/weekly/monthly granularity). It also adds the intended use case ('Ideal para tendências'), which helps distinguish it from a static report, though it does not explicitly name sibling alternatives.

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 phrase 'Ideal para tendências' provides clear usage context for trend analysis, and 'Padrão: últimos 3 meses' tells the agent that no date parameters are needed for a default query. It does not explicitly describe when not to use the tool or name an alternative, but the context is sufficient for common selection.

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 mark this as read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond the schema: card purchases are included, values are computed per transaction (not per invoice), and the default period is the current month.

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 short sentences deliver the essential facts with the main purpose first. The fragment structure is a little choppy, but there is 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 read-only report this is reasonably complete: it names the grouping, granularity, inclusions, output elements, and default period. However, with no output schema, it should have said more about the return shape, and the unexplained lens parameter plus missing date format guidance leave gaps.

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?

With 0% schema description coverage and three undocumented parameters, the description must compensate. It hints that start_date and end_date default to the current month, but it never explains the lens parameter or date formats, leaving part of the call contract underspecified.

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/resource: a report of expenses and revenues grouped by category, including credit-card purchases, with percentages and subcategories. This makes it distinct from sibling report tools such as get_tags_report or get_categories_evolution.

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 gives clear context: category-grouped expense/revenue reporting, by transaction, defaulting to the current month. It does not explicitly name alternatives or exclusions, so it stops short of a 5, but an agent can infer when this report fits.

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=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds useful behavioral context by naming the returned content and disclosing bulk execution support. No contradiction with annotations.

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 with no filler: the first states purpose and preferred input method, the second adds bulk behavior. Every sentence contributes useful information.

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 7 optional parameters and no output schema, the description leaves a key gap: how an agent should identify a single invoice, such as invoice_id versus credit_card combined with year/month. The bulk note helps, but the core invocation logic is underspecified.

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, but it only addresses credit_card, credit_card_ids, and invoice_ids. It does not clarify year, month, invoice_id, or credit_card_id, leaving the required identification combinations ambiguous.

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 states the tool returns details of a specific credit card invoice, including transactions, payments, and expenses by category. The word 'specific' differentiates it from the plural sibling organizze_get_credit_card_invoices, though it does not explicitly name that sibling.

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?

It gives explicit guidance to prefer passing credit_card with the card name, and notes bulk support via credit_card_ids and invoice_ids. This is actionable for parameter selection, though it does not state when to choose this tool over the sibling for listing invoices.

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, and destructiveHint, covering the safety profile. The description adds one useful behavioral trait: bulk execution through credit_card_ids. However, it does not disclose return format, pagination, or how start_date and end_date affect the result, so the added behavioral context is modest.

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 extremely concise: two short sentences that front-load the purpose, then state the required parameter and the bulk option. Every sentence earns its place and there is 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 simple, read-only list operation, the core invocation is clear: provide credit_card_id and optionally use batch ids. But the description lacks return-value details, omits start_date/end_date semantics, and gives no guidance about the closely related singular sibling, leaving some context incomplete.

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 explains credit_card_id as required and credit_card_ids as a bulk alternative, but start_date and end_date are left completely undocumented in both the schema and the description, leaving their meaning and expected format unclear.

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 opens with 'Lista faturas de um cartão', a specific verb+resource statement, and identifies the required credit_card_id. The tool's purpose is clear, but it does not explicitly differentiate itself from the closely related sibling organizze_get_credit_card_invoice, relying on the plural 'faturas' and the tool name to make that distinction.

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 a clear prerequisite ('Informe credit_card_id') and highlights bulk support via credit_card_ids, so the agent knows how to invoke it. However, it does not explain when to choose this tool over the singular invoice sibling or give explicit when-not-to-use 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?

The description adds meaningful behavioral nuance beyond the readOnly/idempotent annotations by explaining that totals use cash basis while top expenses use per-transaction basis and include credit card entries, warning that they do not sum consistently. This helps the agent interpret returned numbers correctly.

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 compact sentences deliver the essential purpose and a critical data caveat with no filler. The main content is front-loaded and every clause adds value.

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 should clarify return shape and period semantics, but it only lists high-level components. The missing parameter guidance and lack of differentiation from siblings leave an agent under-equipped to invoke the tool correctly for a specific period request.

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 for the four undocumented parameters. It only mentions 'período' generically and does not explain how year/month or start_date/end_date should be used, which formats are expected, or whether they are alternative or complementary ways to define the period.

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 states that the tool provides a financial summary for a period, including revenues, expenses, comparison, and top spending. This gives a specific resource and scope, though it does not explicitly distinguish itself from similar sibling report tools like get_income_vs_expenses or get_monthly_overview.

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 phrase 'do período' implies the tool is used when a consolidated financial summary for a time range is needed. However, it offers no explicit guidance about when to prefer this tool over the many other get_* report siblings, and no exclusions or alternatives are mentioned.

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 description adds significant behavioral detail beyond the readOnly/idempotent annotations: it is cash-basis per account, excludes individual card purchases (only invoice payments), defaults to the current month, and supports batched execution. These are non-obvious nuances that materially affect how an agent interprets results.

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 compact, with the core purpose front-loaded, followed by the key cash-basis limitation and bulk support note. Every sentence adds useful information and there is no filler or repetition of structured metadata.

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?

The description covers the essential operational details: purpose, account filtering, default period, cash-basis behavior, and batch support. However, there is no output schema and the description does not describe the report's return format or the valid values for periodicity, which are meaningful gaps for a tool with five optional parameters.

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?

With 0% schema description coverage, the description must carry parameter documentation. It explains account_id and account_ids well, and indirectly covers start_date/end_date via 'período' and 'mês atual', but it leaves periodicity and the exact date format unspecified. It partially compensates for the schema gap but not completely.

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 states it is a report of income vs expenses (entradas vs saídas) by period in cashflow mode, which names a specific verb and resource. It is clear and distinguishable from sibling report tools by its cash-basis focus, though it does not explicitly name or contrast any sibling tool.

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 gives useful parameter-level guidance: use account_id to filter one account, defaults to the current month, and supports account_ids for batch execution. However, it does not explicitly state when to prefer this tool over alternative report tools or when not to use it, so the usage guidance is implied rather than explicit.

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 this a read-only, idempotent, non-destructive operation, so the bar is lower. The description adds useful behavioral context: the output is a matrix with totals, values match get_credit_card_invoices, and the default is the current year for all cards.

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 compact and well-structured: what the tool returns, when to use it, and its default behavior. There is no redundant wording or repetition of the 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?

For a read-only aggregation tool with zero required parameters, the description covers the core needs: output shape, relationship to related values, intended use, and defaults. It does not go into date formats or edge cases, but the provided context is reasonably complete given the annotations and optional parameters.

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. It conveys that cards default to all cards and the date range defaults to the current year, but it does not explain the expected date format or how card identifiers are specified. This is enough for the safe default call but insufficient for custom filters.

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 states that the tool produces an invoice matrix organized by month and credit card, including per-month, per-card, and overall totals. It also references get_credit_card_invoices to clarify the underlying values, distinguishing this aggregation view from other invoice tools.

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 explicitly tells the agent to use this tool when the user asks for invoices across multiple cards and/or months, rather than summing manually. It gives a clear usage context but does not explicitly state when to prefer the sibling get_credit_card_invoices for a single card or month.

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 establish the read-only, idempotent, non-destructive nature. The description adds behavioral value by specifying that results are the most recently imported transactions and by disclosing pagination behavior via page/per_page with default 50 and max 100. No contradiction with annotations.

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 short sentences each carry meaningful information: scope, intended use case, and pagination rule. There is no filler or redundancy, and the most important scoping information is front-loaded.

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 simple read-only paginated list, the description provides the core selection criteria, a concrete use case, and pagination details. With no output schema, slightly more detail about the returned transaction fields would help, but the essential invocation context is present.

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?

With 0% schema description coverage, the description partially compensates by explaining page/per_page and their default/max values. However, the schema also includes a 'limit' parameter whose role is never clarified, leaving a gap in parameter understanding.

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 identifies the resource — most recently imported transactions via Open Finance — and its scope (connected accounts/cards). It is distinguishable from sibling transaction tools through the 'via Open Finance' and 'recém-importados' framing, though it does not explicitly name alternatives or state what it is not.

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?

It explicitly says 'Use para lançamentos novos/recém-importados', giving a direct trigger condition for when the agent should select this tool. It does not contrast with organizze_list_transactions or organizze_search_transactions, so exclusion guidance is absent, but the intended use case is clear.

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 read-only, idempotent, and non-destructive behavior. The description adds meaningful semantic caveats: totals are cash basis, top_expense_categories are per-transaction and must not be added to totals.expenses. This is valuable behavioral nuance beyond what annotations provide, though it omits auth or rate-limit context.

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 dense, front-loaded sentences with no filler. Every clause contributes either scope, content, default behavior, or a critical semantic warning, making it highly efficient.

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, the description does well by enumerating the main result components and exposing a non-obvious aggregation mismatch. It could specify exact response key names or formatting details, but the essential information needed to call and interpret the tool is present.

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 for the two parameters. It only mentions that the default is the current month, leaving the meaning of year and month to be inferred from their names and context. This is adequate but not fully explicit about format or valid ranges.

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 states a specific purpose: a single-call monthly overview with a concrete list of metrics (revenues, expenses, balance, top expense categories, limits status, and next-7-day bills). This content list effectively differentiates it from the many sibling read-only tools even without naming them.

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 implies when to use the tool through 'Visão geral do mês em uma só chamada' and the listed contents, but it does not explicitly state when to prefer this over similar siblings like get_financial_summary or get_cashflow_forecast, nor does it mention exclusions. Usage context is clear but mostly left to inference.

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, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the result is cached for approximately 5 minutes, and the status can be scoped by institution. This helps the agent reason about freshness and optional filtering.

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 three short sentences with no filler. The main purpose is front-loaded, followed by the intended use case and the caching caveat. Every sentence contributes useful information.

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 simple read-only status tool with one optional parameter and no output schema, the description covers the core what, when, and caching behavior. It could also describe the possible status values or how to reliably specify a bank, but those are not essential for selecting and invoking the 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 schema has one optional parameter with zero description coverage. The description compensates by saying the status is 'opcionalmente por banco', which clarifies that the institution parameter is optional and filters by bank. However, it does not specify the expected format or accepted values for the institution parameter.

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 tool as fetching live status of the Open Finance aggregator (Belvo), optionally filtered by bank. This is a specific verb-resource combination that distinguishes it from the many other organizze_get_* tools. The optional per-bank scope is stated upfront.

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 explicitly states when to use the tool: to determine whether 'the bank is not updating' is due to an upstream instability. This is clear, actionable guidance. It does not explicitly mention alternatives or when not to use it, but no closely competing sibling exists.

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?

As anotações já indicam que a operação é somente leitura, idempotente e não destrutiva. A descrição acrescenta contexto comportamental relevante ao expor o período padrão (mês atual) e o conteúdo do relatório, com percentuais de despesas e receitas. Isso vai além do que as anotações já cobrem, embora não detalhe a estrutura exata da saída.

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 descrição é compacta, com a informação principal no início, e a orientação de uso na segunda frase. Não há excessos ou repetições; cada frase contribui com algo útil.

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?

A ferramenta tem quatro parâmetros opcionais, nenhum obrigatório, e não possui esquema de saída. A descrição cobre o propósito, o período padrão e uma ideia do conteúdo, mas não explica tag_name_prefix e não descreve suficientemente o formato do retorno para o agente entender completamente o resultado sem inferência. Isso deixa lacunas importantes para uma chamada confiável.

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?

Com cobertura do esquema em 0%, a descrição precisa compensar. Ela explica o papel de start_date e end_date e o comportamento padrão do período, mas não fornece significado para tag_name nem para tag_name_prefix. A descrição adiciona valor para metade dos parâmetros, mas deixa lacunas para as demais.

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?

A descrição afirma com precisão o que a ferramenta faz: um relatório de transações agrupadas por tag, incluindo despesas, receitas e percentuais. Isso diferencia de ferramentas similares como organizze_get_categories_report, que agrupa por categorias, e de outras ferramentas de relatório no conjunto de irmanãs.

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?

A descrição fornece orientação clara de uso: para projetos ou históricos longos, recomenda informar start_date e end_date amplos, revelando que o padrão é apenas o mês atual. Não há, porém, orientação explícita sobre quando usar esta ferramenta em vez das alternativas, nem exclusões de cenários.

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 establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the batch-execution behavior via transaction_ids, which is useful, but it does not disclose error behavior, response details, or any rate-limit concerns.

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 with no filler. The core operation is front-loaded, and the bulk-support note is placed second without unnecessary elaboration.

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 simple read-only lookup tool with annotations covering safety, the description is mostly complete: it states the resource, the valid lookup modes, and bulk capability. It could be more complete with an explicit required-parameter note or a pointer to list/search siblings, but nothing critical is missing for basic invocation.

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 does map the three parameters: transaction_id ('id'), transaction_uuid ('uuid'), and transaction_ids ('bulk support'). However, it does not explain precedence, mutual exclusivity, or whether one identifier is required.

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 a specific verb ('get') and resource ('transaction'), and clearly identifies the lookup keys: id or uuid. It distinguishes itself from list/search siblings by targeting a single transaction or a batch by identifiers, though it does not explicitly name a contrasting sibling.

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 bulk-support sentence implies when to use transaction_ids instead of a single id, which gives some usage direction. However, it does not explicitly say when to prefer this tool over organizze_list_transactions or organizze_search_transactions, leaving the routing to inference.

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, and destructiveHint, so safety is covered. The description adds meaningful behavior beyond annotations: it specifies that only unpaid transactions and credit card invoices due in the window are returned, and states the default period of 7 days.

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 compact, front-loaded with the core purpose, and includes both a natural language question and the default behavior. Every piece of text adds value without wasted wording.

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 simple read-only listing tool, the description conveys the main behavior and default window, and the annotations cover safety. However, the start_date parameter is not explained and there is no output schema, so the description is not fully self-sufficient for correct invocation.

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 for parameter meaning. It only clarifies the default of '7 dias' for the days window, but says nothing about start_date, its format, or how it interacts with the days parameter. This leaves a material parameter undocumented.

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 tool's purpose: returning upcoming bills, specifically unpaid entries and credit card invoices due within a window. The embedded question 'o que vence essa semana?' makes the use case immediately understandable and helps distinguish it from broader sibling tools like list_transactions or get_credit_card_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 description gives clear usage context by defining the tool as answering 'what is due this week?' and notes the default 7-day window. It does not name alternatives or state when not to use it, but it is sufficient for an agent to infer typical use.

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 are all false, so the description carries the burden of explaining the operation; it does say this informs an automatic payment and supports bulk execution. However, it does not disclose side effects, whether it requires Open Finance consent, reversibility, or partial-failure behavior in bulk mode, leaving the behavioral profile incomplete.

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 front-load the main purpose and immediately add the bulk support detail with an exact parameter name. There is no filler, repetition, or unnecessary context.

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 5 undocumented parameters, no output schema, and no sibling differentiation, the description gives only a high-level action plus one bulk hint. An agent would need additional inference or documentation to call it correctly, especially because so many parameters are undefined.

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 schema has no parameter descriptions and 0% coverage, so the description needs to compensate. It only clarifies that invoice_date_or_ids is used for batch execution; it does not explain the required credit_card, the meaning of date, observation, or when to use singular invoice_date_or_id vs plural invoice_date_or_ids.

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 action — informing payment of a credit-card invoice — and adds the differentiator 'automatic (Open Finance)', which helps separate it from manual register/uninform siblings. It still does not explicitly contrast itself with those sibling tools, so it stops short of 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 phrase 'automatic (Open Finance)' implies when this tool should be used: for automatic card invoice payments via Open Finance. The bulk note also gives a practical usage condition, but there is no explicit when-not-to-use guidance or comparison with organizze_register_invoice_payment / organizze_uninform_invoice_payment.

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 disclose readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only that the result includes ids, which is a minor behavioral detail; it does not describe pagination, ordering, or response fields, but for a zero-parameter read-only list operation this is acceptable.

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 that front-loads the action and resource with no filler. Every word adds information ('com ids' is a useful output hint).

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 parameters, read-only annotations, and no output schema, the description is nearly sufficient: it tells the agent exactly what the call returns (user accounts with ids). It could be slightly more complete by naming the alternative detailed-account tool or noting response fields, but nothing needed to invoke safely 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 has zero parameters and the schema is empty, so there are no parameter semantics for the description to clarify. Baseline 4 applies because the agent cannot err in supplying arguments.

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 ('Lista' / lists), a specific resource ('contas do usuário' / user's accounts), and a concrete output detail ('com ids'). This clearly distinguishes it from the many sibling list_* tools such as list_transactions or list_credit_cards, since accounts are a distinct resource.

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 is given on when to prefer this tool over alternatives like organizze_get_account_context, organizze_get_balances, or organizze_create_account. The description only states what it does, leaving the selection decision to inference.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the scoping behavior of year/month filtering, but does not disclose return format, default behavior when no parameters are provided, or any grouping details.

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 efficient sentence: it states the operation and then the optional scoping parameters. Every word contributes; there is no repetition or 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 simple read-only list tool the description is mostly adequate, but with no output schema it does not mention what the returned data looks like or how the optional year/month parameters affect results when combined or absent. It is usable but leaves an agent to infer expected response structure.

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 carry parameter meaning. It does say year and/or month are used for 'escopo' (scope), giving basic semantics, but it omits expected formats, ranges, or behavior when both are omitted. This is partial compensation only.

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 clear verb and resource: 'Lista limites de gastos por categoria' (lists spending limits by category). This distinguishes it from budget mutation tools like create/update/delete_budget, though it does not explicitly name alternatives.

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 only usage guidance is 'Passe year e/ou month para escopo,' which explains optional parameters but not when to choose this tool over siblings such as organizze_get_budget_summary or organizze_clone_budgets. There is no when-to-use or when-not-to-use 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds only the semantic context that categories are used for classifying transactions, but it does not describe return format, ordering, pagination, or any other behavioral details. This is acceptable for a read-only listing tool but adds no significant behavioral transparency beyond the annotations.

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 concise sentence in Portuguese that clearly states the tool's purpose. It contains no filler, repeats no schema information, and is front-loaded with the action and resource.

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 simple, parameterless, read-only listing tool, the description is mostly complete: it tells the agent what resource is returned. However, there is no output schema and no mention of what fields or format the returned categories will have. This is a minor gap given the tool's low complexity.

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 has zero parameters and the schema is empty, so parameter documentation is unnecessary. The schema description coverage is 100%, and the description does not need to compensate for missing parameter information. Baseline 4 is appropriate for a parameterless tool.

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 ('Lista' = lists) and a specific resource: categories used to classify transactions. It clearly identifies the tool's purpose and is distinct from sibling list tools for accounts, budgets, transactions, etc., though it does not explicitly name any sibling to differentiate from.

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 is provided about when to use this tool versus alternatives such as organizze_create_category, organizze_update_category, organizze_get_categories_report, or organizze_suggest_categories. The intended use is only implied by the tool's name and description, with no explicit context 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scoping ('do usuário') and the returned fields (ids and limits), but does not disclose any additional behavioral traits such as pagination, ordering, or whether inactive cards are included. This is acceptable for a simple read-only list, but adds only modest extra context.

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, compact sentence in Portuguese that front-loads the action and resource, followed by the relevant output fields. Every word earns its place and there is no redundancy or 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?

Given the tool's low complexity (no parameters, no output schema, no nested objects) and strong annotations, the description is largely complete. It states what the tool returns (ids and limits) and the scope (user's cards). Minor omissions like pagination or sorting are not critical for this kind of list operation, so a slight deduction is appropriate.

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 has zero parameters and schema description coverage is 100%. With no parameters, the description has no obligation to explain parameter semantics, and the baseline of 4 applies. It correctly omits any parameter-related information.

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 'Lists the user's credit cards with ids and limits' uses a specific verb (list), a specific resource (credit cards), and states the output fields (ids and limits). This clearly distinguishes it from sibling list tools like organizze_list_accounts and from credit-card-specific operations like create/update/credit card or get_invoice.

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 no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or conditions under which a different listing or credit-card tool should be chosen. The usage context is only implied by the verb and resource.

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=true, idempotentHint=true, and destructiveHint=false. The description adds useful context about the institution_id mapping and query filtering, but it does not disclose pagination, result shape, or matching semantics. The safety profile is covered by annotations, so this is adequate but not rich.

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 compact and front-loaded: it states the purpose, the key slug concept, and the filtering usage in two sentences with no unnecessary words.

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 simple read-only list tool with optional parameters, the description is largely complete: it explains why the catalog matters, how the id is used, and how to filter. The only meaningful gap is the behavior/meaning of limit.

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 for missing parameter documentation. It explains query as a name filter, but limit is entirely undocumented, leaving one of two parameters without semantic guidance.

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: a catalog of financial institutions with the id (slug) used as institution_id. This clearly distinguishes it from sibling list tools such as organizze_list_accounts, organizze_list_categories, and organizze_list_credit_cards.

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 conveys when to use the tool: to obtain the institution id needed when creating or editing accounts and cards. It also gives a concrete filtering instruction with query. It does not explicitly mention alternatives, but the intended context is clear.

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=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond annotations: only manual recurrences are returned, Open Finance connections yield empty results, and installments are excluded. It does not cover pagination or ordering, but that is a minor gap for a zero-parameter list tool.

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 compact and front-loaded: it states the main purpose and examples first, then adds scope limitations and sibling alternatives. Every sentence earns its place, and the exclusions are stated crisply.

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 zero-parameter read-only list tool with no output schema, the description is complete: it states what is returned, what is not returned, the Open Finance empty-result behavior, and the sibling tools to use instead. An agent has enough information to select and invoke 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?

The tool has zero parameters and schema description coverage is 100%, so there is no parameter documentation burden. The description instead clarifies what the returned list represents, which is appropriate and useful.

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 verb and resource: lists registered recurring/infinite transactions (rent, subscriptions, salary) with periodicity, value, and next occurrence. It clearly differentiates the tool from siblings by explicitly excluding installments and pointing to find_subscriptions and find_installments.

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 gives explicit when-to-use guidance: use it for manually registered recurring accounts/cards, expect empty results for Open Finance-connected accounts, and use find_subscriptions for subscriptions and find_installments for installments. This directly routes the agent to the correct sibling tools.

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?

Beyond the read-only/idempotent annotations, it discloses that Open Finance raw details are omitted, that cashflow mode hides paid credit-card invoices and individual card expenses, that truncated pages must not be summed, and exactly how 'paid' should be interpreted for manual vs automatic accounts. This is rich behavioral disclosure.

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?

Long but well organized with uppercase section labels (PAGINAÇÃO, TOTAIS, LIMITE, INTERPRETAÇÃO DO STATUS) and every block carries a distinct operational warning. The purpose statement is front-loaded before advanced nuances.

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 complex 13-parameter tool with no output schema, it covers pagination, totals semantics, mode-specific visibility, limit guidance, paid/pending interpretation, and bulk support. Minor gaps like order_by values and exact response shape are non-critical to calling 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?

With 0% schema description coverage, the description compensates for many parameters: page/per_page caps, list_mode values with default and auto-switch via category_id, and bulk account_ids/credit_card_ids/category_ids. However, order_by and installments_only are left unexplained, and singular vs bulk id parameters are only implicitly covered.

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?

Opens with a specific verb and resource ('Lista transações do usuário no período selecionado') and immediately scopes pagination with a page size cap. It also contrasts with get_transaction for full records and with reporting tools, so an agent can distinguish list from detail/report operations.

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 tells when to choose all_transactions vs cashflow, when to use category_id, and when to prefer get_transaction or get_categories_report/transactions_list_results. It also instructs to narrow filters when truncated or when the period is too large, giving strong routing 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?

Annotations already provide readOnly/idempotent/non-destructive hints. The description adds value by disclosing pagination behavior, date format, and batch execution via account_ids, which annotations do not convey. It does not contradict the annotations.

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 short, front-loaded sentences cover purpose, pagination, date format, and bulk support with no filler. Every sentence 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?

For a simple read-only list operation with no required parameters and no output schema, the description covers the essential invocation details: pagination, date format, and bulk filtering. Minor gaps remain around the singular account_id filter and response shape, but these do not prevent correct selection or invocation.

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?

With 0% schema description coverage, the description must carry parameter meaning. It clarifies page/per_page as pagination, date strings as YYYY-MM-DD, and account_ids as a bulk batched input, but it leaves account_id, start_date, and end_date semantics partly to inference and does not explain defaults or mutual exclusivity.

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 action ('Lista transferências entre contas') and resource (transfers between accounts), with pagination detail. It is clear but does not explicitly name or differentiate sibling listing tools such as organizze_list_transactions, so it stops short of full sibling differentiation.

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 usage context is implied: use this tool when listing transfers between accounts, with page/per_page and date filters. It gives practical details (bulk account_ids, date format) but does not state when to prefer this over alternatives like organizze_list_transactions or organizze_create_transfer, nor any 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?

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false) and the description does not contradict them. The description adds meaningful behavioral context beyond annotations: it is a precursor/sequencing tool that must be invoked before responding, and it documents what each loaded skill covers. No contradiction.

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?

Purpose and usage timing are front-loaded in the first sentence, then the 15-topic catalog follows. The catalog is long but every entry maps 1:1 to an enum value and earns its place by adding routing detail; however, some bullets restate their key (e.g., 'credit_card_spending: Análise de gastos no cartão de crédito') and could be trimmed slightly.

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 router with no output schema and zero nested objects, the routing logic is exhaustively specified — the agent knows exactly when to call and which skill to request. The main gap is not describing what the tool returns or how the loaded skill modifies subsequent behavior, beyond the implied 'use it before answering' instruction.

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% and the sole parameter skill_name is a bare 15-value enum, so the description carries the documentation burden. It compensates strongly by explaining the semantic of every enum value (e.g., 'invoice_payments: Pagamento de fatura de cartão MANUAL: register_invoice_payment — nunca create_transaction para pagar fatura' teaches the agent a rule it must follow). The mapping is implicit (bullet names match enum values exactly) rather than explicitly stating that skill_name takes these values, which prevents a 5.

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 ('Carrega' — loads) and resource (a detailed usage guide/skill about an Organizze topic). It is unambiguous and clearly distinct from the 65 sibling tools, which are all operational (create/list/delete/get); this is the only meta-tool that loads guidance rather than performing a domain action.

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 instructs 'Chame ANTES de responder quando a conversa tocar um destes temas' (call BEFORE answering when the conversation touches one of these topics), giving precise timing and triggering conditions. The 15-item topic catalog provides detailed routing criteria for each skill, telling the agent exactly which skill to load in which situation.

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 are minimal (readOnlyHint=false, idempotentHint=false, destructiveHint=false) and consistent with the description, so there is no contradiction. The description adds substantial behavioral context beyond those hints: the 100-item cap, single-call execution with no interactive confirmation, the mandatory uniqueness/dedupe constraint, and the redirect behavior triggered by attachment fingerprints on canonical imports.

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?

Purpose and scope are front-loaded, and every clause earns its place: batch limit, alternative tool, dedupe rule, exclusion case with error code, naming preference, and execution model. It is dense but contains no filler or 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 complex batch tool with no output schema and 0% schema coverage, the description covers the cap, dedupe, exclusions, and execution model — most of what an agent needs to call it. The notable gaps are the unexplained idempotency_key parameter and the lack of any statement about return values or partial-failure behavior for individual rows.

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 carries the full burden, and it does add real meaning: the uniqueness constraint on description+amount+date+account, the preference for account/category NAMES, and the 100-item array cap. However, it leaves idempotency_key and several item fields (times, periodicity, recurring, observation) without any semantic guidance, so the compensation is strong but incomplete.

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 opens with a precise verb-resource-scope statement: 'Cria VÁRIAS transações em lote (máx. 100) a partir de uma lista de objetos' — batch-creating transactions from an object list with a hard cap. It explicitly differentiates from the sibling organizze_create_transaction by instructing the agent to use this instead of repeated single calls, so there is no ambiguity about which sibling to select.

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 guidance is explicit and bidirectional: use it instead of repeated create_transaction, and do NOT use it for CSV/OFX canonical-snapshot imports, naming the exact redirection path (plan_tabular_import/apply_tabular_import with error_code redirect_to_tabular) and the MCP fallback behavior. It also states a payload precondition (dedupe before sending). No inference is required.

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 description usefully discloses destructive behavior, auto-transaction handling, and recurring-transaction behavior. However, it explicitly says 'Destrutivo' while annotations set destructiveHint=false. This is a direct contradiction, which per the rubric forces a score of 1.

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 short Portuguese sentences with no filler: the action and limit come first, followed by the ID-provenance warning and behavioral notes. Every sentence 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?

For a destructive bulk operation with no output schema, the description covers the essential facts: batch limit, ID provenance, behavior for automatic and recurring transactions, and destructiveness. It does not mention how to split batches over 500 or explicitly route single deletions to organizze_delete_transaction, but those are minor omissions.

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 does explain that the parameter is a list of ids/uuids with a 500-item limit and warns that IDs must come from prior searches. But it doesn't clarify whether each array item needs transaction_id, transaction_uid, or either one, or how the two properties relate. This leaves a significant semantic 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?

The description starts with 'Exclui VÁRIAS transações por lista de ids/uuids,' clearly identifying a bulk delete operation on transactions. This distinguishes it from the singular delete_transaction and from mass create/update siblings. The 500-item cap and ID-source requirement further sharpen the purpose.

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?

Gives explicit usage constraints: IDs must come from a recent list/search/find_duplicates/get_transaction and must never be invented. It also states behavioral limits (auto igored, recurring delete only current occurrence). However, it doesn't explicitly point to the single-delete alternative or say when not to use this tool, so it falls just short of a 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?

As anotações apenas indicam readOnlyHint=false; a descrição adiciona comportamentos materiais: atômicidade com rollback total se uma operação falhar, limite de 100 ops, resolução por nome em vez de IDs e a inexistência de delete. Isso vai além das anotações e fornece um contrato comportamental útil. Não detalha o formato de resposta ou erros, mas o núcleo comportamental é transparente.

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 descrição é compacta, com três frases que colocam as restrições mais importantes no início (atômico, máx. 100), seguidas da lista de operações e da regra de resolução por nome. Não há preenchimento inútil; cada frase contribui.

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?

Para uma ferramenta complexa de lote sem descriptions de parâmetros no schema e sem output schema, a descrição cobre as regras centrais (atomicidade, limite, operações, sem delete), mas deixa gaps: não explica o formato completo de cada item de operations nem o comportamento de resposta/erro além do rollback. É suficiente para um entendimento geral, mas não completamente adequada para uso sem ambiguidades.

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?

A cobertura do schema é 0%, então a descrição precisaria compensar explicando os parâmetros dentro de operations. Ela explica os tipos de op (create, rename, move, archive, unarchive), o significado de parent '0' e a resolução por nome, mas não mapeia campos como name, category, color, kind e group_id para as operações específicas. Um agente pode não saber como codificar corretamente o alvo de um rename/move/archive ou quais campos são obrigatórios em cada op.

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?

A descrição identifica claramente a ação (aplicar várias mudanças na árvore de categorias), o recurso (árvore de categorias) e as restrições principais (atômico, máx. 100 ops, sem delete). Diferencia-se bem dos irmãos como organizze_create_category, organizze_update_category e organizze_delete_category ao especificar operações em lote e a regra 'não há delete—use archive'.

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?

O contexto de uso é claro: ferramenta para múltiplas mudanças atômicas na árvore de categorias. A orientação 'use archive' para o que seriá delete é um guia alternativo explícito, e 'Resolve por NOME' define um contrat de uso. Porém, não mencona explicitamente que para uma única criação/atualização deve-se usar organizze_create_category/organizze_update_category, então falta um pouco de orientação explícita sobre quando não usar esta ferramenta.

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 description adds important behavioral warnings: 'Irreversível em lote', max 200, and validation on empty/oversized result sets. However, annotations declare destructiveHint=false while the description calls the batch operation irreversible, which creates a safety-profile contradiction. Per the rubric, a contradiction with annotations forces a score of 1.

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 dense but efficient: every sentence carries actionable constraints, usage guidance, or alternatives. It is front-loaded with the core scope and limit, and the final bulk-support line adds needed specificity without padding.

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 20 parameters, no output schema, no required fields, and no parameter descriptions, this description is not complete enough for fully reliable invocation. It covers the high-level workflow and some error behavior, but it does not explain the meaning or accepted values of many parameters, nor what a successful response contains beyond the vague validation-error mention.

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% across 20 parameters, so the description must compensate. It adds useful rules: at least one filter and one update field, prefer new_category by name, and category_ids/account_ids/credit_card_ids enable batch execution. But most parameters, such as tag_action, paid_filter, description_find/replace, and new_tags, remain semantically undefined, leaving a substantial 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?

The description uses a specific verb and resource ('Atualiza VÁRIAS transações por FILTRO de busca') and immediately states the max scope (200), making it clear this is a bulk update tool. It also distinguishes itself from line-by-line siblings by naming update_transactions_categories/descriptions.

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?

It explicitly tells the agent when to prefer this tool ('quando a mesma alteração vale para todas as linhas'), when not to use it, and which alternatives to use ('Para mapa linha-a-linha use update_transactions_categories/descriptions'). It also instructs pre-validation with list_transactions/search_transactions and defines minimum inputs ('ao menos um filtro e um campo a alterar').

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 description discloses the key behavior: registering a payment as a transaction entry linked to an invoice, supporting only manual cards, and accepting bulk invoice_date_or_ids. It adds value beyond the annotations by explaining the manual/automatic distinction and the lookup requirement. It does not detail side effects like whether the payment is also marked as paid, but the provided context is solid.

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 compact and well-structured: it leads with the core purpose, then adds the alternative tool, then provides lookup guidance, and finally notes bulk support. Every sentence carries information with no redundancy.

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 the tool has no output schema and 7 parameters, the description offers enough context to invoke it correctly: required fields are identifiable, the linking parameter format is specified, and bulk support is mentioned. It does not describe the return value or error cases, but the essential invocation guidance is present.

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 carries the burden. It explains invoice_date_or_id format (id or YYYY-MM), mentions bulk invoice_date_or_ids, and advises using names for card/account fields. The obvious parameters (amount, date, observation) are self-explanatory, and the key linking parameter is well documented, though source_account and observation get only indirect coverage.

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 action ('Registra o pagamento de uma fatura de cartão MANUAL como lançamento') and clearly identifies the resource. It also distinguishes itself from the sibling tool inform_invoice_payment, which handles automatic cards, so an agent can immediately tell which tool to use.

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 context is explicit: manual card invoices should use this tool, automatic cards should use inform_invoice_payment. It also tells the agent to prefer card/account names, list invoices with get_credit_card_invoices, pass invoice_date_or_id (id or YYYY-MM), and never invent values. This is strong, actionable 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?

Annotations already declare readOnly=true, idempotent=true, and destructive=false. The description adds useful behavioral context: it performs approximate/fuzzy name resolution, returns multiple matches when ambiguous, and is meant as a safeguard before writes. This goes beyond what the annotations alone convey.

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 short sentences, each earning its place: one for the core purpose, one for when to use it, and one for ambiguity behavior. It is front-loaded with the most important information and contains no fluff.

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?

The description covers the tool's purpose, when to use it, and what happens on ambiguous input. Since there is no output schema, it also implies the return value is the real id/uuid. The only meaningful gap is explicit documentation of the `kind` parameter's allowed values and whether it is required, which is minor for a simple lookup 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%, so the description must compensate. It clearly explains the `name` parameter as the approximate name, but it does not explicitly describe the `kind` parameter's accepted values or optionality. The phrase 'conta, cartão ou categoria' hints at valid resource types but leaves the mapping to `kind` implicit.

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 a specific verb ('resolve') and states exactly what is resolved: approximate names to real ids/uuids for accounts, cards, or categories. It clearly differentiates itself from broader read-only tools by framing itself as a pre-write normalization step rather than a general list/search tool.

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 explicitly says to use this tool 'ANTES de uma escrita' (before a write) to avoid invented ids, which gives clear contextual usage. It does not name specific alternative tools or exclusion cases, but the guidance is strong enough for an agent to know when to invoke it.

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=true and destructiveHint=false. The description adds useful behavior beyond those: which fields are searched, pagination behavior, and the important default time window of 6 months. It does not contradict the annotations.

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 tight sentences: the first delivers the core search purpose and examples, the second covers pagination and the date default. There is no filler or 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?

With 9 parameters, no output schema, and 0% schema coverage, the description covers only the query and pagination basics. It omits the meaning of most filter parameters, does not describe the result shape, and gives no guidance on ordering or pagination limits. This is inadequate for the tool's complexity.

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 should compensate for the 9 parameters. It explains query, page, per_page, and hints at date behavior, but leaves end_date, start_date, tags_only, min_amount, max_amount, and activity_type undocumented. This is partial but insufficient compensation.

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: search transactions by text in description, observation, or tags, with concrete examples. This clearly differentiates it from broad listing tools like organizze_list_transactions and get_transaction.

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?

It gives clear operational guidance: pagination via page/per_page and a default 6-month window when no dates are supplied, plus concrete example queries. It does not explicitly state when not to use it or name alternatives, so it stops short of full exclusion 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?

The description explicitly claims 'Idempotente', but the annotations set idempotentHint to false. This is a direct contradiction. The additional behavioral notes about automatic transactions and bulk support are useful, but the contradiction forces a score of 1 per the rubric.

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 compact and front-loaded. Each sentence earns its place: the first defines the action, the second adds idempotency and the automatic-transaction limitation, and the third covers bulk support. No filler or redundant content.

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?

The description covers core behavior, manual-account scope, automatic-transaction behavior, idempotency, and bulk support. However, it leaves the identifier parameters and their relationship unclear, and there is no output-schema or result description to compensate. For a 4-parameter mutation tool, this is workable but has gaps.

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 does explain the paid parameter's true/false semantics and mentions transaction_ids for bulk execution, but it does not explain transaction_id, transaction_uuid, or clarify which identifier is required despite paid being the only required field.

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 action and resource: marking a transaction as paid/received (paid=true) or unpaid (paid=false) on a MANUAL account. It also provides a concrete user scenario ('já paguei o aluguel') and distinguishes the tool from generic update tools by limiting it to manual transactions.

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 clearly indicates when to use the tool: for manual-account transactions only, and it notes that automatic transactions are always paid, implying the tool is not meant for those. It does not name sibling alternatives explicitly, but the context gives a clear usage boundary.

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?

Beyond the annotations, the description reveals behavioral internals: suggestions are based on the user's prior edits, categorized history, and global patterns. It also discloses that each item returns confidence and semantic_strength, which helps the agent decide whether to apply or confirm.

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 dense sentences carry purpose, usage timing, and output semantics with no filler. Information is front-loaded and every phrase adds value.

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 simple one-parameter, read-only tool with no output schema, the description covers the main behavior, the workflow position, and the key returned fields. A more detailed output shape would be helpful, but the current text is sufficient for correct invocation and decision-making.

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 input schema has 0% description coverage, and the description does not explain items.activity_type or items.amount_in_cents or how they influence suggestions. It only implies support for one or more transaction descriptions, leaving the meaning of the optional fields to the raw schema property names.

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 opens with a specific verb and resource: it suggests categories for transaction descriptions, and it distinguishes itself from create/update/delete category tools by framing the action as a recommendation. The phrase 'Use ANTES de create_transaction' further clarifies its role in the workflow.

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 explicitly tells the agent to use this tool before create_transaction when classifying a batch of descriptions. It provides clear contextual timing, though it does not explicitly enumerate alternative tools or when not to use it.

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 read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond that: the default cash basis, the basis change when category_id is provided, the current-month default, and bulk execution support. This meaningfully helps the agent predict behavior, though response shape and error semantics are not disclosed.

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 compact and front-loaded with the tool's core purpose. Every sentence contributes either purpose, usage context, defaults, basis behavior, or bulk support. It is dense but not bloated.

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?

The description covers critical invocation context: default period, cash basis, basis switching, and bulk parameters. However, with no output schema and zero schema-level parameter descriptions, it omits output shape, list_mode semantics, and date/parameter formats, leaving meaningful ambiguity for an agent.

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 carries the burden of explaining parameters. It explains category_id's effect on basis and mentions account_ids/category_ids for bulk support, but it leaves start_date/end_date formatting, list_mode values, and the relationship between account_id and account_ids undocumented. This is insufficient for a tool with 7 parameters.

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 states that the tool returns financial totals for a period (revenues, expenses, result, balance, expected amounts) and positions it as a summary alternative to paginating through transactions. It does not explicitly name a sibling tool, so it stops short of full differentiation, but the purpose is unambiguous.