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

With no annotations, the description carries the transparency burden and it pays off by revealing type-dispatching behavior and product-specific results (balances/cards, credit dates, pension balances). It does not describe auth, errors, or response shape, but for a read-style account-detail call the disclosed behavior is meaningful and not merely a paraphrase of the name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler; the scope is front-loaded before the type-specific details and the source of the key parameter. The type-specific list is dense but each clause distinguishes a branch of behavior.

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 gives enough to call the tool for a chosen product: what it returns per type, that portalId comes from bg_list_accounts, and that it is a single-account full-detail retrieval. It is not a 5 because there is no output schema and the description omits any mention of response structure or the includeTransit behavior beyond what the schema already states.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both portalId and includeTransit. The description only restates the portalId source in the last sentence and adds no additional meaning for includeTransit, so it earns the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource ('one product') and the verb ('Full detail... dispatching on its type'), and enumerates type-specific return fields, so an agent can form a concrete model of the call. It does not explicitly differentiate from the sibling bg_get_pension even though pension is covered here, 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 instruction to get portalId from bg_list_accounts gives a clear prerequisite, and 'Full detail for one product' implies the main use case. However, it does not state when to prefer an alternative such as bg_get_pension, bg_list_accounts, or bg_list_transactions, nor any exclusions, leaving usage conditions mostly implied.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context beyond the schema: the result includes 'transaction counts and totals,' and omitting month/year returns the current period. It does not mention login prerequisites, error behavior, or response format, but for a read-only lookup this is a reasonable disclosure level.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no filler: the first states the purpose and contents, the second gives the key omission instruction, and the third clarifies the distinction from computed categorizations. Every sentence earns its place and the most important usage note 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 tool with no output schema and no annotations, the description covers purpose, result contents, current-period behavior, and the bank-vs-computed distinction. It lacks an explicit mention of the return structure or what happens with invalid inputs, but these are minor gaps given the schema already documents the portalId source.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the optional month/year semantics with 'Omit month/year for the current period,' which is not fully captured in the schema's simple field descriptions. This is a modest enhancement beyond the schema, not a substantial one.

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 verb and resource: retrieving credit card spending by category for a card statement period. It also distinguishes itself from computed alternatives by noting this is 'Banco General's own' categorization, separating it from sibling tools like bg_spending_summary.

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 an implicit usage context by contrasting with a computed categorization, suggesting when the bank's own breakdown is appropriate. However, it never explicitly names an alternative tool or states conditions like 'use X for computed categories,' so the guidance remains implied rather than direct.

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

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

With no annotations, the description carries the disclosure burden. It reveals what data is returned, including the history of past cutoff dates, and implies a read-only statement retrieval. It doesn't cover error cases or auth, but the core behavior is well 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?

Three compact sentences with no filler. The primary output is stated first, then parameter behavior, then the extra return value. 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 three-parameter tool with no output schema, the description names the key return fields and explains optional parameters. It doesn't specify exact response format or error behavior, but it provides enough for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the relationship between month/year and current versus past statements, and how cutoff-date history helps select another 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 identifies a specific resource ('credit card statement') and lists concrete contents: balance, minimum payment, cutoff/due dates, credit plans and rates. This distinguishes it from sibling tools that handle transactions, categories, or account details.

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 for when to pass month/year versus omit them, explicitly covering past and current statements. It doesn't name alternative tools for exclusions, but the usage guidance is unambiguous.

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

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

With no annotations, the description must carry behavioral disclosure itself. It does disclose the conditional statement behavior and enumerates statement components, but it does not describe response structure, edge cases, or what happens when only one of month/year is provided. Nothing contradicts the annotations because there are none.

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 sentence that front-loads the primary result, then adds the conditional statement clause and its components. Every clause contributes information, and there is no filler or redundant restatement.

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?

