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

With no annotations, the description carries full behavioral burden, and it discloses a non-obvious side effect: the invocation counts as an attended check and bypasses the normal polling slot. It also specifies that it evaluates all active watches and returns only those that fired. This gives enough detail for an agent to understand the action, though it does not discuss error cases or state changes beyond the check count.

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 sentence that leads with the core action, then provides the key nuance in a parenthetical, then states the return. No redundant or filler wording is present.

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 action with no output schema and no annotations, the description is sufficiently complete: it defines the scope ('every active watch'), the timing ('right now'), the behavioral consequence ('counts as an attended check'), and the response ('return what fired'). An agent can invoke and interpret the result without further documentation.

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?

There are zero parameters, and the schema is an empty object, so there is nothing for the description to add. The baseline of 4 for parameterless tools 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 action ('Evaluate every active watch right now') and a concrete return ('return what fired'). It is clearly distinct from watch lifecycle siblings (create/list/delete) by focusing on immediate evaluation, though it does not explicitly name an alternative, so it stops short of a full 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 phrase 'counts as an attended check' with 'does not wait for the polling slot' gives clear context for when to invoke: when an immediate, on-demand evaluation is wanted instead of waiting for scheduled polling. No exclusion criteria or alternative tool is mentioned, but the usage context 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 carries the burden of explaining behavior. It discloses the output categories, including the non-obvious 'started but not finished' logins, but does not explicitly state that the tool is read-only or whether it refreshes consent data from the banks.

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 central question and packs three distinct output facets without waste or repetition. Every clause carries meaningful 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 zero-parameter status tool with no output schema, the description explains the return content in enough detail to call correctly. It is missing only an explicit read-only statement or a pointer to sibling list_banks for distinguishing available vs connected banks.

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 confirms this with 100% coverage, so the description has no parameter documentation burden to carry. The baseline for zero-parameter tools 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 identifies the tool as a status/read operation and enumerates what it reports: connected banks, consent days remaining, and incomplete bank logins. This content is specific enough to distinguish it from siblings like list_banks or get_balances, though it lacks an explicit verb like 'retrieves'.

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 intended use is implied: use when you need consent expiry information or unfinished login flows. However, there is no explicit statement of when to prefer this over alternatives such as list_banks or check_watches, and no when-not-to-use 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 provided, the description carries the full burden of behavioral disclosure. It covers key behavioral aspects: the notification destination is fixed (NOTIFY_WEBHOOK_URL, cannot be chosen), checks occur at most 4 times a day (PSD2 limit), and each rule type's exact triggering conditions are detailed (e.g., credit_missing_by notifies on by_date and also when the matching transaction arrives). It does not disclose the response format or error behavior, but the provided details are substantial.

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 lengthy but each sentence earns its place. It opens with the core purpose, then states key constraints (webhook destination, rate limit), and then systematically explains each rule type with its parameters. It is front-loaded with the primary action and avoids redundancy. While it could be more compact, the detail is necessary given the complexity of six rule types and multiple parameters.

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 tool has no output schema, so the description should ideally clarify what the call returns (e.g., a watch ID or confirmation). This is omitted. However, the description fully covers the input semantics, constraints, and rule behaviors, which is the bulk of what an agent needs to invoke the tool correctly. The missing return information is a minor gap, but the overall context is highly 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 schema covers 86% of parameters with descriptions, but the description adds significant context beyond the schema. For each rule type, it explains how the parameters apply (e.g., 'balance_below / balance_above: amount threshold on the booked balance', 'credit_matching / debit_matching: an incoming / outgoing transaction whose counterparty or description contains match'). This maps parameter meanings to specific rules, going beyond the generic schema descriptions and clarifying optional interactions like min_amount.

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's core action: 'Watch an account in the background and send a notification to the webhook... when a rule fires.' It specifies the resource (account), the action (create watch), and the outcome (notification). The enumeration of rule types (balance_below, balance_above, etc.) further clarifies the purpose and distinguishes it from sibling tools like list_watches or delete_watch.

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 the tool (for automated background monitoring) but does not explicitly contrast it with alternatives. It doesn't state 'use this when you need to set up a rule-based alert' or mention that list_watches is for viewing existing watches. The context is clear enough to infer usage, but the description misses direct guidance on when not to use it or when to prefer 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?

