Connect Claude to Ramp

List card transactions, newest first by default. This is the main spend feed: each row carries the merchant, the amount and currency, the card and cardholder, the accounting categorisation and the approval and sync state. Narrow it with from_date and to_date before anything else - a busy account has thousands of rows a month, and `page_size` caps one response rather than the query. `state` is the transaction's lifecycle (PENDING is authorised but not settled, CLEARED has settled, DECLINED never went through), which is not the same question as `sync_status`, the accounting export state. Ids returned here are what get_transaction takes.

Fetch one transaction by id, with its full accounting categorisation, line items, receipts, policy violations and approval chain - more than the listing returns for each row. Ids come from list_transactions. Set include_merchant_data to add what Ramp knows about the merchant itself.

List virtual cards with each one's display name, cardholder, spending restrictions, state and last four digits. Ramp splits cards into two resources rather than one, so this is half the card estate and list_physical_cards is the other half. Full card numbers are never returned by this route and this connector exposes no operation that returns them. Creating, editing, suspending and terminating cards are all deliberately absent.

List physical cards - the plastic people carry - with cardholder, display name, activation state and last four digits. The other half of the card estate; list_virtual_cards covers the rest. Full card numbers are never returned here.

Fetch one virtual card by id, with its spending restrictions, the spend limit it draws on, its cardholder and its state. Ids come from list_virtual_cards, or from the card_id on a transaction. The full card number lives behind Ramp's separate vault route, which this connector does not expose.

List the people on the Ramp account with their name, email, role, department, location and status. Use it to turn a name into the user_id that list_transactions, list_virtual_cards and list_reimbursements filter on. This returns a staff directory, so it is not the health check.

Fetch one person by id, with their role, manager, department, location and status. Ids come from list_users or from the user_id on a transaction or a card.

List the departments configured on the account, with their ids and names. This is org structure rather than anybody's data, which is why it is the health check: it is the cheapest call that proves the client credentials, the scopes and the account all line up, and it returns no personal information while doing it. The ids are what list_users and list_transactions filter on.

List the locations configured on the account, with their ids and names. Org structure, like list_departments, and the source of the location_id that list_users and list_transactions filter on.

List out-of-pocket expense reimbursements with the person who claimed, the amount, the merchant, the memo and the approval and payment state. Narrow with from_date and to_date. `direction` separates money owed to a person (BUSINESS_TO_USER) from money a person owes back (USER_TO_BUSINESS). Nothing here approves, pays or rejects a claim - those routes exist in Ramp's API and are deliberately not exposed.

List accounts-payable bills with the vendor, the invoice number, the amount, the due date and the payment and approval state. Narrow by due date with from_due_date and to_due_date, or by issue date with from_issued_date and to_issued_date. `payment_status` is OPEN or PAID; `approval_status` is the separate question of whether anyone has signed it off. Paying, holding and releasing a bill are all routes Ramp offers and this connector does not.

Fetch one spend limit by id: its name, the cards drawing on it, its members, its restrictions and its cleared, pending and total balance. Ramp now calls these funds and the route is /funds/{fund_id}, which is why an id from Ramp's own interface still works here. Reading a limit does not change it - creating, editing, suspending and terminating one all move real spending authority and are not exposed by this connector at all.