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

The description states the action clearly as submitting an MFA response, which aligns with readOnlyHint=false. However, it does not disclose behavioral consequences such as consuming the pending challenge, advancing the job, or error behavior if the answer is wrong.

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 verb front-loaded and parenthetical examples that are compact and informative. 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?

There is no output schema and no description of the surrounding MFA flow, the source of jobId, or what to do after submitting a response. For a mutation tool in a multi-step connection workflow, this is an incomplete picture.

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 parameters are already well documented. The description's parenthetical examples loosely mirror the type enum and value semantics, but add little meaning beyond what the schema already provides.

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 the specific verb 'Submit' plus the resource 'MFA response' and gives concrete examples (security question answer, verification code, captcha). It is immediately distinguishable from all sibling tools, none of which deal with MFA challenges.

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 about when to call this tool, such as after a connection flow returns an MFA challenge or after a poll_job indicates MFA is required. No alternatives or exclusions are mentioned, so an agent must infer the usage context from the tool name and siblings.

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 the safety profile (not read-only, not destructive, open-world). The description adds useful behavioral context beyond annotations by disclosing that the tool renders a UI, requires credential entry, and handles MFA verification. 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?

Two sentences with no wasted words. The core action is front-loaded, and the second sentence efficiently summarizes what the wizard does. Every 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 zero-parameter, interactive wizard tool, the description gives enough context for an agent to know what will happen when invoked. It could be more explicit about what the wizard returns or whether the connection is fully established on completion, but given the minimal invocation surface, this is a minor gap.

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 full schema coverage, so there is nothing for the description to document. Per the zero-parameter baseline, the description appropriately focuses on the tool's behavior instead of parameter details.

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 launches an interactive wizard to connect a bank or credit card account, and it names the concrete steps (searching institutions, entering credentials, handling MFA). This distinguishes it from siblings like create_connection, which presumably handles programmatic connection creation rather than a guided UI.

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 this tool is for interactive, user-driven flows by highlighting the wizard and guided UI, but it never explicitly contrasts it with alternatives such as create_connection or states when the programmatic path should be used. The guidance is contextual but not 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?

Beyond the annotations, the description usefully discloses that creation is asynchronous by returning a job ID for polling. It does not mention MFA possibilities or failure modes, but it adds meaningful behavioral context not available in the annotations or 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 with no filler. The action and the key return behavior are front-loaded, and every clause 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?

The description is adequate for a basic call: what to create, what credentials are needed, and the async return value. Gaps remain around naming the polling tool, handling MFA via answer_mfa, and explaining potential external side effects, which would make it more 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?

Schema description coverage is 100%, so the schema already documents all parameters, including that institutionId comes from search results and pin is conditionally required. The description adds no additional parameter detail, 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 clearly states the action ('Create'), the resource ('bank connection'), and the return value ('job ID for polling'). It does not explain how it differs from the similarly named sibling connect_bank, so it stops short of full sibling differentiation.

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 no explicit guidance on when to use this tool versus connect_bank, nor does it mention prerequisites such as calling search_institutions first. The polling hint is present but not framed as an explicit workflow instruction.

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?

The readOnlyHint annotation already establishes the safe, non-mutating nature of the tool. The description adds context about the contents of the preferences (selection, custom names) and their association with a connection, but does not disclose any other behavioral traits (e.g., error handling, missing preferences).

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, well-structured sentence that front-loads the action (Read) and packs in the key details (what preferences, for a connection) without any wasted words.

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 (one parameter, simple read operation, no output schema), the description adequately explains what the tool does and what will be returned (the preferences, including selection and custom names). It is complete for an agent to decide and invoke 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?

