Allows for checking Chase Bank account balances, viewing transaction history, accessing account statements, monitoring rewards, and previewing bill payments and transfers.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Chase MCP Server What's my current checking account balance and my recent transactions?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Chase Bank - let AI agents check accounts, view transactions, and manage finances.
Built by Strider Labs for the agentic commerce era.
Accounts - View all checking, savings, credit, investment, and loan accounts
Balances - Get current and available balances
Transactions - View recent transaction history
Bills - See payees and scheduled payments
Transfers - View transfer history and preview new transfers
Statements - Access account statements
Rewards - Check Ultimate Rewards points and cash back
Related MCP server: agent-browser-mcp
npm install @striderlabs/mcp-chaseAdd to your claude_desktop_config.json:
{
"mcpServers": {
"chase": {
"command": "npx",
"args": ["@striderlabs/mcp-chase"]
}
}
}This connector uses browser automation and requires stored cookies:
Log in to Chase in your browser
Export cookies to ~/.strider/chase/cookies.json
Use a browser extension like "Cookie-Editor" to export cookies in JSON format
Note: Chase uses MFA - you may need to re-export cookies periodically
This connector operates in read-only mode for sensitive operations
Transfers and bill payments provide preview only with manual completion instructions
No actual financial transactions are executed by this connector
All credentials are stored locally in ~/.strider/chase/
Tool | Description |
| Check login status |
| Clear stored session |
| List all accounts |
| Get account balance |
| Get transaction history |
| View bill pay payees |
| View transfer history |
| Get account statements |
| Check rewards balance |
| Preview a transfer (manual completion) |
| Preview a bill payment (manual completion) |
// Check if logged in
const auth = await chase_auth_check();
// Get all accounts
const accounts = await chase_accounts();
// Get transactions for an account
const txns = await chase_transactions({ accountId: accounts[0].id, limit: 10 });
// Check rewards
const rewards = await chase_rewards();Node.js 18+
Chase bank account
Stored session cookies
MIT - Strider Labs
Get all Chase accounts - checking, savings, credit cards, investments, and loans.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only states 'Get' without clarifying authentication requirements, rate limits, or whether the response includes sensitive data. Minimal behavioral context beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's 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?
Without an output schema, the description could state what information is returned for each account (e.g., account IDs, balances). It is minimally complete for a list operation, but lacks details about the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and is fully covered by description (no need to describe params). Baseline for 0 parameters is 4, and the description does not add irrelevant information.
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 'Get' and the resource 'all Chase accounts', listing specific account types (checking, savings, credit cards, investments, loans). This distinguishes it effectively from sibling tools like chase_balance and chase_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing all accounts, but it does not provide explicit guidance on when to use it versus siblings nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if user is logged in to Chase. Returns login status and instructions if not authenticated. Call this before any other Chase operations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns login status and instructions if not authenticated. For a read-only check without side effects, this is adequate. Could optionally mention that it does not modify state.
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, front-loaded with purpose, no wasted words. Essential information is presented efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple check tool with no parameters and no output schema, the description explains return value and context of use. Given sibling tools include auth_clear, the description is complete and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description adds meaning by explaining the tool's purpose and output. Baseline for 0 params is 4, and this description meets it.
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 checks login status and returns instructions if not authenticated. The verb 'check' is specific and resource 'user login status' is well-defined. It distinguishes from sibling 'chase_auth_clear' which likely clears authentication.
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 says 'Call this before any other Chase operations,' providing clear usage context. Does not mention when not to use or alternatives, but the context of an auth check makes the guidance sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear stored Chase session cookies. Use this to log out or reset authentication state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the destructive nature (clearing cookies) but does not elaborate on reversibility or effects on subsequent operations. Adequate for a simple action but lacks 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?
Two sentences with no waste. Front-loads the action and immediately gives use case. Perfectly 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?
Given zero parameters and no output schema, the description fully covers the tool's purpose and usage. No gaps remain.
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?
No parameters exist, so schema coverage is 100% trivially. The description adds no param info, which is acceptable since baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'clear' and resource 'stored Chase session cookies', and equates it to 'log out or reset authentication state'. This distinguishes it from sibling tools like chase_auth_check, which checks auth state.
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?
States when to use it: 'to log out or reset authentication state'. Does not explicitly mention when not to use or alternatives, but the context is clear and the sibling tools provide implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current balance for a specific account.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | The account ID to check balance for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It does not state that the operation is read-only, nor does it mention auth requirements, error handling, or what happens if accountId is invalid. This is a significant gap.
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, concise sentence with no wasted words. It is front-loaded and easy to parse, though it could be slightly more informative without losing conciseness.
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 and no annotations, the description should provide more context, such as the return format (e.g., numeric, string) or prerequisites (e.g., need accountId from chase_accounts). It feels incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for the single parameter (accountId). The tool description adds no additional meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the current balance for a specific account', which specifies a verb and resource. However, it does not differentiate between balance types (e.g., available vs ledger), slightly reducing specificity. It distinguishes from siblings like chase_transactions or chase_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?
No guidance on when to use this tool versus siblings such as chase_accounts (which might list account details) or chase_transactions. The description gives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview a bill payment. Does NOT execute the payment - provides instructions for completing it manually.
| Name | Required | Description | Default |
|---|---|---|---|
| payeeId | Yes | Payee ID to pay | |
| amount | Yes | Amount to pay | |
| date | No | Payment date (optional, defaults to immediately) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the non-execution behavior, which is critical for safety. However, it does not detail the format of the instructions returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no waste. The key information is front-loaded and every word is meaningful.
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 explains the return purpose ('provides instructions'), which is sufficient for a simple preview tool with 3 parameters.
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% coverage with clear descriptions for each parameter. The description adds no additional parameter information, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Preview'), the resource ('bill payment'), and explicitly says what it does not do ('Does NOT execute the payment'), distinguishing it from execution tools like 'chase_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 provides clear context that this is a preview only and requires manual completion, but does not explicitly mention when to use it over alternatives like 'chase_transfer_preview'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get bills and payees set up in Chase Bill Pay.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states it's a 'get' operation (read-only), but does not disclose any behavioral traits such as authentication requirements, caching behavior, or scope limitations. For a simple retrieval, this is minimally adequate.
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?
Single, front-loaded sentence of 8 words: 'Get bills and payees set up in Chase Bill Pay.' No wasted words, efficient and direct.
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 parameters and no output schema, the description could be more complete by hinting at the output structure or data fields. It tells what it retrieves but not what the response contains, leaving the agent to infer. Adequate for a simple tool but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters and schema description coverage is 100% (default). The description does not need to add parameter info since none exist. Baseline is high, and the description correctly implies no input is needed.
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 retrieves bills and payees set up in Chase Bill Pay, with specific verb 'Get' and resource 'bills and payees'. It easily distinguishes from sibling tools like chase_accounts and chase_bill_pay_preview by focusing on the already-set-up items.
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 explicit guidance on when to use this tool versus alternatives like chase_bill_pay_preview. Usage is implied: use when you need the list of existing bills/payees, but no exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Ultimate Rewards points and cash back balance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states what data is retrieved but does not disclose whether the values are current, available, or include pending items. There is no mention of authentication requirements 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?
A single sentence that front-loads the action and resource. No filler words, but could be slightly more informative without adding bulk.
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 parameters and no output schema, the description is fairly complete for a simple balance query, but it lacks context on whether the result includes total rewards across all accounts or a specific card, and does not mention if it returns separate values for points and cash back.
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 zero parameters and 100% schema coverage, the description adds value by specifying exactly what is fetched: points and cash back balance. This clarifies the data types beyond the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource as 'Ultimate Rewards points and cash back balance'. It distinguishes itself from sibling tools like 'chase_balance' (likely for checking/savings) and 'chase_transactions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'chase_balance' or 'chase_accounts'. It does not mention any prerequisites or context, leaving the agent to deduce usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available statements for an account.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | The account ID to get statements for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, or that it only returns statement availability (not the actual PDF). The agent lacks context on side effects or constraints.
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?
Extremely concise—single sentence with clear verb and object. However, it may be overly minimal, omitting useful context while still being 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 tool is simple (one parameter, no output schema). The description does not explain the return format (e.g., array of statement dates or IDs). Given sibling tools like chase_transactions likely have richer output, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter (accountId) is fully described in the schema (100% coverage). The description adds no further details, so the baseline of 3 applies. No enrichment 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 (get) and resource (statements) for a specific account. It distinguishes from sibling tools like chase_transactions or chase_balance, but could be more precise by indicating what 'available' means (e.g., 'lists downloadable statement periods').
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. For example, it doesn't clarify that this retrieves statement metadata (not balances or transactions) or that it's for viewing available statements before downloading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent transactions for an account.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | The account ID to get transactions for | |
| limit | No | Maximum number of transactions to return (default: 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only says 'Get recent transactions' without disclosing behavior like ordering, default limit, pagination, or error handling. The agent lacks behavioral context beyond a basic read.
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 of 5 words, efficient but overly terse. It lacks detail on what 'recent' means or the return format, which could be added without excessive length.
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 and no annotations, the description is insufficient for a tool with two parameters. It omits return value details, pagination, and ordering. Sibling tools are unrelated, but no usage context is provided.
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?
Both parameters are described in the schema with 100% coverage. The description adds minimal extra meaning; 'recent' implies a filter but no specifics. 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 'Get' and resource 'transactions' with the scope 'recent' and 'for an account'. It effectively distinguishes from siblings like chase_balance and chase_bills, though 'recent' could be more precise.
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 (e.g., chase_statements, chase_transfers). The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview a transfer between accounts. Does NOT execute the transfer - provides instructions for completing it manually.
| Name | Required | Description | Default |
|---|---|---|---|
| fromAccountId | Yes | Source account ID | |
| toAccountId | Yes | Destination account ID | |
| amount | Yes | Amount to transfer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description appropriately discloses the key behavior: it does not execute the transfer. It implies safety but could elaborate on idempotency or side effects.
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 that immediately convey purpose and limitation, with no 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?
For a simple preview tool with no output schema, the description is mostly sufficient but could specify what kind of instructions 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 coverage is 100%, so the description adds no additional parameter meaning beyond the schema's own 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 it previews a transfer between accounts and explicitly says it does not execute, distinguishing it from the sibling 'chase_transfers' tool.
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 it should be used to see transfer instructions without executing, but does not explicitly mention the alternative 'chase_transfers' for actual execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent transfer history.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It fails to mention that this is a read-only operation, whether authentication is required, or if there are limitations like pagination or date ranges. The tool name implies a read operation but is not explicitly stated.
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 (one sentence), but this brevity sacrifices important details. It is front-loaded with the core action but lacks any structure or additional context.
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 lack of annotations and output schema, the description is incomplete. It does not explain what 'recent transfer history' entails (e.g., fields returned, time range), leaving the agent without enough context to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema provides complete coverage. The description does not add meaning beyond the schema, but the baseline for no parameters is 4.
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 recent transfer history, which is a specific verb and resource. It distinguishes from sibling 'chase_transfer_preview' which likely handles previewing a new transfer, but does not explicitly differentiate.
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 'chase_transfer_preview' or 'chase_transactions'. The description gives no context about prerequisites or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect of Chase banking: accounts, auth, balance, bills, rewards, statements, transactions, and transfers. There is no overlap in purposes.
All tools follow a consistent 'chase_verb_noun' pattern (e.g., chase_accounts, chase_balance, chase_transactions). Naming is uniform and predictable.
With 11 tools covering account management, authentication, balances, transactions, bills, rewards, statements, and transfers, the count is well-scoped for a personal banking MCP.
Core read operations are present, but critical write actions (bill pay execution, actual transfers) are only previews without execution. Missing features like credit card details (beyond balance) and investment account actions. This creates gaps for full financial management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only bank access for your AI agent. Connects Claude, ChatGPT, Cursor, Gemini, Codex.
Connect AI agents to bank accounts, transactions, balances, and investments.
Read-only Increase banking observability plus one safe non-money-moving write, for AI agents.
Chat with your bank data: balances, transactions, budgets, bills. Reads only, never moves money.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/markswendsen-code/mcp-chase'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
