is-bankasi-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.2/5 across 8 of 8 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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.
Conciseness2/5
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.
Completeness1/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![is-bankasi-mcp MCP server](https://glama.ai/mcp/servers/theYahia/is-bankasi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/theYahia/is-bankasi-mcp)

Score Badge

Copy to your README.md:

[![is-bankasi-mcp MCP server](https://glama.ai/mcp/servers/theYahia/is-bankasi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/theYahia/is-bankasi-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/theYahia/is-bankasi-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server