Read-only Increase banking observability plus one safe non-money-moving write, for AI agents.
Scored across 18 tools
Each tool maps to a distinct resource+action (accounts, transfers, entities, cards, etc.), so boundaries are mostly clear. Minor potential confusion among list_transactions, list_pending_transactions, and list_declined_transactions, but descriptions and distinct endpoints clarify them.
Every tool follows a strict increase_verb_noun pattern (create_, get_, list_, lookup_) with snake_case throughout. The single 'lookup' verb is a minor but sensible deviation, and the resource naming is highly predictable.
18 tools is on the heavier side but each covers a distinct Increase resource endpoint, so most earn their place. The breadth of read tools (many transfer/transaction types) is justified by the domain.
Read coverage is broad across many resource types, but the surface is almost entirely read-only: only one mutating tool (create_external_account). Core lifecycle operations (creating transfers, entity/card management, updates) are absent, which will limit agents needing to act, not just observe.
Registers an external (counterparty) bank account in Increase for future transfers. This creates a record only — it MOVES NO MONEY. Increase API: POST /external_accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| funding | No | The type of the destination account. Default checking. | |
| description | Yes | A human-readable description/name for this external account. | |
| account_holder | No | The type of entity that owns the external account. | |
| account_number | Yes | The counterparty's account number. | |
| routing_number | Yes | The counterparty's 9-digit ABA routing number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds a genuinely valuable behavioral disclosure beyond the destructiveHint annotation: 'creates a record only — it MOVES NO MONEY,' which directly addresses an agent's main risk concern for a banking tool. It does not, however, mention idempotency, permissions, or what side effects follow from later referencing this record.
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 tight sentences, front-loaded with the purpose and the safety clarification, plus the API endpoint. Every clause carries information; nothing is padding.
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 flat five-parameter creation tool with no output schema, the description covers purpose and the key mutation caveat well. It is slightly incomplete in not indicating what the call returns (the external account ID) or the entity linkage needed for later transfers.
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 all five parameters are already documented in the schema, and the description adds no parameter-level detail (no mention of routing/account number formats or enum values). This matches the baseline for fully documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Registers an external (counterparty) bank account in Increase') and even names the underlying API endpoint POST /external_accounts. An agent can immediately distinguish this from siblings like increase_list_external_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 phrase 'for future transfers' implies the context of use, but the description never states when to use this versus increase_list_external_accounts or increase_get_account, nor any prerequisites. Usage is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single bank account by id. Increase API: GET /accounts/{account_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | Account id (e.g. account_...). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the underlying API mapping (GET /accounts/{account_id}), which is modestly useful context, but it discloses nothing about return contents, error behavior for unknown ids, or auth requirements.
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 zero padding, and the purpose is front-loaded ahead of the API reference 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 one-parameter read tool with no output schema, the definition covers what the tool does, the identifier it needs, and the endpoint it maps to. The only real gap is the shape of the returned account object, which is a minor omission given the standard pattern.
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 single parameter already carries its own description with an example format ('account_...'). The description's 'by id' adds no meaning beyond the schema, so the baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Retrieve a single bank account by id'), and the word 'single' implicitly distinguishes it from increase_list_accounts. It does not explicitly name the sibling it is not, nor contrast with increase_get_account_balance, so differentiation is inferred rather than stated.
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 'by id' implies the tool is used when an account_id is already known, which is a usable signal, but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as list_accounts or get_account_balance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve an account's current and available balance. Increase API: GET /accounts/{account_id}/balance. Optionally as of a point in time.
| Name | Required | Description | Default |
|---|---|---|---|
| at_time | No | ISO 8601 timestamp to get the balance as of that moment (query param at_time). | |
| account_id | Yes | Account id (e.g. account_...). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description does not need to re-establish safety. It adds modest value by specifying the endpoint and clarifying that both current and available balances are returned, but says nothing about auth requirements, rate limits, or whether 'available' excludes pending holds.
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 that are front-loaded with the core action, with the endpoint reference and the optional time qualifier trailing. No padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with full schema coverage and a readOnlyHint annotation, the definition covers what the tool does and the one optional modifier. No output schema exists, but explaining return fields is arguably already done by naming current and available balance.
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 both account_id and at_time are already documented in the schema, including the ISO 8601 format and the 'as of that moment' semantics. The description's 'optionally as of a point in time' merely restates the at_time parameter, adding no new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Retrieve an account's current and available balance') and names the exact fields returned, so it is clearly distinguishable from sibling reads like get_account or get_transaction. It does not, however, explicitly contrast itself with those siblings.
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 when-to-use or when-not-to-use guidance and no alternatives named among the many sibling get/list tools. The only contextual note is that the balance can be read 'as of a point in time', which is parameter information rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single ACH transfer by id. Increase API: GET /ach_transfers/{ach_transfer_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| ach_transfer_id | Yes | ACH transfer id (e.g. ach_transfer_...). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the bar is lower. The description adds the upstream REST endpoint for context, but omits what happens on a missing/invalid id (error vs empty) and any auth or rate-limit considerations.
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, zero waste, with the core action front-loaded and the endpoint reference relegated to the second sentence.
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 trivial single-resource read with 100% schema coverage and readOnlyHint, the description covers what is needed to invoke it correctly. With no output schema, it could say a little more about the returned transfer object, but that is a minor gap for this tool's 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 description coverage is 100% and the single ach_transfer_id parameter is fully documented in the schema with an example format. The description only restates 'by id' and the path template, adding no meaning beyond the schema, so the 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?
Specific verb (Retrieve) plus resource (ACH transfer) with the 'single' qualifier that implicitly separates it from the sibling increase_list_ach_transfers. It also names the exact upstream endpoint, so an agent knows precisely what operation this wraps.
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?
Usage is implied by 'by id' and 'single', which tells the agent this is the detail-fetch counterpart to the list tool, but it never states when to prefer this over increase_list_ach_transfers or what to do if the id is unknown. No explicit alternatives or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single transaction by id. Increase API: GET /transactions/{transaction_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| transaction_id | Yes | Transaction id (e.g. transaction_...). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds the underlying REST endpoint (GET /transactions/{transaction_id}), which is mildly useful, but says nothing about not-found behavior, error handling, or freshness of the returned data. With annotations carrying the safety profile, a 3 is appropriate.
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 zero filler; the purpose is front-loaded and the endpoint detail is appended compactly. 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?
For a single-parameter read tool whose annotations already establish read-only safety, the description is largely complete; no output schema exists so return values need not be described. The minor gap is the absence of any not-found or error-behavior note.
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?
Only one parameter and schema description coverage is 100%, so the schema already documents transaction_id and its example format. The description adds no format, constraint, or filtering semantics beyond what the schema provides, making the baseline 3 correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Retrieve) and resource (a single transaction) with the lookup key (by id), which implicitly distinguishes it from sibling list_transactions. It stops short of explicitly naming the list alternatives, so differentiation is inferred rather than stated.
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?
Usage is implied by 'by id' versus the list_* siblings, but there is no explicit when-to-use or when-not guidance, no mention of what to do if the id is unknown, and no routing to list_transactions for discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List account numbers (deposit routing/account number pairs). Increase API: GET /account_numbers. Filter by account and status (sent as status.in).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1–100. Default 100. | |
| cursor | No | Opaque pagination cursor from a previous response's next_cursor. | |
| status | No | Status filter (sent as status.in), e.g. active | disabled | canceled. | |
| account_id | No | Only account numbers for this account id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context on the API endpoint and that status is translated to status.in. It does not mention pagination mechanics or result shape, so it adds only modest value beyond the 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?
Three short sentences with the core purpose front-loaded and no filler. Slightly dense with the endpoint and filter notes, but 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?
For a read-only paginated list tool, annotations cover safety and the schema fully covers the four parameters, so the description's job is mainly identification, which it does, including the endpoint. No output schema exists but a list endpoint's return is self-evident; only the missing pagination/return mention 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?
Schema coverage is 100%, so all four parameters are already documented, including 'status.in' and the cursor semantics. The description merely restates the account/status filters without adding format or syntax detail beyond the schema. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource and clarifies the ambiguous term with the parenthetical '(deposit routing/account number pairs)', which separates it from increase_list_accounts. It also pins the underlying endpoint (GET /account_numbers). Sibling differentiation is implicit rather than by naming an alternative, so not quite 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?
'Filter by account and status' communicates the intended filtering use case, and the endpoint reference implies read-only listing. However it never states when to choose this over list_accounts or list_external_accounts, nor any exclusions. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List bank accounts. Increase API: GET /accounts. Filter by entity and status (sent as status.in).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1–100. Default 100. | |
| cursor | No | Opaque pagination cursor from a previous response's next_cursor. | |
| status | No | Account status filter (sent as status.in), e.g. open | closed. | |
| entity_id | No | Only accounts belonging to this entity id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read. The description adds the underlying endpoint (GET /accounts) and the fact that status is transmitted as status.in, which is modest extra context. It says nothing about rate limits, default result size, or pagination behavior beyond what the schema already declares.
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 compact fragments, front-loaded with the purpose before the API detail and filter note. Efficient, though the endpoint string is developer-facing trivia that does little for tool selection.
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?
Adequate for a read-only list tool with full schema coverage and no output schema, so return values need no explanation. The notable gap is disambiguation from sibling list tools that also enumerate 'accounts'.
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 all four parameters are already documented in the schema, including the status.in encoding the description repeats. Baseline 3 is appropriate; the description adds no semantics 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?
States a specific verb and resource ('List bank accounts'), which is clear on its own. However, it never distinguishes itself from close siblings such as increase_list_external_accounts or increase_list_account_numbers, so an agent must infer that this covers primary Increase bank accounts only.
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 names the available filters (entity, status) and implies the tool is the way to enumerate accounts, but gives no explicit when-to-use guidance and no exclusions or alternatives against the many sibling list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List ACH transfers (read-only observability; this server does NOT create transfers). Increase API: GET /ach_transfers. Filter by account and status (sent as status.in).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1–100. Default 100. | |
| cursor | No | Opaque pagination cursor from a previous response's next_cursor. | |
| status | No | Status filter (sent as status.in), e.g. pending_submission | submitted | returned. | |
| account_id | No | Only ACH transfers for this account id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already assert readOnlyHint=true, and the description reinforces this with 'read-only observability; this server does NOT create transfers' — useful confirmation in a family that also contains create/mutate tools. It also exposes the HTTP method and path, adding an observable trait beyond the structured fields, though it says nothing about rate limits or result volume.
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 tight clauses with zero filler: purpose and read-only scope first, then endpoint, then filtering. Every sentence carries information an agent can act on.
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?
No output schema exists, so the description arguably should hint at the returned transfer shape and pagination model, yet it only mentions the cursor indirectly via the schema. For a 4-parameter read-only list tool whose parameters are fully documented, this is adequate but leaves return-value expectations to the API reference.
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 all four parameters (limit, cursor, status, account_id) are already documented in the schema. The description's 'Filter by account and status (sent as status.in)' restates what the status parameter already says, adding no new syntax or semantics — the baseline 3 for schema-covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List ACH transfers') and pins the underlying endpoint (Increase API: GET /ach_transfers). The resource is distinguishable from sibling list tools such as increase_list_wire_transfers and increase_list_check_transfers, though no sibling is named 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 description gives filtering context ('Filter by account and status') and a strong negative signal ('this server does NOT create transfers'), which implicitly steers creation intent elsewhere. However, it never states when to prefer this list tool over increase_get_ach_transfer for a single record, leaving that routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List cards. Increase API: GET /cards. Filter by account and status (sent as status.in). Read-only; no card actions are exposed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1–100. Default 100. | |
| cursor | No | Opaque pagination cursor from a previous response's next_cursor. | |
| status | No | Status filter (sent as status.in), e.g. active | disabled | canceled. | |
| account_id | No | Only cards for this account id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; the description restates 'Read-only' and adds that no card actions are exposed, which is marginally beyond annotations. It also notes the status filter is sent as status.in, but omits other behavioral details like auth or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with purpose, no wasted words. The API endpoint detail is slightly superfluous but overall concise.
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 list tool with full schema coverage and a read-only annotation, the description covers the essentials. It does not explain return format, but no output schema exists and the schema's cursor description implies pagination.
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 limit, cursor, status, and account_id. The description only reiterates account and status filtering without adding syntax or semantics beyond the schema (status.in is already in the schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List cards') and adds the API endpoint ('GET /cards'). It distinguishes the tool by resource (cards) from sibling list tools, though it does not explicitly name alternatives.
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 on when to use this tool versus alternatives like get_account or list_accounts. The description only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List check transfers (read-only observability; this server does NOT create transfers). Increase API: GET /check_transfers. Filter by account.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1–100. Default 100. | |
| cursor | No | Opaque pagination cursor from a previous response's next_cursor. | |
| account_id | No | Only check transfers for this account id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes the safety profile, and the description adds a genuinely useful behavioral claim beyond it: this server does NOT create transfers, so the agent should not look for a create counterpart. It does not, however, describe pagination behavior or result ordering.
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 tight sentences with no filler, and the read-only scoping note is front-loaded where it matters most. The 'Increase API: GET /check_transfers' fragment is slightly redundant with the tool name but cheap and orienting.
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 3-param, zero-required read tool with a fully covered schema and no output schema, the definition covers purpose, safety, and filtering adequately. Only minor gaps remain (pagination expectations, result shape).
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 limit, cursor, and account_id are fully documented in the schema. The description only restates the account filter ('Filter by account') and adds nothing about cursor/limit semantics, 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?
States a specific verb+resource ('List check transfers') and pins down the exact API surface (GET /check_transfers), which cleanly separates it from the many sibling list tools (ach_transfers, wire_transfers, real_time_payments_transfers). The parenthetical also pre-empts confusion about a create counterpart.
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 'Filter by account' hint and the read-only framing imply when this tool is appropriate, but no alternative is named and no exclusion condition is stated. An agent can infer the resource-based routing from the name, but the description never says 'use increase_list_ach_transfers instead when X'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List declined transactions. Increase API: GET /declined_transactions. Filter by account.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1–100. Default 100. | |
| cursor | No | Opaque pagination cursor from a previous response's next_cursor. | |
| account_id | No | Only declined transactions for this account id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read profile is covered structurally, and the GET endpoint citation reinforces it. The description adds nothing about pagination behavior (cursor semantics), volume, or rate limits, so it clears the lower annotated-bar only modestly.
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 fragments, front-loaded with the core action and free of filler. The endpoint citation is compact and informative, though the phrasing is telegraphic rather than polished prose.
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 list tool with full schema coverage and annotations, the description covers the essentials. It omits any note on pagination flow or how this differs from the general transaction-listing sibling, which is the main remaining gap given no output schema exists.
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 all three parameters (limit, cursor, account_id) are already documented in the schema. "Filter by account" merely echoes account_id without adding format or syntax detail, so the 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?
States a specific verb and resource ("List declined transactions") and even maps it to the underlying endpoint GET /declined_transactions. It implicitly separates itself from increase_list_transactions and increase_list_pending_transactions via the "declined" qualifier, but never explicitly distinguishes the three.
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?
"Filter by account" gives a hint about a common narrowing use, so usage is implied. However, with siblings like increase_list_transactions and increase_list_pending_transactions in the namespace, the description never says when to pick this one instead — no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List entities (the people/businesses — KYC records — that own accounts). Increase API: GET /entities. Filter by status (sent as status.in).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1–100. Default 100. | |
| cursor | No | Opaque pagination cursor from a previous response's next_cursor. | |
| status | No | Status filter (sent as status.in), e.g. active | archived | disabled. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read. The description adds mapping value ('GET /entities') and encodes the wire behavior of the status filter ('sent as status.in'), which is real context beyond the annotations. It stops short of describing pagination semantics or the shape of returned entity records.
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 compact sentences, front-loaded with the resource definition, then endpoint, then filter behavior. Nothing is padded, though the endpoint string and the parenthetical overlap slightly in what they convey.
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 read-only list tool with 100% schema coverage the description is adequate, but with no output schema an agent gets no hint of what entity records contain or how pagination terminates — only that a cursor exists in the schema. It covers purpose and filtering but leaves return-shape expectations unaddressed.
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 limit, cursor, and status are all documented in the schema itself. The description only restates the status filter's transmission format ('sent as status.in'), adding slight encoding detail but no new semantics for limit or cursor. Baseline 3 applies when the schema does the heavy lifting.
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?
Specific verb+resource ('List entities') with a useful domain gloss: 'the people/businesses — KYC records — that own accounts', which tells an agent what an entity is. The API endpoint mapping (GET /entities) reinforces it. It does not explicitly differentiate from siblings like increase_list_accounts, but the resource noun alone is distinctive enough to select correctly.
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 statement of when to use this tool, when not to, or which sibling to prefer (e.g., use list_entities to enumerate KYC owners vs list_accounts for accounts). The only guidance is a filter hint ('Filter by status'), which is parameter behavior, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List external (counterparty) bank accounts registered in Increase. Increase API: GET /external_accounts. Filter by status (sent as status.in).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1–100. Default 100. | |
| cursor | No | Opaque pagination cursor from a previous response's next_cursor. | |
| status | No | Status filter (sent as status.in), e.g. active | archived. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=true annotation already establishes this is a safe read operation, so the description only needs to add context. It contributes the underlying REST endpoint (GET /external_accounts) and the status.in query encoding, which are useful, but says nothing about pagination limits, result ordering, or empty results.
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, each earning its place: what it lists, the backing endpoint, and how filtering works. The core scope is front-loaded with zero 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 low-complexity read-only list tool with full schema coverage and a covering readOnlyHint annotation, the definition is nearly sufficient. A brief note on return shape or default pagination behavior would fully close the gap, but nothing critical 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?
Schema description coverage is 100%, so all three parameters (limit, cursor, status) are already documented in the schema. The description's note about status being sent as status.in duplicates the schema text rather than adding new meaning. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (external/counterparty bank accounts), and the parenthetical '(counterparty)' explicitly distinguishes it from the sibling increase_list_accounts, which lists internal accounts. An agent can pick the right tool without opening either 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?
It hints at usage by noting the status filter and its wire format, but gives no explicit when-to-use guidance, prerequisites, or exclusions relative to siblings like increase_get_account or increase_list_accounts. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pending (not-yet-settled) transactions. Increase API: GET /pending_transactions. Filter by account and status (sent as status.in).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1–100. Default 100. | |
| cursor | No | Opaque pagination cursor from a previous response's next_cursor. | |
| status | No | Status filter (sent as status.in), e.g. pending | complete. | |
| account_id | No | Only pending transactions for this account id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this as a safe read, so the description's remaining burden is light. It usefully adds the underlying API call (GET /pending_transactions) and the query-translation detail that status is sent as 'status.in', but says nothing about ordering, result completeness, or iteration depth.
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, front-loaded with the purpose, then endpoint, then filters. No filler and nothing redundant.
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 read-only list tool with full schema coverage on all four parameters and no output schema, the description covers what is needed to invoke it correctly. Only minor gaps remain, such as ordering and the meaning of the opaque cursor when no results are returned.
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 limit, cursor, status, and account_id are all documented in the schema itself; the description only restates the two filter parameters. Baseline 3 is correct since the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List pending transactions') and defines the scope precisely with 'not-yet-settled'. It is distinguishable from increase_list_declined_transactions, but it never explicitly contrasts itself with the sibling increase_list_transactions, which an agent could reasonably confuse it with.
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?
Usage is implied by the '(not-yet-settled)' scope and the named filters (account and status), giving the agent a sense of when this tool is appropriate. However, there is no explicit when-to-use, no exclusions, and no routing to alternatives such as increase_list_transactions or increase_list_declined_transactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Real-Time Payments (RTP) transfers (read-only observability; this server does NOT create transfers). Increase API: GET /real_time_payments_transfers. Filter by account.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1–100. Default 100. | |
| cursor | No | Opaque pagination cursor from a previous response's next_cursor. | |
| account_id | No | Only RTP transfers for this account id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this is a safe read, so the description's 'read-only observability' note is largely reinforcing. It adds a useful scope boundary (no transfers created on this server), but discloses nothing about pagination flow or result characteristics beyond what the annotations and schema already cover.
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?
Front-loaded with the core action, then scope boundary and API endpoint in terse clauses. Every fragment carries information; nothing is padded.
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?
No output schema exists, but for a simple filtered-list tool with fully documented parameters and a readOnly annotation, the description covers what an agent needs. Return shape and pagination mechanics are the only unaddressed items, and those are minor here.
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 limit, cursor, and account_id are fully documented in the schema. The description's 'Filter by account' merely signals the account_id filter and adds no syntax or format detail beyond the schema, which is the expected 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?
States a specific verb (List) and resource (Real-Time Payments transfers) and expands the RTP acronym. This clearly distinguishes it from the many sibling list tools (wire, ACH, check, card transfers), so an agent can select it 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 implies usage ('Filter by account') and clarifies the boundary ('this server does NOT create transfers'), but it never states when to prefer this over sibling list tools or what prerequisites exist. Usage context 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.
List settled transactions. Increase API: GET /transactions. Filter by account, category (sent as category.in), and created date range (created_at.after / created_at.before).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1–100. Default 100. | |
| cursor | No | Opaque pagination cursor from a previous response's next_cursor. | |
| category | No | Transaction category filter (sent as category.in). | |
| account_id | No | Only transactions for this account id. | |
| created_after | No | ISO 8601 timestamp; only transactions created at/after this (sent as created_at.after). | |
| created_before | No | ISO 8601 timestamp; only transactions created before this (sent as created_at.before). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already establishes this as a safe read operation, so the bar is lower. The description adds the important 'settled' scope and documents the underlying query parameter mapping (category.in, created_at.after/before), but does not state pagination semantics beyond what the schema's cursor field implies. Acceptable but not rich.
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, each earning its place: purpose, endpoint, and filter semantics. No filler, no redundancy, and the core scope ('settled transactions') 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 read-only list tool with full schema coverage and readOnlyHint, the description is sufficient: it names the resource, the endpoint, and the filterable dimensions. It stops short of describing pagination behavior or explicitly ruling out pending/declined transactions, which the sibling list makes relevant.
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 defines every parameter, including the API-side parameter names. The description reinforces the filter mapping for category and date range but adds no syntax, format, or constraint details beyond the schema. 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?
States a specific verb and resource ('List settled transactions') and pins it to the concrete API endpoint GET /transactions. It is distinguishable from siblings by the word 'settled' and by the endpoint, though it does not explicitly contrast with increase_list_pending_transactions or increase_list_declined_transactions, which are the nearest neighbors.
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 says what can be filtered (account, category, date range) but gives no explicit when-to-use or when-not-to-use guidance. With siblings like increase_list_pending_transactions and increase_get_transaction present, the agent must infer that this tool covers settled transactions and that single-transaction retrieval goes elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List wire transfers (read-only observability; this server does NOT create transfers). Increase API: GET /wire_transfers. Filter by account.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1–100. Default 100. | |
| cursor | No | Opaque pagination cursor from a previous response's next_cursor. | |
| account_id | No | Only wire transfers for this account id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered structurally; the description usefully reinforces this by asserting the server does not create transfers. It adds little else behaviorally — no mention of result caps, ordering, or how the cursor/next_cursor cycle behaves beyond what the schema text already says.
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, front-loaded clauses with no filler; the purpose and the read-only disambiguation come first. The 'Increase API: GET /wire_transfers' fragment is slightly redundant given the title, but it is compact and earns its place as an implementation anchor.
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-required-parameter list tool with full schema coverage, the description covers purpose, read-only scope, and the filter dimension. With no output schema an agent might still want to know the return shape or default page size, but that is a minor gap for a simple listing endpoint.
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 limit, cursor, and account_id are fully documented in the schema. The description's 'Filter by account' merely restates account_id's purpose without adding format or constraint detail, so the 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?
States a specific verb and resource ('List wire transfers') and explicitly disambiguates from the mutating counterpart by noting the server does NOT create transfers. Naming the underlying endpoint (GET /wire_transfers) further pins the operation, so an agent can distinguish it from sibling read tools like increase_list_transactions or increase_get_transaction.
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?
'Filter by account' hints at how to narrow results, and the read-only/no-create note frames the safe use case. However, it never states when to prefer this over siblings such as increase_list_transactions or increase_get_transaction, nor does it warn about pagination-driven iteration, leaving usage largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a 9-digit ABA routing number to see which real-time services (ACH, Real-Time Payments, wire) that bank supports. Increase API: GET /routing_numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1–100. Default 100. | |
| cursor | No | Opaque pagination cursor from a previous response's next_cursor. | |
| routing_number | Yes | 9-digit ABA routing number to look up (query param routing_number). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered structurally. The description adds that the response tells you which payment rails the bank supports, which is useful return-value context, but says nothing about not-found behavior, errors, or rate limits.
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 tight sentences: the behavioral payload ('which real-time services the bank supports') leads, followed by the API endpoint for reference. No filler or repetition.
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-in-practice lookup with no output schema, the description conveys what the caller gets back and the endpoint reference, and annotations cover the read-only nature. Only the error/not-found case is unaddressed, 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?
Schema description coverage is 100%, so all three parameters (routing_number, limit, cursor) are already documented, including the 9-digit pattern and pagination semantics. The description's mention of '9-digit ABA routing number' merely restates the schema, so the 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?
States a specific verb ('look up') and resource ('9-digit ABA routing number') and goes further by describing what the lookup reveals: which real-time services (ACH, Real-Time Payments, wire) the bank supports. No sibling tool overlaps with routing-number lookup, so no disambiguation is needed.
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?
Usage is implied by the nature of a lookup endpoint, but the description never states when to reach for this tool versus alternatives, nor any preconditions (e.g., needing a valid 9-digit number before calling). No exclusions or sibling routing are offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only banking and personal finance for AI agents: accounts, transactions, spending, budgets.
A household's bank accounts and the context behind them, for any AI. Read-only to banks.
Ask your AI about your own Australian bank accounts. It is read-only at the bank.
Ask your AI about your own accounts, debts, budgets and goals. OAuth sign-in, read-only by default.
Add one secure layer between your agents and this server.