Without an output schema, the description reasonably explains the return content at a high level. However, it leaves ambiguity around partial month/year inputs and does not describe the response shape or behavior when only one of the two optional parameters is supplied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The schema already documents portalId as coming from bg_list_accounts and month/year as statement selectors; the description reinforces the conditionality but adds little semantic value beyond the schema.

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 specific resource (Pro-Futuro pension product) and the two kinds of data returned: balances/fund breakdown and an optional monthly statement. It is specific enough to set the tool apart from generic account tools like bg_get_account, 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 description gives a clear conditional usage rule: the monthly statement is included only when month and year are given. However, it does not state when to prefer this tool over bg_get_account, bg_list_accounts, or other siblings, and it offers no exclusion criteria.

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

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

With no annotations, the description carries the full burden. It discloses important behavioral traits: balances are as of lastSyncDate (not live), and it returns the portalId that other tools need. While it doesn't explicitly state read-only, the wording ('Lists') implies a non-mutating operation. The given caveat and dependency note add genuine value beyond the tool name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The primary purpose is front-loaded, examples of products are given in a parenthetical, and the critical caveat about data freshness is included without bloating. 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 zero-parameter, no-output-schema tool, the description is complete. It tells the agent what it returns (balances, portalId), why it matters (needed by other tools), and the freshness caveat. The 'Start here' guidance sets context for the overall workflow. Nothing needed for correct invocation 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, so schema coverage is 100% by default. The description doesn't need to elaborate on parameters, and it correctly omits any param-related discussion. Baseline 4 applies since there is nothing to clarify.

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 ('Lists') and resource ('every Banco General product on the dashboard'), enumerating the types (savings accounts, credit cards, Pro-Futuro pension). It clearly distinguishes from siblings like bg_get_account by implying a full list, and the phrase 'Start here' positions it as the entry point. No ambiguity about what the tool does.

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 'Start here', which is a clear directive on when to use this tool (as the first call). It also provides a caveat about data freshness ('not live'), which guides expected usage. However, it does not explicitly name alternatives or state when not to use it, leaving some inference to the agent.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It usefully exposes a key behavioral quirk: BG statement periods are not calendar months and run from previous cutoff dates. It does not mention return structure or pagination, but the core behavioral nuance is well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: the resource and scope, the period selection rule, and the critical statement-period nuance. It is front-loaded with the core purpose and wastes no 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 low-complexity read-only list tool, the description plus fully documented schema is sufficient to select and call the tool correctly. It covers period semantics and filtering behavior, though the lack of an output schema means return shape is not described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds value by explaining the combined behavior of omitting month/year and the relationship between clampToMonth and the calendar-month restriction, but it does not add syntax-level detail beyond the schema.

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 lists charges and payments on a credit card for a statement period, and it distinguishes statement periods from calendar months. However, it does not explicitly differentiate itself from sibling tools like bg_list_transactions or bg_search_transactions, so sibling differentiation is absent.

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 concrete invocation guidance: pass month/year for a specific period, omit both for the current period, and use clampToMonth to restrict to the calendar month. It does not mention when to prefer this tool over alternatives, but the usage 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?

There are no annotations, so the description carries the behavioral burden. It discloses two non-obvious traits: pagination is handled internally and dates are interpreted in Panama local time. It does not describe the return structure, but the list operation's read-only nature is clear from the wording.

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 tightly written sentences. Core scope and behavior come first, followed by the sibling redirect, with no redundant 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?

All invocation-critical details are present: single-account scope, date range, internal pagination, timezone handling, and the card-transactions alternative. Since there is no output schema, a note about the returned transaction shape would improve completeness, but this does not seriously hinder 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?

Schema description coverage is 100%, so the schema already documents all four parameters, including the Panama timezone and portalId provenance. The description only reinforces the account and date-range concepts without adding parameter-level detail, so the baseline score 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 states a specific verb and resource: listing transactions for one savings account over a date range. It clearly distinguishes itself from the card-transactions sibling, so an agent can tell what this tool does without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use bg_list_card_transactions instead for credit-card charges, and the savings-account/date-range wording defines when this tool is appropriate. The sibling routing is concrete and actionable.

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

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

