This server provides read-only access to your Monzo bank account via 7 tools, with full OAuth support and a local SQLite transaction cache.
List Accounts (monzo_list_accounts): View all Monzo accounts (personal/joint), including IDs and open/closed status.
Check Balance (monzo_get_balance): Get the current balance and today's spend for a personal or joint account.
View Pots (monzo_list_pots): See all savings pots and their balances for a given account type.
Sync Transactions (monzo_sync): Pull transactions, balances, and pot data from the live Monzo API into a local SQLite cache — supports up to ~11 months of history within the SCA window, or 90 days otherwise.
List Transactions (monzo_list_transactions): Browse and filter cached transactions by date range, category, merchant, or account type (auto-syncs if cache is stale).
Search Transactions (monzo_search_transactions): Search cached transactions by merchant name, description, or notes using case-insensitive partial matching.
Spending Analysis (monzo_spending): Analyse spending for a given month with category breakdowns, with an option to drill into individual transactions.
Key characteristics:
🔒 Zero write operations — cannot send money or modify any financial data
🔄 Automatic OAuth token refresh — no manual token management needed
💾 Persistent local cache — SQLite database preserves transaction history beyond Monzo's 90-day API limit
Provides read-only access to Monzo banking data including accounts, balances, savings pots, and transaction history. Enables spending analysis with category breakdowns and merchant analytics, with automatic synchronization to a local cache for persistent access beyond Monzo's 90-day SCA window.
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., "@monzo-mcp how much did I spend on groceries last month?"
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 the Monzo banking API. Read-only access to accounts, balances, pots, transactions, and spending analysis - all through Claude Code or any MCP client.
Unlike other Monzo MCP implementations that use raw bearer tokens (which expire in 6 hours), this server handles full OAuth with automatic token refresh.
7 read-only tools - no write operations, no money movement
OAuth with auto-refresh - tokens refresh automatically, no manual regeneration
Local transaction cache - SQLite database survives Monzo's 90-day SCA window
Auto-sync on demand - the cache-reading tools run an incremental sync automatically if the cache wasn't synced today, so you rarely need to call monzo_sync by hand
Spending analysis - category breakdowns, top merchants, month-over-month comparison
Transaction search - search by merchant, payee (counterparty), description, or notes across cached history
Counterparty details - bank transfers (faster payments, p2p, Bacs) are cached with the payee's name, sort code, and account number
Related MCP server: monzo-mcp
Tool | Description | Data source |
| List accounts with types and IDs | Live API |
| Current balance and spend today | Live API |
| Savings pots and balances | Live API |
| Sync transactions to local cache | Live API -> SQLite |
| List/filter cached transactions | Local cache (auto-syncs if stale) |
| Search by merchant/payee/description/notes | Local cache (auto-syncs if stale) |
| Spending analysis with category breakdown | Local cache (auto-syncs if stale) |
Python 3.13+ (tested on 3.13 and 3.14, on Linux, macOS and Windows, in CI)
uv (recommended) or pip
A Monzo account with an OAuth client registered at 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 .This package is not on PyPI - the name belongs to an unrelated project. A container image is published instead; see Docker.
Go to developers.monzo.com and create an OAuth client:
Set the redirect URL to http://localhost:6600/callback
Note your Client ID and Client Secret
monzo-mcp authThis opens your browser for Monzo OAuth. After authorizing, approve the login in your Monzo app within 5 minutes for full transaction history access (Monzo's SCA window).
claude mcp add -s user monzo -- /path/to/monzo-mcp/.venv/bin/monzo-mcpOn Windows the console script is at .venv\Scripts\monzo-mcp.exe.
In Claude Code, run monzo_sync to populate the local transaction cache. Do this immediately after auth to take advantage of the SCA window (up to 11 months of history).
Images are published to ghcr.io/partymola/monzo-mcp. Tags carry a v prefix (:vX.Y.Z), and :latest follows the most recent release.
The container needs a volume. Credentials and the transaction cache live under /data; with nothing mounted there, the container still starts and every tool reports that it is not configured, and anything you authorise is lost as soon as the container is replaced.
First register an OAuth client as described in Setup step 1 - auth prompts for the Client ID and secret, and there is no way to supply them later. The redirect URL is http://localhost:6600/callback, the same as a source install.
Authenticate once, into a named volume. Decide before you run this whether you want a bind mount instead - switching afterwards means authorising again:
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 authThe published port is needed only for this step, so the OAuth redirect can reach the container. Binding it to 127.0.0.1 keeps the callback listener off your network. No browser opens - the container has none - so copy the URL it prints. Then approve the login in your Monzo app within 5 minutes (see Monzo SCA window).
Then register the server, reusing the same volume:
claude mcp add -s user monzo -- \
docker run --rm -i -v monzo-mcp-data:/data ghcr.io/partymola/monzo-mcp:latest-i is required - the server speaks JSON-RPC over stdin and stdout.
Sync straight away. The 11-month backfill closes 5 minutes after you approve in the Monzo app (see Monzo SCA window), and this route is longer than a source install - so call monzo_sync as soon as the server is registered. Miss it and you silently get 90 days instead, with no error.
To keep the files somewhere you can read them, use a bind mount instead of a named volume. The container runs as root and writes credentials owner-only, so without --user they end up root-owned:
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 authPass the same -v and --user to the server command. Create the directory first - --user against a named volume fails, because the volume initialises root-owned from the image.
monzo-mcp Start the MCP server (stdio transport)
monzo-mcp auth Interactive OAuth setup (opens the browser)
monzo-mcp --version Print the installed package versionAll configuration is via environment variables (optional):
Variable | Default | Description |
|
| Directory for OAuth credentials and tokens |
|
| Path to SQLite transaction cache |
|
| Interface the |
The container image sets the first two under /data, because the package-relative defaults resolve into the interpreter's lib directory there, which cannot be mounted. It sets the third to 0.0.0.0, because a published port arrives on the container's bridge interface and a localhost bind refuses it.
Credential files (created by monzo-mcp auth):
config/monzo_client.json - OAuth client ID and secret
config/monzo_tokens.json - Access and refresh tokens (auto-refreshed)
Monzo's Strong Customer Authentication (SCA) limits transaction history access:
Within 5 minutes of app approval: up to ~11 months of history
After the window expires: only the last 90 days
The local SQLite cache preserves all synced transactions permanently, so run monzo_sync promptly after monzo-mcp auth.
To backfill a specific range, pass since to monzo_sync - an ISO date (2026-01-01) or datetime (2026-01-01T14:30:00Z). Reaching back more than ~90 days only works inside the SCA window; outside it, only the last 90 days are returned.
Older cached transactions gain fields added in newer versions (e.g. counterparty/payee details on bank transfers) only when re-fetched, which a post-auth full sync does for the history it re-pulls.
Zero write tools - cannot send money, move funds between pots, or modify transactions
Monzo API itself cannot send money to external accounts
Tokens stored as JSON files in the config/ directory (gitignored)
All API calls are GET requests with Bearer token auth
"SCA required" or only 90 days of history - re-run monzo-mcp auth and approve the login in the Monzo app within 5 minutes, then sync straight away (see the SCA window above).
Token expired / no refresh - re-run monzo-mcp auth to re-authorise.
"No transaction data available" - the cache is empty; call monzo_sync (or any cache-reading tool, which auto-syncs) once after authenticating.
Every tool reports "not configured" under Docker, or authentication does not survive a restart - nothing is mounted at /data. See Docker; the same volume must be passed to the auth run and to the server.
auth sits on "Waiting for callback..." after you approve - the callback was not delivered. Press Ctrl-C and run it again. Under Docker, check the port is published (-p 127.0.0.1:6600:6600).
See CONTRIBUTING.md for development setup, the test workflow, and the pre-commit hook. Changes are tracked in CHANGELOG.md.
GPL-3.0-or-later. See 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.
Query your real net worth, spending, transactions, budgets and portfolio from any MCP client.