The input schema has full description coverage for the single parameter (userInstitutionId), so the description does not need to compensate heavily. The phrase 'for a connection' subtly suggests that the parameter identifies a connection, but this is not explicit or additive beyond the schema description.

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 verb 'Read' and the resource 'stored account preferences', with specific detail about what kind of preferences (selection, custom names) and scope (for a connection). This distinguishes it from sibling tools like save_account_preferences and list_accounts.

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 context that this is a read-only retrieval of preferences for a connection, which implies its use case relative to save_account_preferences. However, it does not explicitly name alternatives or exclusion criteria, so it falls 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 burden of disclosure. It clearly signals a read-only listing operation, but does not mention possible pagination, empty results, or whether the connection must be active. Basic behavior is transparent, but deeper behavioral context is absent.

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 concise single sentence with no filler or redundant wording. It front-loads the verb and resource, making it easy for an agent to parse quickly.

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 one-parameter read-only tool with no output schema, the description covers the essential invocation context: list accounts scoped to a specific bank connection. It does not explain output shape or pagination, but the tool's low complexity reduces the need for additional explanation.

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 single parameter is already fully documented by the input schema with 100% coverage. The description adds no extra meaning about the parameter's format, source, or interpretation, 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 states a clear verb ('List') and resource ('accounts') with a specific scope ('for a specific bank connection'), making the tool's purpose unambiguous. It distinguishes itself from generic account-listing siblings like list_accounts by emphasizing the connection scoe, though it does not name that sibling explicitly.

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 'for a specific bank connection' implies the tool is used when an agent already has a connection and needs its accounts, but there is no explicit when-to-use guidance or distinction from list_accounts. Usage is inferable rather than directly stated.

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?

The readOnlyHint annotation already signals this is a safe read operation, and the description adds the 90-day default window. It does not disclose pagination, ordering, or response shape, but for a simple read-only tool the added context is reasonable.

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 two short sentences with no filler. The core action is front-loaded, and the default behavior is stated efficiently.

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 read-only tool with one required parameter and no output schema, the description covers the essential purpose and default range. It could mention response format or ordering, but the agent has enough to invoke 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?

Input schema coverage is 100%, so all three parameters are already documented with types and defaults. The description restates the default window but adds no new parameter-level detail beyond what the schema provides.

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 ('get') and a specific resource ('transactions for a bank account'), clearly stating what the tool does. The default date window further clarifies the scope and distinguishes it from other account-related tools like list_accounts.

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 alternatives such as get_connection_accounts or list_accounts. The usage context is implied by the name and description, but no exclusions or alternative routing are provided.

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, so the description need not repeat that. It adds useful context about default filtering and including hidden accounts. However, it does not disclose other behavioral traits such as pagination, ordering, or any prerequisites beyond the parameter, leaving some gaps.

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 two concise sentences. The first sentence states the primary action, and the second explains the optional parameter. No filler or redundancy, and it is front-loaded with the verb and resource.

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 simplicity (2 params, 1 required, no output schema) and the readOnlyHint annotation, the description adequately covers purpose and behavior. It explains the default selection behavior and how to include hidden accounts. It could mention return format or prerequisites, but these are not critical for a basic list operation.

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 parameters are already documented. The description adds minimal extra meaning: it rephrases includeAll ('show hidden accounts too') and gives context that the tool operates on a bank connection. This adds 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?