No annotations are provided, so the description carries the full burden. It communicates that deletion happens but does not disclose consequences such as irreversibility, side effects on related resources, authorization requirements, or behavior when the id does not exist.

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 front-loaded sentence with no filler. Every word carries meaning and it is immediately scannable.

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 tool is simple: one required string parameter and no output schema. The description is almost sufficient for an agent to call it correctly. It only lacks a brief note on failure/not-found behavior or irreversibility, which prevents a 5.

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 gives only a required string named 'id' with 0% description coverage. The description's 'by id' confirms that the parameter is the identifier of the watch to remove, which is useful but minimal; it does not add format, source, or lifecycle context.

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 ('Remove') with a specific resource ('a watch') and the exact selector ('by id'). It is distinct from watch siblings like create_watch, list_watches, and check_watches, so an agent can tell what this tool does without inspecting further.

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 when-to-use or when-not-to-use guidance, and no alternative tool is named. However, the delete semantics are clear enough that the intended use (when a watch must be removed) is implied by the verb and resource.

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 burden. It tells the agent the operation is destructive by explicitly listing what is forgotten: accounts, labels, and watches. It stops short of stating irreversibility or access requirements, but the disclosed side effects are substantial.

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 compact sentence with the key verb first and side effects following. No filler or redundant restatement of the title.

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 output schema, the description provides enough to understand the action and its consequences. It could mention that the action cannot be undone, but complexity is low and the core behavior is covered.

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 parameter description already tells the agent session_id comes from consent_status. The tool description adds no further parameter semantics, so 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?

Clearly names the action (revoke a bank consent), the provider (Enable Banking), and the local side effects (forget accounts, labels, watches). This distinguishes it from sibling tools like list_banks or create_watch.

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 the use case: when a bank connection should be removed. It does not explicitly state alternatives or conditions when not to use it, such as using delete_watch instead when only a watch should be removed.

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 must carry the behavioral transparency burden. It adds valuable context by defining booked versus available balances, but it does not disclose potential side effects (it is read-only by nature), authorization requirements, or error behavior.

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 efficiently front-load the core purpose and then explain the critical distinction between booked and available balances. There is no redundancy or unnecessary elaboration.

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 tool is simple with one well-documented parameter, and the description covers the key return semantics of balances, which is enough to make a correct call. However, without an output schema or annotation support, it could provide more detail on the response structure or error cases.

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 the single `account` parameter as 'Account uid or label' (100% coverage). The description adds no new semantic detail about the parameter beyond repeating the 'one account' constraint, so it stays at the baseline.

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 'Current balances of one account', which clearly identifies the tool's verb, resource, and scope. It implicitly distinguishes itself from siblings like list_accounts and get_transactions by focusing on balance data for a single account.

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 useful usage context, such as 'use this for net worth' for the booked balance and explains what available means for credit/mortgage accounts. However, it does not explicitly say when to prefer this tool over an alternative or mention any prerequisites like a valid consent.

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 to carry the safety profile, the description adds meaningful behavior: signed amounts, newest-first ordering, default date range, limited bank history, and continuation-based pagination. It does not detail error behavior or output shape, but the core operational traits are 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?

Five short sentences, each carrying distinct information: scope/order, sign convention, default range, history limits, and pagination. Core facts are front-loaded and no sentence 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 six-parameter tool with no output schema and no annotations, the description covers the important operational context: ordering, sign convention, defaults, and continuation. It does not enumerate return fields, but the schema already documents parameters and the core call behavior is clear.

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 value beyond the schema by explaining the continuation mechanism, the 30-day default context, and the practical bank history limit, which helps an agent decide parameters correctly.

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: it fetches transactions for one account, with ordering ('newest first'). This is enough to distinguish it from sibling tools like get_balances or list_accounts 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?

The description establishes clear context: use it for a single account's transaction history, defaulting to 30 days, and mentions pagination for longer histories. It does not explicitly name alternatives or state when not to use it, so it stops short of 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?

With no annotations, the description carries the behavioral burden and does meaningful work: it discloses a per-account bank call cost, explains that booked balance is the reliable total, and warns that available may include credit lines. It does not mention pagination or error behavior, but the disclosed traits go well beyond a bare listing.

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 short sentences, with the core purpose first, the optional parameter behavior second, and the balance-totals caveat last. No repetition of schema fields and 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?

