MCP Server for Natural Language Business Data Analytics

ramp · Finance · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Financial data analytics and business intelligence

Ramp wanted a natural-language analytics interface over business spend data without forcing users to learn API endpoints, dashboards, or SQL, while still handling large financial datasets safely and reliably.

Constraints:

• Directly exposing REST API results to an LLM caused miscalculations, context-window pressure, input-size limits, and high token usage.
• Reporting queries may involve large datasets and complex aggregations that can time out.
• The system handles sensitive business financial data, so credentials, scopes, and auditability matter.
• LLMs may choose incorrect tools or use tools inconsistently across conversations.
• Write-capable tools were too risky to release before a stronger safety framework existed.

Architecture

Ramp built an open-source MCP server with FastMCP that exposes Ramp developer API data as tools for Claude Desktop. The architecture evolved from direct API tools into a local SQL-oriented pipeline: load tools pull Ramp API data, process_data flattens and loads it into in-memory SQLite, execute_query runs SQL over the local table, and an OLAP-powered API handles reporting-scale extracts. Audit logging and constrained OAuth scopes bound the MCP client's access.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  Claude["Claude Desktop"] --> Server["Ramp MCP server"]
  Server --> API["Ramp developer API"]
  Server --> SQLite["In-memory SQLite database"]
  Server --> OLAP["OLAP-powered API"]
  Server --> Audit["Audit logging"]
  Server --> Scopes["OAuth scope controls"]
  Audit --> Scopes

Components

Data flow

Claude connects through an MCP client to Ramp's FastMCP server. The server calls Ramp developer APIs through load tools, transforms REST JSON into SQL rows with inferred types, stores the result in an in-memory SQLite database, and exposes execute_query so Claude can generate SQL instead of loading all raw events into context. For heavier reporting data, the MCP server can call an OLAP-powered API optimized by Ramp's data platform team.

Why this architecture

The SQL-centered design matched LLM strengths better than direct mathematical reasoning over raw API payloads. Keeping data local in SQLite reduced context and token pressure, while OLAP integration handled reporting-scale timeouts and OAuth/audit controls addressed financial-data risk.

Models used: Claude Desktop · LLMs with SQL generation capability

Scale

• The direct/pagination approach struggled beyond a few hundred transactions.
  “At first we hacked together a simple pagination tool to chunk responses into smaller, digestible parts, but we struggled to scale meaningfully beyond a few hundred transactions.”article, stated
• The SQL approach enabled analysis of tens of thousands of spend events.
  “After this move to a SQL-based paradigm, Claude went from struggling with a few hundred data points to accurately analyzing tens of thousands of spend events.”article, stated
• Reduced token usage made the MCP server usable even with the free Claude tier.
  “Thanks to the reduced token usage in this approach, Ramp MCP now even worked with the free version of Claude.”article, stated
• Very large businesses still create API latency and reliability pressure.
  “There's the occasional reliability issue, and API latency can be high for very large businesses with a lot of data.”article, stated

Alternatives considered (roads not taken)

Expose Ramp API endpoints directly as MCP tools

Rejected because: Direct API payloads worked for a small demo but caused math errors, context pressure, token cost, and input-size limits.

Paginate raw API responses into smaller chunks

Rejected because: Pagination made responses digestible but did not scale meaningfully beyond a few hundred transactions.

Use only local SQLite for reporting-heavy workloads

Rejected because: Reporting use cases produced complex, high-volume extracts that timed out, so Ramp added an OLAP-powered API.

Release write tools immediately

Rejected because: Ramp judged write operations unreliable enough that a safety framework should come first.

Patterns

tool-use-orchestration (tooling)

Ramp exposes load, processing, and query operations as MCP tools so Claude can orchestrate data extraction and analysis workflows.

context-engineering (context_management)

The team changed the interface so Claude could keep raw data out of its context window and ask the server/database to do heavy computation.

safety-policy-enforcement (control)

Financial-data access is bounded by audit logging, constrained OAuth scopes, least-privilege design, and delaying write tools until a safety framework exists.

observability-tracing (operations)

Developer API audit logs provide visibility into MCP access to sensitive business data.

Tradeoffs

Use SQL as the LLM-facing data interface

Chose In-memory SQLite and SQL query tools over Direct REST payload analysis by the model.

Rationale: SQL let the LLM express intent while minimizing raw context and moving computation to the database.

Keep a separate process_data step

Chose Load tools plus process_data plus execute_query over Skipping transformation to reduce roundtrips.

Rationale: The explicit processing step made API data queryable as SQL, though the authors note it could be skipped to reduce roundtrips.

Use OLAP integration for reporting workloads

Chose A reporting-optimized API from the data platform team over Only pulling raw operational API data into local SQLite.

Rationale: High-volume reporting use cases timed out, so the team reused enterprise analytics infrastructure optimized for those queries.

Delay agentic write operations

Chose Read/analysis use cases first over Immediate write tools that act on the business.

Rationale: The team viewed write tools as particularly unreliable and wanted a safety framework before letting the LLM perform business actions.

Gotchas (what bit them)

Raw API payloads pushed too much data and arithmetic into the model.

Root cause: The first MCP server design treated API endpoints as the interface instead of giving the model a queryable relational abstraction.

Resolution: Ramp flattened API JSON into SQLite rows and let Claude generate SQL while the database handled aggregation.

Simple pagination did not create meaningful scale.

Root cause: Chunking responses still forced the model to reason over many raw transaction fragments.

Resolution: The interface moved to predictable SQL data formats with server-side computation.

Reporting-scale API latency became the next bottleneck.

Root cause: Large business datasets and complex reporting queries caused tool calls and extracts to time out.

Resolution: Ramp added an OLAP-powered API for reporting-optimized spend extraction and named further optimizations such as concurrency, async pulls, caching, and DuckDB.

LLM tool selection was not deterministic enough to trust without safeguards.

Root cause: Claude sometimes chose incorrect tools or used the same prompt differently across conversations.

Resolution: The implementation used audit logs, OAuth scope limits, and delayed write tools pending a safety framework.

Evaluation

Ramp tested the MCP server with Claude Desktop against spend-analysis prompts, compared behavior before and after SQL/SQLite redesign, observed scaling and timeout failures, and used repeated-prompt behavior to identify tool-selection inconsistency.

Metrics: few hundred transactions before meaningful scaling broke down · tens of thousands of spend events after SQL redesign · input token usage reduction enough to work with free Claude · API latency and timeouts on very large businesses · same-prompt inconsistency across separate conversations

Outcomes

• Ramp released an open-source MCP server for natural-language access to business financial data.
• Claude could analyze tens of thousands of spend events after the SQL/SQLite redesign.
• The system supported curated spend views, cost-savings discovery, and business-hierarchy navigation.
• API latency, reliability, and write-tool safety remained open production constraints.
• Audit logging and constrained OAuth scopes were implemented to reduce financial-data access risk.

The article reports movement from a few hundred transactions to tens of thousands of spend events, plus use cases involving very large businesses with enough data to make API latency and tool timeouts central constraints.