The description clearly states the tool lists accounts for a bank connection, with a specific verb and resource. It mentions default behavior and the includeAll option. However, it doesn't explicitly distinguish from the sibling tool get_connection_accounts, so it lacks full sibling differentiation.

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 implicit usage context by explaining the default selected-account view and the includeAll option. It does not explicitly state when to prefer this tool over alternatives like get_connection_accounts or when not to use it, so 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 the description adds useful behavioral detail about local storage overlays (logo, selected account count) and account scoping, going beyond just the read-only flag.

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, concise sentence that front-loads the action and resource, includes relevant details about overlays, and avoids any redundant or filler text.

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 simplicity (0 params, no output schema), the description adequately conveys what is listed and the overlay detail. It could mention pagination or return format, but this is not critical for basic usage.

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 has zero parameters, so the baseline is 4. The description does not need to document parameters; it only adds context about returned overlay fields, which is sufficient given the lack of params.

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 clearly states the action (list) and resource (linked bank connections/UserInstitutions), defines scope as 'for this account', and distinguishes itself from sibling tools like list_accounts and get_connection_accounts by focusing on connections and mentioning overlays.

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 usage context (listing linked bank connections) but does not explicitly mention when to use this tool over alternatives like search_institutions or get_connection_accounts. No alternatives or exclusions are provided.

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 convey the safety profile (readOnlyHint=false, destructiveHint=false). The description adds a key behavioral trait: it opens a UI rather than performing direct data operations, but it does not disclose what happens after the UI opens (e.g., side effects, interaction requirements, or response format). This is adequate but not rich, given annotations cover the mutation concern.

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 that directly states the action and its purpose. There is no redundant information or extraneous detail, making it highly concise and well-structured.

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 has no parameters and no output schema, the description is mostly complete for what the tool does. However, it does not specify any return values or post-action behavior, which could be relevant in an MCP context, but for a UI-opening tool the description is 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 input schema has zero parameters, and the description implies no arguments are needed by stating a simple UI-opening action. With 0 params, the baseline is 4; the description adds no conflicting information, so this 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 clearly states the action: 'Open the account management UI' with a specific resource ('your linked bank accounts') and the scope of activities ('select, rename, and organize'). This distinguishes it from sibling tools like rename_account or list_accounts which perform individual operations, whereas manage_accounts opens a higher-level UI.

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 no guidance on when to use this tool versus alternatives such as rename_account or list_accounts. It does not clarify whether direct operations should invoke this UI or the specific sibling tools, leaving the agent to infer the appropriate usage context.

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 full burden and does so excellently. It discloses polling interval, MFA field appearance, completion condition (LastStatus 'Completed'), success/failure semantics for SuccessFlag, and the edge case that refresh jobs may never set SuccessFlag. This goes well beyond a simple 'check status' and provides actionable operational detail.

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 four concise sentences, each carrying essential information with no redundancy. It is front-loaded with the purpose, then adds operational details. Every sentence earns its place, making it highly efficient.

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 a single parameter, no output schema, and no annotations, the description covers the most critical aspects: how to poll, when to switch to answer_mfa, and how to interpret completion. It could additionally mention timeout/error handling, but for a polling tool it is largely complete. The minor gap keeps it from 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 input schema already fully describes jobId as 'Job ID from create_connection or refresh_account' (100% coverage). The description adds only the context of 'connection or refresh job' without additional parameter-specific details. Per the baseline for high schema coverage, a score 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 clearly states the tool's purpose: 'Check the status of a connection or refresh job.' This is a specific verb+resource pairing that distinguishes it from siblings like create_connection or answer_mfa. It also references job types and MFA handling, making its scope unmistakable.

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 explicit usage guidance: poll every 4-5 seconds, and if MFA fields appear, use answer_mfa instead. It also gives clear completion criteria. However, it does not explicitly state when not to use this tool, only when to switch to an alternative, so it falls just short of 'explicit when/when-not/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?

Beyond the annotation readOnlyHint=false, the description reveals critical behavioral traits: the operation is asynchronous (returns a job ID), requires polling, may trigger MFA, and must be polled until SuccessFlag is true or false. This goes well beyond the simple mutation flag and prepares the agent for the non-immediate nature of the operation.

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 three sentences long and every sentence earns its place: the first states the action and return, the second gives critical polling and MFA instructions, and the third defines the completion condition. It is front-loaded with the core purpose and includes necessary caveats without unnecessary verbosity.

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 one parameter and no output schema, the description fully covers what the agent needs: the action, the returned job ID, the polling workflow, MFA handling, and the termination condition. It effectively references sibling tools (poll_job, answer_mfa) to complete the process, making it self-sufficient for correct 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?

The schema already covers accountId with a description 'Account ID to refresh,' and the description does not add extra detail about the parameter. Since schema description coverage is 100%, the baseline of 3 is appropriate—no additional semantic value is provided beyond what the schema already states.

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 verb and resource: 'Trigger a fresh data pull from the bank for a specific account.' It also distinguishes itself from sibling tools by focusing on refreshing an existing account rather than creating or managing accounts. The explicit mention of returning a job ID further clarifies the tool's purpose.

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 strong usage guidance by instructing the agent to poll the job with poll_job every 4-5 seconds, and to use answer_mfa if MFA fields appear. It implicitly distinguishes from alternatives by specifying 'for a specific account' and comparing to a new connection, though it does not explicitly name alternatives like create_connection. The polling and MFA instructions are clear and actionable.

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 readOnlyHint=false, indicating a write operation. The description adds valuable behavioral context by explaining that passing null restores the original name, which goes beyond the annotation. It does not mention side effects or permissions, but the annotation covers the core mutating nature.

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 two concise sentences that immediately state the action and include a crucial usage hint. Every word earns its place, with no redundancy or unnecessary detail.

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 rename operation with three clearly described parameters and no output schema, the description sufficiently covers the tool's function and the null clearing behavior. It does not explain expected responses, but that is acceptable given the simplicity and the write-operation annotation.

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%, including the null semantics for customName already documented in the schema. The description repeats the null behavior but adds no new parameter-specific details, so it appropriately meets the baseline for high schema 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 uses specific verbs 'Set or clear' and identifies the exact resource 'custom display name for a bank account', clearly distinguishing it from account management and connection tools. The null behavior is also mentioned, which clarifies the full scope of the action.

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 a usage hint about passing null to restore the original name, but it does not explicitly state when to use this tool versus alternatives like 'manage_accounts' or 'toggle_account'. There are no exclusions or alternative recommendations, so the agent must infer context from the tool name and sibling list.

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 only provide readOnlyHint: false, which the description aligns with by saying 'Save.' The description adds the contextual detail that this is called by the wizard, but it does not disclose additional behavioral traits such as whether existing preferences are overwritten, idempotency, or error conditions. Since the annotation already implies mutation, the added value is moderate.

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 two sentences long, front-loaded with the verb and resource, and immediately provides the call context. Every sentence adds value with no redundant 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?

