The reason a finance question is painful over an API is that the answer spans more rows than a conversation can hold. Loading the dataset into an in-memory database first makes the question a query — and the database goes away with the session.
A Ramp Developer API client with an ETL step in front of it. Rather than returning API pages into the conversation, the load tools pull a dataset into an ephemeral in-memory SQLite database, which you then query with SQL — that is how it gets around token and input size limits.
- Transactions, reimbursements and bills loaded for analysis
- Vendors and vendor bank accounts, users, departments, locations, entities and bank accounts
- Spend limits and spend programs
- Ramp categories and currencies fetched directly, for when a lookup is all you need
- An ephemeral in-memory database: data processed into it, queried with SQL, and tables cleared when you are done
Uv, and a Ramp client with client credentials enabled — its id and secret go on the launch command. Each load tool needs its own read scope granted on the client and passed as a CLI argument. Requests go to the demo environment unless you switch it to prd. Large datasets may not be processable within API and client limits.
One command plus a key — uvx ramp-mcp, then supply credentials
