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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the output contents. It does not mention read-only behavior, required authentication, possible empty results, or any side effects, leaving significant behavioral ambiguity.

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

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

The description is a single concise sentence that immediately states the tool's output. Every word contributes to the purpose, with no filler or redundancy.

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

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

For a zero-parameter read-only listing tool, the description is reasonably complete: it names the returned entity and key fields. It could be slightly richer by noting when this list is meaningful or how consent state is represented, but the low complexity makes this sufficient.

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 input schema is fully described, so parameter-level documentation is unnecessary. The baseline of 4 applies because there is nothing for the description to compensate for.

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

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

The description clearly identifies the tool as returning the list of linked accounts, their bank, and consent status, which differentiates it from siblings like soldes, transactions, or projection. However, it lacks an explicit action verb such as 'List' or 'Retrieve', relying on the noun phrase 'La liste' to convey the 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?

There is no explicit guidance about when to use this tool versus the sibling tools. The intended use is only implied by the word 'comptes', so an agent receives no clear context for selection or exclusion.

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

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

No annotations are provided, so the description carries the full burden. It discloses confidence thresholds ('sure' ≥3 passages, 'faible' for 2), explains that low confidence should not be announced as fact, details the annual detectability limitation (absence of tax foncière proves nothing if history is too short), and notes that bankread accumulates locally extending the ~90-day bank window. This is rich behavioral context beyond basic functioning.

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-structured: it opens with the main output, then explains confidence levels, annual detection, and local accumulation in separate clauses. Every sentence adds value, but the technical details make it somewhat long. It is appropriately sized for the complexity without redundancy.

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

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

There is no output schema, so the description must convey the return structure. It mentions all key fields (cadence, montant médian, date du prochain passage) and specific metadata (confidence, annuel_detectable, jours_avant_annuel_detectable). It lacks an explicit field list or error conditions, but given the single input parameter and straightforward purpose, the description is sufficiently complete for agent 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% for the single parameter, which is self-explanatory ('Identifiant du compte. Omis : le premier compte lié.'). The description adds no additional parameter details, but does not need to since the schema already covers it. Baseline 3 is appropriate for high coverage.

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

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

The description explicitly states the tool's function: detecting recurring operations (both debits and credits) from history and providing cadence, median amount, and next occurrence date. This is a specific verb+resource (detect recurring operations) and clearly distinguishes it from siblings like transactions or projection.

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

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

The description implies when to use it (when you need recurring operation detection) and adds context about historical depth limits. It does not explicitly name alternatives or exclusions, but the sibling tools are distinct enough that this purpose is unambiguous. A clear context is present without explicit when-not 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?

With no annotations, the description carries the transparency burden. It adds meaningful behavioral detail: the projection is day-by-day, returns specific computed fields, and refuses to project on an unobserved balance rather than fabricate a date. It does not discuss errors, side effects, or permissions, but the read-only projection behavior is well conveyed.

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 short sentences, front-loaded with the core concept and no filler. Every sentence adds value: computation, outputs, use case/alternative, and a refusal edge case.

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

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

There is no output schema, so the description must explain return values; it names the key outputs and covers the main edge case. It could be slightly more explicit about the `point_bas` result and exact output shape, but it is sufficient for a small projection 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 coverage is 100%, so the baseline is 3. The description adds useful semantic context by explaining the computation ('today's balance minus certain upcoming due dates, day by day') and the notion of the floor (`franchissement` when balance drops below it), which enriches the schema's minimal field descriptions.

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 a projection tool: it crosses today's balance with upcoming certain due dates and rolls it out day by day. It names concrete outputs (`franchissement`, `point_bas`, movement details) and distinguishes itself from an after-the-fact bank threshold alert.

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

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

It explicitly states when to use it: to answer 'will it pass before the end of the month.' It also contrasts itself with a threshold alert that only warns after the fact, though it does not name sibling tools or describe exclusion cases beyond that contrast.

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 behavioral transparency burden. It discloses that the tool makes no network call ('Aucun appel réseau, donc gratuit en quota') and that 'registres' contains more history than the bank actually returns. This is valuable, though it doesn't explicitly describe side effects or permissions.

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 concise and well-structured: it front-loads the purpose, lists contents, then provides usage guidance. Every sentence contributes meaningful information without redundancy.

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

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

For a zero-parameter inspection tool with no output schema, the description fully covers what the tool returns and when to invoke it, including the important nuance about 'registres' and the weekly renewal check.

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 explain. The description adds context about what the tool reports, which is sufficient given the lack 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 clearly states the tool provides an overview of the bank link status, enumerating specific contents (secrets, linked accounts, consent expiry, quotas, registres). This distinguishes it from sibling tools that fetch specific data like transactions or balances.

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 usage guidance is given: 'À appeler en premier quand quelque chose paraît manquer, et une fois par semaine pour voir venir le renouvellement à 90 j.' It also notes that it makes no network call and is free in quota, helping the agent decide when to use it.

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

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

With no annotations, the description fully discloses behavior: it explains the 'etat' field values (observe, ancien, inconnu), instructs not to misinterpret 'inconnu' as zero or failure, and mentions the quota and caching behavior. This gives the agent a clear understanding of what to expect and how to handle edge cases.

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 concise, consisting of three sentences that efficiently convey the core functionality, the response's reliability states, and the quota constraint. No unnecessary verbosity; every sentence adds value.

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

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

The description provides essential context about the response, including the 'etat' and 'age_lisible' fields, and the quota behavior. However, it does not detail the full response structure (e.g., balance amount, currency) or specify behavior for multiple accounts, which could be considered a minor gap in completeness.

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 description adds significant context beyond the schema: it explains the operational impact of 'rafraichir' (consumes quota, forces network call) and clarifies the default behavior. It also relates the 'etat' field to the parameters, enhancing the schema's basic definitions.

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

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

The description clearly states that the tool returns the available balance of each account, with detailed explanation of the 'etat' field. It is distinct from the sibling tools (health, accounts, schedules, transactions, projections) as it specifically targets balances.

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 explicit guidance on when to set 'rafraichir' to true versus false, based on the quota and need for real-time data. However, it does not explicitly differentiate when to use this tool over the sibling tools, though the purpose inherently implies it for balance queries.

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

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

Despite no annotations, the description thoroughly explains the 'etat' field, including the distinction between 'observe', 'ancien', and 'inconnu', and warns against misinterpreting 'inconnu' as a zero balance or failure. This provides strong transparency about caching and data reliability.

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 concise and well-structured, using two sentences to cover purpose, usage, and the important 'etat' semantics. Every sentence adds value, with no redundancy.

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

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

Given the simplicity of the tool (two optional parameters) and the lack of an output schema, the description adequately covers the essential behavior, including the meaning of the 'etat' field. It doesn't specify all returned transaction fields, but that is often assumed for a transaction list.

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

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

The schema already fully describes both parameters ('jours' as days with default, 'compte' as identifier with fallback). The description adds no additional parameter-specific meaning beyond the schema, so the baseline score of 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?

The description clearly states that the tool retrieves past transactions for an account, ordered most recent first. It also provides specific use cases like verifying a due date or finding a purchase, which clarifies its purpose. However, it lacks an explicit verb like 'list' or 'get', so it's not maximally direct.

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 specific scenarios when to use the tool ('check an announced due date' or 'find a specific purchase'), which serves as guidance. It doesn't explicitly compare to sibling tools, but the context is sufficient for typical use.

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