Overview
What Satchel MCP is, the MVP honesty principle, and how sandbox and live modes relate.
What Satchel MCP is
Satchel MCP connects permitted Satchel account data to an MCP-capable assistant that speaks MCP — Claude, Claude Code, Cursor, Codex, or any other MCP client. You can ask your assistant: "What did I spend on subscriptions this month?" or "How much do we hold across all accounts?" — and it reads your accounts and answers in plain language.
It ships in two parts:
- an MCP server (
mcp/) that is a faithful client of the real Satchel / FintechLab Client Office ("mobile") API — the same endpoints, the same DTO shapes, the same auth flow used in production; - a landing page (
app/) that onboards people into a live-shaped sandbox in under a sandbox and records a request for reviewed live access.
The MVP honesty principle
Real integration surface, sandbox data.
The public default is sandbox mode. The MCP server points at a local sandbox that replays responses in the exact DTO shapes of the real Client Office API — same field names, same enums, same auth flow. Nothing about the client code changes when you go from sandbox to live; only three environment variables do (base URL, credentials, mode — see Getting started and Configuration).
This matters because it means:
- what you build and test against the sandbox is what runs against the real API — there is no separate "demo mode" code path to diverge or rot;
- a sandbox signup is a technically-validated, self-selected lead for the live product, not a synthetic marketing funnel;
- the known, deliberate simplifications in the sandbox are documented, not hidden.
Sandbox → live, by reviewed environment configuration
| Sandbox (default) | Live | |
|---|---|---|
| Target | Local in-memory sandbox (app/api/sandbox/*) | The real FintechLab Client Office API (UAT) |
| Auth | Sandbox API key (demo@satchel.mcp / satchel-demo-key, or a waitlist-issued key) | Real Client Office credentials |
| Data | Seeded, fictional — accounts, cards, ~35–40 transactions | Real account data |
| Writes | satchel_move_money mutates sandbox balances, if enabled | Refuses unless explicitly enabled — see Authentication & security |
| Code changes required | — | None. Reviewed environment, client-policy and credential configuration. |
Two distinct live paths exist, at different levels of trust:
- Local stdio, pointed at live. Set
SATCHEL_MODE=liveplus the live base URL and credentials in the environment of a locally-run stdio MCP server (see Getting started). This is a direct, unmediated client of the real API — you supply your own live credentials. - The hosted remote MCP server. A closed, invite-only pilot with a stricter flow: OAuth consent in the browser, no password retention, an allowlist, a kill switch, and audit logging. Only the six read tools are exposed there — see Authentication & security.
The 7 tools, in one line each
| Tool | What it does |
|---|---|
satchel_list_accounts | List accounts: name, masked identifier, balance. |
satchel_get_balance | Total balance across accounts, grouped by currency, plus per-account breakdown. |
satchel_list_cards | List cards, masked, with status. |
satchel_list_transactions | Recent transactions, paginated. |
satchel_get_transaction | Detail on one transaction; optional narrative data needs its own scope. |
satchel_financial_summary | Money in/out and net change; merchant heuristics need the optional narrative scope. |
satchel_move_money | Transfer between your own accounts — off by default, everywhere. |
See the full MCP tools reference for parameters, output shapes, and the
satchel_ naming convention.
Where to go next
- New to this? Start with Getting started and connect an assistant to the synthetic sandbox.
- Building against the tools programmatically? Read the MCP tools reference.
- Curious how the pieces fit together, or what "the swagger wins" means? See Architecture.
- Evaluating this for real account access? Read Authentication & security first.