FIO Bank MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FIO_API_TOKEN | Yes | Your FIO Bank API token |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| fio_get_transactionsA | Get account transactions for a date range from FIO Bank. Returns account info (IBAN, BIC, balance) and transactions with:
Rate limit: 1 request per 30 seconds. Data older than 90 days requires unlock in internet banking. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
With only one tool exposed, there is no possibility of the agent selecting the wrong tool. Its purpose (fetching account transactions over a date range) is stated unambiguously.
The single name fio_get_transactions follows a clean namespace_verb_noun convention that would extend predictably. There is no competing convention to clash with.
One tool is far too thin for a bank API surface, which naturally spans accounts, statements, and payment operations. The server exposes a single read endpoint, so the count is an extreme mismatch for the apparent domain.
The surface covers only transaction retrieval; there is no way to list accounts, fetch a formal statement, or initiate/verify payments. Agents needing anything beyond a read of transactions will hit a dead end.