Click on "Deploy 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., "@is-bankasi-mcp What is the current USD/TRY exchange rate?"
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 Isbank (Is Bankasi) developer API (Turkey). Access accounts, balances, transactions, exchange rates, transfers, and credit cards via OAuth 2.0 authentication.
Tool | Description |
| List bank accounts |
| Get account balance |
| Get account transactions |
| Get current exchange rates |
| Initiate EFT/FAST/havale transfer |
| Check transfer status |
| List credit cards |
| Get credit card transactions |
Related MCP server: maib-mcp
{
"mcpServers": {
"isbank": {
"command": "npx",
"args": ["-y", "@theyahia/is-bankasi-mcp"],
"env": {
"ISBANK_CLIENT_ID": "<YOUR_CLIENT_ID>",
"ISBANK_CLIENT_SECRET": "<YOUR_CLIENT_SECRET>"
}
}
}
}Variable | Required | Description |
| Yes | OAuth client ID from Isbank developer portal |
| Yes | OAuth client secret from Isbank developer portal |
"Show me all my Isbank accounts"
"What is the balance of account ACC001?"
"List transactions from March 2026 for my main account"
"What is the current USD/TRY exchange rate?"
"Transfer 5000 TRY to IBAN TR123456 via FAST"
"Show my credit card transactions for this month"
MIT
Get account balance by account ID
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | Account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'Get' indicates a read operation, but the description does not elaborate on return format, error behavior, or whether the balance includes pending transactions. It discloses the fundamental read-only nature but lacks additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core purpose, and contains no superfluous words. It is appropriately sized for a simple single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description tells the agent exactly what it does and what input is required. However, the lack of output schema means the agent does not know the exact return structure (e.g., number vs. object), so it is not fully complete. Still, it covers the essential context for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the only parameter (account_id) with a clear description, so the baseline is 3. The description's 'by account ID' merely echoes the schema without adding new meaning, such as format constraints or default values.
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 resource ('account balance'), clearly distinguishing it from sibling tools like get_accounts (which lists accounts) and get_transactions. It also specifies the scope ('by account ID'), indicating a single-account lookup, so it is 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 implies usage when a specific account balance is needed, but it provides no explicit guidance on when to prefer this over alternatives like get_accounts or get_transactions. It does not mention any exclusions or alternative conditions, leaving the agent to infer the appropriate context 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.
List bank accounts
| Name | Required | Description | Default |
|---|---|---|---|
| account_type | No | Account type filter | ALL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'List' implies a read-only operation, providing minimal behavioral disclosure. However, since no annotations are present, the description carries the full burden and omits important details like whether it returns summary or detailed data, pagination, or account statuses. This is insufficient for a tool with zero annotation support.
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 that is front-loaded and free of filler. It efficiently communicates the tool's essence without unnecessary detail, scoring high on conciseness and structure.
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?
Despite the tool's low complexity (one optional parameter), the description is incomplete for effective tool selection. It lacks any context about how this tool relates to sibling tools, what the return structure is (no output schema), or any behavioral notes, making it only marginally useful for an agent deciding whether to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the only parameter (account_type) with an enum and description 'Account type filter', achieving 100% coverage. The tool description adds no additional parameter semantics, but the baseline of 3 holds because the schema already provides complete 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 'List bank accounts' uses a specific verb ('List') and a clear resource ('bank accounts'), making the core purpose unmistakable. However, it does not explicitly distinguish itself from sibling tools like get_credit_cards, which might also list financial accounts, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_account_balance or get_transactions. The description gives no context about typical use cases, prerequisites, or filters beyond the schema's parameter, leaving the agent without selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get credit card transactions
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| card_id | Yes | Credit card ID | |
| end_date | No | End date (YYYY-MM-DD) | |
| per_page | No | Items per page | |
| start_date | No | Start date (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral details. It does not mention pagination, date filtering, read-only assurance, rate limits, or any other operational characteristics, leaving the agent without essential safety and behavior context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and concise, but it is under-specified. It lacks substance and does not earn its place by conveying necessary context beyond what the name already implies.
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 five-parameter schema and no output schema, the description is severely incomplete. It fails to mention pagination, date range, required card_id, or differences from sibling tools, leaving crucial context missing for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters are described in the schema with 100% coverage, so the baseline is 3. The description adds no additional nuance to the parameters, but the schema already provides adequate descriptions for each field.
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 fetches credit card transactions, with a specific verb and resource. However, it does not distinguish this from the sibling tool 'get_transactions', so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus 'get_transactions' or other alternatives. The description lacks any contextual cues for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List credit cards
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only states a list operation, adding no detail about return format, pagination, authentication, or whether the operation is read-only. The transparency is minimal and adds little beyond the name.
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 and front-loaded, consisting of only three words. Every word is purposeful and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is incomplete for an agent to fully understand what to expect. It does not mention return fields, list structure, or any filtering capabilities, and it does not differentiate from sibling tools enough to guide correct selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers the input space (100% coverage). The description adds no parameter details, but with no parameters in existence, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and the resource (credit cards), which is specific and unambiguous. It distinguishes itself from sibling tools like get_accounts and get_card_transactions by focusing on the credit cards entity itself.
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. The description offers no context on prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage solely 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.
Get current exchange rates
| Name | Required | Description | Default |
|---|---|---|---|
| currency_codes | No | Specific currency codes (e.g. ['USD', 'EUR']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It merely says 'current' and gives no information about output format, default behavior, data freshness, or side effects. For a read-only tool, the lack of explicit disclosure 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 sentence with no wasted words. It is concise and front-loaded, but it is so minimal that it borders on under-specification. Still, conciseness is not the issue; the content is fine as far as it goes.
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 has no output schema and no annotations, but the description does not explain what the tool returns, whether all currencies are returned when currency_codes is omitted, or any default behavior. This leaves important gaps for a tool with optional input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter, including an example. The description adds no parameter-specific meaning beyond the schema. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair: 'get' and 'current exchange rates'. It is distinct from sibling tools like account or transaction tools. However, it does not add any nuance beyond the tool name itself, so it does not fully earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of when to omit the optional currency_codes parameter. The description gives no context for tool selection or invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get account transactions
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| end_date | No | End date (YYYY-MM-DD) | |
| per_page | No | Items per page | |
| account_id | Yes | Account ID | |
| max_amount | No | Maximum amount | |
| min_amount | No | Minimum amount | |
| start_date | No | Start date (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'get', implying a read operation, but does not mention return structure, pagination, filtering, authentication, or rate limits. The schema hints at these, but the description adds no behavioral context beyond the name.
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 redundant words. It is efficiently front-loaded, though it sacrifices detail for brevity.
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 7 parameters, rich filtering/pagination options, and lack of output schema, the description is severely under-specified. It does not mention date ranges, amount filters, pagination, or return format, making it incomplete for an agent to fully understand the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description adds no parameter-specific meaning beyond what the schema already provides, which matches 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 'Get account transactions' clearly states the verb 'get' and the resource 'account transactions', distinguishing it from sibling get_card_transactions. It lacks detail about scope, but the core purpose is 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?
No guidance is provided on when to use this tool versus alternatives like get_account_balance or get_card_transactions. The description does not mention prerequisites, alternatives, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get transfer status by ID
| Name | Required | Description | Default |
|---|---|---|---|
| transfer_id | Yes | Transfer ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Get', implying a read-only operation, but does not disclose any additional behavioral traits such as required permissions, response format, error handling, or whether the status is real-time. The description adds minimal value beyond the verb itself.
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: 'Get transfer status by ID'. It is concise, immediately clear, and contains 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?
The tool is simple with one well-documented parameter, but there is no output schema and the description does not elaborate on what a 'status' looks like or how to handle invalid IDs. It is minimally viable but lacks additional context that would fully prepare an agent for using the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the only parameter (transfer_id). The description says 'by ID', which aligns with the schema but does not add any new meaning. Since the schema fully documents the parameter, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is highly specific: verb 'get' + resource 'transfer status' + method 'by ID'. It clearly distinguishes from sibling tools like get_transactions (list) and initiate_transfer (write) by focusing solely on transfer status lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is only implied by the name and description. There is no explicit statement about when to use this tool (e.g., after initiating a transfer) or how it differs from alternatives. The description simply states the function without adding contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initiate a money transfer (EFT/FAST/havale)
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Transfer amount | |
| currency | No | Currency | TRY |
| description | No | Transfer description | |
| receiver_iban | Yes | Receiver IBAN | |
| receiver_name | Yes | Receiver name | |
| transfer_type | No | Transfer type | FAST |
| sender_account_id | Yes | Sender account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Initiate a money transfer' implies a mutable action, but the description does not disclose potential side effects (e.g., funds leave the sender, irreversibility), required permissions, or possible errors. For a financial operation, this is a significant transparency 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 front-loaded sentence with no redundant words. It effectively states the tool's action and scope. However, for a tool with 7 parameters and no annotations, the extreme brevity edges toward under-specification, but it still earns a 4 for being clear and focused.
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 complexity (7 params, mutation, no annotations, no output schema), the description is incomplete. It does not explain return values (e.g., transfer ID or status), behavioral nuances (e.g., differences between EFT, FAST, and HAVALE), or constraints (e.g., processing time or limits). The description leaves too much to inference for a high-stakes financial operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a description (e.g., 'Sender account ID', 'Receiver IBAN'). The tool description adds only the transfer-type enumeration (EFT/FAST/havale), which duplicates the enum in the schema. The description does not add meaningful semantic value beyond the schema, but the schema fully covers parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Initiate') and clearly identifies the resource ('money transfer'), while also enumerating the transfer types (EFT/FAST/havale). This distinguishes the tool from sibling tools, which are all read-only getters (e.g., get_accounts, get_transactions), making 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 clearly conveys when to use this tool: to start a money transfer. Since all sibling tools are read-only (get_accounts, get_balance, get_transactions, etc.), it is implicitly the only tool for initiating transfers, and no exclusions are needed. However, it doesn't explicitly name alternatives or prerequisites (e.g., sufficient funds), so it doesn't earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.1get_account_balanceget_accountsget_card_transactionsget_credit_cardsget_exchange_ratesget_transactionsget_transfer_statusinitiate_transferScored across 8 tools
Each tool targets a distinct resource and action: accounts, balances, transactions, exchange rates, transfers, and cards are clearly separated. There is no overlap between getting account transactions versus card transactions, and transfer initiation/status checking are unambiguous.
Seven of eight tools follow the 'get_' verb-noun pattern, making the set highly predictable. 'initiate_transfer' deviates by using an action verb rather than 'get_', which is a minor inconsistency but does not cause confusion.
With 8 tools, the server is well-scoped for a banking API covering accounts, transactions, cards, exchange rates, and transfers. Each tool serves a distinct purpose, and the number feels appropriate without being overwhelming or sparse.
The toolset covers core banking workflows: listing accounts, checking balances, viewing transactions, managing transfers, and accessing card data. Minor gaps exist, such as lacking a dedicated transfer history or card details endpoint, but agents can work around these using existing tools.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Bank of Israel public API MCP. Keyless.
Hosted MCP server with managed OAuth for 15+ toolkits: Google Workspace, Fitbit, Oura, Kalshi, etc.
MCP server for Modern Treasury — payment orders, transactions, counterparties and ledgers.