Given the tool's moderate complexity (6 parameters, nested accounts array) and no output schema, the description provides essential context: what it saves and when it is invoked. It could mention side effects like overwriting existing preferences, but for a save operation in a wizard flow, the current description is reasonably 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?

While the schema has 100% description coverage, those descriptions are generic (e.g., 'Account preferences', 'Institution ID'). The tool description adds semantic meaning by explaining that the tool saves 'account selection and custom names,' which directly clarifies the purpose of the `selected` and `customName` fields. This goes beyond the schema's bare parameter names.

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 ('Save') and resource ('account preferences'), and clearly specifies what is saved ('account selection and custom names'). It effectively distinguishes this from sibling tools like get_account_preferences, rename_account, and toggle_account by indicating it's the write operation for preferences after connecting a bank.

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 context for when to use the tool: 'Called by the wizard after the user configures their accounts' and 'after connecting a bank.' However, it does not explicitly state when not to use it or mention alternatives, so it lacks explicit exclusions or alternative references.

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 states the operation and the search key, but does not explain matching semantics, result structure, case sensitivity, pagination, or whether the operation is read-only beyond what 'search' implies.

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 one concise sentence with no filler. The action and resource are front-loaded, and every word contributes to 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 simple one-parameter search tool, the description is nearly sufficient for invocation. However, with no output schema and no annotations, an agent receives no indication of the result shape or how returned institution identifiers might feed into connect_bank workflows, which is a noticeable but minor gap.

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 documents the only parameter ('query' with description 'Bank or institution name'), and schema description coverage is 100%. The description restates name-based searching but adds no new meaning beyond the schema, so 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?

The description uses a specific action ('Search') and resource ('banks and financial institutions'), and adds the criterion 'by name,' which gives concrete scope. This clearly distinguishes it from sibling tools that operate on connections, accounts, and transactions, even though no alternative search tool is named.

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 no guidance on when to use this tool relative to siblings like connect_bank or list_connections, and it does not mention prerequisites or exclusions. The only implicit cue is that searching likely happens before connecting, but this is not stated.

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?

The annotations declare readOnlyHint: false, indicating a write operation. The description adds that the operation affects the active list, but does not disclose persistence, permission requirements, or reversibility beyond this basic behavior. While the bar is lower due to annotations, the description provides minimal additional context.

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 redundant information. It achieves maximum efficiency by stating the core function and scope without wasted words.

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?

This is a simple tool with three well-documented parameters and no output schema. The description explains the core function and scope ('active list') sufficiently for an agent to select and invoke it. However, it does not mention return values or prerequisites, which is a minor gap given the low complexity.

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 descriptions cover all three parameters comprehensively, including the semantics of 'selected' (true to show, false to hide). The description does not add parameter information beyond what the schema already provides, so the baseline score 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 clearly states the tool's function with a specific verb ('Show or hide') and resource ('a bank account from the active list'). It effectively distinguishes this tool from siblings like rename_account or save_account_preferences by focusing on visibility toggling.

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 tool is for toggling visibility but does not explicitly state when to use it instead of alternatives such as save_account_preferences or rename_account. There is no mention of exclusions or when-not conditions, leaving usage somewhat implied.

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