For a one-optional-parameter list tool with no output schema, the description covers return fields, optional balance retrieval, and the network cost. It is slightly light on when to choose this over balance-specific siblings, but nothing needed to make a correct call 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 schema provides only a boolean name and default with no property description, so the description fully compensates by explaining the effect of include_balances and the meaning of booked vs available balances. This is exactly the semantic detail needed for correct invocation.

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 returns all linked accounts with the key fields (bank, IBAN, currency, consent expiry). The optional balance behavior distinguishes it from list_banks and get_balances, giving the agent enough to know exactly what this tool retrieves.

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 practical parameter guidance: set include_balances to fetch booked balances and use booked rather than available for totals. However, it does not explicitly state when to choose this tool over siblings like get_balances or list_banks, leaving usage-vs-alternative decisions to inference.

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, and the description implies a read-only listing operation but does not explicitly state side effects, safety, or ordering/pagination behavior.

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, front-loaded with the core purpose, and includes a practical pointer for using the returned bank name with start_consent.

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 listing tool with no output schema, the description gives enough information about what is returned and how to use it downstream.

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 fully describes the search and country parameters with defaults, so the description adds little semantic value beyond what 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?

Clearly states the tool lists banks available through Enable Banking in a country and includes maximum consent length. This distinguishes it from sibling list tools like list_accounts and list_watches.

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 workflow context by telling the agent to use the exact bank name with start_consent, but does not explicitly compare against alternative tools or state when not 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explicitly state that the operation is read-only, has no side effects, or whether any prior state (e.g., consent) is required. Only the returned fields are mentioned.

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 immediately names the resource and its contents. No filler or redundancy; every word contributes meaning.

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 no-parameter list tool without an output schema, the description adequately states the return values (rule, status, last fired). It is slightly under-specified regarding the exact scope of 'all' and the distinction from check_watches, but remains largely complete for its simplicity.

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 is empty with zero parameters and 100% schema description coverage, so the baseline for parameter semantics is 4. The description has no need to add parameter details since there are none.

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 the resource (watches) and the exact fields returned (rule, status, last fired), making it clear this is a list/read operation. It differentiates from create_watch and delete_watch via the listing nature, but does not explicitly distinguish itself from check_watches, a sibling of unknown behavior.

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?

No guidance is given on when to use list_watches versus check_watches, create_watch, or delete_watch. The description only states what the tool returns and does not include any conditions, alternatives, or exclusions.

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 the behavioral burden. It discloses the core effect and that labels are usable across tools, but does not mention whether an existing label is overwritten, whether labels must be unique, or any side effects. Acceptable for a simple setter, but some transparency is missing.

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 carry purpose, examples, and cross-tool relevance. No filler or redundancy; the most important information 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 two-parameter tool with no output schema, the description covers purpose, parameter interpretation, and why labeling is useful. It omits edge-case behavior like overwriting or label removal, but these are not critical to invoking the tool 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 50%: 'account' is documented in the schema, but 'label' is not. The description compensates by explaining what a label is, giving examples, and noting that labels can replace uids everywhere. This adds meaning beyond the raw 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 states a clear action ('Give an account a name') on a specific resource (account) and provides concrete examples. It is immediately distinguishable from the sibling list/get/consent tools, none of which involve labeling.

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 the tool: to assign a recognizable name so labels can replace uids in other tools. It lacks explicit exclusions or alternatives, but since no sibling tool performs labeling, this is clear and sufficient.

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 behavioral disclosure burden. It explains the external-browser redirect flow, the read-only nature of the consent, the callback to the server, the appearance of accounts afterward, and the 180-day expiry. This is comprehensive and leaves no major behavioral surprises.

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 deliver the core action, the multi-step flow, and the consent lifetime with no filler. The main purpose is front-loaded in the first sentence, and every following 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 tool with no output schema, the description gives the essential return semantics (a URL), the required follow-up action (open in browser and approve), the post-approval effect (redirect and accounts in list_accounts), and the consent duration. Nothing an agent needs to correctly invoke and understand the outcome 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 description adds no parameter-specific meaning, while the schema already covers bank (exact name from list_banks) and country (ISO code, default DK). The customer_type parameter is documented only through its enum values and default. With 67% schema coverage, the description does not need to compensate heavily, but it also contributes nothing 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: 'Start linking a bank.' It then explains the exact mechanism (returns a URL for browser login/approval) and clearly differentiates from siblings like consent_status (checking status) and disconnect_bank (ending a consent). The role of the tool is unambiguous.

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 clear contextual guidance: it is the initiation step, and after approval the accounts will appear in list_accounts. This strongly implies when to use it relative to other tools. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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