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

The annotations already signal destructive and idempotent behavior, and the description adds substantial context beyond them: the exact file path (~/.creditkarma-mcp/session or CK_SESSION_PATH), in-memory credential clearing, no network contact, and preservation of synced transactions and host config values. This fully discloses 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 information-dense without redundancy: the primary action and file path come first, followed by the usage condition, then important exclusions. Every sentence adds operational value, and the caveats are separated clearly.

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 state-clearing destructive tool with no output schema, the description covers all an agent needs: exact target file, environment variable override, in-memory effect, local-only guarantee, and what is intentionally preserved. Nothing necessary for correct invocation or safe reasoning 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 coverage is 100%, so the schema carries no semantic burden. With no parameters to describe, the baseline of 4 applies; the description appropriately focuses on behavior instead of 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 uses a specific verb ('Forget') and a clear resource ('Credit Karma session on this machine'), then spells out the concrete mechanism: deleting the saved-session file and clearing in-memory credentials. It also distinguishes the tool from its sibling ck_set_session by explicitly naming the session file both tools write to.

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 states exactly when to use the tool: 'when the user stops using this server or wants their stored login removed.' It also clarifies boundaries by listing what is not affected (synced transactions, CK_COOKIES) and that it is local-only, preventing misuse as a remote logout.

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?

Discloses rich behavior beyond the annotations: staleness thresholds (7 days linked, 35 days credit report), recency of credit-report data (2–5 weeks, no last 4), sign convention (liabilities negative, matching transactions), available-credit formula, and the default hiding of duplicate rows. Annotations only cover the safety profile; the description carries the substantive domain rules.

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

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

A single dense paragraph that is front-loaded with what the tool returns before the qualification rules. Every sentence carries information, though the lack of any separation between return-shape and parameter/source guidance makes it slightly harder to scan.

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

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

With no output schema and no annotations covering return semantics, the description fully documents the payload: field set, source provenance, freshness/staleness, sign convention, and duplicate handling. Nothing an agent needs to interpret the results 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?

Schema coverage is 100%, so baseline is 3, but the description adds meaning: refresh is framed as 'fetch live first' on top of local data, and include_matched is tied to the matched_to field and the duplicate-hiding default. This enriches both parameters beyond their schema text.

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+resource (get account balances) and immediately enumerates the returned fields (institution, type, last 4, current balance, available credit, credit limit, as-of time). It also anchors itself against siblings by noting the data comes from the local database filled by ck_sync_transactions, so an agent can distinguish it from summary/transaction 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?

Gives clear operational context: pass refresh:true to fetch live first, and include_matched:true to surface credit-report duplicates. It explains the two source categories and their freshness, but never explicitly contrasts itself with siblings like ck_get_account_summary or ck_list_transactions, so there are no stated exclusions/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 establish readOnlyHint=true and openWorldHint=false, so the safety profile needs no restatement. The description adds the meaningful fact that results are aggregated per account into debit/credit/net figures rather than raw transactions. It omits any mention that the optional start_date/end_date bound the aggregation or what the default period is.

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 front-loaded sentence with zero filler, and the output shape (per-account debit/credit/net) leads immediately. It is appropriately sized for a two-optional-parameter read tool, though the terseness borders on under-specification rather than economy.

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 correctly takes on responsibility for conveying what comes back, and it does so at a high level. However, for an aggregation tool with date-range parameters it should say whether the range filters the aggregation and what happens when the range is omitted.

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% (both params documented as YYYY-MM-DD), so the schema carries parameter semantics and the baseline is 3. The description never mentions that these totals are date-filterable at all, adding no meaning 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?

Names a specific verb (Return) and a precisely scoped resource: per-account debit, credit, and net totals. This is clearer than a bare name restatement, but it never contrasts itself with close siblings such as ck_get_account_balances or ck_get_spending_by_category, so an agent must infer the distinction from the tool names alone.

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 when-to-use guidance at all: nothing says whether this is for reconciliation, reporting, or a date-bounded period, and no alternative (balances, spending-by-category, query_sql) is named or excluded. The agent is left to guess between several plausible 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds almost no behavioral context beyond the annotations — it doesn't define what 'recent' means (ordering field), whether results are paginated, or what happens at the default limit, so it stays at the low end against an already-light bar.

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

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

Two short sentences, zero filler, with the core action front-loaded and the sibling relationship stated second. Nothing to trim.

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

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

