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?

Goes far beyond annotations. Annotations only declare readOnly, idempotent, and non-destructive. The description adds critical behaviors: investment rows semantics (type, is_cash_flow, units, price_per_unit), the caveat that pending amounts can change, coverage limitation via meta.earliest_available_date, pagination with keyset cursor and meta.has_more, and the guarantee that sensitive identifiers are omitted. No contradiction with annotations.

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

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

The description is long (~400 words) but well-structured into clear sections. Every sentence adds necessary detail for a complex tool with 8 parameters and nuanced behaviors. It front-loads the core purpose and then layers details logically. While it could be trimmed slightly, the thoroughness is justified given the complexity.

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 (investment rows, coverage caveats, pagination, sensitive data, multiple date fields), the description covers all critical aspects an agent needs to call it correctly. The output schema exists, and the description adds context on interpretation (e.g., is_cash_flow) that is essential. Nothing important appears 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 substantially enriches parameter meaning. It explains date_field ('mapped' vs 'booking' vs 'value'), clarifies limit behavior (page may hold fewer rows), describes cursor usage, and details verbose vs lean shape. It also clarifies that 'date' defaults to Synci's authoritative date, adding nuance not in 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: 'List the user's financial transactions in a date window, newest first, across all account types.' It enumerates account types and distinguishes itself from sibling tools (list_accounts, list_holdings, get_account_balance, list_connections) by clearly focusing on transactions. No ambiguity about what it 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?

Provides extensive usage context: how to interpret investment rows for spending, when to use verbose, how to handle coverage gaps, and pagination instructions. It does not explicitly name alternative tools, but the purpose is so distinct that routing is obvious. The 'IMPORTANT' note on is_cash_flow is an explicit when-to-use-this-tool guideline for spending analysis.

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