MCP-сервер для банковского API Monzo. Доступ только на чтение к счетам, балансам, копилкам, транзакциям и анализу расходов — всё через Claude Code или любой MCP-клиент.
В отличие от других реализаций Monzo MCP, которые используют сырые bearer-токены (срок действия которых истекает через 6 часов), этот сервер поддерживает полный OAuth с автоматическим обновлением токенов.
7 инструментов только для чтения — без записывающих операций и движения денег
OAuth с автообновлением — токены обновляются автоматически, без ручной перегенерации
Локальный кэш транзакций — база SQLite переживает 90-дневное окно SCA Monzo
Автосинхронизация по требованию — инструменты чтения кэша автоматически выполняют инкрементальную синхронизацию, если кэш не синхронизировался сегодня, поэтому вызывать monzo_sync вручную почти не приходится
Анализ расходов — разбивка по категориям, топ продавцов, сравнение месяц к месяцу
Поиск по транзакциям — поиск по продавцу, получателю (контрагенту), описанию или заметкам в кэшированной истории
Данные контрагентов — банковские переводы (faster payments, p2p, Bacs) кэшируются с именем получателя, sort code и номером счёта
Related MCP server: monzo-mcp
Инструмент | Описание | Источник данных |
| Список счетов с типами и ID | API в реальном времени |
| Текущий баланс и траты за сегодня | API в реальном времени |
| Копилки и балансы | API в реальном времени |
| Синхронизация транзакций в локальный кэш | API в реальном времени -> SQLite |
| Список/фильтр кэшированных транзакций | Локальный кэш (автосинхронизация при устаревании) |
| Поиск по продавцу/получателю/описанию/заметкам | Локальный кэш (автосинхронизация при устаревании) |
| Анализ расходов с разбивкой по категориям | Локальный кэш (автосинхронизация при устаревании) |
Python 3.13+
uv (рекомендуется) или pip
Учётная запись Monzo с OAuth-клиентом, зарегистрированным на developers.monzo.com
git clone https://github.com/partymola/monzo-mcp.git
cd monzo-mcp
uv venv --python 3.13 .venv
uv pip install -e .Этот пакет отсутствует на PyPI — это имя принадлежит другому, не связанному проекту. Вместо этого публикуется образ контейнера; см. Docker.
Перейдите на developers.monzo.com и создайте OAuth-клиент:
Укажите redirect URL http://localhost:6600/callback
Запишите свои Client ID и Client Secret
monzo-mcp authОткроется браузер для OAuth Monzo. После авторизации подтвердите вход в приложении Monzo в течение 5 минут, чтобы получить полный доступ к истории транзакций (окно SCA Monzo).
claude mcp add -s user monzo -- /path/to/monzo-mcp/.venv/bin/monzo-mcpВ Windows консольный скрипт находится в .venv\Scripts\monzo-mcp.exe.
В Claude Code выполните monzo_sync, чтобы заполнить локальный кэш транзакций. Сделайте это сразу после аутентификации, чтобы воспользоваться окном SCA (до 11 месяцев истории).
Образы публикуются в ghcr.io/partymola/monzo-mcp. Теги имеют префикс v (:vX.Y.Z), а :latest соответствует последнему релизу.
Контейнеру нужен том. Учётные данные и кэш транзакций находятся в /data; если туда ничего не смонтировано, контейнер всё равно запустится, каждый инструмент будет сообщать, что он не настроен, а всё, что вы авторизуете, будет потеряно при замене контейнера.
Сначала зарегистрируйте OAuth-клиент, как описано в шаге 1 настройки — auth запросит Client ID и секрет, и позже их никак не указать. Redirect URL — http://localhost:6600/callback, как и при установке из исходников.
Выполните аутентификацию один раз, в именованный том. Решите до запуска, не нужен ли вам bind mount вместо него; переключение позже означает повторную авторизацию:
docker volume create monzo-mcp-data
docker run --rm -it \
-v monzo-mcp-data:/data \
-p 127.0.0.1:6600:6600 \
ghcr.io/partymola/monzo-mcp:latest authОпубликованный порт нужен только для этого шага, чтобы OAuth-redirect мог достичь контейнера. Привязка к 127.0.0.1 не выводит слушатель callback в вашу сеть. Браузер не откроется — в контейнере его нет — поэтому скопируйте URL, который он выведет. Затем подтвердите вход в приложении Monzo в течение 5 минут (см. окно SCA Monzo).
Затем зарегистрируйте сервер, переиспользуя тот же том:
claude mcp add -s user monzo -- \
docker run --rm -i -v monzo-mcp-data:/data ghcr.io/partymola/monzo-mcp:latest-i обязателен — сервер общается по JSON-RPC через stdin и stdout.
Синхронизируйтесь немедленно. Заполнение истории за 11 месяцев закрывается через 5 минут после подтверждения в приложении Monzo (см. окно SCA Monzo), а этот путь длиннее, чем установка из исходников, — поэтому вызывайте monzo_sync, как только сервер зарегистрирован. Если упустить этот момент, вы молча получите только 90 дней, без ошибок.
Чтобы хранить файлы там, где вы сможете их читать, используйте bind mount вместо именованного тома. Контейнер работает от root и записывает учётные данные с правами только владельца, поэтому без --user они окажутся принадлежащими root:
mkdir -p ~/monzo-mcp-data/config
docker run --rm -it \
-v ~/monzo-mcp-data:/data \
--user $(id -u):$(id -g) \
-p 127.0.0.1:6600:6600 \
ghcr.io/partymola/monzo-mcp:latest authПередайте те же -v и --user команде сервера. Сначала создайте каталог — --user с именованным томом не сработает, потому что том инициализируется как принадлежащий root из образа.
monzo-mcp Start the MCP server (stdio transport)
monzo-mcp auth Interactive OAuth setup (opens the browser)
monzo-mcp --version Print the installed package versionВся настройка выполняется через переменные окружения (необязательно):
Переменная | По умолчанию | Описание |
|
| Каталог для учётных данных OAuth и токенов |
|
| Путь к SQLite-кэшу транзакций |
|
| Интерфейс, к которому привязывается callback-сервер |
Образ контейнера задаёт первые две переменные в /data, потому что относительные к пакету значения по умолчанию там разрешаются в каталог lib интерпретатора, который нельзя смонтировать. Третью он задаёт как 0.0.0.0, потому что опубликованный порт приходит на bridge-интерфейс контейнера, и привязка к localhost отклоняет его.
Файлы учётных данных (создаются командой monzo-mcp auth):
config/monzo_client.json — OAuth Client ID и секрет
config/monzo_tokens.json — токены доступа и обновления (автоматически обновляются)
Строгая аутентификация клиента (SCA) Monzo ограничивает доступ к истории транзакций:
В течение 5 минут после подтверждения в приложении: до ~11 месяцев истории
После истечения окна: только последние 90 дней
Локальный SQLite-кэш сохраняет все синхронизированные транзакции навсегда, поэтому запускайте monzo_sync сразу после monzo-mcp auth.
Чтобы заполнить конкретный диапазон, передайте since в monzo_sync — ISO-дату (2026-01-01) или datetime (2026-01-01T14:30:00Z). Запрос глубже, чем ~90 дней, работает только внутри окна SCA; за его пределами возвращаются только последние 90 дней.
Более старые кэшированные транзакции получают поля, добавленные в новых версиях (например, данные контрагента/получателя по банковским переводам), только при повторной загрузке; полная синхронизация после аутентификации делает это для истории, которую она перезагружает.
Ноль записывающих инструментов — нельзя отправлять деньги, перемещать средства между копилками или изменять транзакции
Сам API Monzo не может отправлять деньги на внешние счета
Токены хранятся в виде JSON-файлов в каталоге config/ (в gitignore)
Все вызовы API — это GET-запросы с авторизацией через Bearer-токен
«SCA required» или только 90 дней истории — повторно запустите monzo-mcp auth и подтвердите вход в приложении Monzo в течение 5 минут, затем сразу синхронизируйтесь (см. окно SCA выше).
Срок действия токена истёк / нет обновления — повторно запустите monzo-mcp auth, чтобы авторизоваться заново.
«No transaction data available» — кэш пуст; один раз после аутентификации вызовите monzo_sync (или любой инструмент чтения кэша, который делает автосинхронизацию).
В Docker каждый инструмент сообщает «not configured», или аутентификация не переживает перезапуск — в /data ничего не смонтировано. См. Docker; один и тот же том должен быть передан и запуску auth, и серверу.
auth зависает на «Waiting for callback...» после подтверждения — callback не доставлен. Нажмите Ctrl-C и запустите снова. В Docker проверьте, что порт опубликован (-p 127.0.0.1:6600:6600).
См. CONTRIBUTING.md — настройка разработки, рабочий процесс тестирования и pre-commit хук. Изменения отслеживаются в CHANGELOG.md.
GPL-3.0-or-later. См. LICENSE.
Get current balance for a Monzo account.
Args: account_type: "personal" or "joint" (default: "personal")
Returns balance, spend today, and currency. Also records a balance snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| account_type | No | personal |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully discloses return fields and a side effect: 'Also records a balance snapshot.' However, it omits details about authorization, whether the balance is live/cached, or consequences of the snapshot, leaving material ambiguity for a side-effecting read tool.
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 compact, front-loaded with the core action, and structured into Args and Returns sections. Every sentence earns its place and there is no filler.
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 single-parameter tool with an output schema, the description is mostly sufficient to invoke correctly. It covers the parameter, the return, and a side effect. However, it lacks usage context and enough detail about the snapshot side effect to feel fully 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 description restates the only parameter and its allowed values, which are already present in the schema as an enum with a default. It provides no deeper meaning about what distinguishes personal from joint or how selection works, so it only partially compensates for the absence of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get current balance for a Monzo account.' This clearly distinguishes it from siblings like monzo_list_transactions, monzo_list_accounts, and monzo_spending.
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 when-to-use or when-not-to-use guidance is provided. It mentions the account_type default but does not explain how to choose between personal and joint, nor does it point to an alternative sibling for cases where a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Monzo accounts with their types and IDs.
Returns account details including whether each is personal or joint, and whether it is open or closed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present. The description states it returns account details, but does not explicitly confirm it is read-only or disclose potential side effects. For a simple list, default behavior is assumed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with purpose and key return details.
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 zero-parameter list tool with an output schema, the description sufficiently explains what is returned (type and status), making it 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?
Zero parameters: schema coverage is 100% trivially, and the description adds no param info (as none needed). Baseline of 4 is appropriate per rubric.
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 verb 'List' and resource 'Monzo accounts', specifying returned details (type, status) that distinguish it from siblings like transaction or balance tools.
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 when-to-use or alternatives are provided. Usage is implied from context, but the description lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all pots (savings buckets) for a Monzo account.
Args: account_type: "personal" or "joint" (default: "personal")
Returns the account the pots belong to, plus pot names and balances. Also records balance snapshots.
| Name | Required | Description | Default |
|---|---|---|---|
| account_type | No | personal |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses what the tool returns (account, pot names, balances) and notes an important side effect: "Also records balance snapshots." It does not discuss authentication or rate limits, but for a simple list tool the disclosure is 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?
The description is compact and well-structured: purpose comes first, followed by the single argument, then return behavior and side effect. Every sentence earns its place and there is no extraneous content.
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 optional parameter and an output schema, the description covers purpose, argument semantics, return contents, and the snapshot side effect. Nothing an agent needs to invoke it correctly is missing.
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 description restates the schema's enum and default values for account_type without adding deeper meaning, such as when to choose personal versus joint. Since it is the only optional parameter and the schema already defines it clearly, this is sufficient but not additive.
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 specific verb and resource: "List all pots (savings buckets) for a Monzo account." This clearly distinguishes the tool from the sibling tools, none of which target pots, and the parenthetical clarifies the domain-specific term.
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 gives clear context on what the tool does and documents the account_type choice of personal or joint. It does not explicitly name alternatives or exclusions, but no sibling tool overlaps with listing pots, so the guidance is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List transactions from the local cache.
Auto-syncs if the cache is stale (last sync before today).
Queries the synced transaction database, not the live API. Bank transfers
(faster payments, p2p, bacs) include a counterparty object with the payee
name and, where the scheme provides them, sort code and account number.
Returns {"account_type": ..., "transactions": [...]}, where account_type
echoes the filter applied and is null when unfiltered.
Args: account_type: "personal" or "joint" (default: all) since: Start date, e.g. "2026-01-01" (inclusive) before: End date, e.g. "2026-02-01" (exclusive) category: Exact category match, e.g. "groceries", "eating_out", "transport" merchant: Merchant name search (case-insensitive, partial match) limit: Max results (default 50)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ||
| before | No | ||
| category | No | ||
| merchant | No | ||
| account_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden, and it discloses the most important behaviors: cached-not-live data access, the auto-sync side effect with its staleness threshold, the counterparty enrichment for bank transfers, and the shape of the response envelope. It stops short of a 5 because it does not state what happens if the auto-sync fails (stale data served? error?) or whether results are paginated beyond the limit.
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 dense but well-organized: purpose front-loaded in the first line, followed by the cache/sync behavior, the counterparty caveat, the return envelope, and a clean Args block. Every sentence earns its place, and the parameter documentation is scannable rather than prose-heavy.
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 that an output schema exists, the description is not obligated to explain return values in detail, yet it still provides the top-level envelope. All six optional parameters are fully documented, and the tool's complexity is moderate. The only material gap is failure behavior during the auto-sync path and the absence of pagination semantics, which keeps this from a 5.
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 0%, so the description must document the parameters itself — and it does, exhaustively and with added meaning. It specifies inclusive/exclusive semantics for since/before, exact-match semantics for category, case-insensitive partial-match semantics for merchant, allowed values plus default for account_type, and the max-results behavior for limit, all with concrete examples. This fully compensates for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first line — 'List transactions from the local cache' — pairs a specific verb (list) with a specific resource (transactions) and a scope qualifier (local cache), immediately distinguishing it from siblings such as monzo_get_balance, monzo_list_pots, and monzo_search_transactions. The follow-up 'not the live API' further sharpens the boundary, making the tool's identity 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 gives clear context for when the tool is appropriate: it reads from the synced database rather than the live API, and it 'auto-syncs if the cache is stale (last sync before today)', which tells an agent when a prior sync step is unnecessary. It does not explicitly name an alternative tool for cases where live or search-level data is required (e.g., monzo_sync or monzo_search_transactions), so the when-not guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search cached transactions by merchant, counterparty (payee), description, or notes.
Auto-syncs if the cache is stale (last sync before today).
Case-insensitive partial match across merchant_name, counterparty_name, description, and notes fields. Counterparty matching finds bank transfers (faster payments, p2p, bacs) by payee name.
Returns {"account_type": ..., "transactions": [...]}, where account_type
echoes the filter applied and is null when unfiltered.
Args: query: Search term account_type: "personal" or "joint" (default: all) since: Start date, e.g. "2026-01-01" (inclusive) before: End date, e.g. "2026-02-01" (exclusive) limit: Max results (default 30)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| since | No | ||
| before | No | ||
| account_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses case-insensitive partial matching, the exact fields searched, counterparty behavior for bank transfers, cache auto-sync behavior, and the response shape. This is unusually transparent for a search tool.
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 purpose is front-loaded in the first sentence, followed by compact, high-value behavioral details and a clean Args list. Every sentence adds information; there is no redundant filler.
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 five parameters and no annotations, the description covers search matching, cache staleness behavior, date-range semantics, account filtering, result limits, and the returned JSON shape. Nothing essential is missing for an agent to select and invoke it 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 input schema has 0% description coverage, but the description lists every parameter with meaningful detail: query semantics, account_type values, since/before inclusivity with examples, and the limit default. This fully compensates for the schema gap.
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?
Opens with a specific verb-resource pair: 'Search cached transactions by merchant, counterparty (payee), description, or notes.' This clearly distinguishes it from sibling tools like monzo_list_transactions or monzo_sync by focusing on search across cached transaction fields.
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?
Gives clear usage context: search by named fields, with automatic sync when the cache is stale ('last sync before today'). It stops short of explicitly naming alternatives or saying when not to use the tool, but the intended scenarios are easy to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyse spending from cached Monzo transactions.
Auto-syncs if the cache is stale (last sync before today).
Every result carries account_type, echoing the filter applied and null
when unfiltered, so a zero total says which account it measured.
Args: month: Month in YYYY-MM format (default: current month) category: Filter by category, e.g. "groceries", "eating_out", "transport" account_type: "personal" or "joint" (default: all) detail: If true, return individual transactions instead of category summary
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | ||
| detail | No | ||
| category | No | ||
| account_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the auto-sync side effect, the output behavior (account_type echo, null when unfiltered), and the detail switch affecting the return format. This goes beyond the schema and provides useful context, though it does not mention potential side effects like rate limits or error handling. The disclosure is substantial and does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear summary sentence, a brief note on caching, an explanation of output behavior, and a concise Args list. It is front-loaded with the core purpose, and every sentence adds value. It is appropriately sized for a tool with four parameters and behavioral nuances, with no redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, caching behavior, output characteristics, and all parameter semantics. It does not explicitly detail the return schema, but an output schema is available, so that is acceptable. It lacks explicit guidance on when to use this versus siblings, but the purpose is clear enough. Overall, it is nearly complete for an analysis tool, with only minor gaps.
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 0%, so the description must compensate. The Args section provides format (YYYY-MM for month), examples (category values), default behavior (current month, all accounts), and the effect of detail (individual transactions vs summary). This adds rich meaning beyond the bare schema titles and types, fully satisfying the requirement.
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 opens with 'Analyse spending from cached Monzo transactions,' which states a specific verb (analyse), a resource (spending from Monzo transactions), and the caching behavior. This clearly distinguishes it from siblings like monzo_list_transactions (which would list raw transactions) and monzo_get_balance (which reads a balance). The 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?
The description explains what the tool does and mentions auto-sync when the cache is stale, but it does not explicitly state when to prefer this tool over alternatives like monzo_search_transactions or monzo_list_transactions. The usage context is implied by the purpose (spending analysis) but not directly contrasted with siblings, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sync transactions, balances, and pots from the Monzo API into the local cache.
Fetches up to 11 months of history (within SCA window) or falls back to the last-synced timestamp / 90 days. Handles pagination and auth-hold deduplication automatically.
Args: account_type: "personal", "joint", or None to sync all accounts since: Optional ISO date ("2026-01-01") or datetime ("2026-01-01T14:30:00Z") to start the backfill from, overriding last-sync resumption. Reaching beyond ~90 days only works inside the post-auth SCA window.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | ||
| account_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently covers the 11-month fetch window, the fallback to last-synced timestamp or 90 days, automatic pagination, auth-hold deduplication, and the SCA constraint on deep backfills. It does not address side effects on the local cache or auth prerequisites in detail, but it is substantially transparent.
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 well-structured with a purpose statement, a behavior summary, and a clear parameter list. Every sentence adds substantive value, and the most important constraints are front-loaded. There is no redundant restatement of schema 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?
The description is complete for a tool with two optional parameters and an output schema. It explains what the tool fetches, the sync window behavior, pagination/deduplication, parameter semantics, and edge cases around the SCA window. Return values are reasonably covered by the output schema, so no extra explanation is needed.
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 0%, so the description must compensate, and it does. It explains account_type values ('personal', 'joint', or None to sync all accounts') and gives precise since formats (ISO date or datetime) plus its override behavior and SCA limitation. This goes well beyond the bare 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 states a specific verb ('Sync') and resource ('transactions, balances, and pots from the Monzo API into the local cache'), clearly distinguishing it from sibling read/list/search tools. It also adds concrete scope details like history depth, pagination, and deduplication.
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 for refreshing or backfilling a local cache, but it does not explicitly state when to prefer this over sibling tools like monzo_list_transactions or monzo_search_transactions. It gives helpful context around backfill windows and last-sync resumption, but no exclusions or alternative routing.
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.
v0.9.0monzo_get_balance1 field changedInput schema / properties / account_type / enumAdded value: +[
+ "personal",
+ "joint"
+]monzo_list_pots1 field changedInput schema / properties / account_type / enumAdded value: +[
+ "personal",
+ "joint"
+]monzo_list_transactions1 field changedInput schema / properties / account_type / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "personal",
+ "joint"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]monzo_search_transactions1 field changedInput schema / properties / account_type / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "personal",
+ "joint"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]monzo_spending1 field changedInput schema / properties / account_type / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "personal",
+ "joint"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]monzo_sync1 field changedInput schema / properties / account_type / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "personal",
+ "joint"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]v0.2.1monzo_sync1 field changedInput schema / properties / sinceAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Since"
+}v0.1.0monzo_get_balancemonzo_list_accountsmonzo_list_potsmonzo_list_transactionsmonzo_search_transactionsmonzo_spendingmonzo_syncScored across 7 tools
Tools are mostly distinct, but monzo_search_transactions and monzo_list_transactions both query cached transactions, differing mainly in search vs filter semantics; users could confuse which to use. Spending analysis is distinct as it provides aggregated insights.
All tools follow the monzo_ prefix with snake_case and mostly verb_noun pattern (get_balance, list_pots, search_transactions). However, 'monzo_sync' lacks a noun and 'monzo_spending' uses a noun as the action, deviating slightly from the pattern.
Seven tools is well-scoped for a personal finance MCP covering balance, pots, accounts, transactions, and spending analysis. Each tool serves a clear purpose without redundancy.
Covers core read-only banking operations: balance, accounts, pots, transaction listing/search, spending analysis, and data synchronization. Missing features like pot transfers or transaction details by ID, but these are beyond typical read-only scope.
Read-only bank & investment accounts via Plaid: balances, holdings, transactions, SQL analytics.
Read-only access to your bank, investment, and crypto accounts: balances, transactions, holdings.
Chat with your bank data: balances, transactions, budgets, bills. Reads only, never moves money.
Read-only Lunch Money accounts, transactions, categories and budgets. Unofficial connector.
