Synci

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

Annotations already mark the call as read-only, idempotent, and non-destructive. The description adds valuable behavioral detail beyond that: balance snapshots may lag transactions, negative CLOSING_BOOKED on credit accounts means amount owed, and investment/crypto accounts typically lack snapshots. This is exactly the kind of context annotations cannot express.

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 dense sentences, front-loaded with the core action, followed by caveats and alternatives. No filler or repetition of schema 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 output schema exists, so return-value documentation is not the description's job. It covers staleness, credit semantics, and the investment/crypto exception, making it complete for a one-parameter read-only 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 input schema fully documents account_id at 100% coverage, so the baseline is 3. The description adds meaning by clarifying that exactly one account is targeted and by describing account-type-dependent balance semantics, which goes beyond the schema's 'id of the financial account' definition.

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: 'Get balance snapshots for one account', and lists concrete snapshot types. It also distinguishes itself from sibling tools by explicitly steering investment/crypto account cases to list_holdings and balance fields.

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 clear context for when the tool is appropriate versus alternatives, especially for investment/crypto accounts where snapshots usually don't exist. The credit-account interpretation guidance and stale-data caveat further tell the agent how to use the result correctly.

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 substantial behavioral context beyond annotations: balances can lag transactions and should be caveated, earliest_available_date defines synced history coverage, investment/crypto accounts have empty balance blocks requiring different field interpretation, and sensitive identifiers are omitted. This is rich, non-obvious behavior that an agent needs to know.

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: it front-loads the core purpose, then provides structured caveats with clear markers (IMPORTANT). Every sentence adds information, though the length is substantial. The structure is logical: purpose, output shape, caveats, special-case behavior, parameter note, and security note.

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 complexity (special balance semantics, date coverage caveats, category-specific behavior) and the presence of an output schema, the description is remarkably complete. It covers return value interpretation, edge cases (investment/crypto empty balance blocks), data freshness caveats, and routing to sibling tools. An agent has everything needed to call this correctly and interpret results.

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 parameters (verbose and account_category). The description adds value by explaining the default lean summary and the verbose:true behavior ('returns the full record'), which clarifies the parameter's effect beyond the schema's phrasing. It doesn't add detail on account_category beyond the schema's enum, but the schema already covers that.

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 ('List') and resource ('the user's connected financial accounts'), enumerates the account types (bank, investment, crypto), and distinguishes the output as a lean summary. It clearly differentiates from siblings like list_holdings and get_account_balance by describing the account-level summary scope.

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 when to use this tool (to list connected accounts and get lean summaries) and when to use alternatives: 'call list_holdings for the positions behind them' for investment/crypto accounts. It also provides critical usage caveats about balance lag and earliest_available_date, which guide correct interpretation of results.

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 valuable detail about the response contents (health status, institution, consent expiry), which goes beyond the annotations. This is useful context for agents deciding whether to call it.

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 that conveys the entire purpose and key output fields without any filler. Every element 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 parameterless read-only tool with an output schema (though not shown) and rich annotations, the description fully covers what the agent needs to know: what is listed and the specific fields returned. No significant 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?

The tool has zero parameters and schema coverage is trivially 100%, so the baseline is 4. The description does not need to add parameter details; it correctly focuses on output semantics.

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 ('List') and resource ('bank/provider connections') and adds distinct details (health status, institution, consent expiry) that clearly differentiate it from sibling tools like list_accounts or list_transactions. It is unambiguous about scope.

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 defines what it returns, making it obvious when to use it for connection health monitoring. It does not explicitly state when not to use it, but sibling tool names provide enough context to infer the distinction. A clear exclusion would earn 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 already cover read-only/idempotent behaviorags. The description adds meaningful scope details: it covers brokerage and crypto-exchange accounts, excludes bank accounts, and enumerates returned fields, which clarifies what the call does beyond the schema.

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 convey scope, exclusions, and optional filtering. Every clause earns its place and the most important verb-resource pairing 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?

With a 100%-covered optional parameter sna an output schema plus annotations, the description provides enough scope detail (investment/crypto accounts, no bank holdings) for safe selection and invocation. Slightly more on when to prefer siblings would close the gap, but nothing essential 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 only parameter, account_id, has a complete schema description, and schema coverage is 100%. The description merely restates 'Optionally restrict to one account', adding little 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?

Description opens with a specific verb ('List') and a precise resource: positions held in brokerage and crypto-exchange accounts, not just generic 'holdings'. It lists the returned fields and explicitly notes 'Bank accounts have no holdings', which helps distinguish it from siblings like list_accounts and get_account_balance.

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 tells the agent when this tool applies (investment/crypto positions) and rules out bank accounts alerting, and the schema points to account_id from list_accounts. It does not explicitly name alternatives or exclusions, but the context is clear enough to select this over list_accounts or get_account_balance.

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, and the description adds substantial behavioral context: pending amounts can still change, rows with is_cash_flow=false are not money spent, coverage can silently under-report totals, pagination is keyset, and sensitive identifiers are always omitted. There is no contradiction with 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?

Long, but every section earns its place: row shape, spend semantics, trade semantics, date behavior, coverage, pagination, and privacy are each covered in focused paragraphs. The most important usage warning is prominently marked and 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 complex 8-parameter read tool with no required arguments, the description covers defaults, output row structure, edge cases, pagination, date-field selection, and coverage limitations. An agent has everything it needs to call the tool correctly and interpret the results, even with an output schema 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?

All 8 parameters already have schema descriptions, and the tool description goes well beyond them by explaining the default date window, the meaning of 'mapped' dates, the effect of verbose mode, the pending-status caveat, and how to use cursor and limit for pagination. This adds meaning an agent could not derive from the schema 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 opens with a specific verb and resource: 'List the user's financial transactions in a date window, newest first, across all account types', which clearly identifies what the tool does and its exact scope. This also differentiates it from the sibling tools (accounts, balances, holdings, connections) without relying on inference.

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 strong operational guidance: caveat partial coverage, exclude is_cash_flow=false rows from spend totals, use amount/units/price_per_unit for trade figures, and pass meta.next_cursor to page. It does not explicitly tell the agent when to prefer a sibling tool such as get_account_balance or list_holdings, so it falls just short of full alternative-routing guidance.

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