For a single-parameter read-only tool with no output schema, the description covers the essentials but leaves the notion of 'recent' undefined and says nothing about result ordering or shape. Adequate, but with clear gaps an agent must infer.

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% — the limit parameter is fully documented with default, range, and bounds. The description mentions 'N' but adds no syntax or format detail beyond the schema, so the baseline of 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 states a specific verb and resource (return the N most recent transactions) and explicitly relates it to the sibling ck_list_transactions as a shortcut. This lets an agent distinguish it from the general listing tool without opening either schema, though it doesn't clarify ordering or filtering differences.

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?

Calling it a 'convenience shortcut for ck_list_transactions' implies when to reach for it (quick recent-item retrieval), but it never states when to prefer the full tool instead or what the shortcut omits (filters, date ranges, pagination). 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description does add one meaningful behavioral constraint not in the structured fields: only debit transactions are aggregated, excluding credits and transfers. It says nothing about date-range defaults, session requirements, or what happens when parameters are omitted.

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 with the aggregation and the grouping dimension front-loaded. Zero filler and nothing redundant with 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?

With no output schema, the description carries some burden for explaining the return shape; it states that results are grouped by category with totals, which is helpful, but says nothing about ordering, category source, or how empty/no-data ranges are represented. Adequate but with a clear gap for an aggregation 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 100% and all three parameters (account, start_date, end_date) carry their own descriptions, so the schema does the heavy lifting. The description adds no format, default, or interaction detail beyond what the schema already provides, which is the expected baseline here.

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 ('Group ... and return totals') and resource ('debit transactions by category'), which an agent can distinguish from the sibling ck_get_spending_by_merchant by the grouping dimension. It stops short of naming that sibling explicitly, so differentiation is inferential rather than stated.

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 versus ck_get_spending_by_merchant, ck_list_transactions, or ck_query_sql, and no mention of required context (e.g., setting a session first). Usage must be inferred entirely from the name and one-line purpose.

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 openWorldHint=false, covering the safety profile, so the bar is lower. The description usefully clarifies the ranking semantics ('top' by total debit spend), but says nothing about what happens when date ranges are omitted, tie-breaking, or result shape.

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

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

A single sentence with no filler and the key qualifier ('by total debit spend') front-loaded. It is efficient, though arguably terse for a four-parameter aggregation tool that needs date-scope clarification.

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

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

With no output schema and no annotations about returns, the description leaves the date-range default behavior unspecified — does omitting start_date/end_date mean all-time or a default period? That is a meaningful gap for a spending aggregation, though the core purpose is conveyed.

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%, with limit, category, start_date and end_date all documented in the schema, so the schema carries the parameter burden. The description adds no parameter detail (e.g., that start/end dates are optional or how 'top' ordering interacts with limit), so the baseline 3 applies.

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

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

States a specific verb ('Return') and a well-defined resource ('top merchants by total debit spend'), including the aggregation dimension (debit spend). It implicitly distinguishes itself from ck_get_spending_by_category by grouping on merchants rather than categories, but it never names or explicitly contrasts 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?

There is no guidance on when to pick this over ck_get_spending_by_category or ck_list_transactions, and no prerequisites or exclusions are stated. The agent must infer the use case from the tool name alone.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered. The description still adds real value beyond them: the guarantee that the credential itself is never returned, and a taxonomy of failure modes ('no credential' vs 'credential rejected' vs upstream problem) plus the steps/failed_step breakdown. Some of that last detail is return-shape information an output schema would normally carry.

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 the ordering of the probe are front-loaded, and the when-to-use clause lands at the end. It is dense but slightly long, with the em-dash clause packing return details that could be tighter.

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 must carry the return contract, and it does: credential source, acceptance, round-trip time, a plain-English hint, and the steps/failed_step fields. Nothing an agent needs to interpret the result 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?

Zero-parameter tool, so the baseline is 4. The description correctly implies no inputs are needed to run the probe and describes only the outputs it produces.

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 sequence and resource: resolve the credential the way real tools do, then make one authenticated request to creditkarma.com. This clearly distinguishes it from the read/data siblings (ck_list_transactions, ck_get_account_summary) as a diagnostic probe rather than a data fetch.

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?

Explicit trigger given: 'Call this when a real tool fails and you want to know which hop broke.' It also names the failure-localization mechanism (steps, failed_step) that selects this tool over simply retrying a sibling.

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 openWorldHint=false, so the safety profile is covered. The description's only added behavior is 'Paginated', which is already implied by the limit/offset parameters in the schema; it omits default page size, total-count behavior, and result ordering.

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

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

