Fintech Data MCP Server — AI for Fintech Lab

The Problem

An LLM has no access to your internal data. You can paste records into a prompt, but that does not scale, goes stale immediately, and puts sensitive information into a context window with no control.

MCP solves this by letting the model call tools you define. The model decides when it needs data, calls the tool, and receives a structured response. You control exactly which queries exist and what they return.

This project implements that pattern for a common fintech scenario: looking up a customer across three separate systems, credit score, preapproved limit, and risk profile, and returning a consolidated view. The synthetic data is there so it runs immediately. The architecture is what you keep.

What It Delivers

Five tools

Three individual lookups, one consolidated profile, and a health check. Each takes a customer id and returns structured data.

Any database

Built on SQLAlchemy. Swapping SQLite for Postgres, MySQL or SQL Server means changing a connection string, not the code.

Any schema

A single mapping file declares which physical table and column corresponds to each logical field. Adapting to a real database is configuration, not refactoring.

Read only by design

Write statements are rejected at the application layer, including chained ones, and every result set is capped by a configured row limit.

Key Terms

MCP

Model Context Protocol. A standard for exposing tools that any compatible LLM client can discover and call.

stdio transport

The client starts the server as a subprocess and communicates through standard input and output. No port, no deployment, nothing running permanently.

Schema mapping

The declaration of which physical table and column in your database corresponds to each field the tools expose.

Layered Architecture

Fig. 1 · Data layer generates and connects, access layer queries and validates, MCP layer exposes tools over stdio. The LLM lives in the client, not in the server.

Key Decisions

Predefined queries over text to SQL

The server exposes a fixed set of parameterized queries. The model chooses which one to call, never what SQL to run. Text to SQL against a production financial database is a risk no institution accepts, and it removes any guarantee about what the model can reach.

Raw data, no business logic

Tools return what the tables hold. Eligibility rules, risk thresholds and approval criteria differ at every institution, so embedding them would make the template opinionated and less reusable.

Read only enforced twice

The application layer rejects any statement containing a write keyword. The database user should be read only as well. The first catches mistakes, the second catches everything else.

Independent layers

Swapping the database touches only the connection. Adding a table touches only the mapping, repository and schemas. Replacing MCP with another protocol touches only the tools and server. Nothing cascades.

Synthetic data generated, not committed

The generator produces internally consistent records: a low score drives a high default probability, which in turn blocks a limit increase. Running it produces a working database in seconds, and nothing sensitive lives in the repository.

Repository

mcp-001-fintech-data-server github.com →

mcp-001-fintech-data-server/
├── README.md
├── requirements.txt
├── .env.example
├── .gitignore
├── config/
│ ├── __init__.py
│ └── mcp_config.py
├── src/
│ ├── __init__.py
│ ├── data_generator.py
│ ├── database.py
│ ├── schema_mapping.py
│ ├── repository.py
│ ├── schemas.py
│ ├── server.py
│ └── demo.py
└── data/
└── fintech.db

Stack: MCP Python SDK, SQLAlchemy, Pydantic, pandas, numpy. Python 3.13. The README includes a five step deploy guide covering how to point the server at a real database, map an existing schema, and connect it to Claude Desktop or any MCP compatible client.