No annotations are present, so the description carries the burden of behavioral disclosure. It reveals both possible response statuses and the follow-up branch, which is meaningful context beyond the bare action. It does not mention failure/error responses or side effects of the remember flag, but the core login behavior is transparent.

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 compact sentences, with the step context front-loaded before the success/OTP branch. Every sentence contributes useful information 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?

Since there is no output schema, the description properly supplies the key response shapes and the OTP branch instruction. It also anchors the tool in the 3-step login sequence. Minor omissions around error responses keep it from being 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?

The input schema already documents all four parameters, including the remember flag's Keychain behavior, so the baseline is 3. The description adds only that the security answer and password are what completes the login, without adding extra parameter-level meaning.

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 the specific action: complete the login with the security answer and password, and labels it as Step 2 of 3. This clearly distinguishes it from bg_login_start and bg_login_otp, so an agent can tell where it fits in the auth flow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says what to do when the response is otp_required: ask the user for the code and call bg_login_otp. This gives the agent a direct rule for choosing the correct next tool, with no ambiguity.

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?

There are no annotations, so the description carries the burden of behavioral disclosure. It usefully communicates sequencing and an OTP-required precondition, but it does not disclose success/failure behavior, whether the OTP is consumed, session effects, or expected outputs after submission.

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 conditional trigger is front-loaded, and every clause contributes actionable information without repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description clearly positions the tool within the login sequence but omits post-submission behavior and error handling. Without an output schema or annotations, an agent might not know what statuses to expect or how to react after sending the code.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds slight context by noting that loginId is the same one used in previous steps, but code is already described well in the schema. No major extra meaning is provided.

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 and resource: 'Submits the code Banco General sent to the user.' It also anchors the tool within the login flow as 'Step 3 of 3,' clearly distinguishing it from related login tools like bg_login_start and bg_login_answer.

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?

Provides an explicit trigger condition: 'only needed when bg_login_answer returned status "otp_required".' This tells an agent exactly when to invoke the tool and ties it to a prior step's output.

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

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

With no annotations, the description carries the full burden and does well: it reveals that login expires after 5 minutes if not completed, that the tool returns a security question, and that this is only the first step. It does not mention failure modes like invalid username, but the disclosed expiry and step sequencing provide meaningful behavioral 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?

Three sentences, all useful: the step number, the action and return value, the user relay instruction, and the expiry warning. The most important information is front-loaded and 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 one-parameter tool with no annotations and no output schema, the description explains the flow, the next step, and the time limit well. A minor gap is that it does not describe the exact shape or content of the returned security question, but 'returns the security question BG asks' is sufficient for an agent to act.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the single 'username' parameter already has a clear description in the schema. The tool description adds only that the username is submitted, which reinforces but does not expand on the schema's meaning. Baseline 3 is appropriate.

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 action ('submits the username') and a specific resource (Banco General login), plus the expected return ('the security question BG asks'). It explicitly identifies itself as 'Step 1 of 3' and names bg_login_answer as the continuation, which distinguishes it from sibling login 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 clear sequential guidance: submit the username, relay the returned question to the user, then call bg_login_answer. It does not explicitly state when not to use this tool versus alternatives, but the step-based flow and named next step make the intended usage unambiguous.

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

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

With no annotations provided, the description carries the full burden, and it does disclose the destructive side effects: it deletes stored session data and Keychain credentials, and closes an in-progress login. It could add idempotency or failure behavior (e.g., behavior when already logged out), but the key side effects are clearly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that names the primary effect first ('Deletes the stored session') and then the additional side effects. Every phrase earns its place; 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?

Given that this is a parameterless logout operation with no output schema, the description is sufficient for an agent to invoke it correctly: it identifies the action and the important side effects. There is no missing information that would affect how the tool is called.

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 coverage is nominally 100%, so there is nothing for the description to add about parameters. 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 clearly identifies the action ('Deletes', 'closes'), the resources affected (stored session, Keychain credentials, login in progress), and the overall purpose of logout. This distinguishes it from sibling tools like bg_session_status (which only checks state) and the various bg_login_* 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?