Two short sentences, purpose front-loaded, zero filler. Nothing could be trimmed without losing 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 ten-parameter list tool with no output schema, the description is too thin: it never describes the returned transaction shape, sort order, or whether pagination metadata is returned. Combined with no sibling routing, an agent is left to infer the important behavior from the schema alone.

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 itself documents all ten filters, defaults, and formats; the baseline is therefore 3. The description adds nothing beyond 'optional filters'—no clarification of how filters combine (AND vs OR) or how date/amount ranges are interpreted.

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 ('List transactions') plus scope ('with optional filters'), so an agent knows the operation immediately. However, it does nothing to distinguish itself from close siblings like ck_get_recent_transactions or ck_query_sql, which also return transaction data.

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

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

'with optional filters' hints at the use case but there is no explicit when-to-use guidance, no exclusions, and no routing to alternatives such as ck_get_recent_transactions (recent-only) or ck_query_sql (arbitrary queries). An agent must guess which transaction reader to pick.

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?

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing that non-SELECT statements are rejected, that only the first statement executes, the 10-second timeout, and the truncated:true flag on oversized results. These are exactly the behavioral traits an agent needs before issuing arbitrary SQL.

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?

Four dense sentences that are front-loaded with purpose and then layer constraints and return behavior. No filler, repetition, or ambiguity.

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

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

No output schema exists, and the description compensates by covering the row cap, truncation flag, timeout, statement handling, and available tables. An agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds real value by explaining the truncated:true return behavior tied to max_rows and recommending LIMIT/OFFSET paging, exceeding the schema's bare default and maximum notes.

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 action (execute a raw SQL SELECT) and resource (the transactions database), and enumerates available tables. It clearly positions itself as the raw-query escape hatch versus purpose-built siblings like ck_list_transactions and ck_get_spending_by_category.

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 operational context for correct use: SELECT-only, only the first statement runs, 10 s timeout, and the recommendation to prefer aggregates or LIMIT/OFFSET paging for large results. It does not explicitly compare itself to sibling tools or say when to prefer them, so it falls short of the top score.

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 declare non-read-only, idempotent, non-destructive behavior, so the safety bar is lower. The description adds real context by revealing what is being persisted (a credential that drives automatic token refresh) and the required provenance of the value; it does not discuss overwrite semantics or failure behavior, but the idempotentHint covers re-writes.

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 payoff are front-loaded in the first sentence, followed by concrete acquisition steps and a simpler alternative. The DevTools click-path is long but each clause is actionable, so little is wasted.

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 credential-ingestion tool with no output schema, this covers the essential questions: what the value is, where to get it, why to provide it, and an easier substitute. Annotations carry the mutation/idempotency profile, so nothing critical 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?

Schema coverage is 100% and the single parameter's description already states it is the full Cookie header containing CKAT/CKTRKID. The description repeats that plus a harvesting procedure, which is operationally useful but adds little semantic meaning 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?

States a specific verb and resource ('Store a Credit Karma session') and adds the downstream purpose ('enable automatic token refresh'). An agent can distinguish this from sibling ck_forget_session and the read-oriented ck_* tools 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?

Gives clear onboarding context (call this during setup) and names an alternative path (ContextMint Bridge extension that reads cookies automatically). It does not explicitly say when not to call it or point to ck_forget_session for teardown, so it falls short of full 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?

Goes well beyond the annotations: incremental vs full behavior, the exact resumability contract (another_run_needed:true plus a note, continue from where it stopped), that a balance failure is reported in `balances` and never thrown, and how auth is resolved or how it fails. This is rich behavioral context an agent cannot get from readOnlyHint/openWorldHint/idempotentHint alone.

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

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

Front-loads the core action before the parenthetical caveats, and every clause carries real information. The nested parentheses make it dense to parse, but it is appropriately sized for the complexity involved.

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 compensates by naming the response fields (`balances`, another_run_needed, a note) and the failure semantics. Auth prerequisites and resumption behavior are covered, so an agent has everything needed 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 max_pages and force_full are already fully documented in the schema. The description adds little parameter-specific detail beyond restating that force_full restarts from a failed/stuck sync. 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?

States a specific verb+resource: sync Credit Karma transactions into the local SQLite database, plus a balance refresh. It names the related sibling (ck_get_account_balances) and distinguishes itself from read-only siblings like ck_list_transactions by being the sync/persist operation.

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

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

Explains the default incremental mode (since last sync + 30-day overlap), when resumption applies, and that credentials come from ck_set_session/CK_COOKIES/bridge, not a login flow. It routes to ck_get_account_balances for balances, but does not explicitly state when to prefer force_full or a sibling over this tool.

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