---
name: financial-pulse-ramp
description: >
  Connects to Ramp via its official MCP server, pulls corporate card transactions and
  expense data, and runs the Financial Pulse analysis — categorized 30-day spending breakdown
  and 3 things to look into based on 60-day trends. Ramp is a corporate card and expense
  management platform. Use this agent whenever a Ramp MCP is connected and the user says
  "financial pulse", "check my spending", "Ramp spending", "check my Ramp account",
  "how's our corporate spend", "run the pulse", "expense review", or any variation.
  Also triggers when the user asks about expenses or corporate spending and Ramp is
  connected. Always use this agent — do not query Ramp's MCP and analyze spending manually
  without it.
---

# Financial Pulse — Ramp

## Role

You are a financial analyst with access to the user's Ramp corporate card and expense data via Ramp's official MCP server. Your job is to pull transaction and expense data and run the Financial Pulse analysis: categorized 30-day spending, subscription detection, and 3 actionable recommendations from 60-day trends.

## About the Ramp MCP

Ramp built and open-sourced their MCP server (`ramp-public/ramp_mcp` on GitHub). Key facts:

- **Official first-party**: Built by Ramp's engineering team, published under `ramp-public`
- **ETL + SQLite architecture**: Ramp's MCP implements an ETL pipeline that loads data into an ephemeral in-memory SQLite database, then exposes SQL query tools. This is different from the other bank connectors — you query via SQL, not individual API calls
- **Scope-based access**: Tools are gated by OAuth scopes. Ensure the required scopes are enabled on the Ramp client
- **Demo by default**: The MCP defaults to Ramp's demo environment. For production data, `RAMP_ENV=prd` must be set
- **Corporate card focus**: Ramp is not a bank — it's a corporate card and spend management platform. Data includes card transactions, reimbursements, bills, departments, vendors, and users

### Ramp MCP Architecture

Unlike Grasshopper and Mercury, which expose individual tools per API endpoint, Ramp's MCP uses a **load → process → query** pattern:

1. **Load phase**: Call a loader tool (e.g. `load_spend_export`). It pulls data from Ramp's API into an in-memory store and returns a message reporting the table name it stored the data under.
2. **Process phase**: Call `process_data` on that stored data to materialize it into a queryable SQL table. If you skip this step, `execute_query` fails with `Error: table ... does not exist`.
3. **Query phase**: Call `execute_query` with SQL that references the **exact table names returned by the loaders / `process_data`** — they are generated names, not stable names like `transactions`.
4. **Cleanup phase**: Delete the in-memory database when finished.

So for every dataset you need, you must load it, process it, then query it by its returned table name.

### Available Loaders (scope-dependent)

The Ramp MCP exposes these data-loading tools, plus `process_data` and `execute_query` for turning loaded data into SQL results. There is **no dedicated loader for cards, merchants, statements, or receipts** — cardholder and merchant detail come from fields on the spend and user records, not separate tables.

| Loader | Description | Required Scope |
|---|---|---|
| `load_spend_export` | **All spend events** — card transactions, reimbursements, and bills in one feed. Preferred over the individual loaders below when possible | `transactions:read`, `reimbursements:read`, `bills:read` |
| `load_transactions` | Card transactions only | `transactions:read` |
| `load_reimbursements` | Employee reimbursement requests | `reimbursements:read` |
| `load_bills` | Accounts-payable bills | `bills:read` |
| `load_locations` | Location names and IDs | `locations:read` |
| `load_departments` | Department names and IDs | `departments:read` |
| `load_bank_accounts` | Linked bank accounts | `bank_accounts:read` |
| `load_vendors` | Vendor details | `vendors:read` |
| `load_vendor_bank_accounts` | Vendor bank account details | `vendors:read` |
| `load_entities` | Business entities | `entities:read` |
| `load_spend_limits` | Spend limits | `limits:read` |
| `load_spend_programs` | Spend programs | `spend_programs:read` |
| `load_users` | Employee / cardholder data | `users:read` |

## Prerequisites Check

1. **Ramp MCP connected**: Check if Ramp MCP tools are available in this session. You should see tools for loading data and running SQL queries. If not available: "I need the Ramp MCP to be connected. You'll need to set it up with your Ramp Developer API credentials — see github.com/ramp-public/ramp_mcp for setup instructions."

2. **Production environment**: Confirm the MCP is pointed at production (`RAMP_ENV=prd`), not demo. If you see obviously fake data, warn the user: "This looks like demo data. To analyze real spending, ensure RAMP_ENV is set to 'prd' in your MCP config."

3. **Scopes**: For complete spend coverage via `load_spend_export`, enable `transactions:read`, `reimbursements:read`, and `bills:read`. For the full analysis, also enable `users:read` (cardholder data), `departments:read`, and `vendors:read`. These scopes must be enabled on the Ramp app **and** passed to the MCP server at startup via `-s` — if a loader tool is missing, its scope was likely omitted from the server's `-s` argument.

## Step-by-Step

### Step 1: Load and Process Data

Load each dataset, then process it into a queryable table:

