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?

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?

The readOnlyHint annotation already covers the safety profile, so the bar is lower. The description adds the scoping observation that it lists ALL accounts for a bank connection, which is mildly useful behavioral context, but it does not disclose anything further such as pagination, errors for invalid connections, or data freshness.

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 the core purpose front-loaded in the first sentence. The second sentence is slightly redundant since the schema already requires the parameter, but the description remains appropriately sized and free of waste.

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 a readOnly annotation, but a critical piece of context is missing: how this tool differs from the sibling get_connection_accounts. With no output schema, some indication of what the response contains would also help. The description leaves the agent to guess which of the two account-listing tools to call.

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 userInstitutionId. The instruction 'Provide the UserInstitution ID' merely restates the schema's required parameter and adds no meaning about ID format, where to obtain it, or its relationship to a connection.

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 ('List') and resource ('all accounts for a bank connection'), clearly stating what the tool does. However, it does not differentiate itself from the nearly identical sibling get_connection_accounts, so it falls short of a 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?

No guidance is given on when to use this tool versus alternatives. Despite get_connection_accounts sounding like the same operation, the description does not explain the distinction or provide any usage context, exclusions, or prerequisites for selecting this tool.

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 that this is a safe read operation, and the description's 'list all linked' wording is consistent with that. It adds the 'for this account' scoping detail, which is useful, but it does not mention pagination, ordering, or what happens when no connections 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, well-structured sentence with no filler. The key action and resource are front-loaded, and the parenthetical clarification is placed where it adds value without bloating the 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?

For a parameterless list tool with a readOnlyHint annotation, the description covers the essential purpose and scope. It lacks explicit usage guidance or output shape details, but the tool is simple enough that these are not critical gaps.

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

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

There are zero parameters, so the description does not need to explain parameter behavior. The mention of 'for this account' provides meaningful context even without parameters, making the tool's execution context clear.

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 'list' with the resource 'bank connections' and clarifies the domain term 'UserInstitutions' in parentheses. It also specifies scope with 'for this account,' making it distinguishable from sibling tools like list_accounts or get_connection_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 gives no guidance on when to choose this tool over alternatives such as search_institutions, create_connection, or get_connection_accounts. The intended use is only implied by the title and description, with no explicit context 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?

No annotations are provided, so the description carries the full burden. 'Check' indicates a read-only, non-mutating poll, and 'used during the connection flow' adds useful context. However, it does not disclose polling semantics such as whether the call is non-blocking, what statuses may appear, or how to interpret the result for next steps.

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 the core action front-loaded and the usage context immediately after. There is no filler or redundant wording.

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 tool, the description is mostly sufficient for invoking it. However, with no output schema it does not explain what status values are returned or how the agent should react to them, which is relevant in a connection flow that may require MFA or further polling.

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 jobId is already documented as coming from create_connection. The description itself adds no parameter-level meaning, 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 specific verb ('check'), a specific resource ('status of a bank connection job'), and places it in the connection flow. It is clearly distinct from sibling tools like create_connection or answer_mfa, which perform different actions.

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

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

The description explicitly says the tool is used during the connection flow, giving clear contextual timing. It does not name alternatives or exclusions, but no sibling tool is a plausible substitute for polling job status.

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 description discloses key behavioral traits beyond the readOnlyHint=false annotation: the operation triggers an asynchronous data pull and returns a job ID rather than immediate data. It doesn't mention failure modes, rate limits, or connection prerequisites, but the async behavior is the most important transparency point and it is present.

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 that front-loads the action and immediately states the important result (job ID to poll). Every word earns its place with no redundancy or vague 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 single-parameter tool with no output schema, the description is largely complete: it explains what happens, for which account, and what the caller receives. It could slightly improve by mentioning that the returned job ID should be used with poll_job, but the phrase 'to poll' adequately hints at the next step.

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

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

The only parameter, accountId, is fully documented in the schema with 'Account ID to refresh', and the description merely restates the concept of 'a specific account'. With 100% schema description coverage, the description adds no additional semantic value 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 uses a specific verb ('Trigger a fresh data pull') and a precise resource ('a specific account'), making the tool's purpose immediately clear. It also states the return value (a job ID to poll), which distinguishes it from read-only tools like get_transactions or 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 clearly implies when to use the tool: when fresh bank data is needed for an account, and the caller should expect an asynchronous job to poll. It does not explicitly name alternatives or state exclusions, but the context is clear enough given the sibling tools like poll_job and get_transactions.

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.