Usage is implied rather than explicitly stated: the description makes it obvious that this tool ends a banking session and aborts in-progress logins. However, it does not explicitly say when to use it versus checking session state with bg_session_status, nor does it mention any preconditions such as being logged in.

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

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

No annotations are present, so the description bears the behavioral burden. It reveals the operation is an aggregate read/search over every savings account and credit card, which is meaningful scope information. However, it doesn't mention ordering, pagination, response shape, or how limit/defaults behave beyond what the schema already says.

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 the core scope and filters front-loaded. Every clause earns its place; the examples are illustrative rather than redundant.

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 7-parameter search tool with no output schema and no annotations, the description is reasonably complete for selection and invocation: all parameters are documented in the schema, and the description clarifies aggregate scope. It could still be stronger by stating that results are a list of transactions and noting default result limits or ordering, but these gaps are minor.

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?

All seven parameters already have schema descriptions, so the baseline is 3. The description reinforces that 'query' filters by description text and 'minAmount'/'maxAmount' apply to amounts, and the examples may help an agent map natural-language requests to parameters, though it adds no syntax or constraints beyond the schema.

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: 'Searches every savings account and credit card at once over a date range.' It clearly distinguishes this aggregate tool from the per-account siblings by emphasizing all-accounts scope and optional filters.

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?

'Use this for questions like "how much did I spend at X" or "find that $250 charge in March"' gives concrete invocation triggers. It also contrasts with 'per-account tools one by one,' identifying the alternative class, though it doesn't name a specific sibling or state a hard when-not-to-use condition.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does explain the report contents (usable session, owner, freshness) but does not explicitly state that calling it is side-effect-free or describe what happens when no session exists. This is adequate for a simple status check 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?

Two concise sentences with no wasted words. The most important outcome—whether a usable session exists—is front-loaded, and the actionable guidance follows directly.

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 gives enough context for an agent to know when to call the tool and what kind of information to expect, even without an output schema. It could be more explicit about the exact return format, but the semantics are sufficiently clear for deciding the next step in a login flow.

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 there is nothing to document. The baseline of 4 applies because there are no parameter semantics to convey and the description does not need to compensate for any missing parameter details.

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 verb and resource: it reports whether a usable Banco General session exists, its owner, and freshness. This strongly distinguishes it from the login and account-list 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?

The description gives explicit when-to-use guidance: call this before asking the user for credentials, because they may already be logged in. It does not explicitly say when not to use it or name an alternative, but the unique purpose makes that less necessary.

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

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

With no annotations provided, the description carries the burden of behavior disclosure. It clearly says the tool aggregates across all accounts over a month or date range and returns a financial summary, which implies a read-only analytical operation. It doesn't explicitly state 'does not modify data' or discuss authorization, but the behavioral scope is reasonably transparent.

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 only two sentences, front-loads the core aggregation behavior, and includes a compact usage example at the end. Every phrase contributes meaning and there is no redundant 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?

Although there is no output schema, the description lists the key return components: total income, total spending, net, per-account breakdown, and largest transactions. The period-selection behavior is clarified between month and explicit date range, making the tool fully invocable without missing critical context.

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 already documents all four parameters with 100% coverage, so the description is not required to repeat parameter details. It does add the high-level notion of 'month (or an explicit date range)' and 'largest transactions', but these align with the schema rather than revealing new semantics. Baseline 3 is appropriate.

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 ('Aggregates') and resource ('every account'), and clearly enumerates the produced outputs: total income, total spending, net, per-account breakdown, and largest transactions. This makes it easy to distinguish from sibling transaction-listing and account-detail 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?

It gives an explicit usage cue: 'Use this for "how did I do this month"', which clearly frames when this summary tool is appropriate. It does not name specific alternatives or state when not to use it, so it stops short of a full when/when-not comparison.

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