Wealth Finder MCP: Designing a Financial AI Workflow with Human Approval

Wealth Finder began as a four-day prototype for Wealthsimple's AI Builders application. The useful result was not another financial chatbot. It was a working Model Context Protocol integration that gave an AI assistant a small, explicit set of financial tools while keeping consequential actions behind human approval.

The project is a proof of concept, not production financial infrastructure. It uses synthetic Canadian account data for a fictional user, Claude Desktop as the interface, Supabase PostgreSQL as the data layer, and ten purpose-built MCP tools.

Start with the decision boundary

The first concept was a standalone chat interface where users could ask questions about spending, debt, and registered accounts. That approach introduced a broad surface: authentication, account aggregation, conversational UX, compliance, data security, and financial-advice boundaries.

For a four-day prototype, that scope would have hidden the most important product question: what should the AI be allowed to read, draft, and change?

The project therefore focused on the intelligence layer. The Model Context Protocol provided a structured way for Claude Desktop to discover and call defined tools. The protocol handled the connection. The product design defined the permissions and approval path.

Ten tools instead of open-ended account access

The public Wealth Finder MCP repository exposes ten tools for focused tasks such as:

• Summarizing accounts and spending categories.
• Reviewing bills and possible anomalies.
• Auditing subscriptions against transaction activity.
• Calculating interest paid.
• Drafting spending alerts and complaint records.

The dataset is synthetic and seeded locally. Investment execution and production banking integrations are intentionally outside the scope.

This tool surface makes the system easier to inspect than a general database connection. Each action has a defined input and output, and write operations can enforce their own approval requirements.

Human approval belongs in the tool workflow

Every consequential write follows a two-stage pattern. The assistant first prepares a draft. The user reviews it. The action is recorded only after explicit confirmation.

That pattern appears in the spending-alert and complaint flows. It is not a prompt asking the model to behave carefully. It is part of how the tools are designed.

Human approval does not make a financial workflow automatically safe or compliant. Production use would still require identity controls, authorization, audit history, privacy safeguards, regulatory review, and integration with authoritative systems. The proof of concept demonstrates one useful boundary: a model can help interpret information and prepare an action without receiving unrestricted authority to execute it.

Three workflows tested the product idea

The spending workflow compares category activity across periods, lets the user inspect relevant transactions, and prepares a monthly alert for confirmation.

The bill-review workflow identifies an unusual charge in the synthetic dataset and drafts a complaint containing the amount, dates, and explanation. The prototype writes the confirmed complaint to its own database rather than contacting a telecommunications provider.

The subscription workflow compares a recurring subscription with transaction history and flags it when no corresponding activity appears during the review period. The value is not the arithmetic. It is connecting several records into a useful explanation.

Together, the workflows test a broader product pattern: read structured data, surface a finding, prepare a bounded action, and keep the user responsible for the final decision.

What the four-day constraint revealed

The compressed timeline forced several useful decisions:

• Synthetic data was enough to evaluate the workflow without exposing real financial records.
• Specific tools produced clearer boundaries than a broad assistant with database access.
• Prompt templates made the demonstration more repeatable, but they were a prototype constraint rather than the desired long-term experience.
• Approval needed to remain explicit even if future orchestration became more flexible.
• Product and regulatory questions had to shape the architecture before implementation.

The broader concept included cross-product analysis across savings goals, debt, emergency funds, and Canadian registered accounts such as TFSAs, RRSPs, and FHSAs. That concept remained design work. It was not implemented in the public prototype.

Where this pattern can be useful

The same interaction model can support other workflows involving complex records and consequential decisions: insurance, healthcare administration, legal operations, human resources, or internal approvals. The domain controls and evidence requirements change, but the core design question remains: what can the assistant inspect or prepare, and what still requires accountable human confirmation?

Wealth Finder shows how Lab829 approaches that question through product framing, scoped tools, implementation, and explicit limits. It also connects directly to our broader work on MCP workflow design and applied AI systems.

If your team is considering an AI workflow around sensitive or structured data, explore AI and machine learning integrations or start a conversation with Lab829.