Read-only Increase banking observability plus one safe non-money-moving write, for AI agents.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 17 of 18 tools scored. Lowest: 3.2/5.
Each tool targets a distinct resource type (account, account number, ACH transfer, etc.) with clear verb_noun naming, making them easily distinguishable.
All tools follow a consistent `increase_verb_noun` pattern in snake_case, with verbs like create, get, list, lookup.
18 tools is slightly above the typical 3-15 range, but the scope of banking operations (accounts, transfers, transactions, cards, entities) justifies the count.
The server is heavily read-only with only one mutation (create_external_account). Missing create/update/delete for accounts, transfers, cards, etc., which limits its usefulness for full banking workflows.
increase_create_external_accountCreate external accountARegisters 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?
The description adds value beyond annotations by stating the tool is non-monetary ('MOVES NO MONEY') and gives the API endpoint. Annotations already provide destructiveHint=true, so the description reinforces but does not contradict.
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?
Description is two sentences with no filler. Key information is front-loaded and every word contributes to clarity.
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 creation tool with 5 well-documented parameters and no output schema, the description covers the core purpose and constraints. Missing details like error handling are acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully described in the schema. The description does not add extra semantics beyond the schema, meeting the baseline of 3.
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 registers an external bank account for future transfers and explicitly clarifies it does not move money. This distinguishes it from transfer siblings and provides a specific verb-resource-scope combination.
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 clarifies that this tool only creates a record and does not initiate transfers, guiding agents to use other tools for money movement. However, it does not explicitly list when not to use it or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_get_accountGet accountARetrieve 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 description adds the API endpoint. It does not cover error handling, rate limits, or other behavioral traits, but the safety profile is clear from 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?
The description is extremely concise with one sentence and an API reference. No unnecessary words; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one required parameter and readOnlyHint, the description is sufficient. It could mention the return format, but overall it is complete enough given the context.
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% with a clear description for account_id. The description reiterates that it retrieves by id, which adds little 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?
The description clearly states it retrieves a single bank account by id, with a specific verb and resource. It distinguishes from siblings like increase_list_accounts (which lists) and increase_get_account_balance (which gets balance).
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 when you need a specific account by id, but it does not explicitly state when to use this versus alternatives like increase_list_accounts or increase_get_account_balance. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_get_account_balanceGet account balanceARetrieve 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?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds value by specifying that both current and available balance are returned, and that an optional point-in-time query is supported. No contradictions 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?
The description is extremely concise: two sentences capture purpose, endpoint, and optional behavior. Every sentence adds meaningful information, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately hints at return values (current and available balance). It covers the essential purpose and optional historical query. Some detail on response format or error cases could improve completeness, but it is sufficient for standard usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description's role is reduced. The description mentions 'optionally as of a point in time' which aligns with the at_time parameter, but it adds minimal detail beyond the schema's parameter descriptions. Hence, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an account's current and available balance, and provides the exact API endpoint. The purpose is specific and well-distinguished from siblings like "increase_get_account" which retrieves full account details.
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 implicitly indicates when to use this tool (when an account's balance is needed) and mentions the optional time parameter for historical queries. However, it does not explicitly state when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_get_ach_transferGet ACH transferBRetrieve 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?
The readOnlyHint annotation already signals a safe read operation, but the description adds no behavioral context beyond that. It does not disclose error behaviors, rate limits, or auth requirements, which would be valuable for agents relying solely on the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose, followed by a minimal API reference. Every character earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with one parameter and no output schema, the description is adequate but minimal. It lacks explanation of return values or error conditions, which would improve completeness for an agent.
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% with the parameter clearly documented. The description does not add new semantics beyond the schema; the mention of 'by id' reinforces but does not extend 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?
The description clearly states the verb 'Retrieve', the resource 'ACH transfer', and the required identifier 'by id'. It distinguishes from sibling list tools (e.g., increase_list_ach_transfers) and other get tools by specifying the exact resource.
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 provided on when to use this tool versus alternatives like increase_list_ach_transfers. The description lacks explicit context for when-to-use or when-not-to-use, leaving the agent to infer from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_get_transactionGet transactionARetrieve 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. Description adds API endpoint method but no additional behavioral traits 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?
Two sentences, no fluff, front-loaded with action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks return value description and error cases. Adequate for a simple get tool but could be 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% with example. Description does not add meaning beyond what 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?
Clear verb 'retrieve' with resource 'a single transaction by id', distinguishes from list tools. API endpoint explicitly 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?
Implied usage when you have a transaction_id, but no explicit guidance on when to use this vs. other get tools like get_account. Sibling tools not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_list_account_numbersList account numbersAList 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?
The description adds behavioral context beyond the readOnlyHint annotation by specifying the exact API path (GET /account_numbers) and detailing how filters are sent (e.g., 'status.in'). It does not cover all behaviors like pagination details (though the schema covers limit and cursor) or rate limits, but the added info is valuable for understanding the API interaction.
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 brief, at two sentences, and front-loads the core action. While it could be more structured (e.g., using bullet points for filters), it avoids unnecessary detail and is efficiently written. Every sentence contributes value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list operation), the description provides the essential purpose and filtering context. However, it lacks details about the response format or pagination behavior beyond the cursor parameter. Since there is no output schema, the description could have included what the response contains (e.g., object array with id, routing, account number). Still, for a straightforward list tool, it is minimally adequate.
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?
With 100% schema description coverage, the baseline is 3. The description adds value by clarifying that the status parameter is sent as 'status.in' in the query string, which is not obvious from the schema alone. This helps the agent correctly construct the API call. The other parameters are adequately described in the schema, so the overall parameter semantics are well-served.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', resource 'account numbers', and explains they are 'deposit routing/account number pairs'. It also mentions the API endpoint and filtering options, making the purpose unmistakable. This distinguishes it from sibling tools like 'increase_list_accounts' which lists accounts themselves.
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 indicates the tool lists account numbers with optional filters, implying its use for retrieving such data. However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., when account IDs are known vs. needing to list all), nor does it state when not to use it. The context of sibling tools helps but the description itself lacks explicit usage recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_list_accountsList accountsAList 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?
Annotations already declare readOnlyHint=true, so the description need not restate safety. It adds no further behavioral details (e.g., rate limits, authentication). Adequate but minimal value beyond 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?
The description is three short sentences, conveying essential information without fluff. Could be slightly better structured, but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should ideally mention return format or pagination. It only says 'List bank accounts' without clarifying the response structure. Adequate given sibling tools have similar minimalism.
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 each parameter already has a description. The description rephrases filters but adds no new information; 'sent as status.in' is already in the schema. No additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('bank accounts'), and distinguishes from sibling tools like 'get_account' (singular) by explicitly using plural '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 mentions filtering options but provides no guidance on when to use this tool versus alternatives like 'increase_get_account' for a single account or other list tools. Implicit use case only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_list_ach_transfersList ACH transfersAList 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?
The annotations already declare readOnlyHint=true. The description adds that the server does not create transfers and mentions the API endpoint, but does not elaborate on pagination or response behavior. It reinforces the annotation without adding substantial new behavioral insights.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The key points are front-loaded, 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?
Given the absence of an output schema, the description covers the main purpose and parameters adequately. It could mention pagination (cursor/limit) or that the response is a list, but the current content is mostly complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters. The description adds value by clarifying that the 'status' filter is sent as 'status.in', which is a helpful detail beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'ACH transfers', and distinguishes from siblings by emphasizing that it is read-only and does not create transfers. This makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: read-only observability, not for creation, and mentions filtering by account and status. It lacks explicit exclusions or alternative tool references, but the context is sufficient for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_list_cardsList cardsAList 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 adds 'Read-only; no card actions are exposed' and specifies the API endpoint, but does not discuss pagination behavior, error handling, or other operational details beyond what annotations 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?
The description is concise (three sentences) with the purpose front-loaded. Every sentence adds distinct value: purpose, API endpoint, filtering, and safety clarification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 optional parameters and no output schema, the description adequately covers purpose and safety but does not hint at response structure or pagination behavior. Schema descriptions fully cover parameters, so completeness is adequate but not enriched beyond that.
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 baseline is 3. The tool description repeats the schema's filter details (account and status with 'status.in') without adding new meaning or clarifying parameter formats beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List cards' as the verb+resource, and the title 'List cards' reinforces this. Among siblings, it is the only tool for listing cards, so it is well-distinguished.
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 mentions filtering by account and status, implying usage for listing cards with optional filters. However, it does not explicitly state when to use this tool versus alternative tools (e.g., for card creation or updates) or provide when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_list_check_transfersList check transfersAList 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 description adds significant value beyond the readOnlyHint annotation by explicitly stating the server does NOT create transfers, which is a critical behavioral trait. It also provides the API endpoint, enhancing transparency without contradicting 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?
The description is extremely concise: a single sentence followed by the API endpoint and filter note. Every part is essential and front-loaded, achieving maximum efficiency.
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?
While the description covers key aspects (read-only, API, filter), it lacks any indication of the return format or structure. Since there is no output schema, a brief mention of the response type would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for all three parameters. The description only mentions 'Filter by account,' which is already in the schema, adding no new semantic 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?
The description clearly states the verb 'List' and the resource 'check transfers', explicitly notes it is read-only and does not create transfers, and mentions filtering by account. This distinguishes it from creation tools and other list tools in the sibling set.
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 basic context (read-only, filter by account) but does not explicitly compare this tool to sibling list tools (e.g., list_ach_transfers, list_wire_transfers) or state when to prefer it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_list_declined_transactionsList declined transactionsAList 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, and the description adds 'GET /declined_transactions' which reinforces read-only behavior. However, no additional behavioral traits (e.g., rate limits, idempotency) are disclosed beyond what annotations provide.
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, no unnecessary words. The first sentence immediately states the purpose, and the second adds endpoint and filtering capability. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description states the tool lists declined transactions but doesn't describe the return structure (e.g., pagination, fields). The cursor parameter hints at pagination, but the description could be more complete for a tool with no output schema.
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 parameters (limit, cursor, account_id) are fully documented in the schema. The description mentions 'Filter by account' which is redundant with the account_id parameter description, 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?
Description clearly specifies 'List declined transactions' and gives the API endpoint. It implicitly distinguishes from sibling 'increase_list_transactions' which lists all transactions, so the agent knows this tool is for declined ones 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?
No guidance on when to use this tool versus alternatives like 'increase_list_transactions' or 'increase_list_pending_transactions'. The description only says 'Filter by account' without explaining when filtering is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_list_entitiesList entitiesAList 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?
Annotations already declare readOnlyHint=true, so the description's mention of listing adds minimal behavioral context. It clarifies that entities are KYC records, but doesn't disclose pagination behavior 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 sentences, direct and efficient. No fluff; each sentence serves a purpose: defining entities and describing endpoint/filter.
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 list tool with 3 params, no output schema, and annotations, the description is mostly complete. It covers entity type and filter, but lacks mention of pagination behavior or how to use the cursor beyond schema.
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%; description adds syntax detail 'sent as status.in' for the status parameter, which is value beyond the schema's description. Other parameters (limit, cursor) rely on 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?
Description clearly states 'List entities (the people/businesses — KYC records — that own accounts)' using a specific verb+resource. It distinguishes from sibling list tools (e.g., list_accounts, list_transactions) by specifying entities are KYC records.
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 list_accounts or list_external_accounts. Only mentions filtering by status, not context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_list_external_accountsList external accountsAList 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?
Annotations indicate readOnlyHint=true, and the description reinforces read-only behavior with 'List'. It adds context on cursor-based pagination and the status filter (sent as status.in), providing useful behavioral details beyond 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 concise sentences: first states purpose, second adds filtering. No wasted words, front-loaded with key action.
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, but the description is adequate for a list tool. It explains the endpoint and filter but does not detail return format or pagination behavior beyond cursor, which is acceptable for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-documented. The description adds a minor detail about the status filter ('sent as status.in') but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List external (counterparty) bank accounts registered in Increase' with a specific verb and resource, and distinguishes from sibling list tools by focusing on external accounts. It also references the Increase API endpoint.
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 mentions filtering by status but lacks explicit guidance on when to use this tool versus other list tools. No alternatives or exclusions are provided, leaving usage context implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_list_pending_transactionsList pending transactionsAList 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?
Annotations already provide readOnlyHint=true; the description adds the GET endpoint and filter semantics, but does not disclose additional behavioral traits like rate limits or auth requirements beyond what annotations 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?
The description is concise (three lines) and front-loaded with the purpose, endpoint, and filter hint, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no output schema), the description adequately covers purpose and filtering. It omits pagination details but those are in the schema; overall sufficient for a list tool with good annotations.
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 baseline is 3. The description adds value by explaining that 'status' is sent as 'status.in', providing context beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List pending (not-yet-settled) transactions' with a specific verb and resource, and distinguishes from siblings like 'increase_list_transactions' by focusing on pending status.
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 implicitly guides usage by specifying 'pending transactions' and mentioning filter parameters, but does not explicitly state when not to use it or compare alternatives among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_list_real_time_payments_transfersList Real-Time Payments transfersAList 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?
Annotations already provide readOnlyHint=true. Description reinforces that the server does not create transfers, but adds minimal new behavioral insight beyond the annotation.
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 concise sentences with front-loaded purpose and key constraints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple list operation with no output schema and good annotations, the description covers all essential information: purpose, safety, and filtering.
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 baseline is 3. Description mentions 'Filter by account' which matches account_id, but adds no additional meaning beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists RTP transfers, specifies it's read-only, and distinguishes from other list tools (e.g., list_ach_transfers) by naming the resource. The verb 'List' is specific.
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?
Explicitly states read-only observability and that creation is separate, setting clear context. Does not name alternative tools for filtering or other operations, so slightly less than perfect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_list_transactionsList transactionsAList 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?
Annotations already provide readOnlyHint: true, indicating no side effects. The description adds that the tool lists settled transactions and supports filtering, but does not disclose additional behavioral traits such as pagination behavior or rate limits. It does not contradict 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?
The description is extremely concise: two sentences covering purpose and key details. It is front-loaded with the core function and avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description provides a good overview of filtering capabilities but does not mention pagination (cursor, limit) or the return format. However, the title and parameter descriptions compensate somewhat.
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 input schema already documents each parameter. The description summarizes filtering options but does not add new semantics beyond what is already in the schema. 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 clearly states 'List settled transactions', which provides a specific verb and resource. It distinguishes from sibling tools like 'increase_list_pending_transactions' and 'increase_list_declined_transactions' by specifying that only settled transactions are returned.
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 does not explicitly state when to use this tool versus alternatives like list_pending_transactions or get_transaction. Usage is implied by the term 'settled', but no direct guidance or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_list_wire_transfersList wire transfersAList 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?
The description adds valuable context beyond the 'readOnlyHint' annotation by stating the server does not create transfers and highlighting the read-only observability nature. This reinforces the behavioral trait without contradiction.
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 extremely concise with two sentences covering purpose, read-only nature, API endpoint, and filtering capability. Every sentence adds value without any fluff 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?
Given the tool's simplicity (3 parameters, no output schema), the description is largely complete. It covers the essential behavioral and usage context. However, it does not explicitly describe the return format, though this is a minor gap for a list operation with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description adds minimal extra semantic meaning beyond the schema (e.g., 'Filter by account' reiterates the account_id parameter). No additional benefit is provided for limit and cursor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists wire transfers, using a specific verb ('List') and resource ('wire transfers'). The tool name itself distinguishes it from siblings like 'increase_list_ach_transfers' by specifying 'wire_transfers'.
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 emphasizes that the tool is for read-only observability and explicitly states it does NOT create transfers, providing clear context for when to use it. It does not explicitly mention alternatives, but the tool name and resource type inherently differentiate it from sibling list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
increase_lookup_routing_numberLook up routing numberALook 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 provide readOnlyHint=true. The description adds value by specifying the services checked (ACH, Real-Time Payments, wire). However, it fails to mention that the query supports pagination (limit, cursor) as indicated in the schema. This omission could lead to incomplete understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first explains what the tool does, second provides the underlying API endpoint. No extraneous information. Front-loaded with key purpose.
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?
With no output schema, the description should clarify the return structure (e.g., a list of supported services). It mentions the services but not the format. Additionally, pagination is hinted only in the schema, leaving the AI to infer response shape. Completeness is adequate but not robust.
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 each parameter is already described. The tool description adds no additional parameter-specific details beyond the overall purpose. It does not explain how limit and cursor affect the lookup or that the response may be paginated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'look up', the resource '9-digit ABA routing number', and the outcome 'see which real-time services (ACH, Real-Time Payments, wire) that bank supports'. It uniquely identifies the tool's purpose and distinguishes it from sibling tools which deal with accounts, transfers, etc.
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 does not explicitly state when to use this tool versus alternatives. However, because no sibling tool performs a routing number lookup, the usage context is implied. The description could be improved by adding a note like 'Use this when you need to check a bank's real-time service capabilities.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