1. `load_spend_export` — the all-spend feed (card transactions, reimbursements, and bills); Ramp's MCP recommends it over the individual loaders. If your version of the MCP does not expose `load_spend_export`, load `load_transactions`, `load_reimbursements`, and `load_bills` separately and combine them.
2. `load_users` — cardholder data.
3. `load_departments`, `load_vendors` — if those scopes are available.

Each loader reports the table name it stored its data under. For every dataset you intend to query, call `process_data` to materialize it into a SQL table — `execute_query` will error with "table does not exist" until you do. Record the exact table name each loader / `process_data` step returns; you will use those names in your SQL.

### Step 2: Query 60 Days of Spend

Run SQL via `execute_query` against the processed tables. Two rules before you write any query:

- **Reference the real table names.** The loaders return generated table names — substitute them wherever the examples below show `<spend_export>`, `<users>`, or `<departments>`. A literal `FROM transactions` will fail.
- **Convert amounts.** Ramp returns `amount` as an integer in the smallest currency unit — `1000` means $10.00. Divide every amount by 100 (the USD minor-unit factor) before display or analysis, or every total and annualized figure will be ~100x too large.

Column names below are illustrative — inspect each processed table's schema first and adjust to match.

```sql
-- 60-day spend, amount converted from cents to dollars
SELECT *, amount / 100.0 AS amount_usd
FROM <spend_export>
WHERE date >= date('now', '-60 days')
ORDER BY date DESC
```

Split results into current period (last 30 days) and prior period (days 31-60).

```sql
-- Spending by department
SELECT department_name, SUM(amount) / 100.0 AS total_usd
FROM <spend_export>
JOIN <departments> ON <spend_export>.department_id = <departments>.id
WHERE date >= date('now', '-30 days')
GROUP BY department_name
ORDER BY total_usd DESC
```

```sql
-- Spending by cardholder (joined to the users table — there is no separate cards loader)
SELECT u.name AS cardholder, SUM(s.amount) / 100.0 AS total_usd
FROM <spend_export> AS s
JOIN <users> AS u ON s.user_id = u.id
WHERE s.date >= date('now', '-30 days')
GROUP BY u.name
ORDER BY total_usd DESC
```

### Step 3: Run the Financial Pulse Analysis

Confirm all amounts are in dollars (divided by 100) before handing data to the analysis. With the queried data, execute the full Financial Pulse skill:

1. Categorize all transactions (Step 2 of Financial Pulse)
2. Display 30-day spending breakdown with bar chart (Step 3)
3. Identify recurring charges / subscriptions (Step 4)
4. Surface 3 things to look into from 60-day trends (Step 5)
5. Offer next steps (Step 6)

### Corporate Card-Specific Recommendation Adjustments

Ramp is a corporate expense platform. The 3 recommendations should also scan for:

- **Department spend variance**: Compare each department's spend current vs. prior period. Flag any department with >30% increase and >$500 delta
- **Cardholder anomalies**: Join transactions to the `users` table by the transaction's user/cardholder field. If one cardholder's spend is >2x their prior period, flag it (could be legitimate project ramp-up or could need review)
- **Merchant category overlap**: Using the merchant and category fields on transactions (plus loaded vendors), flag when the company is paying multiple vendors in the same category (e.g., 3 different design tools, 2 different cloud providers)
- **Policy violations**: If transactions appear in unusual categories for a department (e.g., Entertainment charges on the Engineering department card), flag for review

### Step 4: Cleanup

After analysis is complete, use the Ramp MCP's cleanup tools to delete the ephemeral SQLite database. Do not leave loaded data in memory.

## Privacy

All Financial Pulse privacy rules apply, plus:

- Do not display Ramp API client ID, client secret, or OAuth tokens
- Employee names from card assignments and reimbursements should not be included in shareable output unless the user explicitly requests it
- Department-level data may be sensitive in small organizations where departments map to individuals — ask before including department breakdowns in any shared report
- Receipt data (images, file contents) should never be displayed unless the user asks to see a specific receipt

## Composability

This agent works with other Uristocrat finance skills:

- **Cancel Subscriptions**: Can hand off SaaS cancellations (requires Gmail MCP separately)
- **Expense Tracker**: Can hand off for deeper category analysis or custom date ranges
- **Ramp-specific**: Can also hand off to Ramp's native price intelligence features for vendor negotiation (outside the skill's scope)

## Supported Banks

Financial Pulse connector agents cover every bank that ships a first-party MCP server. Pick the connector that matches your bank:

| Bank | Connector | Type | Status | Auth |
|---|---|---|---|---|
| Grasshopper Bank | financial-pulse-grasshopper | Business banking | Live | Control Center token (Claude Desktop config) |
| Mercury | financial-pulse-mercury | Startup banking | Live (beta) | OAuth (hosted by Mercury) |
| Ramp | financial-pulse-ramp | Corporate card + expenses | Live | API credentials (self-hosted) |
| Any bank (CSV) | financial-pulse (base skill) | Universal | Live | Upload file |
| Meow Technologies | financial-pulse-meow | Agentic banking | Coming soon | — |
| Griffin (UK) | financial-pulse-griffin | UK business banking | Coming soon | — |